Sign in with
Sign up | Sign in
Your question

subclassed IP address ranges using 802.1Q VLANs

Last response: in Networking
Share
Anonymous
January 19, 2005 3:25:00 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

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.

--

It gives some oddball error messages, but it basically just works, and
it frees me from writing scripts using /sbin/vconfig (well done, whoever
did the integration work; even virtual addresses on top of the vlan
interfaces work).

Once I hooked it up to the Internet feed with the new 802.1Q tagged IP
address ranges coming from my provider, I could ping each VLAN interface
gateway address. Also, I can browse the web from it, so long as I set
the default route metric on one of the VLAN interfaces lower than the
others or have only one vlan interface up.

So I know the laptop sees the tagged packets. Unfortunately, if I have
all the VLAN interfaces up, I can ping only the IP addresses tied to the
VLAN interface with the metric for the default route lower than all the
others (with only one VLAN interface up, it has the lowest metric for
the default route).

What must I do to make this pig fly?

My goal is to have this laptop connected to all the vlans, and to ping
any IP I set up on any of the VLAN interfaces. Once I do that, I figure
I can set up multiple servers connecting to the VLANS with arbitrary IP
addresses using a managed switch easily enough.

--
Christopher L. Everett

Chief Technology Officer www.medbanner.com
MedBanner, Inc. www.physemp.com
Anonymous
January 20, 2005 12:46:54 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

On Wed, 19 Jan 2005 12:25:00 -0600, ceverett wrote:
> So I know the laptop sees the tagged packets. Unfortunately, if I have
> all the VLAN interfaces up, I can ping only the IP addresses tied to the
> VLAN interface with the metric for the default route lower than all the
> others (with only one VLAN interface up, it has the lowest metric for
> the default route).
>
> What must I do to make this pig fly?

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.

> My goal is to have this laptop connected to all the vlans, and to ping
> any IP I set up on any of the VLAN interfaces. Once I do that, I figure
> I can set up multiple servers connecting to the VLANS with arbitrary IP
> addresses using a managed switch easily enough.

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.
Anonymous
January 20, 2005 10:25:41 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

ceverett wrote:
> So I know the laptop sees the tagged packets.

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.

> Unfortunately, if I have
> all the VLAN interfaces up, I can ping only the IP addresses tied to
the
> VLAN interface with the metric for the default route lower than all
the
> others (with only one VLAN interface up, it has the lowest metric for

> the default route).

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
Anonymous
January 25, 2005 4:48:39 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

anoop wrote:
> ceverett wrote:
>
>>So I know the laptop sees the tagged packets.
>
>
> 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.
>
>
>>Unfortunately, if I have
>>all the VLAN interfaces up, I can ping only the IP addresses tied to
>
> the
>
>>VLAN interface with the metric for the default route lower than all
>
> the
>
>>others (with only one VLAN interface up, it has the lowest metric for
>
>
>>the default route).
>
>
> 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.

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.

> Anoop
>
Related resources
!