cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2098
Views
10
Helpful
9
Replies

MPLS over PPP , supported or not

Samuel De Wever
Level 1
Level 1

Dear,


Since I am getting very different answers from one to another, I am posting it now in the MPLS map.

Is MPLS over PPP supported or not? I have tested it heavily but not get it working. I have put the mpls ip on the Dialer of my CE device (3725) and mpls ip on the virtual-template of me PE (7200). The LDP neighbor comes up, but I cannot ping it and after some minutes its showing down again.


any help please

9 Replies 9

Peter Paluch
Cisco Employee
Cisco Employee

Hello Samuel,

MPLS is fully supported on links with PPP encapsulation. See the RFC 3032 for more information.

However, the problem you are dealing with here seems not to be related to the MPLS-labeled packets themselves but rather to a different problem. The LDP session created between your two devices is a TCP-based session with UDP-encapsulated Hello packets - a completely normal and usual TCP/UDP communication. There is no MPLS labeling used to create or maintain this LDP session. Therefore, if the LDP session flaps, there must be a different reason for it.

Can you please post the configuration of both your devices? And also please post the debug messages appearing at the console at the time of the flap.

Best regards,

Peter

Dear Peter,


Please find my configs below:

PE router (Cisco 7200 - Running IOS 12.2-22.SRE2)

!
boot-start-marker
boot system flash
boot-end-marker
!
security passwords min-length 1
logging console notifications
enable secret 5 *****************************

!
aaa new-model
!
!
aaa authentication login default local
aaa authentication enable default enable
aaa authentication ppp default group radius local
aaa authorization exec default local
aaa authorization network default group radius none
!
!
!
!
!
aaa session-id common
ip source-route
ip cef
!
!
ip vrf vlan1

rd 39721:100
route-target export 39721:100
route-target import 39721:100
!

bba-group pppoe global
virtual-template 1

!

interface Loopback0
description INT
ip address 1.3.5.7 255.255.255.255

interface GigabitEthernet0/3
mtu 1540
no ip address
media-type gbic
speed 1000
duplex full
no negotiation auto
!
interface GigabitEthernet0/3.120
encapsulation dot1Q 120
pppoe enable group global

!
interface Virtual-Template1
ip unnumbered Loopback0
ip load-sharing per-packet
peer default ip address pool default

mpls ip
mpls label protocol ldp
keepalive 2
ppp mtu adaptive
ppp authentication pap
ppp multilink
ppp multilink links minimum 1
ppp multilink fragment maximum 2

!

radius-server attribute nas-port format d
radius-server host ********* auth-port 1812 acct-port 1813 key 7 **********************

radius-server vsa send authentication

CE DEVICE ( 3725 - running IOS 12.4-15.T14)

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
ip cef
!
!
!
!
ip vrf vlan1

rd 39721:100
route-target export 39721:100
route-target import 39721:100

mpls label protocol ldp

controller DSL 0/0
mode atm
line-term cpe
line-mode 2-wire line-zero
dsl-mode shdsl symmetric annex B
line-rate auto

interface ATM0/0
no ip address
no atm ilmi-keepalive
pvc 8/35
  encapsulation aal5snap
  pppoe-client dial-pool-number 1

interface Dialer0
ip address negotiated
encapsulation ppp
dialer pool 1
dialer-group 1
mpls ip
ppp authentication pap callin
ppp pap sent-username ************** password 0 ***********

mpls ldp router-id Dialer0 force

Router#sh users
    Line       User       Host(s)              Idle       Location
*  0 con 0                idle                 00:00:00

  Interface    User               Mode         Idle     Peer Address
  Vi2                             PPPoE        00:00:19 1.3.5.7

*Jul 26 12:18:44.595: %LDP-5-NBRCHG: LDP Neighbor 1.3.5.7 (1) is UP

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.3.5.7, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Router#

*Jul 26 12:21:44.627: %LDP-5-NBRCHG: LDP Neighbor 1.3.5.7:0 (1) is DOWN (Session KeepAlive Timer expired)
*Jul 26 12:21:48.951: %BGP-5-ADJCHANGE: neighbor 1.3.5.7 Up
*Jul 26 12:21:51.271: %LDP-5-NBRCHG: LDP Neighbor 1.3.5.7:0 (1) is UP

When I disable MPLS on virtual-template or Dialer interface, I am able to ping the PE router.


Rgds,

Samuel

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

Hello Peter,

very good job

I had some doubts after having seen Samuel's configuration but you have done some tests and pointed to the issue

Best Regards

Giuseppe

I have noticed the issues with PPPoE also.  Tested on 12.4 24T4 and 15.0M4.

Once I add the LDP access list as above and a static IP on the dialer it works.

Anyone know if this is by design or a bug?

I would like to be able to assign addresses through Radius but if we have to staticaly assign our edge routers I guess that is ok too.

Hello Feene1,

the LDP router-id is supposed to be a stable address on the device typically that of a loopback interface.

>> Once I add the LDP access list as above and a static IP on the dialer it works.

When the IP address on the dialer is static and not the result of IPCP negotiation the dialer interface is treated as a normal interface.

I'm afraid this depends from MPLS implementation and this may be by design rather then a SW bug.

By the way, if we try to change the MPLS LDP router-id on the fly, the change is not active immediately unless we add the force option.

We can consider the use of MPLS over PPPoE a corner case that is not covered by current MPLS code implementation.

Hope to help

Giuseppe

Dear,


After our last discussion I have worked with this on Cisco 3745 and it worked smootly.

Now I was testing this feature on the Cisco 2651XM. With the Cisco 12.3(26) software, all is working perfect.
Since we want to support SHDSL WICs in the device, I was forced to move to 12.3T version. Here, the LDP neighbor is comming up but MPLS is not working correctly:

Router#sh mpls forwarding-table

16     Untagged    1.3.5.7/32  0          Vi1        point2point
17     Aggregate   1.115.0.12/30[V]  0

Tag 16 should be POP tag. Packets sent from the PE to CE are arriving at the CE, but the CE is not answering them.

I believe this is a bug but I was wondering if their is a workaround.

Rgds,

Samuel

When I ran into an IOS that didnt work - I put a static IP on the dialer interface and it popped up.

Something to try.

I tried that already yesterday but this was not solving the issue.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: