MED isn't going to solve this problem. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Koch Sent: Monday, 15 September 2008 9:01 AM To: Tomas Hlavacek Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] separation of transit, peerings and this-AS traffic (long)
use meds On Sun, Sep 14, 2008 at 5:48 PM, Tomas Hlavacek <[EMAIL PROTECTED]> wrote: > Greetings! > > I am thinking about a scenario, which is maybe quite common, but I do not > know how to make that work. > > Say that an AS1 is receiving full BGP table from multiple upstreams, for > example AS100 and AS200. AS1 has a customer, say AS2. There is one Ethernet > physical connection between border routers of AS1 and AS2. AS2 is paying to > AS1 for upstream and receives full BGP feed. AS1 has another customer AS3, > paying for upstream also. Besides that AS1 and AS2 has a peering via some > IX. AS2 is stub, so it is announcing only prefixes with as-path ^2$. AS1 is > announcing ^1$ and ^1 3$ prefixes to its peers in the IX. AS1 preferres > paths via IX by local-preferrence. > > The point is how to make packets traveling from upstreams of AS1 to AS2 not > to take path via IX, but via direct Ethernet connection while traffic > originating in AS1 and traffic from AS3 traveling trough AS1 take path via > IX? > > I have two ideas: > > 1) policy based routing, bind some route-map to AS1's upstream-facing > interfaces and set ip next-hop or set interface... But it does not scale > well of course. > > 2) put transit neighbors (upstream and customers also) into vrf, for > example: > > ip vrf transit > rd 1:100 > export map EXPORT_ALL > import map IMPORT_ALL > ! > router bgp 1 > network 1.1.1.0 mask 255.255.255.0 > neighbor 2.2.2.1 remote-as 2 > neighbor 2.2.2.1 route-map SET_IX_LOCPREF in > neighbor 2.2.2.1 filter-list 1 > ! > address-family ipv4 vrf transit > neighbor 1.1.0.1 remote-as 100 > neighbor 1.1.0.1 route-map SET_TRANSIT_LOCPREF in > neighbor 1.1.0.1 description UPSTREAM1 > neighbor 1.1.0.2 remote-as 200 > neighbor 1.1.0.2 route-map SET_TRANSIT_LOCPREF in > neighbor 1.1.0.2 description UPSTREAM2 > neighbor 2.2.2.2 remote-as 2 > neighbor 2.2.2.2 route-map SET_TRANSIT_LOCPREF in > neighbor 2.2.2.2 description CUSTOMER AS2 > neighbor 3.3.3.1 remote-as 3 > neighbor 3.3.3.1 route-map SET_TRANSIT_LOCPREF in > neighbor 3.3.3.1 description CUSTOMER AS3 > ! > ! > route-map SET_IX_LOCPREF permit 10 > set local-preference 200 > ! > route-map SET_TRANSIT_LOCPREF permit 10 > set local-preference 100 > ! > route-map EXPORT_ALL permit 10 > ! > route-map IMPORT_ALL permit 10 > ! > > I spent few hours in lab experimenting with this configuration. I am using > old Cisco 1600, so there is possibility that issues I had could come from > some bug in this EoL platform... For reference, I used IOS (tm) 1600 > Software (C1600-SY-M), Version 12.2(37) RELEASE SOFTWARE (fc1) for > experiments. Problems: > > 1) routes in vrf transit are learned to into vrf routing table and are > announced in both directions from AS100 to AS2 and AS3 and vice-versa, as > expected. But routes from vrf transit are not exported into global routing > table nor imported from global into vrf. I tried everything (I put some > prefix- or access-list to match ip address clause in IMPORT_ALL and > EXPORT_ALL maps,...), but nothing appeared in the global table. It should be > some misconfiguration over there but I do not see that. Any help would be > appreciated. > > 2) Let's assume that the import and export works, so I have all transit > routes in my global table and route 1.1.1.0/24 inside vrf transit (this is a > route originated in AS2). Those routes are therefore in fact duplicated... > Is there any mechanism or chance to overcome that? Something like default > route in global table pointing into transit VRF and triggering one extra > routing decission inside VRF? Or is the duplication somehow optimized and it > won't be any problem even for full BGP table? (O course I mean full table on > real routers... 7200 or 7600.) > > Is there any best-practice or common approach to that? Maybe something > completly different which I am not aware of? > > Tomas > > -- > Tomáš Hlaváček <[EMAIL PROTECTED]> > > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/