Justin Shore wrote:
Core:
....
!
address-family vpnv4
neighbor ibgp-peer send-community extended
neighbor 10.64.0.34 activate
exit-address-family
I added the last activate for grins but it didn't help. peer-groups are
auto-activated which is why it's not explicitly spelled out in the vpn4
statement.
DC:
....
neighbor 10.64.0.20 peer-group ibgp-peer
neighbor 10.64.0.20 description iBGP to 7613-2.clr (65001)
!
address-family vpnv4
neighbor ibgp-peer send-community extended
exit-address-family
So I did a little more playing around and found that if I added an vpnv4
activate on the DC #2 router for core #2's IP I got my vpnv4 routes. I
only got those connected to core #2 though. I had to add another
activate for core #1. I'm assuming that core #2 sent those BGP routes
that it learned via iBGP from core #1 to DC #2 because of the RR config.
Since I'm eliminating the iBGP RR config I have to complete the full
mesh to get the full set of routes. That makes sense.
One thing that doesn't make sense at this point is why the ibgp-peer
peer-group config in the vpnv4 address-family wasn't sufficient enough
to enable the learning of vpnv4 routes. Do peer-groups and vpnv4 config
not mix? Trying to add the command "neighbor aaa.bbb.ccc.ddd
send-community extendeded" to any of the routers involved (where
aaa.bbb.ccc.ddd is a configured member of a peer-group) results in the
error:
% Invalid command for a peer-group member
To me that implies that some sort of interaction exists between vpnv4
config and peer-group config. Can anyone add any input to this?
Thanks
Justin
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
