ASR-920 VLANs (Service Instances, BDIs) - Create equivalent to switch access port

[MatJones_1]

Hi

We have an ASR-920 router and want to segregate traffic from end devices using VLANs.

I've previously used Service Interfaces and BDIs for dot1q VLAN frame matching and rewriting for when tagged packets arrive, but on certain interfaces we want to tag incoming (untagged) packets with a single VLAN tag, like a switch can do as an access port.

For example, say End Devices 1 and 10 both communicate with the Up-Stream Device but we want to segregate the two End Devices with VLANs. Device 1 packets can be tagged by the Switch2 but I'm not sure about packets from Device10.

Up-Stream Device ___ Switch1 ___ ASR-920 Router ___ Switch2 ____ End Device1
                                      |                    
                                      \__ End Device10

- Switch2 to End Device1 may tag packets as VLAN 50 (switchport mode access, switchport access vlan 50)

- Switch2 carries the tagged packets to the router (switchport mode trunk, switchport trunk encapsulation dot1q, switchport trunk allowed vlan 50).

- Router interface to Switch2 may have a config like this:

interface g0/0/1
no ip address
service instance 1 ethernet
  encapsulation dot1q 50
  rewrite ingress tag pop 1 symmetric
  bridge-domain 50

- Router interface to Switch1 may be similar.
- ???? Router interface to End Device10 in order to tag incoming untagged packets with VLAN 75 so they cannot get to Device1 ????

Any ideas, thanks?

[balaji.bandi]

Hope below information help you : 

https://www.cisco.com/c/en/us/support/docs/lan-switching/integrated-routing-bridging-irb/200650-Understanding-Bridge-Virtual-Interface.html

[decode.chr13]

Let's say End Device 10 is connected to ASR920 Gi0/0/10

interface g0/0/10
no ip address
service instance 1 ethernet
  encapsulation default !(or encapsulation untagged)
  bridge-domain 75

configuration:

asr920 (config-if-srv)#encapsulation ?
 default          catch-all unconfigured encapsulation
 dot1q            IEEE 802.1Q Virtual LAN or S-VLAN
 priority-tagged  Priority tagged EFP
 untagged         Untagged encapsulation

Hope it helps

[MatJones_1]

Thanks for the responses. I think that is right if using the router just as a layer 2 switch, it would prevent Device10 communicating with Device1.
It falls down when we want to route outside of the router because BDI interface configuration is required (an ip address assigned to the BDIs). I've not yet confirmed this on the ASR-920, only simulating in GNS3, but for example if:

• Up-Stream device was on 192.168.0.1/24 with gateway 192.168.0.254 and connected to g0/0/0 (with incoming packets to the router dot1q tagged with VLAN 1000)
• End Device1 was on 10.0.0.1/24 with gateway 10.0.0.254 and connected to g0/0/1 (with incoming packets to the router dot1q tagged with VLAN 50)
• End Device10 was on 10.0.0.10/24 with gateway 10.0.0.254 and connected to g0/0/10 (with untagged incoming packets)

I think that as soon as you want to route to the Up-Stream device, but segregate from each other, then Device1 and Device10 need to connect to the same Bridge Domain Interface, i.e. BDI 50:

! Up-Stream Device
interface g0/0/0
 no ip address
 service instance 1 ethernet
  encapsulation dot1q 1000
  rewrite ingress tag pop 1 symmetric
  bridge-domain 1000
!
! End Device1
interface g0/0/1
 no ip address
 service instance 1 ethernet
  encapsulation dot1q 50
  rewrite ingress tag pop 1 symmetric
  bridge-domain 50
!
! End Device10
interface g0/0/10
 no ip address
 service instance 1 ethernet
  encapsulation untagged
  rewrite ingress tag push dot1q 75
  bridge-domain 50
!
interface BDI50
 ip address 10.0.0.254 255.255.0.0
!
interface BDI1000
 ip address 192.168.0.254 255.255.255.0

I can't prove whether the 'rewrite ingress tag push dot1q 75' did actually inject a VLAN 75 tag to the incoming packet but it was needed to stop pings between End Device1 and End Device10, yet allowed both to ping the Up-Stream Device.

If the End Devices were on different sub-nets then they would need to be routed from separate BDIs and then we're back to square one where all the End Devices can communicate with each other.

I think there's a solution in there somewhere !!!!