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

[Ben Steele]

The main reason I didn't like the sound of PBR was me thinking you have a service provider style network with quite a large internal routing infrastructure having to work this on a hop by hop basis, if it's just one box connecting everything then pbr with verify next hop will do the job.

-----Original Message-----
From: Tomas Hlavacek [mailto:tomas.hlavacek at elfove.cz] 
Sent: Monday, 15 September 2008 9:07 AM
To: Ben Steele; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] separation of transit, peerings and this-AS traffic (long)

Hello Ben and all,

thanks for reply. First thing is that I am only trying to set up a 
proof-of-concept using small old boxes which are not doing MPLS at all. 
In my lab scenario one box stays for one AS.

When it comes to deployment of the solution - whatever it is - to my 
real network, it will be all done by a single 7600, which has connected 
upstreams, peerings and customers into one single box. In real life my 
network will stay for AS2.

As I am new to MPLS (I only did several labs and read theory) I could be 
wrong, but I think that sice I have only one box involved, I have only 
one RIB and so I can not use your solution now.

And yes, you are right. I don't like solution with policy based routing 
despite that I know how to achive what I need using PBR. But I am scared 
by eventual future expanding of PBR for more customers and more sites.

Tomas

Ben Steele wrote:
> Is your network MPLS enabled? You could do TE from your bdr of YOUR upstreams to your PE that connects to AS1 and set a bgp weight (not local pref) on that router to prefer the directly connected Ethernet bgp peer, this solution will also give you some redundancy in should the TE tunnel go down or the bgp relationship over the ethernet it will just take the natural path of the IX.
>
> More static options like policy route-maps and static routing next hops etc have the consequence of leaving your neighbour with a broken network in the event of a failure through that policy, sure you can add sla tracking to your next hop but you mentioned scalability etc. So you don't want to be configuring ip sla all over the place and route-maps.
>
> Ben
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tomas Hlavacek
> Sent: Monday, 15 September 2008 7:19 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] separation of transit, peerings and this-AS traffic (long)
>
> 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>