MPLS VPN 'Hairpin'

Answered Question
Jun 26th, 2007

Hi

I am trying to understand if an MPLS 'hairpin' could occur when the egress PE router strips the VRF label and determines that the next hop is back into the MPLS cloud.

Does the PE re-apply the new labels and forward back along the LSP, or does it drop the packet?

kind regards

Graeme

Correct Answer by mheusing about 9 years 7 months ago

Hi,

The LFIB/CEF table will determine the forwarding action. Thus, if a VPN label points out a specific interface towards a CE, the packet will be forwarded out that interface by CEF. There will be NO additional IP lookup. You can check this f.e. by doing a traceroute across an MPLS network with ttl-propagation disabled. The outgoing PE will NOT show up in the traceroute.

The only exclusion is the directly connected interface network (PE-CE). In this case you will see an "aggregate" label and no outgoing interface f.e. with "show mpls forwarding-table".

The whole concept is especially important for Central Service VPNs or Hub-and-Spoke VPNs, where you do not want a client to client shortcut by the VRF routing table.

So in short: there are no unwanted hairpins in MPLS.

Hope this helps!

Regards, Martin

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
mheusing Tue, 06/26/2007 - 10:16

Hi,

The LFIB/CEF table will determine the forwarding action. Thus, if a VPN label points out a specific interface towards a CE, the packet will be forwarded out that interface by CEF. There will be NO additional IP lookup. You can check this f.e. by doing a traceroute across an MPLS network with ttl-propagation disabled. The outgoing PE will NOT show up in the traceroute.

The only exclusion is the directly connected interface network (PE-CE). In this case you will see an "aggregate" label and no outgoing interface f.e. with "show mpls forwarding-table".

The whole concept is especially important for Central Service VPNs or Hub-and-Spoke VPNs, where you do not want a client to client shortcut by the VRF routing table.

So in short: there are no unwanted hairpins in MPLS.

Hope this helps!

Regards, Martin

g.sperryn Tue, 06/26/2007 - 10:22

Perfect!

I was looking to confirm that there was no way that packets following the default route could hit an egress PE with multiple RDs imported into a 'common' vrf table, and find a way back towards a route in another RD/VRF even though the original VRF did not include this route.

Thanks Martin

mheusing Wed, 06/27/2007 - 01:07

Hi,

Well, your first IP hop will probably do exactly that: interconnect different client sites, as longest match routing will not follow the default route, if a more specific is known. You can only try to setup forwarding rules (ACL, PBR) on the first IP hop after the PE. In case the PE creates the default route, it is treated like "directly connected". The PE will have an aggregate label and then do the IP lookup.

As a general rule: do NOT announce client networks from a server site. This includes summaries containing client routes (like 10.0.0.0/8 or default route) as they "contain" client routes. This might create a client to client leakage.

Hope this helps!

Regards, Martin

g.sperryn Wed, 06/27/2007 - 01:53

Thanks for that

So as long as i am not advertising the defualt route from the PE, the PE will not an IP lookup for the next hop.

In short, this means the PE won't reroute back into the MPLS domain (hairpin) unless it is advertising the default route.

g.sperryn Wed, 06/27/2007 - 02:26

So how would I go about setting up a common services VRF on a PE, importing multiple customer RD from other PE, with the default next hop being a Firewall?

I would have to configure a static(assume FW does not support dynamic routing) on this PE and advertise this default route out, so therefore this would appear as an 'aggregate' label and this PE would hairpin because it would do an IP lookup and determine the next hop to be back into the MPLS domain.

What would be good practise here?

kind regards

Graeme

jiangu Tue, 06/26/2007 - 10:41

Of course this scenario can occur, one obvious example is traceroute between VPN sites. When P router forwards "ICMP time exceeded packet" to remote PE, remote PE will strip the VPN (aggregate) label and do VPN route lookup, next hop will be back into the MPLS cloud. PE router will forward this packet exactly the same way as if this packet is received from local CE, aka, new LSP/VPN label will be applied.

g.sperryn Tue, 06/26/2007 - 15:07

But can this happen for user traffic passing through the routers as well as traffic generated by the routers (eg ICMP)?

mheusing Tue, 06/26/2007 - 23:55

Hi,

The VPN traceroute example is not entirely correct. The ICMP TTL exceeded produced by a P router will be forwarded to the CE behind which the destination IP is found - assuming you are not tracing to the PE-CE network. You can easily check this by applying an incoming ACL to the CE denying ICMP packets (permit the rest!). This will "break" the traceroute, i.e. ICMP packets from P routers will be dropped by the CE ACL and thus you will see asterisks (* * *) for each P router.

For the record: do this in a lab environment only.

Hope this helps!

Regards, Martin

jiangu Wed, 06/27/2007 - 10:16

Hi, Martin,

You are absolutely right, if the destination is behind CE, PE will advertise a non-aggregate label in that case PE will directly forward the icmp packets to CE without IP lookup because LFIB has already had next-hop information. But this scenario is not an exactly "hair-pin", because PE is not making decision that the incoming packets have to be sent back to the core.

Actions

This Discussion