0
1 votes
MPLS part 2.5
06 September 2010
Here I will be comparing the BGP and MP-BGP update messages. MP-BGP is used for MPLS VPNs, which requires the addition of a new address family, VPNv4. It also supports MPLS.
Standard BGP UPDATE message:
MP-BGP UPDATE message with MPLS VPN info:
Both update messages include the well-known attributes: ORIGIN, AS_PATH, LOCAL_PREF. In addition, Cisco IOS includes the optional MED attribute by default.
EXTENDED_COMMUNITIES are present in the MP-BGP update. These are the heart of the MPLS VPN operation. “UnknownRoute Target: 1:100” is the exported route-target associated with the client vrf:
“UnknownOSPF Domain: 0.0.0.0:100” indicates that the domain-id has note been set (0.0.0.0) and that the OSPF process ID is 100 (:100). This can be changed on the PE routers:
If the domain-id values are different between VPN endpoints, Ce routers will show them as type E2. If they are the same, or remain unset the OSPF routes will show up as IA. It should also be noted that by default the redistribution between OSPF > BGP will only take internal OSPF routes. To change this your redistribution command must explicitly define external routes:
The “UnknownOSPF route type” shows the area, LSA update type and any route options. If you choose to propagate type E1 or E2 routes across the MPLS VPN, this field will reflect the OSPF route type (eg: External E2).
“UnknownOSPF Router ID” carries the OSPF router ID of the PE's vrf OSPF instance. By default this will be the interface connecting the PE and C routers.
The update messages include NEXT_HOP, however they are advertised in different manners . Note that in the standard iBGP update the NEXT_HOP is advertised as 8.8.8.8 in the update message. This applies to the four prefixes below, as 8.8.8.8 is the iBGP peer that originated these networks.
MP-BGP is advertising only the 10.0.12.0/24 prefix by way of MPLS label 24. Rather than having an IP next hop, packets destined for 10.0.12.0/24 will have the label 24 imposed. This is seen on the PE router's VRF LFIB:
Conversely, traffic originating at the far-end of the MPLS VPN tunnel, 192.168.6.0/24, and bound for 172.16.0.0/24 will use the label 23 (note that this is the bottom tag, as indicated by the BOS bit = 1 on this ICMP packets labels):
The P, or core routers have no knowledge of the 10.0.12.0/24 network, now of label 24. An outer label is also imposed by the PE router to allows the core to switch the packet to the far end PE router (by its iBGP peering address 200.0.0.2):
Each P router along the way forwards the data along the LSP and swaps the outer label as necessary. Once the far end router receives the packet, it makes use of PHP (on by default) and pops the outer label:
The far end PE LSR receives a packet with only one remaining label, 24, which signifies the VPN membership, or interface to switch the packet out:
The [V] means that the prefix resides within a vrf, vrf A in this case. Aggregate “Outgoing tag” means that ingress labels tagged with 24 will have its label stack removed and it will be forwarded via IP lookup. Labels for a remote MPLS VPN network will show up as Aggregate because they will require an additional IP lookup. Subnets on the local CE router will show up as Untagged on the connected PE router.
Additionally it should be noted that remote MPLS VPN labels will not show up in the PE LIB because they are distributed via MP-BGP and not via LDP. In fact, none of the vrf labels will show via pure MPLS:
One last curiosity, MPLS cores mess with ICMP messages. Specifically when using tracert. Given my topology:
What would you expect the tracert from CE router 1 to CE router 6 to show? Normally this would be a full 5 IP hops, but:
The path reflected here is R1 > R2 > R5 > R6
By default IP TTL propagation is enabled on Cisco LSRs. Many ISPs disable this to hide the size of their core, this is done easily on a per-router basis. I have done this for the purposes of this lab:
~sly
Standard BGP UPDATE message:
MP-BGP UPDATE message with MPLS VPN info:
Both update messages include the well-known attributes: ORIGIN, AS_PATH, LOCAL_PREF. In addition, Cisco IOS includes the optional MED attribute by default.
EXTENDED_COMMUNITIES are present in the MP-BGP update. These are the heart of the MPLS VPN operation. “UnknownRoute Target: 1:100” is the exported route-target associated with the client vrf:
R5#sh run | sec vrf ip vrf A rd 100:100 route-target export 1:100 route-target import 1:100
“UnknownOSPF Domain: 0.0.0.0:100” indicates that the domain-id has note been set (0.0.0.0) and that the OSPF process ID is 100 (:100). This can be changed on the PE routers:
R5(config)#router ospf 100 vrf A R5(config-router)#dom R5(config-router)#domain-id R5(config-router)#domain-id 1.1.1.1
If the domain-id values are different between VPN endpoints, Ce routers will show them as type E2. If they are the same, or remain unset the OSPF routes will show up as IA. It should also be noted that by default the redistribution between OSPF > BGP will only take internal OSPF routes. To change this your redistribution command must explicitly define external routes:
R2(config-router)#redistribute ospf 100 vrf A match internal external 1 external 2
The “UnknownOSPF route type” shows the area, LSA update type and any route options. If you choose to propagate type E1 or E2 routes across the MPLS VPN, this field will reflect the OSPF route type (eg: External E2).
“UnknownOSPF Router ID” carries the OSPF router ID of the PE's vrf OSPF instance. By default this will be the interface connecting the PE and C routers.
The update messages include NEXT_HOP, however they are advertised in different manners . Note that in the standard iBGP update the NEXT_HOP is advertised as 8.8.8.8 in the update message. This applies to the four prefixes below, as 8.8.8.8 is the iBGP peer that originated these networks.
MP-BGP is advertising only the 10.0.12.0/24 prefix by way of MPLS label 24. Rather than having an IP next hop, packets destined for 10.0.12.0/24 will have the label 24 imposed. This is seen on the PE router's VRF LFIB:
R2#sh mpls forwarding-table vrf A Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 23 Untagged 172.16.0.1/32[V] 113430 Fa0/0 10.0.12.1 24 Aggregate 10.0.12.0/24[V] 0
Conversely, traffic originating at the far-end of the MPLS VPN tunnel, 192.168.6.0/24, and bound for 172.16.0.0/24 will use the label 23 (note that this is the bottom tag, as indicated by the BOS bit = 1 on this ICMP packets labels):
The P, or core routers have no knowledge of the 10.0.12.0/24 network, now of label 24. An outer label is also imposed by the PE router to allows the core to switch the packet to the far end PE router (by its iBGP peering address 200.0.0.2):
R4#sh mpls forwarding-table 200.0.0.2 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 19 19 200.0.0.2/32 134017 Fa0/0 10.0.34.3
Each P router along the way forwards the data along the LSP and swaps the outer label as necessary. Once the far end router receives the packet, it makes use of PHP (on by default) and pops the outer label:
R3#sh mpls for 200.0.0.2 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 19 Pop tag 200.0.0.2/32 129450 Fa0/0 10.0.23.2
The far end PE LSR receives a packet with only one remaining label, 24, which signifies the VPN membership, or interface to switch the packet out:
R2#sh mpls forwarding-table labels 24 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 24 Aggregate 10.0.12.0/24[V] 0 R2#sh ip int br | i 10.0.12 FastEthernet0/0 10.0.12.2 YES manual up up
The [V] means that the prefix resides within a vrf, vrf A in this case. Aggregate “Outgoing tag” means that ingress labels tagged with 24 will have its label stack removed and it will be forwarded via IP lookup. Labels for a remote MPLS VPN network will show up as Aggregate because they will require an additional IP lookup. Subnets on the local CE router will show up as Untagged on the connected PE router.
Additionally it should be noted that remote MPLS VPN labels will not show up in the PE LIB because they are distributed via MP-BGP and not via LDP. In fact, none of the vrf labels will show via pure MPLS:
R5#show mpls ip binding vrf A LIB not enabled
One last curiosity, MPLS cores mess with ICMP messages. Specifically when using tracert. Given my topology:
What would you expect the tracert from CE router 1 to CE router 6 to show? Normally this would be a full 5 IP hops, but:
R1>traceroute 192.168.6.1 Type escape sequence to abort. Tracing the route to 192.168.6.1 1 10.0.12.2 20 msec 16 msec 8 msec 2 10.0.56.5 [MPLS: Label 23 Exp 0] 28 msec 36 msec 48 msec 3 10.0.56.6 40 msec 44 msec *
The path reflected here is R1 > R2 > R5 > R6
By default IP TTL propagation is enabled on Cisco LSRs. Many ISPs disable this to hide the size of their core, this is done easily on a per-router basis. I have done this for the purposes of this lab:
R1(config)#no mpls ip propagate-ttl
~sly
