× NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Orbi WiFi 7 RBE973
Reply

IP Subnet-Based VLANs and ARPs

epmryan
Follower

IP Subnet-Based VLANs and ARPs

I am trying to wrap my head around a concept involving subnet based VLANs and how ARPs for those IP subnets are classified into the correct VLAN. So for example let's say I have untagged traffic ingressing a switch port and that port classifies traffic to VLAN 10 based on a subnet and say that would be 100.0.10.X. So all traffic destined for 100.0.10.X is tagged VLAN 10. Here's my question: How are the ARPs for subnet 100.0.10.X classified to VLAN 10? Are they? Wouldn't I have a seperate rule for tagging ARPs that 'ARP' for that subnet (i.e., VLAN 10)? I could see numerous ARPs supporting numerous subnets ingressing over a single port, so then how does a switch ensure ARPs are classified into their VLAN? With subnet-based VLANs, are ARPs for those subnets classified to those subnet-based VLANs as well?

 

Thanks

 

 

 

Model: M5300-28G-POE+ (GSM7228PSv1h2)|Prosafe 24+4 L2+ Gigabit Stackable Managed Switch
Message 1 of 4
Evans-o
NETGEAR Expert

Re: IP Subnet-Based VLANs and ARPs

Hi epmryan,

 

Thanks for joining our online community.

 

I just wanted to reccommend that you look at the following excerpt starting from page 37 of the Software Administration Manual (for M5300-28G-POE+ (GSM7228PSv1h2) proSAFE 24+4 L2+ Gigabit Stackable Managed Switch) if it might answer your question at least in part while the comminity looks further into it.

 

"Virtual VLANs: Create an IP Subnet–Based VLAN
In an IP subnet–based VLAN, all the end workstations in an IP subnet are assigned to the same VLAN. In this VLAN, users can move their workstations without reconfiguring their network addresses. IP subnet VLANs are based on Layer 3 information from packet headers. The switch makes use of the network-layer address (for example, the subnet address for TCP/IP networks) in determining VLAN membership. If a packet is untagged or priority tagged, the switch associates the packet with any matching IP subnet classification. If no IP subnet classification can be made, the packet is subjected to the normal VLAN classification rules of the switch. This IP subnet capability does not imply a routing function or that the VLAN is routed. The IP subnet classification feature affects only the VLAN assignment of a packet. Appropriate 802.1Q VLAN configuration must exist in order for the packet to be switched."
 
You may find the manual here to read further:
 
Feel free to give us feedback.
Thanks
 
Model: M5300-28G-PoE+ (GSM7228PSv1h2)|ProSAFE 24+4 L2+ Gigabit Stackable Managed Switch
Message 2 of 4
Evans-o
NETGEAR Expert

Re: IP Subnet-Based VLANs and ARPs

Please find the excerpt here:

For some reason, it didnt show up in my previouse post. Sorry about that.

 

 

Virtual VLANs: Create an IP Subnet–Based VLAN

In an IP subnet–based VLAN, all the end workstations in an IP subnet are assigned to the same VLAN. In this VLAN, users can move their workstations without reconfiguring their network addresses. IP subnet VLANs are based on Layer 3 information from packet headers. The switch makes use of the network-layer address (for example, the subnet address for TCP/IP networks) in determining VLAN membership. If a packet is untagged or priority tagged, the switch associates the packet with any matching IP subnet classification. If no IP subnet classification can be made, the packet is subjected to the normal VLAN classification rules of the switch. This IP subnet capability does not imply a routing function or that the VLAN is routed. The IP subnet classification feature affects only the VLAN assignment of a packet. Appropriate 802.1Q VLAN configuration must exist in order for the packet to be switched.

 

Thanks

Message 3 of 4
Jedi_Exile
NETGEAR Expert

Re: IP Subnet-Based VLANs and ARPs

Had to make a post.

 

By design ARP would be flooding the port egress and ingress on PVID port or any tagged vlans.  IP based subnet follow ingress rule.  The assumption isn't about how to egress it.  The assumption is how to treat the traffic on ingress.  Egress applies seperately.

 

Using your example below for vlan 10 and adding vlan 5 as alternative.

vlan database

vlan 5

vlan 10

vlan association subnet 50.0.10.0 255.255.255.0 5

vlan association subnet 100.0.10.0 255.255.255.0 10

exit

 

So in the above configuration, Any incoming traffic on any port where the source IP address given is 100.0.10.x will be mapped to vlan 10 and source ip 50.0.10.x will be mapped to vlan 5.   That does not take into account destination here.  Arp is done on destination and not source.  When the traffic arrives into the port, the assumption here is that packet already has source IP address and MAC which will then get added to ARP table as "Source Address Table" get updated.  Depending on where your traffic is headed.. then ARP is done.  So if source is 100.0.10.50 and destination is 100.0.10.25, if both location already send a packet into the switch then "Source Address Table" already has entry for both and traffic will be forwarded, but if switch does not know 100.0.10.25 then it will flood all VLAN 10 member ports to try to find the location.  If you have failed to take that into account and not properly participated the vlan on the port, then you will never forward the packet.   WIth that in mind, you will need to flood VLAN 10 and 5 broadcast (ARP) to port where you expect either to have destination.

 

interface 1/0/1

description "Port with vlan 5 or 10 client"

vlan participation include 5,10

exit

interface 1/0/1

description "port with vlan 10 only client"

vlan participation include 10

exit

 

Remember the whole point of IP based subnet is use case of specific needs, mostly around ISP needs, I have not seen anyone try to implement this in production LAN enviroment unless they have specific need.

 

Hope that help.  Apologize for any spelling mistakes.

 

 

Message 4 of 4
Top Contributors
Discussion stats
  • 3 replies
  • 3547 views
  • 0 kudos
  • 3 in conversation
Announcements