Skip to main content

MPLS Routing Loop




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

Popular posts from this blog

DHCP option 121

http://tools.ietf.org/html/rfc3442 This is used to add a classless  static route to the DHCP clients. To add option 121 to a Mikrotik DHCP server, it's value is specified in HEX. The format is as follows. 0xnnddddddddgggggggg where n=mask, d=destination, g=gateway. To convert ip address to HEX, you convert each octet, so 192=C0, 168=A8, 55=37, 1=01 You can use a tool such as  http://www.miniwebtool.com/ip-address-to-hex-converter/?ip=192.168.55.1 Example: To add a route to the destination network of 192.168.55.0/24 via gateway 172.16.10.1. /ip dhcp-server option add name=classlessroutes code=121 value=0x18C0A837AC100A01 where 18 is 24 in hex. *note: depending on the subnet mask, you may only need to specify 0-4 octets. In fact only the non-zero, or network portion of the subnet. Here is a table from the RFC. subnet mask Number of octets 0 0 1- 8 1

Mikrotik Bridge Horizon

To achieve similar functionality to Cisco's private VLANS, where all ports are on the same L2 segment, but cannot exchange packets, you can use Mikrotik's Bridge Horizon feature. Basically, every port in a bridge is assigned a horizon value, and RouterOS will only forward frames to other interfaces in the bridge that have different horizon values. This means that you assign the same horizon value to the interfaces that you don't want to be able to communicate. For example, you want to bridge all your customers and use a single /24 subnet and the same gateway. Typically this is bad and poses a huge security risk, not to mention performance issues. If you assign the same horizon value to the customer interfaces, then the router will not forward traffic between customers. Customer A will not be able to ping Customer B. If you had a server, such as an IP-PBX that all customers needed to access, and you were lazy and added it to the bridge, then you would assign a diff

Mikrotik mac address filtering

Playing with an RB493G and wanted to allow only a certain list of mac addresses to be able to connect. We all know this type of security is in no way fool proof. The 493G has 2 switch chips in it and ports 2-5 are on switch2 and ports 1 and 6-9 are on switch1 Much like /ip firewall filter rules, switch rules are checked chronologically (top down). And like /ip firewall filter rules, you must specify a deny rule. Although there is no 'deny' rule as such, you can just specify a redirect to null (specify no port) which achieves the same result.