Pokemon Gold Silver Trade Vba

What to do with harmful more specific routes

There's an old problem:
client announces / 23 upstream and the same grid as the two / 24, IX (for example, UA-IX). The result is that traffic comes from the world upstream on / 23, and then the client is already on / 24 (more specific) through IX. As a result, the client receives the external traffic through IX, with no speed limits, accounting, etc.

issue in detail investigated and described Ginsburg here , and give a solution for JunOS (for which many thanks to him). Therefore, I can only tell their own words, lead configuration for Cisco, and to describe other, less accurate and more simple solutions.

Firstly, just want to say that the administration to tackle the problem unpromising. The client can this be done without malice. In the end, nothing illegal, he does not.

first thing that comes to mind for the protection of from this situation - the imposition of IX to a separate router. Customers who have their own inclusion in the IX, made by "external" router, which just announced by IX no. Drawbacks: firstly, the client may want to reserve access to that IX, secondly, the client should switch to another router if it is connected to IX, in the third place, the client may not be included in the IX, but some client of the client - to be in the fourth, different IX may be several (KH-IX, UA-IX, DE-CIX, etc .), and it is unclear as their share of routers. Actually, the traffic from the IX is a "bonus" for the upstream, which is denied, providing the client paid only IPT-traffic апстриму, очевидно, невыгодно. Вместо отдельных роутеров, разумеется, можно использовать разные vrf в пределах одного роутера. Ещё вариант - строить с клиентами two BGP-session "peace" and "Ukraine" (in other words, IPT, and IX). If IX is only one solution to completely work, though, and creates some inconvenience for customers.

second option - To filter traffic on a router, which goes from upstream to IX. More specifically, from the upstream and peering links of the traffic should go only to customers, and all that goes out on the upstream or peering, start dropping. The disadvantage is that the client in this case simply did not work, causing his displeasure. In addition, upstream and peering can be incorporated into different routers, and in this case, the filtering interface receives more difficult.

solution proposed Ginsburg, the most correct, although not always easy to implement. Namely: to have two routing tables, one only clients, and in another - fullview. Traffic from upstream and peering is being routed to the first table of customers - for the second. In this case, traffic from upstream will take on a client, even if from the IX is more specific route. It does not require a lot of memory, because the client routes is relatively small. A small additional modification: make another routing table, which there is only client prefixes and fallback to the complete table, if the route is not found, and the table used for routing traffic from clients. In this case, traffic from one customer goes to another client, even if there are more specific to IX. Disadvantage: in case of multiple routers decision on where the package is being routed, should be taken immediately at the entrance to the package in our network. That is, it is suitable for MPLS-networks and for networks with a single "external" router, but not very suitable for the rest. However, not hopeless: if external links are included in the different routers, then you can either mark traffic, or build internal links so as to always was unambiguously clear whether upstream traffic from the client or vice versa.

Example configuration with different routing tables for JunOS is at Ginsburg. For Cisco is roughly the same, using vrf. Derived from the upstream traffic in zarulivaetsya vrf through PBR (more elegant solutions are not invent). Checked and ISR (3825, 7200) and 6500 (12.2 (33) SXI) - works. In some cases, the NO-LOCAL to add traffic to its own IP, otherwise the behavior of the receiving country. Configuration changes BGP не требуется.

 
ip vrf upstreams
 rd xx:yy
 import ipv4 unicast map IMPORT-UPSTREAMS
!
interface GigabitEthernet0/1.100
 description Upstream
 encapsulation dot1Q 100
 ip address 4.1.1.1 255.255.255.252
 ip policy route-map FROM-UPSTREAM
!
route-map FROM-UPSTREAM permit 10
 match ip address NO-LOCAL
 set vrf upstreams
!
route-map IMPORT-UPSTREAMS permit 10
 match community CLIENTS
!
route-map IMPORT-UPSTREAMS permit 20
 match community FROM-IGP
!
route-map IMPORT-UPSTREAMS deny 30
!
ip access-list extended NO-LOCAL
 deny   ospf any any
 permit ip any any
!
 

UPD: Возможные грабли. Up to a 1000 prefixes will be imported by default. The prefix-limit argument is used to specify a limit from 1 to 2,147,483,647 prefixes. That is, if the client prefixes may be more than 1000 (including as a result of erroneous stuffing customer something extra) better in line import ipv4 unicast explicitly known to a sufficient number of imported prefixes.