Peter Rathlev wrote:
Core #2 doesn't have "route-reflector-client" configured towards the new router, so it only sends it's own prefixes and prefixes from any RR clients of it's own. That seems to make sense to me too.
It does now that I've thought about it. With iBGP not forwarding on updates it learns from other iBGP speakers, the only way I was receiving the routes in the existing environment was with the RR config. That makes sense. So now I'm building a full mesh between all the speakers. I haven't done a great deal of RR work so I always have to stop and research RRs when I work with them. I was pretty sure that I couldn't pull an eBGP confederation speaker off of the RR client which is why I was pushing everything back towards the full mesh.
AFAIK you always have to activate the specific peers in the VPNv4 configuration for VPNv4 functionality. I.e. : VPNv4 and IPv4 mixes fine, but the activation is seperated so you can run some IPv4 only peers, some VPNv4 only peers and some mixed peers.
That's good to know. I assumed that the I could make the change en mass by using the peer-group but adding individual activations will work too. That's probably a good thing so I can be more flexible with my peer-group use.
Thanks for the input Justin _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
