BNG + PWHE Untagged

benediktsv · ‎02-07-2017

Hi all

I have trunks connected to wholesale providers, providing xDSL/FTTH etc and the users are delivered to us via L2 trunks tagged.

I have still 7600 SUP720's terminating those connections and bit stuck using that platform (remote locations)

So I plan to xconnect it to the ASR9k running BNG - tested with 5.3.3 and 6.1.2

the AC is like this

interface GigabitEthernet2/15.2000

description *** Incoming IPoE sessions ***
encapsulation dot1Q 2000
xconnect 1.1.1.1 666 pw-class EoMPLS
mtu 1510

where 1.1.1.1 is the BNG

here is the PEWE config

interface PW-Ether666
mtu 1524
mac-address 1212.9000.8666
attach generic-interface-list GI-Te0-1
l2overhead 20

interface PW-Ether666.1
ipv4 address 2.2.2.2 255.255.255.224
service-policy type control subscriber PM_BNG
pppoe enable bba-group default
load-interval 30
ipsubscriber ipv4 l2-connected
initiator dhcp
initiator unclassified-source
!
encapsulation ambiguous dot1q any

l2vpn

pw-class BRAS-XConnect
encapsulation mpls
protocol ldp
transport-mode ethernet

xconnect group BNG

p2p TestLab-7600-test
interface PW-Ether666
neighbor ipv4 3.3.3.3 pw-id 666
pw-class BNG-XConnect

This is not working - the sub interface is not picking up the the traffic (all counters 0)

Is this possible or just not supported ?

(you can't configure BNG on the main interface) - works perfectly on a loop into a BE interface

- Benni

smailmilak · ‎02-07-2017

Hi,

I have never configured PW-HE (will do in a few weeks). What I do when configuring L2VPN is that I put an IPv4 address on the interface and do a simple ping. If ping is successful then L2VPN is ok and I continue with PPPoE/IPoE config.

Have you tried it?

interface PW-Ether666.1
ipv4 address 2.2.2.2 255.255.255.224
encapsulation ambiguous dot1q any

Xconnect is up?

Aleksandar Vidakovic · ‎02-07-2017

Your approach is good.

Instead of using "encapsulation ambiguous dot1q any", why don't you simply declare the PW-Ether as l2transport interface?

/Aleksandar

benediktsv · ‎02-07-2017

I did some testing with this

but I get incorrect config

either doing untagged on pe666.1 l2transport or pe666 main interface.

!!% Subinterface or Layer 2 configuration conflicts with existing configuration, or configuration in this commit: Cannot configure an interface as L2 when L3 configuration exi

can you supply an example ?

- Benni

Aleksandar Vidakovic · ‎02-07-2017

hi Benni,

sure. For configuration example please search for BRKSPG-2003 from Cisco Live 2016 (Berlin). There's a section on PWHE.

regards,

/Aleksandar

smailmilak · ‎03-15-2017

Hi,

I am trying to establish a PW-HE connection between BNG and C7609 but I am not able to reach (ICMP) the other side even the xconnect is up.

BNG HW:

- RSP 880 SE

- MOD80 SE

Running on 6.1.3

I will paste my config and a simple drawing. I hope that someone can tell me what I am doing wrong. I have followed the configuration steps in official Cisco config guide. If this configuration is correct, then I have to troubleshoot a little bit more.

xthuijs · ‎03-15-2017

hi smail,

can you try transport mode ethernet? in vlan mode, the tag is service delimiting and I think that the a9k side may strip that from its processing on reception.

cheers!

xander

smailmilak · ‎03-16-2017

Hi,

it's working only when I have an IP address on PW-Ether 10.

It's not working on the PW-Ether 10.992 (subinterface)

interface PW-Ether10
mtu 1540
ipv4 address 1.1.1.1 255.255.255.252
mac-address baba.deda.baba
attach generic-interface-list PWHE_10
l2overhead 64

So the PW-Ether 10 is the trunk interface, right?

Do I need additional config to put the PW-Ether 10 and PW-Ether10.992 in same bridge domain or does it work automatically?

This is working:

VC Type 5 and IP address on PW-Ether 10

Not working:
VC type 5 or VC 4 and IP address on PW-Ether 10.992.

In the guide it says this:

The VLAN ID is allowed only if VC type is 4. Which makes sense.

http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-1/lxvpn/configuration/guide/vc41crs/vc41vpls.html#48935

I have tried to add PW-Ether10.992 under xconnect, but I get an error saying "PWHE Sub-interface not allowed in xconnect"

xthuijs · ‎03-16-2017

pw-type4 I am always struggling with, not only find a reasonable purpose :) but also that different implementations follow different rules... the statement in the doc is not correct. a pw-type 5 which is effectively a "trunk" type CAN carry vlans, but the vlan is service insignificant. that is fine, because we want to use that vlan for the user separation. pwtype5 can carry plain ehter.

Now the thing is for a pwtype 4 we MUST have a vlan, and it is treated as service delimiting if there is no vlan, a dummy one is inserted.

it looks like the pw from the 7600 is not inserting the vlan. before it goes over the pw, that is why this vlan lands on the pw main interface.

I have a few config pieces for you from the xcon device and the pwhe side.

XCON:

xconnect group pwhe

p2p pwhe

interface Bundle-Ether100.60

neighbor ipv4 9.9.9.9 pw-id 60

pw-class mpls

interface Bundle-Ether100.60 l2transport

encapsulation dot1q 60

! Note! no pop!

PWHE side:

l2vpn

pw-class mpls

encapsulation mpls

control-word

!

xconnect group pwhe

p2p pwhe

interface PW-Ether60

neighbor ipv4 8.8.8.8 pw-id 60

pw-class mpls

!

interface PW-Ether60.60

service-policy type control subscriber sub

pppoe enable bba-group X

load-interval 30

encapsulation dot1q 60

!

SHOW:

Group pwhe, XC pwhe, state is up; Interworking none

AC: PW-Ether60, state is up

Type PW-Ether

Interface-list: pwhe

Replicate status:

BE100: success

MTU 1504; interworking none

Internal label: 24000

Statistics:

packets: received 144472, sent 0

bytes: received 9246208, sent 0

PW: neighbor 8.8.8.8, PW ID 60, state is up ( established )

PW class mpls, XC ID 0xc0000001

Encapsulation MPLS, protocol LDP

Source address 9.9.9.9

PW type Ethernet, control word enabled, interworking none

PW backup disable delay 0 sec

Sequencing not set

PW Status TLV in use

MPLS Local Remote

------------ ------------------------------ -----------------------------

Label 24001 24007

Group ID 0x320 0x5a0

Interface PW-Ether60 Bundle-Ether100.60

MTU 1504 1504

Control word enabled enabled

PW type Ethernet Ethernet

VCCV CV type 0x2 0x2

(LSP ping verification) (LSP ping verification)

VCCV CC type 0x7 0x7

(control word) (control word)

(router alert label) (router alert label)

(TTL expiry) (TTL expiry)

------------ ------------------------------ -----------------------------

Incoming Status (PW Status TLV):

xander

smailmilak · ‎03-16-2017

Hi and thanks for replying.

VLAN 992 on C7609 is coming from a trunk port and I am not using service instance where I can pop the VLAN. The VLAN should leave the C7609.

Maybe it's an interoperability issue? Your example has two XRs

In this output you will see that the BNG does not see control word on the remote side even it's configured on C7609 (see second screenshot).

xthuijs · ‎03-16-2017

ah ok you know it smells to me that the 7600 is stripping the vlan by default on a trunk interface.

check the cisco live id 2904 from orlando 2013, where I had some comparison overviews as to how 7600 does vlan stripping vs 9k. what you need to have for your case is the remote PE (7600 here) preserve the vlan tag and not make it service delimiting that is make it type5.

we're almost there:)xander

smailmilak · ‎03-17-2017

Hi,

I did not had the time today to test it but I am sure that you are correct.

Customer is always using SVI on C7600 and xconnect on it (eompls or vfi).

On the other side it's either C7600 with ES+ LC or A9K with a subinterface and "rewrite ingress tag pop 1 symmetric".

With PW-HE we don't have that and this is the reason why PW-Ether 10 is working but not the subintf with vlan tag.

I think that the solution is to configure the xconnect on a service instance (ES+ LC) without pop, right?

Few more questions:

1. PW-HE is supported only with xconnect (p2p), not VPLS? Config guide does not mention VPLS.

2. PW-HE is officially supported on -SE LC's but technically it should work on TR (MOD200 and 400) also? We would like to terminate around 5 customers using PWHE. Without any fancy features, only QoS policing. Is it safe? What is the worst case scenario?

xthuijs · ‎03-17-2017

correct that's right!! we don't want to pop the tag on ingress indeed, we want to leave that in tact for the PWHE in this case.

on the other hand, since you are tying the PW to a single vlan instance, we'd be only receiving one vlan in that pw anyway. in that regard it wouldnt really matter to terminate that on the main interface vs subinterface, and there'd be only one subintf.

now thing is that if you want to run BNG, then you will want a subinterface ( that restriction we are lifting btw, to allow subscr on main interfaces, whether that is (10)gig, bundle or pwhe.

the reason why we suggested SE cards for PWHE is when QOS is in play. without the SE, and having a qos policy, you'd be running out of queues on the pindownlist interfaces very quickly.

technically the PWHE side doesnt know if the other side is a bridge domain or xconnect. having pwhe in a BD is more like a BVI on a loooohooong stick :)

regards

xander

smailmilak · ‎03-17-2017

Great!

It's for BNG, so we need that subintf. For now it's not doable because we would need to move allll xconnects from SVI to service instances. They are not paying enough :D

We can test it on one PWHE subintf and document it. They can migrate all other VLAN's later. Maybe we will get BNG support on main interfaces by then :)

Cisco is doing a great job. In 6.1.2 Cisco introduced "autoroute destination" and this feature helped me a lot today to solve an issue on a huge project.

So, you don't recommend to use PWHE on TR's because of policing (we will not use shaping)? I could tell our customer to police the traffic before the xcon...not sure if it's always possible, tough.

xthuijs · ‎03-19-2017

hey smail! ah great to hear! on the 612! :)

yeah we are productizing the main interface piece also! check/follow CSCvd22621

Correct it is best to use SE cards for BNG and PWHE. PWHE has that pindown-list which is similar as bundle members effectively. all features are programmed on all intfs in the pindown list.

with TR's only 8 queues, shaping is out of the question here quickly. and with 8k policers you dont have a lot of room for subscriber policing either!

cheers!

xander