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

[Tomas Hlavacek]

Hello Christian,

thanks for reply! Maybe I do not see some obvious solution with MED...

The point is, that I need to route traffic from all of my upstreams to 
my customer AS2 via one path and any other traffic from my AS or from my 
other customers via another path facing AS2 too. So the problem is not 
which of two routes with the same prefix and different next-hops should 
be installed into routing table - that is, what the MED solves, AFAIK. 
The problem is how to use concurrently on a one single box two routes 
with the same prefix and different next-hops and select which of routes 
is to be used based on where the traffic comes from (not src IP address 
but interface).

Tomas

Christian Koch wrote:
> use meds
>
> On Sun, Sep 14, 2008 at 5:48 PM, Tomas Hlavacek
> <tomas.hlavacek at elfove.cz> 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 <tomas.hlavacek at elfove.cz>
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>     

-- 
Tomáš Hlaváček <tomas.hlavacek at elfove.cz>