cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
419
Views
0
Helpful
12
Replies
Highlighted

Verifying 6PE forwarding

I am having problems resolving 6PE routes on a few routers in our test environment and I'm looking for direction on how to troubleshoot 6PE.  

 

We have a v6 lableled-unicast route that has a next-hop set to a 6pe address.  On some routers, we get cef recursion to the next-hop and on others we do not.  

 

Here's a working router(crr01):

RP/0/RSP0/CPU0:crr01#show cef ipv6 2001:506:100:f240::192:206 detail
2001:506:100:f240::192:206/128, version 21592958, internal 0x5000001 0x0 (ptr 0x7c1ea06c) [1], 0x0 (0x0), 0x208 (0x7213e888)
 Updated Sep  7 20:56:16.430
 Prefix Len 128, traffic index 0, precedence n/a, priority 4
 BGP Attribute: id: 0x48ea, Local id: 0x4bea, Origin AS: 0, Next Hop AS: 0

  gateway array (0x71cc5a78) reference count 1, flags 0x4038, source rib (7), 0 backups
                [1 type 1 flags 0x48441 (0x7216fcd0) ext 0x0 (0x0)]
  LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
  gateway array update type-time 1 Sep  7 20:56:16.430
 LDI Update time Sep  7 20:56:16.430
   via ::ffff:96.34.224.204/128, 3 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0x7c94b050 0x0]
    recursion-via-/128
    next hop VRF - 'default', table - 0xe0000000
    next hop ::ffff:96.34.224.204/128 via ::ffff:96.34.224.204:0
     next hop 96.34.8.5/32 BE5          labels imposed {24146 319008}


    Load distribution: 0 (refcount 1)

    Hash  OK  Interface                 Address
    0     Y   Unknown                   ::ffff:96.34.224.204:0

 

Here is a router which is not recursing correctly(brr01):

RP/0/RP1/CPU0:bbr01#show cef ipv6 2001:506:100:f240::192:206 detail
2001:506:100:f240::192:206/128, version 32473621, internal 0x5000001 0x0 (ptr 0x74d60554) [1], 0x0 (0x0), 0x208 (0x7328c118)
 Updated Sep  7 21:06:34.906
 Prefix Len 128, traffic index 0, precedence n/a, priority 4
 BGP Attribute: id: 0x6050, Local id: 0x471d, Origin AS: 0, Next Hop AS: 0

  gateway array (0x72bf8ce4) reference count 1, flags 0x403a, source rib (7), 0 backups
                [1 type 1 flags 0x148441 (0x732be248) ext 0x0 (0x0)]
  LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
  gateway array update type-time 3 Sep 10 17:31:17.911
 LDI Update time Sep  7 21:06:34.906
   via ::ffff:96.34.224.204/128, 0 dependencies, recursive, platform-non_preferred [flags 0x6000]
    path-idx 0 NHID 0x0 [0x0 0x0]
    recursion-via-/128
    next hop VRF - 'default', table - 0xe0000000
    unresolved
     labels imposed {319008}


    Load distribution: 0 (refcount 1)
Hash OK Interface Address 0 Y Unknown drop

Both routers have a valid cef entry with a valid label for the v4 address that corresponds to the 6PE address.

 

RP/0/RSP0/CPU0:crr01#show cef 96.34.224.204/32
96.34.224.204/32, version 344, internal 0x1000001 0x0 (ptr 0x771113c0) [3], 0x0 (0x71ebc9e8), 0xa28 (0x7213e180)
 Updated Jul 18 22:31:58.095
 Prefix Len 32, traffic index 0, precedence n/a, priority 3
   via 96.34.8.5/32, Bundle-Ether5, 21 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x0 [0x7181cad8 0x0]
    next hop 96.34.8.5/32
    local adjacency
     local label 24032      labels imposed {24146}
RP/0/RP1/CPU0:bbr01#show cef 96.34.224.204/32
96.34.224.204/32, version 164846, internal 0x1000001 0x0 (ptr 0x7cbb8990) [3], 0x0 (0x72def720), 0xa28 (0x7bd00208)
 Updated Aug  7 22:00:09.543
 Prefix Len 32, traffic index 0, precedence n/a, priority 3
   via 96.34.11.3/32, Bundle-Ether2, 8 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x0 [0x7271d3f4 0x0]
    next hop 96.34.11.3/32
    local adjacency
     local label 1048523      labels imposed {24016}
   via 96.34.8.1/32, Bundle-Ether4, 8 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 1 NHID 0x0 [0x7271d1fc 0x0]
    next hop 96.34.8.1/32
    local adjacency
     local label 1048523      labels imposed {24032}

It looks as though both hosts should have connectivity and valid control-plane entries to make this work but one system is not recursing the next-hop correctly and the other is.  Are there any additional 6PE troubleshooting commands I can use?

 

Both systems are running IOS-XR 5.3.3 BTW.

 

Thanks

12 REPLIES 12
Highlighted
Cisco Employee

Re: Verifying 6PE forwarding

This is a problem

 

 

NHID 0x0 [0x0 0x0]

i am unsure why its unresolved, maybe we can check the following

 

show rib ipv6 opaques ip-nexthop
show cef vrf default ipv6 unresolved detail
show route (vrf?) 96.34.224.204 detail

 

 

Highlighted

Re: Verifying 6PE forwarding

Thanks @tkarnani.

 

Here's what you asked for:

RP/0/RP1/CPU0:bbr01x1sacc#show rib ipv6 opaques ip-nexthop
RP/0/RP1/CPU0:bbr01x1sacc#show cef vrf default ipv6 unresolved detail
2001:506:100:f240::192:206/128, version 32473621, internal 0x5000001 0x0 (ptr 0x74d60554) [1], 0x0 (0x0), 0x208 (0x7328c118)
 Updated Sep  7 21:06:34.973
 Prefix Len 128, traffic index 0, precedence n/a, priority 4
 BGP Attribute: id: 0x6050, Local id: 0x471d, Origin AS: 0, Next Hop AS: 0

   via ::ffff:96.34.224.204/128, 0 dependencies, recursive, platform-non_preferred [flags 0x6000]
    path-idx 0 NHID 0x0 [0x0 0x0]
    recursion-via-/128
    next hop VRF - 'default', table - 0xe0000000
    unresolved
     labels imposed {319008}
2001:506:100:f240::192:207/128, version 32473622, internal 0x5000001 0x0 (ptr 0x74d5c774) [1], 0x0 (0x0), 0x208 (0x7328cc30)
 Updated Sep  7 21:06:34.973
 Prefix Len 128, traffic index 0, precedence n/a, priority 4
 BGP Attribute: id: 0x6050, Local id: 0x471d, Origin AS: 0, Next Hop AS: 0

   via ::ffff:96.34.224.205/128, 0 dependencies, recursive, platform-non_preferred [flags 0x6000]
    path-idx 0 NHID 0x0 [0x0 0x0]
    recursion-via-/128
    next hop VRF - 'default', table - 0xe0000000
    unresolved
     labels imposed {319024}
RP/0/RP1/CPU0:bbr01x1sacc#show route 96.34.224.204 detail

Routing entry for 96.34.224.204/32
  Known via "isis default", distance 115, metric 10200, type level-1
  Installed Aug  7 22:00:09.600 for 4w6d
  Routing Descriptor Blocks
    96.34.11.3, from 94.34.192.204, via Bundle-Ether2
      Route metric is 10200
      Label: None
      Tunnel ID: None
      Extended communities count: 0
      Path id:1       Path ref count:0
      NHID:0x0(Ref:0)
    96.34.8.1, from 94.34.192.204, via Bundle-Ether4
      Route metric is 10200
      Label: None
      Tunnel ID: None
      Extended communities count: 0
      Path id:2       Path ref count:0
      NHID:0x0(Ref:0)
  Route version is 0xb (11)
  No local label
  IP Precedence: Not Set
  QoS Group ID: Not Set
  Flow-tag: Not Set
  Route Priority: RIB_PRIORITY_NON_RECURSIVE_MEDIUM (7) SVD Type RIB_SVD_TYPE_LOCAL
  Download Priority 1, Download Version 145928969
  No advertising protos.

Unsure as to why that hop is unresolved.  I can mpls ping between the systems which is strange.

RP/0/RP1/CPU0:bbr01x1sacc#ping mpls ipv4 96.34.224.204/32 source 96.34.224.192

Sending 5, 100-byte MPLS Echos to 96.34.224.204/32,
      timeout is 2 seconds, send interval is 0 msec:

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
  'L' - labeled output interface, 'B' - unlabeled output interface,
  'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
  'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
  'P' - no rx intf label prot, 'p' - premature termination of LSP,
  'R' - transit router, 'I' - unknown upstream index,
  'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/12/53 ms

Traceroute looks good as well:

RP/0/RP1/CPU0:bbr01x1sacc#traceroute mpls ipv4 96.34.224.204/32 source 96.34.224.192

Tracing MPLS Label Switched Path to 96.34.224.204/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
  'L' - labeled output interface, 'B' - unlabeled output interface,
  'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
  'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
  'P' - no rx intf label prot, 'p' - premature termination of LSP,
  'R' - transit router, 'I' - unknown upstream index,
  'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

  0 96.34.8.0 MRU 9202 [Labels: 24032 Exp: 0]
L 1 96.34.8.1 MRU 9202 [Labels: 24146 Exp: 0] 3 ms
L 2 96.34.8.5 MRU 1500 [Labels: implicit-null Exp: 0] 3 ms
! 3 96.34.9.124 3 ms

Thanks for helping me out....

Highlighted
Cisco Employee

Re: Verifying 6PE forwarding

we should have some information in this

show rib ipv6 opaques ip-nexthop

can you provide from working node?

we expect to learn the next hop from bgp

bgp puts it in the rib in the form of

Opaque key: ::Nexthop

Highlighted

Re: Verifying 6PE forwarding

Thanks @tkarnani.  Let me give you a more complete output.

 

Working box including your previous requests for information:

RP/0/RSP0/CPU0:crr01#show rib ipv6 opaques ip-nexthop
Summary of 6PE/6VPE IP over MPLS opaque data in IPv6 RIB:

Opaque key: ::ffff:96.34.224.204
Opaque key: ::ffff:96.34.224.205
RP/0/RSP0/CPU0:crr01#show cef vrf default ipv6 unresolved detail
RP/0/RSP0/CPU0:crr01#show route 96.34.224.204 detail

Routing entry for 96.34.224.204/32
  Known via "isis default", distance 115, metric 10100, type level-1
  Installed Jul 18 22:31:58.321 for 7w5d
  Routing Descriptor Blocks
    96.34.8.5, from 94.34.192.204, via Bundle-Ether5
      Route metric is 10100
      Label: None
      Tunnel ID: None
      Extended communities count: 0
      Path id:1       Path ref count:0
      NHID:0xe(Ref:50)
  Route version is 0x5 (5)
  No local label
  IP Precedence: Not Set
  QoS Group ID: Not Set
  Flow-tag: Not Set
  Route Priority: RIB_PRIORITY_NON_RECURSIVE_MEDIUM (7) SVD Type RIB_SVD_TYPE_LOCAL
  Download Priority 1, Download Version 66478507
  No advertising protos.

Router showing the issues:

RP/0/RP1/CPU0:bbr01#show rib ipv6 opaques ip-nexthop
RP/0/RP1/CPU0:bbr01#show cef vrf default ipv6 unresolved detail
2001:506:100:f240::192:206/128, version 32473621, internal 0x5000001 0x0 (ptr 0x74d60554) [1], 0x0 (0x0), 0x208 (0x7328c118)
 Updated Sep  7 21:06:35.119
 Prefix Len 128, traffic index 0, precedence n/a, priority 4
 BGP Attribute: id: 0x6050, Local id: 0x471d, Origin AS: 0, Next Hop AS: 0

   via ::ffff:96.34.224.204/128, 0 dependencies, recursive, platform-non_preferred [flags 0x6000]
    path-idx 0 NHID 0x0 [0x0 0x0]
    recursion-via-/128
    next hop VRF - 'default', table - 0xe0000000
    unresolved
     labels imposed {319008}
2001:506:100:f240::192:207/128, version 32473622, internal 0x5000001 0x0 (ptr 0x74d5c774) [1], 0x0 (0x0), 0x208 (0x7328cc30)
 Updated Sep  7 21:06:35.119
 Prefix Len 128, traffic index 0, precedence n/a, priority 4
 BGP Attribute: id: 0x6050, Local id: 0x471d, Origin AS: 0, Next Hop AS: 0

   via ::ffff:96.34.224.205/128, 0 dependencies, recursive, platform-non_preferred [flags 0x6000]
    path-idx 0 NHID 0x0 [0x0 0x0]
    recursion-via-/128
    next hop VRF - 'default', table - 0xe0000000
    unresolved
     labels imposed {319024}
RP/0/RP1/CPU0:bbr01#show route 96.34.224.204 detail

Routing entry for 96.34.224.204/32
  Known via "isis default", distance 115, metric 10200, type level-1
  Installed Aug  7 22:00:09.746 for 4w6d
  Routing Descriptor Blocks
    96.34.11.3, from 94.34.192.204, via Bundle-Ether2
      Route metric is 10200
      Label: None
      Tunnel ID: None
      Extended communities count: 0
      Path id:1       Path ref count:0
      NHID:0x0(Ref:0)
    96.34.8.1, from 94.34.192.204, via Bundle-Ether4
      Route metric is 10200
      Label: None
      Tunnel ID: None
      Extended communities count: 0
      Path id:2       Path ref count:0
      NHID:0x0(Ref:0)
  Route version is 0xb (11)
  No local label
  IP Precedence: Not Set
  QoS Group ID: Not Set
  Flow-tag: Not Set
  Route Priority: RIB_PRIORITY_NON_RECURSIVE_MEDIUM (7) SVD Type RIB_SVD_TYPE_LOCAL
  Download Priority 1, Download Version 145928969
  No advertising protos.

In our network, both devices are learning about the v4 next-hops via ISIS.  Neither of the routers I'm looking at have the v4 next-hop in their v4 or v6 BGP tables.  The closest thing either of them have to that /32 is the summary route which is a /23 for the MPLS range, 96.34.224.0/23.

 

Thanks

Highlighted
Cisco Employee

Re: Verifying 6PE forwarding

this is the issue, we are missing

Opaque key: ::ffff:96.34.224.204
Opaque key: ::ffff:96.34.224.205

 

for a vrf route, can we see on both working/non-working how we are learning the next hop from BGP?

 

show bgp vrf XXXXX ipv6 unicast

 

 

Highlighted

Re: Verifying 6PE forwarding

@tkarnani,

These routes are in the default vrf only.  We do not have 6VPE traffic running over them currently.  What we are trying to do is use the BGP-LU routes as label-switched next-hops for other BGP routes.  The 6PE addresses are not learned via BGP and are only carried in ISIS.  If we aren't learning those routes from BGP, what other attributes would be required for a router to correctly install those routes as valid 6PE entires?

 

Here are the current routing entries for the target 6PE address on each box.

 

Working router:

RP/0/RSP0/CPU0:crr01#show route 96.34.224.204 detail

Routing entry for 96.34.224.204/32
  Known via "isis default", distance 115, metric 10100, type level-1
  Installed Jul 18 22:31:58.330 for 7w5d
  Routing Descriptor Blocks
    96.34.8.5, from 94.34.192.204, via Bundle-Ether5
      Route metric is 10100
      Label: None
      Tunnel ID: None
      Extended communities count: 0
      Path id:1       Path ref count:0
      NHID:0xe(Ref:50)
  Route version is 0x5 (5)
  No local label
  IP Precedence: Not Set
  QoS Group ID: Not Set
  Flow-tag: Not Set
  Route Priority: RIB_PRIORITY_NON_RECURSIVE_MEDIUM (7) SVD Type RIB_SVD_TYPE_LOCAL
  Download Priority 1, Download Version 66478507
  No advertising protos.

Non-working router:

RP/0/RP1/CPU0:bbr01#show route 96.34.224.204 detail

Routing entry for 96.34.224.204/32
  Known via "isis default", distance 115, metric 10200, type level-1
  Installed Aug  7 22:00:09.753 for 4w6d
  Routing Descriptor Blocks
    96.34.11.3, from 94.34.192.204, via Bundle-Ether2
      Route metric is 10200
      Label: None
      Tunnel ID: None
      Extended communities count: 0
      Path id:1       Path ref count:0
      NHID:0x0(Ref:0)
    96.34.8.1, from 94.34.192.204, via Bundle-Ether4
      Route metric is 10200
      Label: None
      Tunnel ID: None
      Extended communities count: 0
      Path id:2       Path ref count:0
      NHID:0x0(Ref:0)
  Route version is 0xb (11)
  No local label
  IP Precedence: Not Set
  QoS Group ID: Not Set
  Flow-tag: Not Set
  Route Priority: RIB_PRIORITY_NON_RECURSIVE_MEDIUM (7) SVD Type RIB_SVD_TYPE_LOCAL
  Download Priority 1, Download Version 145928969
  No advertising protos.

  

I highlighted the NHID from the non-working router as that seems to be un-set.  Not sure if 0x0 is a valid ID, but could that be an issue?  Like I said, connectivity is otherwise fine between these systems so the exact disconnect is not readily apparent.

 

Thank you.

Highlighted
Cisco Employee

Re: Verifying 6PE forwarding

In order for the 6PE address to work, we must learn it from BGP, it must be installed in the rib with the opaque value for it to be used by cef.

 

i do not know the reason why, but there seems to be some *magic* behind the scenes or restrictions that require this

Highlighted

Re: Verifying 6PE forwarding

Should it be learned as a v4 or v6 route?

Highlighted
Cisco Employee

Re: Verifying 6PE forwarding

We need to learn it as a v6 route from bgp

show bgp ipv6 labeled-unicast v6prefix detail
show bgp ipv6 unicast v6prefix detail

 hopefully we should have our v6 route with a v4 next hop, once we receive this we should populate

show rib ipv6 opaques ip-nexthop

Highlighted

Re: Verifying 6PE forwarding

@tkarnani, we have a Cisco RE looking into this for us.  I will post the outcome when I hear back.  Thank you for your quick responses and all of your help.

Highlighted
Beginner

Re: Verifying 6PE forwarding

Hi,

 

Are you using RSVP TE tunnels (and no LDP) in your setup?  If so, you will need to enable 'mpls ldp' *even if* you do not use LDP in your network -- just configure 'mpls ldp', apply router-id, but do not list any interfaces for LDP to run on.

 

We had the same issue with eXR 6.4.2 on ASR9906.  We do not use LDP in our core, just RSVP-TE.  'sh mpls forward' shows no labels being created and CEF would refuse to program 6PE properly until 'mpls ldp' was added to config.

 

Highlighted

Re: Verifying 6PE forwarding

Thanks @James Jun.  Unfortunately, we are using LDP in our network and we have labels for those endpoints.

 

RP/0/RP0/CPU0:bbr01#show mpls forwarding 
24052  24045       96.34.224.204/32   BE2          96.34.11.3      0
       24052       96.34.224.204/32   BE4          96.34.8.1       0
24053  24046       96.34.224.205/32   BE2          96.34.11.3      0
       24053       96.34.224.205/32   BE4          96.34.8.1       0

I wish it was that simple and thanks for the suggestion.

CreatePlease to create content
Content for Community-Ad

Cisco COVID-19 Survey