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

[Ben Steele]

MED isn't going to solve this problem.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Christian Koch
Sent: Monday, 15 September 2008 9:01 AM
To: Tomas Hlavacek
Cc: cisco-nsp at 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
<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/
_______________________________________________
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/