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/
