6PE without PHP

[ksriram29]

Hi All,

I need some info on the following 6PE scenario.

The 6PE rfc states that second label must be used. Though I understand the above condition in a penultimate hop popping scenario, I am not clear about it when PHP is not involved.

When PHP is not involved the 6PE router will be receiving packets with two labels (top label corresponding to IPv4 LSP and the bottom label corresponding to IPv6 prefix). How will the packet be processed by the 6PE router?

Will the 6PE router do the following?

1. pop the top label

2. inspect the bottom label

3. pop the bottom label

4. forward the unlabeled packet to the

destination?

Are there any additional configuration involved in this?

Thanks in advance.

Cheers,

Sriram K

[mheusing]

Hi Sriram,

Your description is correct.

Usually the top label points to the BGP next hop, which in 6PE usually is the IPv4 address of the Loopback of the egress PE. The default is to allocate implicit null for it resulting in PHP and the egress PE will forward the packet based on the bottom label.

If you do not want to use PHP you can configure a PE to allocate an explicit null label to the directly connected networks including the BGP next hop address.

Then the penultimate LSR will send bottom label plus explicit null. The egress PE will remove the explicit null label and forward the packet based on the bottom label.

So with PHP there is one label lookup less than without PHP, but forwarding is not changed, because ultimately in both cases it is based on the bottom label (usually assigned to the IPv6 prefix).

The only configuration required is to enforce the allocation of the explicit null label, which is done with the command:

Router(config)#mpls ldp explicit-null

A detailed description of the command with all the options can be found for example at

http://www.cisco.com/en/US/docs/ios/12_3/switch/command/reference/swi_m2.html#wp1076838

Hope this helps! Please use the rating system.

Regards,

Martin

[ksriram29]

Thank you very much for the replies. That was very helpful.

So, I believe the last hop label must be either implicit null or explicit null. Any other label value in the last hop will not work, since the egress 6PE will be forwarding a labeled (IPv6 prefix label) packet to the CE, after popping the top label in case of non-null label value.

Is my understanding correct?

Cheers,

Sriram K

[Harold Ritter]

Srikram,

In the case the PHP doesn't take place, the explicit-null will be popped by the egress PE and the second label will be used to forward the packet. The packet is not forward to the CE with a label.

The PHP happens by default. Any specific reason you don't want it to take place?

Regards

[ksriram29]

Harold,

Thanks for your reply.

My doubt is, if the PHP doesn't take place and the top label is not a explicit-null label (e.g. label value = 30), will the 6PE router still be popping the top label (with value = 30) and look in to the next label (label corresponding to the IPv6 prefix), pop it and forward the packet to the CE?

There is no specific reason, but just to understand the scenario. Will there be such a scenario?

Thanks,

Sriram

[Harold Ritter]

Sriram,

If PHP doesn't take place it necessarily means that the top label is an explicit-null. The scenario you are describing is not valid unless of a software bug, which is beyond the scope of this discussion.

Regards

[ksriram29]

Thanks Harold. That was very helpful.

[Mohamed Sobair]

Hi,

when PHP is not involved, the 6PE has to perform 3 Lookups, one for the BGP next hop (IGP label) and the second for the IPv6 Prefix. the 3rd lookup is performed on CEF table in order to forward unlabeled packet to the destination.

HTH

Mohamed

[Harold Ritter]

Hi Mohamed,

What you are describing is in fact the legacy behavior. We used to allocate aggregate labels out of a limited pool of labels for each ipv6 prefixes, which would force an IPv6 lookup on the egress PE.

In recent IOS versions, we allocate a non-aggregate label for each IPv6 prefix, which causes 6PE packets to be label switched even on the egress PE. This is basically the same behavior you get with MPLS VPN.

Regards