Same IP addresses in different PEs

[jyubero]

Hi.

We have the same IP Addresses in different PEs. These addreses are not redistributed by routing. These IPs belongs to loopbacks that we use for communication with CEs.

The problem is that the P routers receive these addresses by LDP.

Then in the P routers we have event of this type:

Nov 23 14:02:58.183: %TAGCON-3-DUP_ADDR_RCVD: Duplicate Address 10.10.10.1 advertised by peer 10.1.1.8:0 is already bound to 10.2.1.28:0

Nov 23 14:02:58.183: %TAGCON-3-TDPID: peer 10.1.1.8:0, TDP Id/Addr mapping problem (rcvd TDP address PIE, bind failed).

When the LDP flaps, then the events appears again.

This is not a problem for the traffic, because there are not traffic directed to these addresses, but the logs are fulled of these events.

Are there any method to avoid these events or that LDP announce these addresses?

Thanks

[swaroop.potdar · Accepted solution]

Hi,

Without much insight into the assignment of duplicate loopback addresses for PE-CE peering

You can filter out these prefixes to be not advertised by LDP as below.

mpls ldp advertise-labels old-style

mpls ldp advertise-labels for 10

access-list 10 permit 10.1.1.0 0.0.0.255

access-list 10 permit 10.2.1.0 0.0.0.255

access-list 10 deny any

HTH-Cheers,

Swaroop

[jyubero]

Hi Swaroop

I have tested with access-list for advertise-labels and for 'neighbor X.X.X.X labels accept ...'

But the events continues appearing.

I think that it's not a problem related with advertised prefixes.

I suppose that is related with the interfaces of the PE:

ROUTER#sh mpls ldp neighbor

...

Duplicate Addresses advertised by peer:

10.10.10.1

ROUTER#

[mheusing · Accepted solution]

Hi,

Unfortunately this can not be filtered as of today. The addresses can be viewed by "show mpls ldp neighbor x.x.x.x". The underlying reason is that a LSR has to find the proper label for a routing table entry. The RIB contains next hop IPs, which typically are assigned to a physical interface. Labels are announced by LDP and neighbors identified by the LDP ID x.x.x.x:0

Example:

LDP ID 10.1.1.1:0

route 192.168.1.0/24 via 10.1.2.3

To know which LDP ID, hence which label, should be used for 192.168.1.0/24 the LSRs announce all their IP addresses through LDP.

From section 2.7 in RFC 5036:

"... To enable LSRs to map between a peer LDP Identifier and the peer's addresses, LSRs advertise their addresses using LDP Address and Withdraw Address messages."

So unfortunately for you, the behaviour is part of the LDP standard.

Hope this helps! Please rate all posts.

Regards, Martin

[swaroop.potdar]

I believe you have configured exactly as given as,

mpls ldp advertise-labels

mpls ldp advertise-labels for x

wont work

the below would work as given previously.

mpls ldp advertise-labels oldstyle

no mpls ldp advertise-labels

mpls ldp advertise-labels for x.

also you will have to specify a deny any at the end of the acl, even though its a explicit deny.

------

Enforce this as a policy on all the PE/P routers in the network so everyone will only have a local binding for the duplicate prefix but wont advertise it to their peers. (Even the PE where this duplicate is assigned he would have a local binding of imp-null but wont advertise it to any.)

HTH-Cheers,

Swaroop

[jyubero]

Hi Swaroop.

I have tried your configuration:

tag-switching advertise-tags oldstyle

no tag-switching advertise-tags

tag-switching advertise-tags for 10

access-list 10 deny any

I don't receive any prefix associated to this PE, but i still receive the local interfaces and the event appears again.

I think that Martin has reason, the Peer redistribute the local addresses for binding the routes.

Thanks.

[mheusing]

Hi Swaroop,

The message

Nov 23 14:02:58.183: %TAGCON-3-DUP_ADDR_RCVD: Duplicate Address 10.10.10.1 advertised by peer 10.1.1.8:0 is already bound to 10.2.1.28:0

can not be influenced by suppressing the advertisement of labels, because it happens BEFORE any label is exchanged when setting up the LDP session as described in my previous post.

Nov 23 14:02:58.183: %TAGCON-3-TDPID: peer 10.1.1.8:0, TDP Id/Addr mapping problem (rcvd TDP address PIE, bind failed).

This message denotes the problem the LSR has: IP addresses, i.e. potential next hop addresses in the RIB are beound to LDP IDs. The message denotes, that this is not possible because an IP address is advertised twice in LDP.

This points to a potential problem, as it could result in a broken label switched path, IF the duplicate IP was used as a next hop in the RIB.

So the issue does not have to do with label announcements, but the LDP FEC-To-NHLFE (Forwarding Equivalence Class To Next Hop Label Forwarding Entry) mapping.

Hope this helps! Please rate all posts.

Regards, Martin

[swaroop.potdar]

Hi Martin,

It seems my interpretation of the log message is not right.

But I would like to simulate this problem and re-verify, as I have not come across this message in my deployment experiences.

It would be nice if you can give or elaborate a topology where in this can be simulated.

Cheers,

Swaroop

[jyubero]

Hi Swaroop.

The topology is very simple. I have these events in our network and i have simulated in lab.

See the attached file.

Regards.

Jose

[jyubero]

The file

[swaroop.potdar]

Thanks Jose/Martin.

Thats correct I did a quick simulation and found the same results. (Learning is a never ending curve, I am happy it goes on)

Apart from this confusion, a quick question, why dont you put the loopbacks meant for the CE's in respective vrf's.

HTH-Cheers,

Swaroop

[jyubero]

Hi Swaroop.

These loopbacks are used for CPEs, several of them external to vrf.

The PE is used for both services, with and without vrfs.

Regards.

Jose

[oldcreek12]

LDP will not advertise those IP addresses that are not in default VRF.