[CentOS] VLAN tagging problems [SOLVED]

Sat Oct 29 00:19:22 UTC 2005
Robin Mordasiewicz <robin at bullseye.tv>

On Fri, 28 Oct 2005, Robin Mordasiewicz wrote:
> On Fri, 28 Oct 2005, Les Mikesell wrote:
>
>> On Fri, 2005-10-28 at 11:14, Robin Mordasiewicz wrote:
>>>>> We are using Centos behind an F5 Bigip load balancer.
>>>>> The linux box is using bonding and tagged VLAN's
>>>>> 
>>>>> Everything works fine except that when traffic is forwarded from the 
>>>>> BigIP
>>>>> to the linux box on the VLAN where the web server is running the 
>>>>> linux box
>>>>> returns the traffic on the wrong VLAN, It returns traffic on the 
>>>>> lowest
>>>>> ordered VLAN.
>>>>> 
>>>>> ie. here is a tcpdump on my load balancer showing traffic being sent 
>>>>> on
>>>>> VLAN 911 to the linux box, but the linux box returns traffic on VLAN 
>>>>> 902.
>>>>> The linux box is returning traffic on the same VLAN as its 
>>>>> configured
>>>>> default gateway. If I change the default gateway to be on the VLAN 
>>>>> 911
>>>>> then everytyhing works.
>>>> 
>>>> It seems reasonable to require a route to the destination on the
>>>> VLAN used.  Why should it ever do otherwise?  What are you trying
>>>> to accomplish by using a VLAN interface with no route back?
>>> 
>>> Is there any way to say that if traffic is recieved on VLAN#911 to be 
>>> sure
>>> that the return traffic is tagged with the same vlan id. Currently 
>>> traffic
>>> is tagged based on the routing table, and even if traffic comes in on
>>> VLAN#911, when it returns the traffc it uses the VLAN tag from the 
>>> network
>>> that the default gateway is on(VLAN#902).
>> 
>> The BigIP will do this sort of magic itself to save the time looking
>> up the return route, but it really is black magic in terms of
>> standard networking where asymmetrical routes are permitted and
>> expected.  The reply packet doesn't have much to connect it to the
>> one that came in and it's path is determined by the route to the
>> destination address.   That said, there may be some black magic
>> you can do with iptables and the ip_conntrack info or some sort
>> of policy based routing.
>
> I will research policy based routing.

This is now working properly.
After googling "policy based routing linux" I came across a very helpful 
article, which explained how to use the ip command to create multiple 
routing tables. I have ended up creating a routing table for each tagged 
VLAN.

http://www.linuxjournal.com/article/7291

My setup is slightly different than the article, as I am bonding nic's 
together and then bringing up 802.1q tagged interfaces on the bond.

I have a multi homed, as in multiple tagged vlan 
interfaces. For example I have an interface bond0.101(10.10.1.244), 
bond0.102(10.10.2.244), bond0.103(10.10.3.244). For each interface I have 
issued commands...

ip ro add 0.0.0.0/0 via 10.10.1.1 table 101 
ip ru add from 10.10.1.244 table 101
ip ro add 0.0.0.0/0 via 10.10.2.1 table 102
ip ru add from 10.10.2.244 table 102
ip ro add 0.0.0.0/0 via 10.10.3.1 table 103
ip ru add from 10.10.3.244 table 103


Now each interface has its own routing table. I may have left out some 
information in my explanation, as I am still teaching myself how to use 
the ip command, and to configure the /etc/iproute2/* config files.

Any further hints are appreciated.