cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1342
Views
15
Helpful
5
Replies

ISR 4000 bridged serial sub-interface support removed - need workaround

ian.m.covington
Level 1
Level 1

All,

 

For buildings without fiber, a T1 solution was used to provide connectivity using the ISR Gen 1 & 2. The solution bridged Ethernet sub-interfaces to serial sub-interfaces. Each Serial sub-interface had a Frame Relay DLCI assigned to it. This allowed the T1 to act as an Ethernet trunk and maintain L2 separation. Now that the 2900 and 3900 ISRs are EoS, we are forced to use the ISR 4000s. Unfortunately, they do not support bridging of serial sub-interfaces and we are in a bind to be able to provide the same solution to customers using the new platform. Has anyone else found this issue and been able to find a workaround? Any suggestions are appreciated. The previous solution was done as shown below

bridge irb
!
!
interface GigabitEthernet0/0
 description <== <SITE>-U<USERZONE>-AS-<ACCESSSWITCH> ==>
 no ip address
!
interface GigabitEthernet0/0.1
 description <== Bridged to User DLCI ==>
 encapsulation dot1Q 21
 bridge-group 21
!
interface GigabitEthernet0/0.2
 description <== Bridge to Print DLCI ==>
 encapsulation dot1Q 51
 bridge-group 51
!
interface GigabitEthernet0/0.99
 description <== Bridge to Mgt DLCI ==>
 encapsulation dot1Q 99
 bridge-group 99
!
interface Serial0/0/0:0
 description <== WAN link to <SITE>-U<USERZONE>-WR-<PREMISE> ==>
 no ip address
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 encapsulation frame-relay
 no fair-queue
 no keepalive
!
interface Serial0/0/0:0.21 point-to-point
 description <== User DLCI ==>
 frame-relay interface-dlci 21   
 bridge-group 21

!
interface Serial0/0/0:0.51 point-to-point
 description <== Printer DLCI ==>
 frame-relay interface-dlci 51
 bridge-group 51
!
interface Serial0/0/0:0.99 point-to-point
 description <== Management DLCI ==>
 frame-relay interface-dlci 99   
 bridge-group 99
!
interface BVI99
 description <== Management VLAN ==>
 ip address <S.X.V99.H99> 255.255.<X.VL99-S-MASK>
 no ip redirects
 no ip proxy-arp
!



 

 

5 Replies 5

educruz
Cisco Employee
Cisco Employee

Good day,

The most similar solution that I could think of, is EVC. Could you review the following document, compare, and see if that suits your environment?

 

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

 

Hope that helps.

 

Eduardo.

Thanks Eduardo,

 

I've looked into EVCs using service instances and BDI, unfortunately it is only supported using Ethernet interfaces, and we need to bridge between Ethernet and Serial on the same device.

 

I'm looking into L2VPN with Ethernet/VLAN to Frame Relay Interworking, but I don't think the behavior is quite what I am looking for. It is hard to tell without further reading, but I believe the traffic would be transparent to the  T1 routers, which means that they would be unmanageable. The configuration would follow this format:

!
interface GigabitEthernet0/0/2.21
 encapsulation dot1Q 21
!
interface GigabitEthernet0/0/2.51
 encapsulation dot1Q 51
!
interface Serial0/1/0:0
 no ip address
 encapsulation frame-relay
 frame-relay interface-dlci 21 switched
 frame-relay interface-dlci 51 switched
!
connect 21 GigabitEthernet0/0/2.21 Serial0/1/0:0 21 interworking ethernet
!
connect 51 GigabitEthernet0/0/2.51 Serial0/1/0:0 51 interworking ethernet
!



Understood Ian,

 

 

I have spent a couple of hours investigating and the ISR4k platform does not support IRB, so your last configuration proposal is as close to IRB as it can be. 

 

I apologize as I believe a dead end has been reached, under the conditions provided in your scenario. Maybe someone else could comment.

 

Kind regards,

 

Eduardo.

Looking at the documentation found here: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/wan_frly/configuration/xe-3s/wan-frly-xe-3s-book/wan-frly-eth-ls-xe.html . Would you agree that 'In the direction from Ethernet to Frame Relay: On the Ethernet side, the MAC header is ignored.' means the traffic is entirely transparent to the router?

Hi Ian,

Looking over the wording, I agree, it looks like the packet is transparent to the router from an Ethernet standpoint.

Kind regards,

Eduardo.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: