cancel
Showing results for 
Search instead for 
Did you mean: 

Inter-VLAN Routing to Untagged Interfaces

doug_adams_bjiu
New Contributor II

Hello All - Relatively new to VLANs and am building upon a setup from a previous employee.

Initial question: How do I make a device which is untagged in a non-default VLAN be able communicate with the other VLANS?

More Details: Our school district has a single core district router, with individual routers in each of our building locations. We are implementing an Avaya VOIP system and have set up voice VLANS for each location. Inter-VLAN routing works great for these separate voice-vlans, but there is an Avaya IP Office linux server that also needs to be in a voice VLAN and communicate with the other VLANs. Due to its location, it is currently connected to our core router and untagged in one of the Voice VLANS, however none of the other VLANS can communicate with it. 

Sumary

  • Linux Server IP: 10.127.0.70 / 255.255.0.0, Gateway = 10.127.0.1 / 24
  • Server is connected directly to the core router for the entire district. It is untagged in VLAN 127 (VE127 ip = 10.127.0.1 / 24)
  • I can ping it from the core router, and from other 10.127.x.x IP's (such as the avaya phones that are tagged within VLAN 127)
  • I cannot ping it from any other subnet. Ping from Building A makes it to the associated Building A virtual interface on the core router and then drops. 

4 REPLIES 4

kpfleming
New Contributor III

The subnet mask that you set on the server should be 255.255.255.0 (/24), you currently have it set to 255.255.0.0 (/16). If the other subnets are underneath 10.127/16, the server won't send replies through its gateway because it believes those addresses are on its subnet.

What is the IP address of one of the endpoints which cannot ping 10.127.0.70?

doug_adams_bjiu
New Contributor II

Changing the subnet to /24 did not do the trick.

An example of an endpoint that cannot ping it is 10.71.0.1. For further reference, here is an example of one of our buildings initial VLANs as they existed when I arrived. VLAN 127 is the addition I made.

  • Building A router
    • VLAN 1 / VE 1: Was left as the default vlan. 10.71.0.1 / 16. All ports and uplinks are untagged.
    • VLAN 71 / VE 71: 10.254.71.1 / 24. All uplinks are tagged.
    • VLAN 127 / VE 127: Voice VLAN, 10.127.71.1 / 24, all uplinks are tagged

  • Core Router
    • VLAN 1 / VE 1: Was left as the default vlan. 10.1.0.254 / 16. Only unused ports are untagged in this, except for two ports to our SonicWall.
    • VLAN 71 / VE 71: 10.254.71.254 / 24. Only the uplink ports to Building A are tagged.
    • VLAN 127 / VE 127: 10.127.0.1 / 24. Uplinks to Building A are tagged and Linux Server port is Untagged.

Traceroute from 10.71.1.240 results in:

 1     1 ms    <1 ms    <1 ms  10.71.0.1
  2     2 ms     2 ms     2 ms  10.254.71.254
  3     *        *        *     Request timed out.

You have VLAN 127 using 10.127.71.0/24 in Building A, but using 10.127.0.0/24 in Core. If you intended those to be the same subnet (which would be logical if they are the same VLAN), then the subnet mask will need to be 10.127.0.0/16 on both routers, or you'll need to change Building A to also use 10.127.0.0/24 for that VLAN.

You've also got VLAN 1 using different subnets between the two routers; if those untagged default VLANs are interconnected, they should also be using the same addressing scheme.

Thank you Kevin, things seem to be working now. I went and changed the subnet mask of each VE127 to /16, and applied the same mask to the linux server. This seems to have done the trick, with some other weird hiccups related to a second nic on the linux server categorized as the WAN port. It was temporarily plugged in to get console access from the other side of the building, and for whatever reason was causing issues with updating the device, restarting the service, etc... Whether or not that was part of the issue is unknown.

Everything is working as it should now, the Linux Server can get to the WAN and reach all subnets EXCEPT VE1 on the router (10.1.x.x / 16). This does not impact the phone system though so it's getting tabled for the moment while we finish installing the phones. I suspect it has to do with VLAN 1 on the core-router being left as the default-vlan rather than having a separate data-vlan created.