VLAN tagging problems [SOLVED]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Fri, 28 Oct 2005, Robin Mordasiewicz wrote:
> 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.

This is also a must read for any Linux sysadmin, which needs to learn more 
about more advanced networking
http://linux-ip.net/

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux