I've found several other resources online regarding this question, but I think I have a small twist to my example that I would like feedback on. Please see the attached NetDiagram to explain setup. Using NV3448 at HQ and NV1335 at Remote Location. Both running AOS R10.9.0.E. I'm attempting to setup IRB Configuration.
Goals:
1. Bridge Default VLAN(1) traffic across Point-to-Point (PtP) T1 between HQ and Remote Site.
2. Route Voice at Remote Site across PtP T1 and out the default Voice Internet connection located at HQ
3. Use the HQ NV3448 as the Transparent SIP Proxy for voice at both locations.
4. Using seperate IP schemes, seperate the Voice so I can easily track/manage/troubleshoot in the NV3448 VOQ and Tranparent SIP Proxy
In reviewing the Configuring Bridging in AOS.pdf https://supportforums.adtran.com/docs/DOC-1627 I'm predomanently focusing on example starting on Page 28 and Figure 5, but the more I stew over this I'm leaning more towards the example starting on Page 32 and Figure 6. You might note in the diagram that I have BVI 1 on each end of the PtP T1 with 172.16.1.0/30 Subnet becuase I started down that road initially.
Questions
A. I really don't need to pass VLAN55 TAGGED traffic across the link. My thinking was that I could get away with using VLAN55 at both sites for Voice since at the remote site I'm going to route the VLAN55/Voice traffic from the NV1335 to the NV3448 and out the VOICE INTERNET connection. Perhaps this is flawed logic which is making it more complex?
B. If it is easier, I could just pass VLAN 1 and VLAN55 traffic across the bridge and abandon my #4 Goal above.
C. Do I really need IP FIREWALL on at the Remote Site? Pros/Cons?
D. Most of the examples use Fixed Ethernet Ports. Since I'm using Switch Ports on both sides as my internal interfaces, how does that alter the implementation?
Would greatly apprecate feedback and help. It will help reduce the potential support call tomorrow. Thanks in advance!
****************************************
HQ Config Overview
*****************************************
!
ip routing
!
ip firewall
!
bridge irb
!
bridge 1 protocol ieee
!
interface vlan 1
bridge-group 1
no ip address
no shutdown
!
interface vlan 55
ip address 10.10.10.1 255.255.255.0
no shutdown
!
interface t1 1/1
clock source line
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface t1 1/2
clock source internal
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface hdlc 1
ip address Voice Internet Public IP
no shutdown
cross connect 1 t1 1/1 1 hdlc 1
!
interface ppp 1
bridge-group 1
no ip address
mtu 1520
no shutdown
cross connect 1 t1 1/2 1 ppp 1
!
interface bvi 1
ip address 10.1.2.102 255.255.0.0
no shutdown
!
ip policy-class Voice_VLAN55
allow list VoiceT1Admin self
nat source list VoiceT1NAT interface t1 1/1 overload
!
ip route 0.0.0.0 0.0.0.0 VoiceT1GatewayPublicIP
*****************************************************************
Remote Site
*****************************************************************
!
ip routing
!
ip firewall
!
bridge irb
!
bridge 1 protocol ieee
!
interface vlan 1
bridge-group 1
no ip address
no shutdown
!
inteface vlan 55
ip address 10.10.11.1 255.255.255.0
no shutdown
!
interface t1 1/1
clock source line
tdm-group 1 timeslots 1-24 speed 64
no shutdown
!
interface ppp 1
bridge-group 1
no ip address
mtu 1520
no shutdown
cross connect 1 t1 1/1 1 ppp 1
!
interface bvi 1
ip address 10.1.2.103 255.255.0.0
no shutdown
!
ip route 0.0.0.0 0.0.0.0 10.1.2.102
One option when sending different traffic across a single T1 is to use frame-relay encapsulation with a different PVC for each type of traffic. This would allow you to have PVC 55 map to VLAN 55 and PVC 100 for example map to VLAN 1 (frame-relay PVCs don't go below 16). You can then bridge or route across each PVC as you choose and prioritize QoS easily based on PVC.
At one time there was a bug in AOS where you couldn't assign a subinterface to a bridge group on some platforms, which might complicate the bridging if this bug still exists on that platform.
Frame-relay is similar to PRI in that there's a network and user end. One side of the connection has to be set for DCE and the other to DTE in order for the link to come up.
While this may not be an exact answer to the question you asked, it is one way we handle multiple different traffic streams over a single or multilink T1 circuit.
I went ahead and flagged this post as "Assumed Answered". If any of the responses on this thread assisted you, please mark them as Correct or Helpful as the case may be with the applicable buttons. This will make them visible and help other members of the community find solutions more easily. If you have any additional information on this that others may benefit from, please come back to this post to provide an update. If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.
Thanks,
Noor