[c-nsp] MPLS VPN aggregate label / route lookup

[Oliver Boehmer (oboehmer)]

Peter Rathlev <> wrote on Tuesday, June 17, 2008 4:33 PM:

> 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

did you test this in the lab? A simple "redistribute connected" and a
change of the vlan netmask works just as well.. but as you're using
network statements, the above sounds ok.

> 
> 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?

It doesn't matter in your case (see below), but a Null0 static creates
an aggregate vpn label, so the PE will pop it and perform another
lookup, using the connected prefix in your scenario.

> If it makes any difference, 

It makes one :)

> 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.

Yes.

And actually: As you're dealing with a "connected" prefix, connected
routes also trigger an aggregate prefix label (as the PE might need to
ARP for the next-hop). So even if you didn't use per-vrf labels, it
would still work.

> 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? 

Can I take a look at the config (unicast, if you prefer)?

	oli