PWHE or Routed VPLS (IRB, Routed PW)

[filopeter]

Hello,

could someone explain me the benefits of PWHE over Routed VPLS configuration on IOS XR platform?

Both configurations provide the termination of access pseudowires (PWs) into a Layer 3 (VRF or global) domain.

So I would like to know if the key differentiator is the provisioning of QoS policies and ACLs directly on the pw-ether interface, or there is something more behind which I am missing.

### Router VPLS configuration example ###
!
l2vpn
  bridge group bg
   bridge-domain bd
    vfi vfi
     neighbor 10.10.10.10 pw-id 10
!
   routed interface BVI1
!
interface BVI1
  vrf A
  ipv4 address 192.168.1.1 255.255.255.252
!

### PWHE configuration example ###
!
l2vpn
 xconnect group pwhe
   p2p pwhe
     interface PW-Ether1
     neighbor ipv4 10.10.10.10 pw-id 10
!
generic-interface-list LIST
 interface GigabitEthernet0/0/0/1
!
interface PW-Ether1
vrf A
ipv4 address 192.168.1.1 255.255.255.252
attach generic-interface-list LIST
!

Best Regards,

P.

[Aleksandar Vidakovic · Accepted solution]

There are two main aspects in which PWHE solution is better for scenarios where you have a single PW and single attachment circuit:

1. Resource allocation. This is obviously relevant in a high scale deployment scenario.
   1. ARP entries related to BVI are distributed across all line cards. ARP entries related to PW-Ether are distributed on LCs that own interfaces from the generic interface list. This replication is required because you can't predict on which interface will a packet be received on a PW.
   2. QoS config on BVI is replicated across all NPs on all line cards. QoS config on PW-Ether is replicated only across those NPs that own interfaces from the generic interface list.
   3. bridge-domain implies that MAC addresses are learned by the router, which makes little sense in case of a single PW and single attachment circuit.
2. QoS: on BVI you can only configure policing and marking, whereas on PW-Ether we also support queuing action. 

Hope this helps,

Aleksandar

[Michalis Milaitis]

VPLS uses mac learning. You can have multiple attachment circuits/pseudowires that terminate on the same bridge domain. The second example (PWHE) is a point to point circuit (xconnect). 

[TIDAFI]

Hello, 

i ma trying to use PWHE inside a VPLS bridge group on ASR9K IOS XR 6.2.2 in order to terminate a PWs on attachment circuit interface using  interface PW-Ether , however once commited an error message apear showing that this kind of interface is nor supported in bridge group , below the configuration i made : 

RP/0/RSP1/CPU0:N-ASR9K-PESNG-1(config-l2vpn-bg-bd-ac)#show configuration failed
Thu Dec 8 15:28:31.951 CET
!! SEMANTIC ERRORS: This configuration was rejected by
!! the system due to semantic errors. The individual
!! errors with each failed configuration command can be
!! found below.

l2vpn
bridge group test_pw-ether
bridge-domain test_pw-ether
interface PW-Ether1338
!!% Invalid argument: Interface not supported
!
!
!
!
end

Somone could help please ! 

Regards 

[smilstea]

Can you try making an xconnect instead?

Sam

[Aleksandar Vidakovic]

hi @TIDAFI ,

if you use a PW-Ether sub-interface (configured as l2transport) in this context instead of the main interface, the configuration commit will be accepted. 

If you really need a main PW-Ether interface in this context, that is actually identical to configuring a neighbour under bridge-domain. Can you use this approach?

PW-Ether is a very complex forwarding path through the NP. We recommend to use it only when there's no simpler solution that delivers the same service. That's why we never considered supporting a main PW-Ether interface as AC in a BD. 

/Aleksandar

[TIDAFI]

Hello Aleksandar,
thanks for your reply,
PW-ether sub-interface configured as L2transport is a l2 interface that can not support IP address inside ,
If i can explain in more detail, my need is to finish PWs arrived in BD in L3 interface directly using PW-ether instead of using a dédicated l2 interface applied in the BD that will be connected physicaly to another L3 interface (using local physical loop on the router) .

Regards 

[Aleksandar Vidakovic]

Attachment circuit in a bridge domain must by definition be a l2transport interface. If you want to terminate L3 in a bridge domain, use the BVI.

[TIDAFI]

I have tried to use BVI, however unfortunatly BVI L3 interface can not support BNG events to trigger authentification requests to RADIUS Server ---> in my case l3 interface should handle dhcp requests coming from clients trough PWs : 

Below the configuration of a standard l3 interface using physical loop on the router : 

 interface HundredGigE0/0/0/1
description Vers Hu0/1/0/1.100 - PORT SERVICES (L3)
vrf dhcp-clients 
ipv4 point-to-point
ipv4 address 192.168.0.1
arp learning disable
service-policy type control subscriber BNG-EVENT_DHCP
load-interval 30
ipsubscriber ipv4 l2-connected
initiator dhcp
initiator unclassified-source
!
!

Regards 

[Aleksandar Vidakovic]

I'm afraid that these are two conflicting requirements. BNG on BVI is not supported. The only way to terminate L3 in a BD is via BVI.

Since you want to provide BNG services, you need the PW-Ether interface or sub-interface to be a L3. We used to support BNG only on PW-Ether sub-interfaces, but in more recent releases you should be able to use PW-Ether main interface as well as BNG access interface.

I'm not quite sure why do you need a bridge-domain in this solution. It shouldn't be required.

[TIDAFI]

In fact, our Customers are connected to Collecting PEs (named PEC) and then from each PEC we have an XCs that terminate in VPLS BD in remote service PE (PES) who has the role of BNG, currently what we are using is a local physical loop in OF, it means in the first end of physical loop we have one interface in Layer 2 applied as AC in VPLS BD , and remote end of physical loop is L3 interface that terminate L3 and provide BNG service, 

Hope my explaination is clear, 

Regards  

[Aleksandar Vidakovic]

Yes, this is clear now. If you want to get rid of the physical loop on PES, instead of terminating multiple PWs in a VPLS BD, each of those PWs should be bound to one PW-Ether interface. So instead of using one PW-Ether interface per bridge domain (as you are trying to do), you will end up with one PW-Ether per PW. If you care concerned with the number of PW-Ether interfaces that you'd end up with, you can see the max supported scale of PWHE interfaces by running the "sh l2vpn capability" command.

best,

/Aleksandar

[TIDAFI]

Hello, 

With XConnect it works but in my case i need to use a bridge VPLS since all PWs arrive to a single AC, do you know from witch version of IOS XR PWHE in bridge VPLS is supported ? 

Thanks in advance 

Regards 

[smilstea]

As of right now PWHE is only supported with xconnect. There is some discussion about adding the feature you are talking about, I recommend contacting your sales team so they can help prioritize the request internally.

Sam