0

Using our SonicWALL NSA 3600 and doing some cleanup, I noticed that one our physical interface, the X5, does not have a subinterface for the VLAN 7 (VoIP VLAN). Instead, it has the gateway IP of the subnet (172.16.7.0/24).

There is a trunk connected to this interface (coming from a Dell N4023F, the port setting is a dot1q trunk with PVID 7).

Why is there no subinterface on the SonicWALL? How does it know that the VLAN is tagged as 7, so how does it route it?

Another strange thing is that this interface has a subinterface, but for the VLAN 8 (so it knows how to route the VLAN 8 from the switch). Why not simply adding a subinterface for the VLAN 7? Is it really necessary?

My guess is that the VLAN 7 is only used on the switch, and nowhere else, which does not really make sense, am I correct here?

LeRouteur
  • 376
  • 2
  • 13
  • 1
    Is it just that VLAN 7 on that interface is the native VLAN? – Chopper3 Jun 30 '22 at 08:09
  • Actually, the PVID functionality on the Dell switch (as I understood) is to tag untagged frames with VLAN ID 7. And this make sense, since the VLAN 8 is routed to the subinterface, and with every packet coming to the FW comes a VLAN ID 7. Did I get it right? And by saying "native VLAN", you mean there is a configuration in the X5 interface saying "I'm a member of the VLAN 7"? – LeRouteur Jun 30 '22 at 08:28

1 Answers1

3

To answer your comment, basically a lot of managed/VLAN-capable switches can support what's known in the Cisco world as a 'Native VLAN'. It's quite easy to understand, basically you state on a whole switch or port basis the Native VLAN and what you're saying is 'if you get a un-tagged packet in on this port then consider it's on VLAN xxx', then if it's being forwarded it's actually re-encapsulated with that VLAN tag as part of the packet so it can be dealt with by the upstream devices accordingly.

This is a surprisingly often-used config as not everything is .1q capable - as an example for years the RHEL bootable installer wasn't 1.q capable, so when it tried to connect to our repository servers it couldn't get to them as they were on different VLANs - so we set the Native VLAN to the VLAN that the server would use once it was fully built - that way all the untagged traffic trying to get to these servers would in fact be tagged by the switch as if it always had been - then when the OS was installed and rebooted the running version WAS .1q capable and...profit.

So I suspect in this case that either the switch or the port are set to VLAN 7, it would explain the behaviour you're seeing. Sadly I'm mostly a Cisco chap so may not know the config of your actual switch, but I imagine others here will if you wanted to post it.

Hope this help.

Chopper3
  • 100,240
  • 9
  • 106
  • 238
  • 1
    Thanks for the precise explanation. That's what I thought, so the SonicWALL isn't looking at the VLAN number since the Dell switch port native VLAN is 7, making every frame coming into it tagged as 7 if not already tagged. – LeRouteur Jun 30 '22 at 11:37