[c-nsp] Internet in VRF

[Mark Tinka]

On 5/May/15 12:13, Adam Vitkovsky wrote:
>
>
> 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 :-).

Mark.