Hi, We're about to change the netmask of an interface which is part of an MPLS L3 VPN. During preparation we've been wondering about how this would affect connectivity to the net. It's 6500/Sup720/12.2SXF, and the configuration looks something like this:
ip vrf A rd 64512:1 route-target both 64512:1 ! interface Vlan123 ip vrf forwarding A ip address 10.0.0.1 255.255.255.128 ! router bgp 64512 address-family ipv4 vrf A network 10.0.0.0 mask 255.255.255.128 ! ! We want to change Vlan123 from 10.0.0.1/25 to 10.0.0.1/24, and we'd like to do it without any connectivity loss. The plan would be something like: - Add "ip route vrf A 10.0.0.0 255.255.255.0 Null0 250" - Add "network 10.0.0.0 mask 255.255.255.0" to MP-BGP - Wait for the new prefix to be visible all over the network - Change Vlan123 to 10.0.0.1/24 - Clean up The question is: When the routers build a Null adjacency for the /24 network, will they just throw the traffic away upon receiving the tagged traffic from the core? Or will they perform a lookup in the local RIB/FIB and see that the connected /24 net has a better admin distance than the Null route, even though it was that latter that the label was built for? If it makes any difference, the VRF only takes up a single aggregate label in the TIB: R1#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface <cut> 36 Aggregate vrf:A 155825439 <cut> R1# If this means the PFC will look at the FIB after VPN label popping then all should be fine. On another note: We have other PEs that build "full" mpls forwarding-tables, including all local prefixes, but the one in question only has aggregate labels for the VRFs. It's neighbor at the POP has ~3800 label assigned, this one only has ~50, and they hold the same VRFs and the same prefixes. They should be configured the same way. Can anybody point at how I can find out what makes this one use aggregates? Thanks, Peter _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
