Broadband PPPoE over MPLS Backbone Issue !

Unanswered Question
Jun 8th, 2010
User Badges:
  • Silver, 250 points or more

Hi All


I am looking for some pointers for an issue I am stuck with on Broadband PPPoE across MPLS Backbone.


I am implementing PPPoE from User LAN GW to the Broadband RAS using an MPLS L2 VPN as transport

across the MPLS Backbone. The setup works all good with the MPLS Psuedowire with Normal TE Tunnels

running in the Core.


The Problem is the moment I switch to EXP aware TE Tunnels to achieve CBTS(Class Based Tunnel Selection)

to implement MPLS AToM Vll(Virtual Leased Line),my PPPoE session goes down at the Broadband RAS.


I have not tried to do any debug or anything till now,but I definitely see the session for the User being not active and

the IP being returned to the local pool.


Any pointers to understand this typical behaviuor over EXP aware TE Tunnel for the PPPoE Session. The PPPoE

session works all fine for the normal non-exp aware TE Tunnels.


Setup is like this

                                         NAT                                                             MPLS Traffic Engineering Tunnel

CE_LAN---(OSPF)--LAN_GW--(PPPoE Dialer Interface1)---edge1.pop1--core1.pop1-edge1.noc------BRAS--(EBGP)--Internet GW

                                                                                                           MPLS L2                              MPLS L2

                                                                                                           Xconnect                              Xconnect


Regards

Vaibhava Varma

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
Loading.
Giuseppe Larosa Tue, 06/08/2010 - 09:40
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Vaibhava,

Some notes follow:


Class Based TE is for transport of IPv4 traffic I guess, your MPLS L2 VPN frames get an MPLS EXP field but you may need to mark in some way to use a specific class of tunnels, otherwise the risk is to try to use a "default" tunnel and it has to be seen if this kind of traffic has enough resources to be successfully setup.


Another point to check is MTU if there is an additional overhead for Class Based traffic engineering but this should lead to problems to carry big user packets but PPPoE negotiation should be successful


Hope to help

Giuseppe

Vaibhava Varma Tue, 06/08/2010 - 10:08
User Badges:
  • Silver, 250 points or more

Hi

qiusalar (hope I am spelling ur name correct :-) )



Thats a catchy point you made for a default tunnel . I tested using two tunnels of EXP 5 and EXP 0 3 4 but it was not working.


I did no marking for the attachment circuit assuming that it will be automatically mapped to the EXP but now I think since its L2 attachment I might need

to explicitly mark them for EXP and push them across TE Tunnel.


Thanks much for your pointer. I will check this and get back to you on this.


Hope it resolves the issue now.


Thanks & Regards

Vaibhava Varma

Vaibhava Varma Tue, 06/08/2010 - 15:01
User Badges:
  • Silver, 250 points or more

Hi qiuslar


The explicit marking of the attachment circuit to an EXP worked cool and got my PPPoE session negotiated cool.

Everything working fine now. So the issue boiled down to the L2 VPN being not marked to any EXP and there

was no non-exp aware routing path available making it show bad.Thanks much for your valuable pointer



Can you give me one more pointer. I can see an IP assigned to the PPPoE Client fine and even all the Unicast Routing and

Multicast Rotuing is working fine except that I can not ping the PPPoE Client's IP back from my Broadband RAS or Internet Gateway


Any Pointers . Attached are some snapshots for your reference.



Thanks and Regards

Vaibhava Varma

Giuseppe Larosa Wed, 06/09/2010 - 08:12
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Vaibhava,


nice to know that now with explicit marking  it is working with class based TE.


About second issue I see from your attachment:



S        10.0.0.0/8 is directly connected, Null0

on device Broadband RAS#
S        10.0.0.0/8 is directly connected, Null0
C        10.0.1.1/32 is directly connected, Loopback0
C        10.10.10.1/32 is directly connected, Virtual-Access1.1
so it is correct that the packet is silently dropped
Broadband RAS#ping 10.0.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.10.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
I don't know how it was before but now sending to null0 means discarding.
Hope to help
Giuseppe

Actions

This Discussion