Avaya SBC – Dual SIP Trunks via VLAN Tagging (No Gateway Reachability)

[William C290]

Hi everyone,


I'm working on a dual SIP trunk setup from our telco (Orange) and using an Avaya SBC (virtualized) in front of Avaya IP Office Server Edition R11.1.


Each SIP trunk is delivered via separate physical links and separate /30 networks:

• Link 1 (Primary): Signaling and media IPs over subnet X.X.X.144/30 (Gateway: X.X.X.145)
• Link 2 (Backup): Signaling and media IPs over subnet X.X.X.36/30 (Gateway: X.X.X.37)

Since we only have one physical SBC interface (B1) available for SIP trunking, we're trying to handle both links using VLAN separation:

• B1.451 → Link 1 (Primary SIP)
• B1.452 → Link 2 (Backup SIP)

Each VLAN interface is configured with its own IP and default gateway. Routing table on the SBC reflects both networks.

• VMware networking is correctly set up with:
  
  • Port groups for both SIP_VLAN451 and SIP_VLAN452
  • vSwitch connected to physical NIC (vmnic1)
  • Trunking enabled on the switch port
• On the switch:
  
  • Port going to SBC: switchport mode trunk
  • Ports going to Orange media converters: switchport mode access + appropriate VLAN (451 or 452)
  • Media converters are assumed to not support tagged traffic, so they're on untagged access ports

• SBC cannot reach either SIP gateway via ping from the VLAN interfaces.
• No SIP registration or options exchange is working.
• Direct physical connection to media converter with flat IP works fine, so issue seems to be VLAN-related.

What I need help with:​

1. Is this design officially supported by Avaya?
   (i.e., multiple VLAN-tagged interfaces on same SBC physical port for SIP trunks)
2. Any known issues with multiple default gateways on different VLANs over the same NIC?
3. Does the SBC handle VLAN-tagged traffic differently that would prevent reachability?
4. Any detailed guide or best practice design document for SIP trunk load balancing / redundancy over VLANs?

---

I’d love to hear from anyone who has implemented a similar design or has insight into why this setup might fail despite proper VLAN and routing configurations.


Thanks in advance,

 

[Shaun E]

The SBC can indeed support VLAN tagging on interfaces.

I believe you're using VMware from previous posts so before we go into too much detail on the SBC side can you please confirm you have enabled VGT (Virtual Guest Tagging) on the VMware side? This is essential to expose the dot1q IDs to the guest operating system. Without that the tags will be stripped before the traffic is sent to the virtual machine.

 

[derfloh]

I can confirm that it works with multiple VLANs on one single NIC.

 

[msalvary]

I concur with Shaun E, that VGT is required on the VMware port group assigned to the physical interface of the server. In other words, set a Port Group to VLAN 4095 for this purpose, which will allow all VLAN tagging to pass through to the VM (SBCE). Then assign that port group to the VM's network adaptor.

 

[derfloh]

You also have to configure allowed VLANs on the vSwitch or port group.

 

[William C290]

Hi all,


Just wanted to close the loop on this case and share our resolution for future reference.

Background:​

We were trying to configure two SIP trunk lines from our provider (Orange), delivered via two separate media converters. Our goal was to connect them to our Avaya SBC using VLAN tagging and route separation through different gateways and interfaces (B1 VLAN10 & VLAN20).

What We Tried:​

• Option 1: Configure two VLAN-tagged interfaces on the SBC and route each SIP trunk via a separate gateway (172.x.x.x).
  ➤ This caused SIP options to fail intermittently, and routing stability was unreliable.
• Option 2: Merge both VLANs into the same interface and use internal routing and default gateway switching.
  ➤ This was difficult to manage and still resulted in heartbeat and media issues.

Final Resolution:​

After further discussions with the provider and referencing a similar setup at another customer site (Rotana), we agreed to implement a PGP-style setup (Private Gateway per Provider).

Orange provided a single internal IP and gateway to consolidate both SIP trunks via one path.
They managed the routing on their side through a dedicated router, which resolved all stability and media routing issues.

Everything is now stable and working as expected via a single SBC interface (B1).


Thanks to everyone who contributed!


Best regards,