Certain destination IP addresses are not routable within certain parts of the network, and appear to loop. This has been narrowed down to the label swap on a Cisco 6500 for the next hop of a GRE tunnel [point2point].
As per the LFIB, the Cisco 6500 is appending label 133 for network 10.10.32.1 and sending it out tun0, but appears to be snatching the packet back again, as it has a local label of 133 for the network 10.10.32.70/32.
##Traceroute from test router (simplified for readability)
10.10.64.220 and 10.8.8.2 are c6500 interfaces, the latter being the GRE interface.
[admin@rtr3] > /tool trace 10.10.32.1
# ADDRESS STATUS
1 10.10.32.137 <MPLS:L=873,E=0> **local-label for 10.10.32.1
2 10.10.64.220 <MPLS:L=71,E=0> **local-label for 10.10.32.1
**appends label 133 as per LFIB
3 10.8.8.2 <MPLS:L=133,E=0> **takes the packet back as per LIB
4 10.10.64.214 <MPLS:L=218,E=0> **appends label for 10.10.32.70
5 10.10.64.135 <MPLS:L=422,E=0> **pops label
6 10.10.64.66 **reads original ip header and appends
label for 10.10.32.1
7 10.10.64.67 <MPLS:L=1032,E=0> **
8 10.10.64.134 <MPLS:L=835,E=0> **
9 10.10.64.220 <MPLS:L=71,E=0> ** and carries on until the TTL expires
#show mpls ldp bindings local-label 71
lib entry: 10.10.32.1/32, rev 1474
local binding: label: 71
#show mpls ldp bindings local-label 133
lib entry: 10.10.32.70/32, rev 636
local binding: label: 133
#show mpls forwarding-table labels 71
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
71 133 10.10.32.1/32 22346897 Tu0 point2point
No routing loops occur when the router preceeding the c6500 pops the label. This is obviously due to using the routing table.
Possible solutions perhaps specify next hop IP for the label rather than the p2p interface, somehow preventing local labels from having the same labels as the remote gre end point.
I believe if I rebuild the LFIB, this problem will go away... until next time. I would like to find a solution, whether it be a bug fix or best practice, or perhaps something that I am missing or haven't RTFM'd properly.
Comments
Post a Comment