Internet in VRF



> Nice that’s clever.

> And since you are using CSR1000v you don’t need to worry about the

> cost of HW for RRs.


Yes, the CSR1000v’s are workhorses.



> I see, so RRs do the routing decision on behalf of the PE routers in a

> particular PoP.


Correct, but in some cases, the routing decision is done in a completely different country/continent/cluster, before that final decision is pushed down to the RR which has the target edge router. Either way, the result is always the same, since the destination traffic was headed toward that different country/continent anyway.



> Since RR cluster is local to the PoP the AS-exit proximity is

> accurate, in other words what is good for the RR has to be good for

> the PEs within the PoP.


Yes, and this is a very important point that you note. Having iBGP sessions to RR’s not in the same physical PoP can lead to sub-optimal routing for devices in that PoP, as by default, RR’s base best-path selection for IGP metrics on the local IGP metric, while the iBGP neighbor would be remote.


BGP-ORR, covered in “draft-ietf-idr-bgp-optimal-route-reflection-09”, is trying to fix this. But I don’t know of anyone shipping code yet.



> But still you’d have to use add-path to advertise backup paths from

> RRs to PEs in a local PoP whereas with MP-BGP you’d just use unique RDs.


You might find it strange but I do neither :-).


Each cluster has 2x RR’s. Each iBGP client has 2x sessions to each RR for all address families.


Based on our hardware, we’ve modeled convergence performance for BGP routing and found it to be reasonably quick across the network.

Considering the additonal overhead Add-Paths and such would bring, it has been a calculated decision to keep things simple, and rely on Next-Hop Address Tracking tech. in Cisco and Juniper to speed up convergence. BFD for IS-IS has also been very helpful, as we’ve found BGP to be a lot more stable in a steady-state.


We are still watching this, and will decide if physically installing additional paths is a good idea. For now, it’s not hurting overall network performance.




> I see it as more of a good practice not to hold default route or full

> inet table on a peering box but as I said before peer pointing a

> default at you is rather a corner case I guess.


Hehe, depends. Some folk point default toward you at peering points because they don’t know better. Others do because they are chancers.

Either way, avoid the risk.


We have dedicated peering routers in each PoP. We carry neither a full table nor a default route on those. In fact, we null-route default routes on every peering box.





> Yeah been doing EoMPLS PW to provide full internet feed to customers

> behind MEs didn’t have the confidence to use the table-map/SRD šŸ™‚


You should try BGP-SD, works great over here :-).


Tunnels or eBGP-Multihop is too much for me for passing full feeds to customers :-).