Date created: Monday, November 13, 2017 4:41:51 PM. Last modified: Monday, November 13, 2017 4:57:11 PM
6PE Interop (IOS/IOS-XR/Junos)
References:
https://forums.juniper.net/t5/TheRoutingChurn/Using-IPv6-Labeled-Unicast-BGP-for-6PE/ba-p/178249
http://tools.ietf.org/html/rfc4798
https://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/gsxnlbsp.html
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mpls/command/mp-cr-book/mp-m4.html#wp1488478482
http://www.oreilly.com/catalog/errataunconfirmed.csp?isbn=0636920033905
http://www.oreilly.com/catalog/errata.csp?isbn=0636920033905
Contents:
6PE and Label Usage Problem Background
Config Examples
Example Outputs
6PE and Label Usage Problem Background:
When using 6PE between MP-iBGP neighbours (with or without route-reflectors), if the full global Internet routing table is not inside a VRF but in the router GRT (global routing table) then 6PE will allocate labels for all of the global Internet IPv6 routes by default on IOS. For PEs that do carry the full internet table this consumes an additional 40k MPLS labels (the global IPv6 routing table is circa 40k routes at the time of writing).
This isn't a problem with IPv4 for most service providers as they use IPv4 within the IGP, and the packets could be routed across the SP network as vanilla IPv4 packets, from customer edge to service provider edge where they hand over to a transit provider or peer ASN. Alternatively LDP or RSVP may be used to allocate an MPLS label to an IPv4 loopback interface address on each PE and traffic from ingress PE an egress PE towards the global Internet is MPLS packet switched to the egress PE's loopback (next-hop) address, based on an IPv4 lookup (1.2.3.0/24 is via 10.0.0.1, 10.0.0.1 is reachable via Gi0/0 using transport label 100).
This IPv4 labelled loopback scenario with the global Internet in a routers GRT is a common scenario (many SPs run "Internet in a VRF" however every man and his dog has an opinion on that and it's out of scope here); the egress LER will receive an unlabelled IPv4 packet from the penultimate PE (due to penultimate-hop-popping) and the IGP links being IPv4 enabled, and simply perform an IPv4 lookup and forward the packet out to the directly attached transit provider or peer ASN. The exception being if IPv4 MPLS explicit-null labels (label 0) are used (such as for QoS). In this case the IPv4 packet will reach the egress PE with the IPv4 explicit-null MPLS label and the egress PE will pop that label and because it was label 0 this in turn tells the LER that it needs to perform an IPv4 lookup (this can lead to packet recirculation on some devices, halving the PPS rate of that device, so end-to-end QoS isn't necessarily free!).
When the underlying IGP isn't dual stacked or is IPv4 only, and the Internet egress PEs have the full IPv6 global Internet table in their GRT, 6PE must be used to carry customer IPv6 traffic over the IPv4 only service provider network.
IOS will allocate 40k MPLS labels by default when using the neighbour statement "send-label" without a route-map to filter which prefixes receive a label. IOS only supports per-prefix labelling for 6PE.
IOS-XR uses the BGP global "address-family ipv6 unicast" keyword "allocate-label [all|route-policy ...]" where "all" obviously allocates labels to all IPv6 unicast prefixes and "route-policy X" will apply route-policy X to only allocate labels to routes that pass through the policy. IOS-XR will also accept the keyword "label mode per-vrf" under the global "address-family ipv6 unicast", this has the effect of allocating the IPv6 MPLS explicit-null label to all IPv6 GRT prefixes, the same as the Junos behaviour below with the "explicit-null" keyword ("allocate-label all" is still required for "label mode per-vrf" to work).
When configuring Junos and applying "family inet6 { labelled-unicast }" to a BGP neighbour, the keyword "explicit-null" allocates one label (the MPLS IPv6 explicit-null, label 2) to all prefixes creating a per-vrf/per-tabel label effect despite not being a VPNv6/inet6-vpn/6vPE session. All traffic arriving with a label value of 2 at an egress Junos PE will be resolved in the global IPv6 RIB (inet6.0).
Config Examples:
For Junos "family inet6" must be enabled no the core facing interface. When an MPLS labelled packet arrives are the edge PE and the IPv6 explicit-null labelled is popped, even though the packet was received on a core facing IPv4 only interface, Junos "knows" the source interface and won't perform an IPv6 lookup if the ingress interface doesn't have "family inet6" enabled. Also "ipv6-tunnelling" Must be enabled under "protocol mpls" otherwise Junos won't re-write IPv6 next-hops as the special IPv4-encoded-IPv6 address "::FFFF:10.0.0.20" (where in this case 10.0.0.20/32 is the lo0.0 address on this Junos PE):
ge-0/1/9 {
unit 0 {
family inet {
address 10.10.1.1/30;
}
family inet6;
family mpls;
}
}
protocols {
mpls {
ipv6-tunneling;
interface ge-0/1/9.0;
}
bgp {
group MP-iBGP-PEs {
family inet6 {
labeled-unicast {
explicit-null;
}
}
}
}
}
With IOS-XR when configuring BGP global “address-family ipv6 unicast”, if “allocate-label all|route-policy X” isn’t used then no labels are allocated to IPv6 routes and thus no routes are sent over an IPv6 BGP-LU peering. If no IPv6 unicast peering exists, only an IPv6-BGP-LU peering between PEs/RR, then no IPv6 routes will be exchanged at all, even if IPv6 unicast routes exist just without a label, they won’t be sent over an IPv6-BGP-LU peering. In IOS-XR this behaviour makes a clearer distinction between IPv6 unicast (AFI 2 / SAFI 1) and IPv6 BGP labelled-unicast (AFI 2 / SAFI 4) peerings.
Also of note is IOS-XR bug CSCtq26829, an IOS-XR PE won’t establish an IPv6 unicast peering if it doesn’t have an IPv6 address configured on its BGP update-source interface (usually loopback0) which it can use for next-hop-self rewriting. This makes sense, the bug is a cosmetic bug because IOS-XR doesn’t clearly indicate when there is no valid IPv6 address locally configured on the BGP NH/update-source interface. The local PE doesn’t care if the remote PE has an IPv6 address on its update-source interface as it can’t check that, this isn’t mentioned in the BGP negotiation.
Below is the matching IOS-XR config for the Junos config above;
router bgp 123 address-family ipv6 unicast label mode per-vrf allocate-label all ! session-group IBGP remote-as 123 update-source Loopback0 ! neighbor-group CORE-IBGP use session-group IBGP ! address-family ipv6 labeled-unicast next-hop-self ! ! neighbor 1.0.0.1 use neighbor-group CORE-IBGP description PE1
There is a known bug in IOS CSCtf27303 where another PE sends an AFI 2 / SAFI 1 (IPv6 unicast) BGP Unreachable NLRI to an IOS PE and only AFI 2 / SAFI 4 (IPv6 BGP-LU) has been negotiated, causing the session to flap. With IOS all prefixes should be labelled (AFI 2 / SAFI 4) or unlabelled (AFI 2 / SAFI 1) for simplicity as it blurs the lines between IPv6 unicast and IPv6 BGP-LU, “show bgp ipv6 unicast” for example show routes from both AFI/SAFIs as if they were the same. When mixing IPv6 unicast and IPv6 BGP-LU care must be taken that both AFI/SAFI combos configured and negotiated on both PEs.
IOS only supports per-prefix labelling for 6PE. Even though a keyword exists “send-label explicit-null” this actually doesn’t work for IPv6. It is meant for IPv4-BGP-LU and CsC. It has no effect on a 6PE (IPv6-BGP-LU) session, per-prefix labels are still allocated and sent.
Example Outputs:
Below the output shows a Junos PE with an IPv4 lo0.0 address of 10.0.0.21/32 advertising it’s lo0.0 IPv6 address 2011:10::21/128 to an IOS PE with loop back addresses 10.0.0.20/23 and 2011:10:20/128, using 6PE. It can be seen that the Junos PE is sending the IPv6 explicit-null label (2):
c7604#show ipv6 route 2011:10::21/128
Routing entry for 2011:10::21/128
Known via "bgp 123", distance 200, metric 0, type internal
Route count is 1/1, share count 0
Routing paths:
10.0.0.21%default indirectly connected
MPLS label: 2
Last updated 03:26:30 ago
c7604#show bgp ipv6 unicast 2011:10::21/128
BGP routing table entry for 2011:10::21/128, version 13
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
Local
::FFFF:10.0.0.21 (metric 1) from 10.0.0.21 (10.0.0.21)
Origin IGP, localpref 100, valid, internal, best
mpls labels in/out nolabel/2
rx pathid: 0, tx pathid: 0x0
c7604#show ip route 10.0.0.21
Routing entry for 10.0.0.21/32
Known via "ospf 100", distance 110, metric 1, type intra area
Last update from 10.10.1.1 on GigabitEthernet4/24, 3w3d ago
Routing Descriptor Blocks:
* 10.10.1.1, from 10.0.0.21, 3w3d ago, via GigabitEthernet4/24
Route metric is 1, traffic share count is 1
c7604#show ipv6 cef exact-route 2011:10::20 2011:10::21
2011:10::20 -> 2011:10::21 => label ipv6-explicit-null label implicit-null TAG adj out of GigabitEthernet4/24, addr 10.10.1.1
root@mx480> show route table mpls.0 label 2 detail
mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
2 (1 entry, 1 announced)
*MPLS Preference: 0
Next hop type: Receive
Address: 0x9270ee4
Next-hop reference count: 8
State:
Local AS: 123
Age: 3w3d 2:24:45 Metric: 1
Validation State: unverified
Task: MPLS
Announcement bits (1): 0-KRT
AS path: I
The following output shows an IOS PE with loopback0 IPv4 address 1.0.01/32 and IPv6 address 1::1/128, pinging the IPv6 loopback0 address 1::2/128 of an IOS-XR PE (which has 1.0.0.2/32 for its IPv4 loopback0 address), again using 6PE and again the egress PE is advertising label 2 to the ingress PE:
PE1#show bgp ipv6 unicast 1::2/128
BGP routing table entry for 1::2/128, version 40
Paths: (1 available, best #1, table default)
Advertised to update-groups:
4
Refresh Epoch 1
Local
::FFFF:1.0.0.2 (metric 2) from 1.0.0.2 (1.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: 123:10 123:11
mpls labels in/out nolabel/2
PE1#show ipv6 cef exact-route 1::1 1::2
1::1 -> 1::2 => label ipv6-explicit-null label implicit-null TAG adj out of FastEthernet0/0, addr 10.0.0.2
In the example output blow a Junos PE (with lo0.0 IPv4 address 10.0.0.21/32 and IPv6 address 2011:10::21/128) is showing its path to the loopback0 IPv6 address (2011:10::20/128) of an IOS device (which has loopback0 IPv4 address 10.0.0.20/32). In this example the IOS PE is using per-prefix labelling so the service label is 22 and not 2 (the IPv6 explicit-null label value).
Although label 2 is reserved as the IPv6 explicit-null label, any valid non-reserved label value can be used for 6PE, just as with IPv4 BGP labelled-unicast (AFI 1 / SAFI 4) routes or IPv4/IPv6 (AFI 1 / SAFI 128 and AFI 2 / SAFI 128 respectively) L3 VPN routes. The egress PE can choose a valid free label and in its LFIB assign the action upon receipt of that label to perform an IPv6 lookup with the contained IPv6 packet destination address.
From: http://tools.ietf.org/html/rfc4798:
The label bound by MP-BGP to the IPv6 prefix indicates to the egress 6PE Router that the packet is an IPv6 packet. This label advertised by the egress 6PE Router with MP-BGP MAY be an arbitrary label value, which identifies an IPv6 routing context or outgoing interface to send the packet to, or MAY be the IPv6 Explicit Null Label. An ingress 6PE Router MUST be able to accept any such advertised label.
root@mx480> show route table inet6.0 2011:10::20/128 detail
inet6.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
2011:10::20/128 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Indirect
Address: 0x95625c4
Next-hop reference count: 3
Source: 10.0.0.20
Next hop type: Router, Next hop index: 665
Next hop: 10.10.1.2 via ge-0/1/9.0, selected
Label operation: Push 22
Label TTL action: prop-ttl
Session Id: 0x101
Protocol next hop: ::ffff:10.0.0.20
Push 22
Indirect next hop: 0x96bc118 1048576 INH Session ID: 0x103
State:
Local AS: 123 Peer AS: 123
Age: 4:03:25 Metric: 0 Metric2: 1
Validation State: unverified
Task: BGP_123.10.0.0.20+40420
Announcement bits (2): 0-KRT 2-Resolve tree 3
AS path: ?
Accepted
Route Label: 22
Localpref: 100
Router ID: 10.0.0.20
root@mx480> show route table inet6.3 ::ffff:10.0.0.20/128 detail
inet6.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
::ffff:10.0.0.20/128 (1 entry, 1 announced)
State:
*LDP Preference: 9
Next hop type: Router
Address: 0x956122c
Next-hop reference count: 9
Next hop: 10.10.1.2 via ge-0/1/9.0, selected
Session Id: 0x0
State:
Local AS: 123
Age: 44:11 Metric: 1
Validation State: unverified
Task: LDP
Announcement bits (3): 0-Resolve tree 3 1-Resolve tree 4 2-Resolve_IGP_FRR_task
AS path: I
Primary Routing Table inet.3
root@mx480> show route table inet.3 10.0.0.20/32 detail
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
10.0.0.20/32 (1 entry, 1 announced)
State:
*LDP Preference: 9
Next hop type: Router
Address: 0x956122c
Next-hop reference count: 9
Next hop: 10.10.1.2 via ge-0/1/9.0, selected
Session Id: 0x0
State:
Local AS: 123
Age: 44:27 Metric: 1
Validation State: unverified
Task: LDP
Announcement bits (3): 0-Resolve tree 1 2-Resolve tree 2 4-Resolve_IGP_FRR_task
AS path: I
Secondary Tables: inet6.3
show route forwarding-table destination 2011:10::20/128 extensive
Routing table: default.inet6 [Index 0]
Internet6:
Destination: 2011:10::20/128
Route type: user
Route reference: 0 Route interface-index: 0
Flags: sent to PFE, prefix load balance
Next-hop type: indirect Index: 1048576 Reference: 2
Nexthop: 10.10.1.2
Next-hop type: Push 22 Index: 665 Reference: 2
Next-hop interface: ge-0/1/9.0
c7604#show mpls forwarding-table labels 22 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
22 Pop Label 2011:10::20/128 1190 aggregate
MAC/Encaps=0/0, MRU=0, Label Stack{}
No output feature configured
Previous page: IOS-XR Bridge Domains & MAC Addresses
Next page: CSC (Squashed) with LDP