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

[Christian Koch]

my apologies, i seem to have read through your original to quickly

2008/9/14 Tomas Hlavacek <tomas.hlavacek at elfove.cz>:
> 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>
>
>