I have 2 PE routers (loopback ip: 172.18.255.101 and 172.18.255.102) which are connected to 2 P routers respectively. In one of the LAN interface between the 2 PE routers, I have HSRP running with VIP 172.18.94.99. This particular LAN interface doesn't attached to any VRF. This LAN subnet is not advertised to the MPLS network as well. HOwever, I received the below message in the P routers where these 2 PE routers connected to. What could be the reason causing this ?
%TAGCON-3-DUP_ADDR_RCVD: Duplicate Address 172.18.94.99 advertised by peer 172.18.255.102:0 is already bound to 172.18.255.101:0
%TAGCON-3-TDPID: peer 172.18.255.102:0, TDP Id/Addr mapping problem (rcvd TDP address PIE, bind failed)
Please make sure that both routers have the following:
tag-switching tdp router-id Loopback0
where the loopback 0 is the TDP RID for each.
I would assume the issue is related to the next hop IPs announced by your PE routers. Have a look at the IPs with "show mpls ldp neighbor detail". Each LDP peer announces all its IP addresses, which can be seen below "Addresses bound to peer LDP Ident:
This is needed to select the proper forwarding label from the next hop IP in the RIB. Example:
Routing table contains
10.0.0.0/8 next hop 192.168.1.1
LDP peer ID is 172.16.1.1:0
To pick the proper label for 10.0.0.0/8 from the LIB to be used in the LFIB, a LSR needs to know, to which LDP peer the IP next hop 192.168.1.1 belongs.
Thus the IPs are announced through LDP.
In your case the message can simply point out the fact, that both LDP peers announce the same next hop IP.
This explanation is further supported by looking at
The result can be a wrong LFIB entry in your P routers and potentially broken connectivity. One solution is not to use HSRP but dynamic routing between your P and PE devices.
Hope this helps!
Going by the example given it would mean that if 3 LSR's are connected on a an ethernet(subnet x) . And of them 2 LSR's are announicng the same subnet (subnet y) to the 3rd LSR with the next hop on subnet x for both the LSR's.
Then it would mean we would get this message. But somehow I feel the 3rd LSR would load balance between both the LDP' ID rather than give a duplicate ID add recd message.
Correct me if wrong. And also how would running HSRP between the any LSR's affect the forwarding table. As it would only give a virtual IP for end points who want to reach that virtual IP. and the response to the requests to the virtual Ip would be catered by the active HSRP router.
And here in this case there is HSRP between the 2 PE's and the HSRP subnet which is not announced in MPLS. So for any upstream LSR's it would be a "no route" situation rather than duplicate IP addr. And if the route was there then it would load balance between the appropriate next-hop interface IP's of the 2 PE's.
This should not happen even when using HSRP as only the active HSRP node should send the VIP address as part of its reachable next hops.
I have come across a bugid documenting the behavior you are seeing but it was affecting rather old code (12.2(17)SX). What level of code are you running on the HRSP routers?
Hi Harold and Swaroop,
I agree that it should not happen for HSRP, as this would rule out the use of HSRP in a MPLS or better LDP environment.
Swaroop, the LDP peers do announce their configured interface IPs in through LDP. This has nothing to do with routing per se, but with IP next hop-to-FEC mapping. It is easy to reproduce this in a lab environment:
where i1 or i2 denotes an interface of the respective router. Assume the following IP addressing: R1(i2)=10.1.1.1 and R3(i2)=10.1.1.1 This for sure is not recommended from an IP addressing point of view, yet it would allow IP forwarding (for networks aside 10.1.1.0). From an MPLS point of view forwarding could be broken. The reason is, that R2 does not "know" which label to insert into the LFIB when an IP next hop of 10.1.1.1 shows up in the RIB.
The LDP announcement of "Addresses bound to peer" in LDP can be translated to: "If you see one of those IP addresses as next hop in the routing table, then take my label for that network". In my example this unfortunately is told by both, R1 and R3 to R2, which in turn gets a problem.
The error message in the original post is then created by R2 to denote "his misery".
So a workaround would be to enable dynamic routing or to upgrade IOS as it seems to be a bug and not the expected behaviour.
I agree that it looks like a bug. I did a quick test with 12.0S and it works like a charm.
It looks more like a bug. As it works all right with or without HSRP in the lab.
Its most likely non reproducible with a good code.
Thanks for the replies. The IOS used for the 2 PE routers is c7200-spservicesk9-mz.124-6.T2.bin.
The P router that seen the error messages runs s72033-advipservicesk9_wan-mz.122-18.SXF6.bin.
I checked thru but not seen any bugs related to it.
Appreciate if you can share the bug that you come across with this. thanks.