11-29-2016 08:40 AM
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
Solved! Go to Solution.
12-02-2016 10:01 AM
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
12-02-2016 10:01 AM
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
12-06-2016 05:57 AM
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
12-06-2016 07:36 AM
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
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
12-06-2016 07:51 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide