Thursday, February 6, 2014

NTS: 6PE/6VPE

6PE/6VPE




6PE is defined in RFC 4798.
6VPE is defined in RFC 4659.



  • 6PE
    • customer's IPv6 prefixes are inside the global routing table
    • IPv6 labels/prefixes are exchanged using Labeled IPv6 over IPv4 iBGP between the PEs
  • 6VPE
    • customer's IPv6 prefixes are inside a VRF
    • IPv6 labels/prefixes are exchanged using VPNv6 over IPv4 iBGP between the PEs



6PE

6PE is a technology that allows IPv6 customers to communicate with each other over an IPv4 MPLS Provider without any tunnel setup, by having the customer IPv6 prefixes using a IPv4-mapped IPv6 address as next-hop inside the Provider's network and using IPv4 LSPs between the 6PEs.

In 6PE, labels must be exchanged between the 6PEs for their IPv6 prefixes, which means that a labeled IPv4 iBGP session must be activated under the IPv6 address family (in IOS) or the labeled IPv6 capability must be activated for the IPv4 peer 6PE (in IOS-XR).

IOS
router bgp 100
 no bgp default ipv4-unicast
 neighbor 6PE-IPv4 remote-as 100
 neighbor 6PE-IPv4 update-source Loopback0
 neighbor CE-IPv6 remote-as X

!
 address-family ipv6
  neighbor 6PE-IPv4 activate
  neighbor 6PE-IPv4 send-label

  neighbor CE-IPv6 activate

IOS-XR
router bgp 100
 address-family ipv6 unicast
  allocate-label all
 !
 neighbor 6PE-IPv4
  remote-as 100
  update-source Loopback0
  address-family ipv6 labeled-unicast
  !
 neighbor CE-IPv6
  remote-as X
  address-family ipv6 unicast



The 6PE routers are dual-stack: IPv6 towards the CE and IPv4 towards the MPLS core.

You don't need to set the "next-hop-self" in the labeled IPv4 iBGP session for the IPv6 prefixes, because that happens automatically while creating the IPv4-mapped IPv6 address.

MP_REACH_NLRI attribute
  • AFI = 2 (IPv6)
  • SAFI=  4 (labels)
  • Prefix =X:X:X:X::X
  • Label = X
  • next-hop = ::FFFF:IPv4-ADDRESS

The IPv4 address which is encoded into the next-hop must be present in the IPv4 routing table and a LSP must exist to this destination. If the above conditions are not both met, the IPv6 prefix is declared inaccessible.

R5#sh bgp ipv6 unicast 2001::1:1:1:1/128
BGP routing table entry for 2001::1:1:1:1/128, version 4
Paths: (1 available, no best path)
  Not advertised to any peer
  1
    ::FFFF:2.2.2.2 (inaccessible) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal


If a 6PE receives unlabeled IPv6 prefixes, then the 6PE marks these prefixes as unreachable in the IPv6 routing table, so that packets to this destination get dropped and not sent into MPLS core.

If RRs are to be used for 6PE connectivity, then they also must have labeled BGP enabled.


Control Plane

  • CEs and 6PEs run eBGP (or IGP) in order to exchange IPv6 prefixes
  • 6PEs run iBGP+Label in order to exchange labels and IPv6 prefixes
  • Provider routers run IGP+LDP in order to exchange all their internal BGP IPv4 next-hops and their labels



6PE Example

Assume the following network:

R1-R2-R3-R4-R5-R6

where

IPv6 Customer
6PE Provider (with 6PE routers and IPv4 routers)


Then the following would happen for an IPv6 packet originating at R1 and terminating at R6.

  • R1 (IPv6)
    • next-hop is R2 (IPv6 link-local)
  • R2 (IPv4/IPv6 6PE)
    • next-hop is R5 (IPv4 loopback)
    • Transport label is 26, IPv6 label is 28
  • R3 (IPv4)
    • next-hop is R5 (IPv4 loopback)
    • Transport label is 25, IPv6 label is 28
  • R4 (IPv4)
    • next-hop is R5 (IPv4 loopback)
    • Transport label is removed, IPv6 label is 28
  • R5 (IPv4/IPv6 6PE)
    • next-hop is R6 (IPv6 link-local)
    • IPv6 label is removed, IPv6 destination reached in next-hop
  • R6 (IPv6)
    • IPv6 destination reached

The IPv6 label in 6PE can be considered like the VPN label in MPLS VPN.

The customer routers could be IPv4/IPv6, having IPv4 traffic being forwarded as usual and IPv6 traffic over 6PE.

Use extended traceroute if you want to source from an IPv6 address.

R1#trace
Protocol [ip]: ipv6
Target IPv6 address: 2001::6:6:6:6
Source address: 2001::1:1:1:1

...
Tracing the route to 2001::6:6:6:6

  1 2001:10:1:2::2 44 msec 72 msec 32 msec
  2 ::FFFF:10.2.3.3 [MPLS: Labels 26/28 Exp 0] 1 msec 1 msec 1 msec
  3 ::FFFF:10.3.4.4 [MPLS: Labels 25/28 Exp 0] 1 msec 1 msec 1 msec
  4 2001:10:5:6::5[MPLS: Label 28 Exp 0] 1 msec 1 msec  1 msec

  5 2001:10:5:6::6 1 msec 1 msec 1 msec


Although all traceroute answers are given by the closest interface to the source ip, in some software releases in the last 6PE router the traceroute answer is given by the IPv6 address on the PE-CE link.

You can use "no mpls ip propagate-ttl" on the first-hop 6PE if you want to hide the ::FFFF: IPv4 hops.

  1 2001:10:1:2::2 44 msec 72 msec 32 msec
  2 2001:10:5:6::5[MPLS: Label 28 Exp 0] 1 msec 1 msec  1 msec
  3 2001:10:5:6::6 1 msec 1 msec 1 msec



Verification in every hop


Customer IPv6 router
R1#sh ipv6 route 2001::6:6:6:6
Routing entry for 2001::6:6:6:6/128
  Known via "bgp 1", distance 20, metric 0, type external
  Route count is 1/1, share count 0
  Routing paths:
    FE80::C805:17FF:FEC8:1C, FastEthernet0/0
      MPLS label: nolabel
      Last updated 00:31:05 ago



Provider 6PE router
R2#sh bgp ipv6 unicast 2001::6:6:6:6/128
BGP routing table entry for 2001::6:6:6:6/128, version 3
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1
  20
    ::FFFF:5.5.5.5(metric 4) from 5.5.5.5(5.5.5.5)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      mpls labels in/out nolabel/28


IOS-XR doesn't display the "::FFFF:" in front of the IPv4 next-hop (How Multi is MP-BGP in IOS-XR - Part #2).

IPv6 label is 28

R2#sh mpls forwarding-table 5.5.5.5 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
27         26         5.5.5.5/32       0             Fa0/0.23   10.2.3.3
        MAC/Encaps=18/22, MRU=1500, Label Stack{26}
        CA071AC40000CA0517C80000810000178847 0001A000
        No output feature configured


Transport label is 26

R2#sh ipv6 cef 2001::6:6:6:6/128 detail
2001::6:6:6:6/128, epoch 0, flags rib defined all labels
  recursive via 5.5.5.5 label 28
    nexthop 10.2.3.3 FastEthernet0/0.23 label 26


Transport label is 26, IPv6 label is 28


You can follow the next-hop or the labels (like in CsC), but let's follow the next-hop on this example.


Provider IPv4 Router
R3#sh mpls forwarding-table 5.5.5.5 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
26         25         5.5.5.5/32       16342         Fa0/0.34   10.3.4.4
        MAC/Encaps=18/22, MRU=1500, Label Stack{25}
        CA0113200000CA071AC40000810000248847 00019000
        No output feature configured


Transport label is 25, IPv6 label is 28


Provider IPv4 Router
R4#sh mpls forwarding-table 5.5.5.5 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
25         Pop Label  5.5.5.5/32       16125         Fa0/0.45 10.4.5.5
        MAC/Encaps=18/18, MRU=1504, Label Stack{}
        CA0214D00008CA01132000008100026B8847
        No output feature configured


Transport label is removed, IPv6 label is 28


Provider 6PE router
R5#sh mpls forwarding-table 2001::6:6:6:6/128 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
28         No Label   2001::6:6:6:6/128   \
                                       2244          PO2/0      point2point
        MAC/Encaps=4/4, MRU=4474, Label Stack{}
        0F0086DD
        No output feature configured


R5#sh bgp ipv6 unicast 2001::6:6:6:6/128
BGP routing table entry for 2001::6:6:6:6/128, version 3
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2
  20
    2001:10:5:6::6 (FE80::C803:14FF:FED0:8) from 2001:10:5:6::6 (6.6.6.6)
      Origin IGP, metric 0, localpref 100, valid, external, best
      mpls labels in/out 28/nolabel


R5#sh bgp ipv6 unicast labels
   Network          Next Hop      In label/Out label
   2001::6:6:6:6/128
                    2001:10:5:6::6
                                    28/nolabel


R5#sh ipv6 route 2001::6:6:6:6/128
Routing entry for 2001::6:6:6:6/128
  Known via "bgp 100", distance 20, metric 0, type external
  Route count is 1/1, share count 0
  Routing paths:
    FE80::C803:14FF:FED0:8, POS2/0
      MPLS label: nolabel
      Last updated 00:43:37 ago


IPv6 label is removed, IPv6 destination reached in next-hop



6VPE

6VPE is a technology that allows IPv6 VPN customers to communicate with each other over an IPv4 MPLS Provider without any tunnel setup, by having the customer VPNv6 prefixes using a v4-mapped IPv6 address as next-hop inside the provider's network and using IPv4 LSPs between the 6VPEs.

In 6VPE, labels must be exchanged between the 6VPEs for their VPNv6 prefixes, which means that the VPNv6 address-family must be activated on the IPv4 iBGP session between the 6VPEs.

IOS
router bgp 100
 no bgp default ipv4-unicast
 neighbor 6VPE-IPv4 remote-as 100
 neighbor 6VPE-IPv4 update-source Loopback0
 !
 address-family vpnv6
  neighbor 6VPE-IPv4 activate
  neighbor 6VPE-IPv4 send-community extended
 exit-address-family
 !
 address-family ipv6 vrf VPN

  neighbor CE-IPv6 remote-as X
  neighbor CE-IPv6 activate
 exit-address-family


IOS-XR
router bgp 100
 address-family vpnv6 unicast
 !
 neighbor 6VPE-IPv4
  remote-as 100
  update-source Loopback0
  address-family vpnv6 unicast
  !
 vrf VPN
  rd 100:1
  address-family ipv6 unicast
  !
  neighbor CE-IPv6
   remote-as x
   address-family ipv6 unicast



The 6VPE routers are dual-stack: IPv6 towards the CE (inside a VRF) and IPv4 towards the MPLS core.


MP_REACH_NLRI attribute
  • AFI = 2 (IPv6)
  • SAFI= 128 (.)
  • Prefix =X:X:X:X::X
  • Label = X
  • next-hop = ::FFFF:IPv4-ADDRESS

The IPv4 address which is encoded into the next-hop must be present in the IPv4 routing table and a LSP must exist to this destination. If the above conditions are not both met, the IPv6 prefix is declared inaccessible.

If RRs are to be used for 6VPE connectivity, then they also must have the VPNv6 address-family enabled.


Control Plane

  • CEs and 6VPEs run eBGP (or IGP) in order to exchange IPv6 prefixes
  • 6VPEs run VPNv6 iBGP in order to exchange labels and VPNv6 prefixes
  • Provider routers run IGP+LDP in order to exchange all their internal BGP IPv4 next-hops and their labels

In IOS, if you enable the VPNv6 address-family on an existing VPNv4 peering, you might need to reset the whole BGP session for VPNv6 to come up.



6VPE Example

Assume the following network:

R1-R2-R3-R4-R5-R6

where

IPv6 VPN Customer
6VPE Provider (with 6VPE routers and IPv4 routers)


Then the following would happen for an IPv6 packet originating at R1 and terminating at R6.

  • R1 (IPv6)
    • next-hop is R2 (IPv6 link-local)
  • R2 (IPv4/IPv6 6VPE)
    • next-hop is R5 (IPv4 loopback)
    • Transport label is 18, VPNv6 label is 28
  • R3 (IPv4)
    • next-hop is R5 (IPv4 loopback)
    • Transport label is 25, VPNv6 label is 28
  • R4 (IPv4)
    • next-hop is R5 (IPv4 loopback)
    • Transport label is removed, VPNv6 label is 28
  • R5 (IPv4/IPv6 6VPE)
    • next-hop is R6 (IPv6 link-local)
    • VPNv6 label is removed, IPv6 destination reached in next-hop
  • R6 (IPv6)
    • IPv6 destination reached

Use extended traceroute if you want to source from a specific IPv6 address.

R1#trace 2001:6:6:6::6

Type escape sequence to abort.
Tracing the route to 2001:6:6:6::6

  1 2001:10:1:2::2 1 msec 1 msec 1 msec
  2 ::FFFF:10.2.3.3 [MPLS: Labels 18/28 Exp 0] 1 msec 1 msec 1 msec
  3 ::FFFF:10.3.4.4 [MPLS: Labels 25/28 Exp 0] 1 msec 1 msec 1 msec
  4 2001:10:5:6::5 [AS 100] [MPLS: Label 28 Exp 0] 1 msec 1 msec 1 msec

  5 2001:10:5:6::6 [AS 100] 1 msec 1 msec 1 msec


Although all traceroute answers are given by the closest interface to the source ip, in some software releases in the last 6VPE router the traceroute answer is given by the IPv6 address on the PE-CE link.

You can use "no mpls ip propagate-ttl" on the first-hop 6VPE if you want to hide the ::FFFF: IPv4 hops.

  1 2001:10:1:2::2 1 msec 1 msec 1 msec
  2 2001:10:5:6::5 [AS 100] [MPLS: Label 28 Exp 0] 1 msec 1 msec 1 msec
  3 2001:10:5:6::6 [AS 100] 1 msec 1 msec 1 msec



Verification in every hop


Customer IPv6 router
R1#sh ipv6 route 2001::6:6:6:6
Routing entry for 2001::6:6:6:6/128
  Known via "bgp 1", distance 20, metric 0, type external
  Route count is 1/1, share count 0
  Routing paths:
    FE80::C805:EFF:FE2C:1C, FastEthernet0/0
      MPLS label: nolabel
      Last updated 01:47:39 ago



Provider 6VPE router
R2#sh bgp vpnv6 unicast vrf VPN 2001::6:6:6:6/128
BGP routing table entry for [100:1]2001::6:6:6:6/128, version 6
Paths: (1 available, best #1, table VPN)
  Advertised to update-groups:
     3
  1
    ::FFFF:5.5.5.5 (metric 4) from 5.5.5.5 (5.5.5.5)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:100:1
      mpls labels in/out nolabel/28


IOS-XR doesn't display the "::FFFF:" in front of the IPv4 next-hop (How Multi is MP-BGP in IOS-XR - Part #2).

VPNv6 label is 28

R2#sh mpls forwarding-table 5.5.5.5 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
19         18         5.5.5.5/32       0             Fa0/0.23   10.2.3.3
        MAC/Encaps=18/22, MRU=1500, Label Stack{18}
        CA070D4C0000CA050E2C0000810000178847 00012000
        No output feature configured


Transport label is 18

R2#sh ipv6 cef vrf VPN 2001::6:6:6:6 detail
2001::6:6:6:6/128, epoch 0, flags rib defined all labels
  recursive via 5.5.5.5 label 28
    nexthop 10.2.3.3 FastEthernet0/0.23 label 18


Transport label is 18, VPNv6 label is 28


You can follow the next-hop or the labels (like in CsC), but for easiness let's follow the labels this time.


Provider IPv4 Router
R3#sh mpls forwarding-table labels 18 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
18         25         5.5.5.5/32       45876         Fa0/0.34   10.3.4.4
        MAC/Encaps=18/22, MRU=1500, Label Stack{25}
        CA0119D80000CA070D4C0000810000248847 00019000
        No output feature configured


Transport label is 25, VPNv6 label is 28


Provider IPv4 Router
R4#sh mpls forwarding-table labels 25 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
25         Pop Label  5.5.5.5/32       45343         Fa0/0.45   10.4.5.5
        MAC/Encaps=18/18, MRU=1504, Label Stack{}
        CA0217AC0008CA0119D800008100026B8847
        No output feature configured


Transport label is removed, VPNv6 label is 28


Provider 6VPE router

R5#sh mpls forwarding-table labels 28 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
28         No Label   2001::6:6:6:6/128[V]   \
                                       2820          PO2/0      point2point
        MAC/Encaps=4/4, MRU=4474, Label Stack{}
        0F0086DD
        VPN route: VPN
        No output feature configured


R5#sh bgp vpnv6 unicast vrf A 2001::6:6:6:6/128
BGP routing table entry for [100:1]2001::6:6:6:6/128, version 6
Paths: (1 available, best #1, table VPN)
  Advertised to update-groups:
     1
  1
    2001:10:5:6::6 (FE80::C803:17FF:FEAC:8) from 2001:10:5:6::6 (6.6.6.6)
      Origin incomplete, metric 0, localpref 100, valid, external, best
      Extended Community: RT:100:1
      mpls labels in/out 28/nolabel


Use prefix/size to verify when doing bgp lookups.

R5#sh ipv6 route vrf VPN 2001::20:20:20:20/128
Routing entry for 2001::6:6:6:6/128
  Known via "bgp 100", distance 20, metric 0, type external
  Route count is 1/1, share count 0
  Routing paths:
    FE80::C803:17FF:FEAC:8, POS2/0
      MPLS label: nolabel
      Last updated 02:08:07 ago


VPNv6 label is removed, IPv6 destination reached in next-hop




IPv6 prefixes over an IPv4 PE-CE BGP session

Usually when doing 6PE or 6VPE, the BGP session between the PE and the CE (which is used for exchanging the IPv6 prefixes) is IPv6 based.

If you want to exchange IPv6 prefixes over an IPv4 PE-CE BGP session, then you must change the IPv6 next-hop in the PEs in both directions (and then reset the session) Otherwise you might have the control plane showing everything is fine, but most probably data plane won't work.

IOS
R2#sh bgp vpnv6 unicast all
BGP table version is 1, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 26:65001 (default for vrf VPN)
*  2001:10:2:8::/64 ::FFFF:10.2.8.8          0             0 65001 i



R2#sh bgp vpnv6 unicast all 2001:10:2:8::/64
BGP routing table entry for [26:65001]2001:10:2:8::/64, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  65001
    ::FFFF:10.2.8.8 (inaccessible) from 10.2.8.8 (10.8.8.8)
      Origin IGP, metric 0, localpref 100, valid, external
      Extended Community: RT:26:65001



IOS
router bgp X
 address-family ipv6 vrf VPN
  neighbor CE-IPv4 route-map SET-IPV6NH-IN-ROUTEMAP in
  neighbor CE-IPv4 route-map SET-IPV6NH-OUT-ROUTEMAP out
 exit-address-family

!
route-map SET-IPV6NH-IN-ROUTEMAP permit 10
 set ipv6 next-hop CE-IPv6

!
route-map SET-IPV6NH-OUT-ROUTEMAP permit 10
 set ipv6 next-hop PE-IPv6


In general:
  • PE=>CE (out)
    • set ipv6 next-hop PE-IPv6
  • PE<=CE (in)
    • set ipv6 next-hop CE-IPv6

After applying the route-map and resetting the session:

IOS
R2#sh bgp vpnv6 unicast all 2001:10:2:8::/64
BGP routing table entry for [26:65001]2001:10:2:8::/64, version 14
Paths: (1 available, best #1, table VPN)
  Advertised to update-groups:
     4
  65001
    2001:10:2:8::8 from 10.2.8.8 (10.8.8.8)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Extended Community: RT:26:65001
      mpls labels in/out 27/nolabel



In IOS-XR, you won't even get an IPv4 BGP session up, if there are no IPv6 addresses configured on the PE-CE connection.

The default order of IPv6 next-hop operation is the following:
  • use the IPv6 address defined in the route-map of the session
  • use the IPv6 address used for peering (directly connected interface or loopback)
  • use an IPv4-mapped IPv6 address
"no bgp default ipv6-nexthop" is also an option.

Also, sometimes in the CE you must enable ebgp-multihop for the PE session (2 hops at least), otherwise the remote IPv6 routes won't be installed in the CE's BGP table and you'll be getting messages "DENIED due to: non-connected MP_REACH NEXTHOP" (enable "debug bgp ipv6 unicast updates" to see these). This is probably a bug, since the next-hop (PE) is actually connected to the CE router.

A correct output of "sh bgp vpnv6 unicast" from a PE will include:
  • IPv6 routes from the directly connected CE
    • The next hop shown must be the directly connected CE IPv6 address (i.e. 2001:10:2:8::8)
  • IPv6 routes from other PEs
    • The next hop shown must be the remote PE IPv4 address (in v4-mapped IPv6 address format like.::FFFF:1.1.1.1 in IOS, or just 1.1.1.1 in IOS-XR)
Example:

IOS
R2#sh bgp vpnv6 unicast all
BGP table version is 23, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 26:65001 (default for vrf X)
*>i2001:10:1:7::/64 ::FFFF:1.1.1.1           0    100      0 65001 i
*> 2001:10:2:8::/64 2001:10:2:8::8           0             0 65001 i



IOS-XR
GSR#sh bgp vpnv6 unicast
BGP router identifier 19.19.19.19, local AS number 26
...

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 26:65001 (default for vrf VPN)
*>i2001:10:1:7::/64   1.1.1.1                  0    100      0 65001 i
*> 2001:10:20:20::/64 2001:10:19:20::20
                               0             0 65001 i


When doing the opposite and trying to exchange IPv4 prefixes over an IPv6 BGP session, you have to set manually the IPv4 next-hop

IOS-XR requires to enable the VPNv6 address-family before enabling the IPv6 address-family under a VRF.



Hints

If you get issues with IPv6 next-hops being inaccessible when they point to eBGP interfaces (while they shouldn't), try to shut/no shut the interface.

Before

R2#sh bgp ipv6 unicast 2001:10:1:7::/64
BGP routing table entry for 2001:10:1:7::/64, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  26 26
    2001:10:19:20::19 (FE80::C802:15FF:FE18:8) (inaccessible) from 10.19.20.19 (19.19.19.19)
      Origin IGP, localpref 100, valid, external


After

R2#sh bgp ipv6 unicast 2001:10:1:7::/64
BGP routing table entry for 2001:10:1:7::/64, version 6
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  26 26
    2001:10:19:20::19 from 10.19.20.19 (19.19.19.19)
      Origin IGP, localpref 100, valid, external, best


This is probably another bug.




2 comments:

  1. Hi Tassos,

    Great Blog. Very impressive work.!

    I was trying to simulate 6VPE with IOS on one end as PE and XR as another PE. I found a strange behavior when XR was learning the route from its CE2 (IOS)

    Topology: GNS3

    lo0 2002::7 IOS (CE1) --- IOS (PE1) --- MPLS cloud --- XR (PE2) --- IOS (CE2) lo0 2002::8

    Version:

    RP/0/0/CPU0:R5-PE2#sh ver
    Thu Oct 30 00:37:25.604 UTC

    Cisco IOS XR Software, Version 5.1.1[Default]
    Copyright (c) 2014 by Cisco Systems, Inc.


    <--- on XR

    RP/0/0/CPU0:R5-PE2#sh cef vrf B ipv6
    Thu Oct 30 00:11:22.721 UTC

    ::/0
    drop default handler
    2002::7/128
    recursive ::ffff:1.1.1.2
    2002::8/128
    recursive ::ffff:10.5.8.8 (?) <<<<<<<<<<< a question mark for the route learned from CE2
    2002:10:5:8::/64
    connected GigabitEthernet0/0/0/0.58
    2002:10:5:8::5/128
    receive GigabitEthernet0/0/0/0.58 <<<<<<<< connected route towards CE2
    2002:10:5:8::8/128
    2002:10:5:8::8 GigabitEthernet0/0/0/0.58

    <--- CEF on XR

    RP/0/0/CPU0:R5-PE2#sh cef vrf B ipv6 2002::8/128
    Thu Oct 30 00:11:28.940 UTC
    2002::8/128, version 22, drop adjacency, internal 0x4000001 0x0 (ptr 0xacba4628) [1], 0x0 (0x0), 0x400 (0xacc2b984)
    Updated Oct 29 23:55:58.154
    Prefix Len 128, traffic index 0, precedence n/a, priority 3
    via ::ffff:10.5.8.8, 0 dependencies, recursive, bgp-ext [flags 0x6020]
    path-idx 0 NHID 0x0 [0x0 0x0]
    next hop VRF - 'Unknown', table - 0xe0000003 <<<<<<<<<<<<<< unknown ?
    unresolved
    local label 16006
    labels imposed {None}
    RP/0/0/CPU0:R5-PE2#

    <--- ping doesn’t work too
    RP/0/0/CPU0:R5-PE2#ping vrf B 2002::8 count 5 source 2002:10:5:8::5 verbose
    Wed Oct 29 23:56:27.082 UTC
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 2002::8, timeout is 2 seconds:
    .UUUU
    Success rate is 0 percent (0/5)
    RP/0/0/CPU0:R5-PE2#

    <--- now change the NH on R8-CE2 for BGP updates towards R5-PE2

    neighbor 10.5.8.5 route-map SET-NH out
    route-map SET-NH permit 10
    set ipv6 next-hop 2002:10:5:8::8
    R8-BGP-CE2#

    <--- after clearing the session, we see the below:

    RP/0/0/CPU0:R5-PE2#sh cef vrf B ipv6
    Thu Oct 30 00:15:59.382 UTC

    ::/0
    drop default handler
    2002::7/128
    recursive ::ffff:1.1.1.2
    2002::8/128
    recursive 2002:10:5:8::8

    <--- ping works

    RP/0/0/CPU0:R5-PE2#ping vrf B 2002::8 count 5 source 2002:10:5:8::5 verbose
    Thu Oct 30 00:16:11.551 UTC
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 2002::8, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 9/11/19 ms
    RP/0/0/CPU0:R5-PE2#


    I am unable to understand this behavior on why XR was not able to resolve the NH when received as the v4 mapped format.

    Secondly, even if the NH was not resolved, the route was sent to the other PE..!!

    Have you seen this issue in your lab?













    ReplyDelete
  2. Hi Tassos,
    The PE XR config of the 6VPE case
    neighbor 6VPE-IPv4
    remote-as 100
    update-source Loopback0
    address-family vpnv6 unicast
    !
    should it now also include address-family ipv4 unicast
    Thanks

    ReplyDelete