On 2012-12-13, at 9:23 AM, Phil Mayers <[email protected]> wrote:
> On 13/12/12 14:15, Jason Lixfeld wrote: >> >> On 2012-12-13, at 4:29 AM, Adam Vitkovsky <[email protected]> wrote: >> >>> Using common RD in a vrf is asking for trouble if route-reflection is used. >>> >>> Let's say you have two PEs advertising default for vrf inet -if you use RRs >>> to spread the routes throughout the backbone -RRs will only advertise one >>> (best path)default route to all PEs. >>> Now with unique RD per PE RRs will consider default form each PE as a unique >>> route sending both to all PEs. >>> Than you are ready for fast convergence. >>> adam >> >> Hold on, are you saying that within a single VRF, you can actually use more >> than one RD? > > Yes. In fact, that's *required* if you want to do multi-path. I seem to do multi-path just fine with maximum-paths ibgp 2 on my RR clients inside a VRF that sees a default sourced from two different RRs. Said VRF has a common RD between the two PEs. How is that different? > route target controls what gets "into" a VRF. RD is just a unique value that > prefixes the route. It can be completely different. That's what I thought. So I don't understand what the benefit would be to have PE'centric RDs if the ultimate goal is to treat the prefixes exactly the same way you'd treat prefixes if they weren't inside a VRF at all and were all just floating around in the global table; just like before all the L3VPN kung-fu started making sense. > FWIW we use the convention of: > > xxx:N > > ...where N is the last octet of the routers loopback, so the RD is different > on each router. > > There are differing opinions about the wisdom of this strategy - see here, > for example: > > http://blog.ioshints.info/2012/07/bgp-route-replication-in-mplsvpn-pe.html Thanks for this! I've been looking around for some good documentation sources. Clearly I need some subject matter edjamacation. > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
