[c-nsp] separation of transit, peerings and this-AS traffic (long)

Tomas Hlavacek tomas.hlavacek at elfove.cz
Sun Sep 14 17:48:45 EDT 2008


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 <tomas.hlavacek at elfove.cz>



More information about the cisco-nsp mailing list