Hello Samuel,
I have a feeling you have stumbled across a bug. I have been able to replicate this behavior using two routers interconnected via a direct Ethernet interconnection running PPPoE.
What I observed using Wireshark was that when I pinged the PE's loopback from CE, pings failed because CE sent unlabeled ICMP packets to CE (which is correct) but the PE responded by sending MPLS-labeled ICMP replies back to CE, and CE dropped them. After further investigation, the CE was found to advertise its PPP-negotiated IP address from its Dialer0 interface in LDP using an explicit non-null label, just as if that prefix was a remotely-learned network. This behavior is incorrect - the CE should have advertised this prefix with implicit-null label or should not have advertised it at all. As a result, PE started using this label when sending packets to CE's IP address, and the CE dropped them.
In my lab, I have tried to replicate your configuration to a reasonable degree. The CE negotiated an IP address of 100.100.100.1. The PE was using the IP 1.3.5.7/32 on its loopback.
Note that CE has created a forwarding entry in its LFIB for its own negotiated IP address:
CE(config)#do show mpls fo
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 1.3.5.7/32 0 Di0 point2point
17 Untagged 100.100.100.1/32 918 Di0 point2point
CE(config)#
That is unusual - there are also other interfaces created on the CE but they do not have any mapping created and inserted into the LFIB.
Moreover, CE has advertised this prefix to PE:
PE(config)#do show mpls fo
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 17 100.100.100.1/32 0 Vi1.1 point2point
17 Pop tag 15.15.15.0/24 0 Vi1.1 point2point
PE(config)#do show ip cef 100.100.100.1
100.100.100.1/32, version 32, epoch 0, attached, connected, cached adjacency to Virtual-Access1.1
0 packets, 0 bytes
tag information set
local tag: 16
fast tag rewrite with Vi1.1, point2point, tags imposed: {17}
via Virtual-Access1.1, 0 dependencies
valid cached adjacency
tag rewrite with Vi1.1, point2point, tags imposed: {17}
Note that PE learned the label 17 for the Di0's IP address at CE, and is using it to communicate with 100.100.100.1. For some reason, the CE is unable to process such packets and it drops them. Also note that there is another network 15.15.15.0/24 learned from the CE which is also directly attached to it but which is correctly recognized with the implicit-null label, and which was not explicitly mentioned in the LFIB output on CE. This is how the 100.100.100.1/32 entry should have looked like - but it does not, and I believe this is the symptom of the bug.
To summarize, this issue is created by the fact that after CE negotiates its own IP address via IPCP, it assigns it an explicit non-null label instead of treating that IP address as a locally-attached prefix, and advertises a label mapping for this prefix to PE, forcing it into using that label when communicating with CE. It is important that this problem arises only when using the ip address negotiated command on CE. I have verified that if using a statically configured IP address on the CE router, no bogus label mappings are advertised and the connection is stable.
A workaround is possible by preventing the CE from advertising a label mapping for its own Di0's IP address. Unfortunately, I have not found a way how to filter received label mappings on PE, but only how to filter label mapping being sent. Therefore, this filtering has to be done on the CE, and if the CE is not assigned a constant IP address then the ACL has to cover the entire IP local pool defined on the PE.
The configuration of the workaround on the CE would be as follows:
ip access-list standard LDP_Mappings
deny 100.100.100.0 0.0.0.255 ! This is the range of the IP local pool used on PE
permit any
mpls ldp advertise-labels for LDP_Mappings
no mpls ldp advertise-labels
This configuration appears to prevent the CE from advertising its negotiated IP address on Di0 in a label mapping, thus making sure that CE-PE communication itself is unlabeled.
Please give it a try and let me if it worked. You can also raise a TAC ticket directly from this thread - consider doing that please. If this is indeed a bug then it definitely should be resolved.
Best regards,
Peter
