Encapsulation default on ASR903 issue vs XR BVI limitation

[satitcha]

Hi SP Folk,

Background
I need to provide L3 termination for CE device.
CE device on the production having no vlan tagging capability.

Scenario. (See also attachment , diagram)

There are ASR9K and ASR903 connected together,
running VPLS as following

ASR9K configuration
Version 4.3.2

interface BVI598
  mtu 9180
 ipv4 address 98.98.98.11 255.255.255.0

l2vpn
 bridge group star-MonitorSW-5012
  bridge-domain VLAN598
   mtu 9180
   vfi 598
    neighbor 192.168.10.7 pw-id 510590598  
   routed interface BVI598

ASR903
Version 3.13.1S

l2 vfi 598 manual
 vpn id 510590598
 bridge-domain 598
 mtu 9180
 neighbor 172.16.10.11 encapsulation mpls

interface GigabitEthernet0/5/5
mtu 9180
 no ip address
 negotiation auto
 no keepalive
 service instance 598 ethernet
  encapsulation default
  bridge-domain 598

NOTE. VPLS PW status already be verified.

Issue

1. CE device can not ping to bvi598 interface on XR device.

NOTE.

Customer's report,

This configuration used to be worked fine on previous ASR903 Version 3.10.S .

It not work after upgrading ASR903 to 3.13.1S.

2. I also can not ping from BDI interface to BVI interface, vice and versa.

if i try to change AC to be,

(try to remove vlan tagging before packet going to PW.)

ASR903
interface GigabitEthernet0/5/5
 service instance 598 ethernet
  encapsulation dot1q 598
  rewrite ingress tag pop 1 symmetric
  bridge-domain 598

CE

(This configuration just for testing for CE as dot1q)
interface GigabitEthernet0/5/5
 service instance 598 ethernet
  encapsulation dot1q 598
  rewrite ingress tag pop 1 symmetric
  bridge-domain 598

interface BDI598
 ip address 98.98.98.9 255.255.255.0

This CE configuration , is working fine.
I can ping to BVI on XR device.

I wonder if i'm hitting this limitation of bvi.
"What is important here is that the BVI is not vlan tagged. So in order for the EFP's to talk to the BVI, we need to pop ALL Tags on ingress!!"
https://supportforums.cisco.com/document/59741/asr9000xr-flexible-vlan-matching-evc-vlan-tag-rewriting-irbbvi-and-defining-l2

My workaround
I try to used L3 EFP to perform L3 termination instead of bvi.

My question.

Anyone can give me for suggestion to do workaround other than L3 EFP on other device as my workaround.

Thank you in advance

Satit

[Florian Frotzler]

IOS-XR counts L2 payload as MTU, IOS [XE] counts L3 payload as mtu. Therefore:

MTU 9180 on ASR903 = MTU 9194 on ASR9K

Florian

[Florian Frotzler]

Apart from that, yes, you need to pop any VLAN tags to use BVIs, thats a fact.

Florian

[satitcha]

Thank you again for confirming of this fact.

Per the diagram,

I still wonder why I can not perform initiate ping from ASR903 to ASR9K,

by configuring BDI interface on ASR903 , then ping to BVI interface on ASR9K, vise and versa.

I expected that Ping Packet that initiated from BDI's itself should not be vlan tagged.

So the ASR903's BDI behavior shoud be the same as ASR9K's BVI or not ?

Regarding to my workaround to the original requirement.
I tried to used L3 EFP to perform L3 termination on another connected device instead of bvi's itself.

Could you please help me to give an other idea  to overcome BVI's limitation to my scenario ?

Thank you in advance.

Satit

[Florian Frotzler]

Which L3 EFP configuration do you use which works in comparison to the BVI?

Florian

[satitcha]

Refer to original diagram,

I have another connected ASR9K connected via Bundle-Ethernet1 .

I tested my workaround as following,

1.  I created AC on this ASR9K,

interface Bundle-Ether1.598 l2transport

encapsulation dot1q 598

rewrite ingress tag pop 1 symmetric

l2vpn

bridge group star-MonitorSW-5012

  bridge-domain VLAN598

   interface Bundle-Ether1.598

2. on another ASR9K

Created L3 EFP to above AC.

interface Bundle-Ether1.598

ipv4 address 98.98.98.13 255.255.255.0

encapsulation dot1q 598

The result is ,

I can ping through this BD,

from CE to mentioned L3 EFP instead of BVI.

Satit

[Florian Frotzler]

Hi Satit,

In your original test configuration you use "encapsulation default" on the ASR 903. This essentially allows both tagged and untagged frames to be transported on the vfi. So I would SPAN the packets to verify that they are really untagged before they go to the BVI. Apart from that, as I mentioned in my other reply, if it worked with an older software release show this to TAC.

Florian

[satitcha]

Hi Florian,

I'm working with TAC,

TAC is checking with BU.

I will update once get the update.

Satit

[satitcha]

Thank you Florian for warmest answer,

Could you please check for my a little bit more query ?

You mean, you're suspecting issue of missed match MTU ?

I verified PW from ASR903 to ASR9K already up.

DN1#show mpls l2transport vc 510590598

Local intf     Local circuit              Dest address    VC ID      Status
-------------  -------------------------- --------------- ---------- ----------
VFI 598        vfi                        172.16.10.11    510590598  UP

DN1#show mpls l2transport vc 510590598 detail
Local interface: VFI 598 vfi up
  Interworking type is Ethernet
  Destination address: 172.16.10.11, VC ID: 510590598, VC status: up
    Output interface: Po11, imposed label stack {0 16031}
    Preferred path: not configured  
    Default path: active
    Next hop: 172.16.11.1
  Create time: 00:01:19, last status change time: 00:01:19
    Last label FSM state change time: 00:01:19
  Signaling protocol: LDP, peer 172.16.10.11:0 up
    Targeted Hello: 192.168.10.7(LDP Id) -> 172.16.10.11, LDP is UP
    Graceful restart: configured and enabled
    Non stop routing: not configured and not enabled
    Status TLV support (local/remote)   : enabled/supported
      LDP route watch                   : enabled
      Label/status state machine        : established, LruRru
      Last local dataplane   status rcvd: No fault
      Last BFD dataplane     status rcvd: Not sent
      Last BFD peer monitor  status rcvd: No fault
      Last local AC  circuit status rcvd: No fault
      Last local AC  circuit status sent: No fault
      Last local PW i/f circ status rcvd: No fault
      Last local LDP TLV     status sent: No fault
      Last remote LDP TLV    status rcvd: No fault
      Last remote LDP ADJ    status rcvd: No fault
    MPLS VC labels: local 41, remote 16031
    Group ID: local 0, remote 6
    MTU: local 9180, remote 9180
    Remote interface description: 598
  Sequencing: receive disabled, send disabled
  Control Word: Off (configured: autosense)
  SSO Descriptor: 172.16.10.11/510590598, local label: 41
  Dataplane:
    SSM segment/switch IDs: 94293/135251 (used), PWID: 33
  VC statistics:
    transit packet totals: receive 0, send 0
    transit byte totals:   receive 0, send 0
    transit packet drops:  receive 0, seq error 0, send 0

Thank you in advance,

Satit

[Florian Frotzler]

Hi,

You set the MTU on the bridge domain level, this is the reason why there is no mismatch. On interface level, you need to add 14 byte on the IOS-XR side. Nevertheless, this is just for information, it will not be the root cause for your problems.

Florian

[satitcha]

From the original configuration,

MTU configuration on BVI interface is configured by 'mtu 9180'

if your assumption is the root cause for my scenario,

How much interface mtu should be configured on Attach Circuit of ASR903 ?

My ASR903 interface MTU configuration being default.

NOTE.

As mentioned earlier,

This configuration used to be worked on XE 3.10.S,

It doesn't work after upgrading to XE 3.13.1S.

I'm not sure if any significant changing of XE 3.13.1S.

Satit

[Florian Frotzler]

Hi Satit,

You have to be careful about setting the mtu. First of all, it is not a good idea to set the mtu on every configuration item where this is possible, set it only where it is necessary (probably the physical interface and the bridge domain). It is especialy a bad idea to set the same value everywhere as the value might mean differrent things on different configuration items and platforms. On the interface level this is the whole L2 payload inlcuding the 14 byte L2 Header and excluding the 4 byte CRC field at the end on IOS-XR, and only the L3 payload on IOS devices (hence the 14 byte difference). On the interface level you need to add any .1Q tags or mpls tags, on bridge domain level you dont, on this level ony the L2 payload is counted.

So all in all your configuration strategy will bring you problems at some point. But as I already stated, this is not necessarilty the root cause of your ping problem and if it worked in an older software release I would show this to TAC.

Florian

[satitcha]

็Hi Florian,

Thank you for information.

I'm working with TAC,

TAC is checking with BU.

I will update once get the update.

Satit