CSCuv37114 - PWHE Generic Interface list enhancement for sub-interfaces

[siportalsrl]

I hope this feature will be released soon! We have many ASR901 for traffic aggregation of customer PPPoE connections. Requests come from EoMPLS circuits to ASR9K routers through subinterfaces.

So I need to use subinterfaces (ASR9K with 6.0.2) and this happen:

RP/0/RSP0/CPU0:ASR9001-A#RP/0/RSP0/CPU0:Nov 24 16:14:10.047 : pppoe_ma[380]: PW-Ether1.1: I dst ffff.ffff.ffff src 0023.33aa.b1ea: len 46 0x11090000001001010000010300080d00000100001518000000000000000000000000000000000000000000000000

RP/0/RSP0/CPU0:Nov 24 16:14:10.047 : pppoe_ma[380]: [PADI-Recv]: PW-Ether1.1 peer-mac 0023.33aa.b1ea
RP/0/RSP0/CPU0:Nov 24 16:14:10.048 : pppoe_ma[380]: [PADI-Recv]:    vlan-id-outer 140
RP/0/RSP0/CPU0:Nov 24 16:14:10.048 : pppoe_ma[380]: [PADI-Recv]:    Service-name:
RP/0/RSP0/CPU0:Nov 24 16:14:10.048 : pppoe_ma[380]: [PADI-Recv]:    Host-uniq: 0d00000100001518
RP/0/RSP0/CPU0:Nov 24 16:14:10.048 : pppoe_ma[380]: PW-Ether1.1: O dst 0023.33aa.b1ea src e0ac.f113.809f: len 35 0x11070000001d01010000010300080d0000010000151801020009415352393030312d41

ASR9K receive the PADI and try to answer with a PADO. So the customer request comes. The answer packet, that you can see in the PW-Ether1.1 is lost.

Traffic is coming from giga0/0/0/16.1 interface but it is not possible insert it in the "generic-interface-list":

!
generic-interface-list PWHE_appoggio
   interface GigabitEthernet0/0/0/16
!
interface PW-Ether1
  attach generic-interface-list PWHE_appoggio
!
interface PW-Ether1.1
  service-policy type control subscriber policy2
  pppoe enable bba-group bba1
  encapsulation dot1q 140
! 

As you can see the PADO packet is lost: "packets output" is zero:

PW-Ether1.1 is up, line protocol is up
   Hardware is VLAN sub-interface(s), address is e0ac.f113.809f
   Internet address is Unknown
   Encapsulation 802.1Q Virtual LAN, VLAN Id 140, loopback not set,
   ...
   4945 packets input, 316480 bytes, 0 total input drops
   92 drops for unrecognized upper-level protocol
   Received 4941 broadcast packets, 0 multicast packets
   0 packets output, 0 bytes, 0 total output drops
   Output 0 broadcast packets, 0 multicast packets

Someone has experienced the same problem? Do you think that there is a workaround?

Thankyou

Gianrico Fichera

[Douglas Ramirez · Accepted solution]

Hi Gianrico

Defect CSCuv37114 has no workaround available. If you think that this is critical for your operation please contact your Cisco Account representative.

Thx,

Douglas

[xthuijs]

I take it that your PW come in on an mpls enabled vlan subinterface, is that right?

would it be possible to migrate that access link where the pw comes in on to be plain either (no vlan encap). that would bypass this current limitation.

the logging you show says that we can't transmit the packet out of the pw, which is likely caused by the fact that the egress interface (gig main) isnt found to be mpls enabled.

regards

xander

[siportalsrl]

Yes, I have an EoMPLS xconnect coming from many subinterfaces:

RP/0/RSP0/CPU0:ASR9001#sh run int gigabitEthernet 0/0/0/16
interface GigabitEthernet0/0/0/16

RP/0/RSP0/CPU0:ASR9001#sh run int gigabitEthernet 0/0/0/16.1
interface GigabitEthernet0/0/0/16.1
  ipv4 address 192.168.118.185 255.255.255.252
  encapsulation dot1q 333
!

It is not possible to enable MPLS in Giga0/0/0/16 because of the configuration above. If I try to enable it:

RP/0/RSP0/CPU0:ASR9001-A#sh run mpls ldp | include 0/16
Tue Dec 6 16:20:39.173 MET
    interface GigabitEthernet0/0/0/16
    interface GigabitEthernet0/0/0/16.1
 interface GigabitEthernet0/0/0/16
 interface GigabitEthernet0/0/0/16.1

It remains disabled in the main interface:

RP/0/RSP0/CPU0:ASR9001-A#show mpls interfaces | include 0/0/16
Tue Dec 6 16:23:17.288 MET
GigabitEthernet0/0/0/16.1 Yes Yes No Yes

We have a network that use VLAN encapsulation. Our customer use PPPoE. I'm thinking about the possibility to use MPLS-TE tunnels to carry the EoMPLS and then terminate the PPPoE in a PWHE interface. Do you know if it works?

It seems that with p2p l2vpn in the xconnect group you can't use tunnel interfaces.

thankyou

[xthuijs]

yeah I dont think that using mpls te tunnels will simplify the solution/solve the problem at hand.

if you cant move the mpls access interface from 16.1 to main interface 16 (so remove the vlan config) then another option may be to terminate the PW on the adjacent node and pull in plain ether (so ether/<dot1q>/pppoe) into the bng.

the current restriction that we have to design around is the issue of the pwhe can only have a main interface in its pindown list.

I'll also check in to see if there are a lot of difficulties supporting subinterfaces in the pindown-list.

cheers!

xander