subclassed IP address ranges using 802.1Q VLANs

Jan 19, 2005 3 Replies

Hi,



My provider can give me more IP addresses if and only if I can play nice with his 802.1Q tagged VLAN network setup, with each subclassed IP address range on its own VLAN.



For testing, I have a Debian linux laptop with a VLAN enabled kernel and the vlan package installed, with its /etc/network/interfaces file configured more or less like this:


-- # /etc/network/interfaces auto lo iface lo inet loopback



# no gateway address for eth0 itself auto eth0 iface eth0 inet static address w.x.y.z netmask 255.255.255.0



## not the real vlan id :) auto eth0.1234 iface eth0.1234 inet static address 207.177.74.18 netmask 255.255.255.0 gateway 207.177.74.1



## not the real vlan id auto eth0.2345 iface eth0.2345 inet static address 207.177.73.226 netmask 255.255.255.240 gateway 207.177.73.225 metric 1



# repeat the above stanza 3 more times in its essentials to create # 5 VLANS total.


Check the Reverse Path Filter on your VLAN interfaces: $ cat /proc/sys/net/ipv4/conf/$INTERFACE/rp_filter

If it is enabled (1), the kernel will discard all packets whose source IP address does not match the route to the interface the packet was received on. To be more precise, the kernel will determine the interface which a (hypothetical) answer to this IP address would be routed to, and compare this to the interface on which the original packet was received. If the interfaces do not match, the packet will be dropped.

This is meant as a protection against source IP spoofing - any packet which pretends to originate from your LAN but was received from the outside will be dropped, and so it usually simplifies the design of the packet filtering rules in a firewall.

I could think of two options to resolve this (choose one):

  1. disable rp_filter to allow asymmetric routing In this case you might want to set up packet filtering rules to prevent source IP spoofing.
  2. use policy routing (based on the source IP address) for outgoing traffic This way you can make sure that the routing is symmetric, so rp_filter does not interfere anymore.

Do you intend to connect the switch directly to an ethernet line from your provider? I hope you have a suitable firewall concept.

I wish you good luck with your project.

Mirko

NB: This is not really an ethernet issue anymore. If you have further questions, you might want to take them to a TCP/IP newsgroup.

I assume the laptop is sending tagged packets as well. This is necessary or the receiving switch won't be able to tell which VLAN the packet was sourced on.

Your observed behavior makes sense. Basically you can think of your laptop is sitting on multiple interfaces. It chooses which interface to send packets on based on its routing table. If your default route points to a single interface, then regardless of metric, any packet addressed to a destination that matches the default route (i.e. does not match one of the local subnets) will be sent out the interface on which the default route was configured.

One way to get around this would be to manually configure sets of routes for each interface. This would be quite tedious. The other option would be to enable routing protocols on the laptop and have the provider advertise different prefixes on each of the VLANs...this may be more than the provider is willing to do. I'm also not familiar with what routing protocols are supported on linux. The third option would be to configure the default route with equal cost on all interfaces and have linux choose one based on a load-balancing algorithm. Again, I'm not sure if that is supported on linux.

Anoop

As it happens, routing on Linux is quite well developed. The answer as far as I can tell, is to have a linux kernel enabled for policy based routing, and use the source address of the packet to assign it a default route.

But that's more of an IP instead of ethernet issue.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required