Bridge domain with a pool of VLANs included

[Mario Rosi]

Hi,

if i have a configuration like this one on a PE router (ios XE):

interface GigabitEthernet3
no ip address
negotiation auto
..
service instance 5 ethernet
encapsulation dot1q 3-5
bridge-domain 200
! 
interface GigabitEthernet6
no ip address
negotiation auto
..
service instance 1 ethernet
encapsulation dot1q 3-5
bridge-domain 200
!

...and i have traffic coming from GE6 encapsulated as VLAN ID 3; even though i've all the VLANs included in the same bridge domain, there is no chance that i can have traffic crossing the VLAN (i.e. for instance, if the destination IP address of a ping is on a VLAN with ID 4 leaving the GE3, and the source of ping is IP address on a VLAN with ID 3 entering the GE6, the ICMP echo reply shouldn't work), right?

What i'm not sure is if i have to introduce the equivalent of command ethernet egress filter strict"(from XR) in XE or the egress checking is already done automatically.

Thanks,

Mario

[Mario Rosi]

What i' referring to is well explained here below for XR; what i don't know is how XE behave in the same identical scenario...any ideas?

ethernet egress-filter

In the egress direction of an AC, suppose there is no rewrite ingress tag pop <> symmetric command that determines the egress VLAN tags. In that case, there is no check in order to ensure that the outgoing frame has the correct VLAN tags according to the encapsulation command.

This is an example configuration:

interface GigabitEthernet0/1/0/3.2 l2transport
 encapsulation dot1q 2
!
interface GigabitEthernet0/1/0/3.3 l2transport
 encapsulation dot1q 3
!
interface GigabitEthernet0/1/0/39.2 l2transport
 encapsulation dot1q 2
!
l2vpn
 bridge group customer2
  bridge-domain test
   interface GigabitEthernet0/1/0/3.2
   !
   interface GigabitEthernet0/1/0/3.3
   !
   interface GigabitEthernet0/1/0/39.2
   !
  !
 !
!

In this configuration, note that:

• A broadcast received with a dot1q tag 2 on GigabitEthernet0/1/0/39.2 keeps its incoming tag because there is no rewrite ingress command.
• That broadcast is flooded out of GigabitEthernet0/1/0/3.2 with its dot1q tag 2, but that does not cause a problem because GigabitEthernet0/1/0/3.2 is also configured with the dot1q tag 2.
• That broadcast is also flooded out of GigabitEthernet0/1/0/3.3, which keeps its original tag 2 because there is no rewrite command on GigabitEthernet0/1/0/3.3. The encapsulation dot1q 3command on GigabitEthernet0/1/0/3.3 is not checked in the egress direction.
• The result is that, for one broadcast received with tag 2 on GigabitEthernet0/1/0/39, there are two broadcasts with tag 2 going out of GigabitEthernet0/1/0/3. That duplicated traffic might cause some application issues.
• The solution is configuration of ethernet egress-filter strict in order to ensure that packets leave the subinterface with the correct VLAN tags. Otherwise, the packets are not forwarded and are dropped.

interface GigabitEthernet0/1/0/3.2 l2transport
 ethernet egress-filter strict
!
interface GigabitEthernet0/1/0/3.3 l2transport
 ethernet egress-filter strict
!