[clug] packet management on multi-homed network

[Andrew]

Thanks to the replies so far-  i'll try and elaborate some more.

TOS is a field marking you can use (modify the QoS value within a packet 
which has the benefit of being able to pass between devices)

The system in mind uses BGP already. To give an idea of the scale, not 
huge but not too simple either. An AS with two BGP routers (ibgp in 
between), 2 transit links, 2 peering links at the initial stage (likely 
4-6 total before too long).

NAT isn't an option (there is a public address pool in use, so the 
packets do not have to go back out the same interface they arrived on).

Classifying on the way in easy (just the way out that creates the 
headache (when the bandwidth management is done before the path out)).

I haven't been to a clug meeting in a long time, I might have to trundle 
along to the next one to draw a diagram.


Cheers,






On 30/12/10 11:20, steve jenkin wrote:
> Andrew wrote on 29/12/10 9:43 PM:
>> Hi All!
>>
>> I have spent a fair bit of time on google trying to find a solution for
>> this problem, but no luck as yet.
>>
>> For traffic management purposes I am trying to track packets based on
>> incoming and outgoing interfaces (in a multi-homed network, presume 100%
>> linux minus the switches).
> <snip>
>
>> Incoming is simple enough (TOS marking based on incoming interface).
>> Outgoing is much harder (as I don't know which interface it is going out
>> of until it reaches one of the border routers - too late for the
>> shaping). It would be possible to manually (or automatically export the
>> routes), but this is far less than dynamic and becomes more of a
>> headache as the number of peering arrangement (and routes) increase.
>> Also risky (if the peer goes down then we risk congestion through an
>> alternative route)
> Don't ISP's&  large sites use e-BGP to manage this sort of situation?
> Most people avoid BGP - has a reputation of being complex.
> [Richard S???? used to be on list and has run ISP's and large sites and
> must have seen multi-homing. Perhaps approach him directly (apologies
> for forgetting names)]
>
> <snip>
>
>
>> On a related matter-  is anyone able to give some clues on how TOS
>> tagging is managed in a return packet situation? (eg packet comes in
>> with TOS values, passes to the application server eventually, then a new
>> but related packet returns back out). On the return path, is there a way
>> to recognise the return packet and assign the correct TOS value? (kind
>> of like a 'related/established'), or does the server sending the return
>> packet have to preserve the TOS value?   I am aware that this has a
>> fundamental flaw when used in multi-homing network (it presumes that
>> return path is the same as entry).
> I've heard of QoS (Quality of Service) being used in networks.
> Don't know what TOS is.
>
>>
>> Grateful for any input.
>>
>>
>> Cheers,
>
> Andrew,
>
> An interesting thing you're trying to do...
>
> I'm guess you already have a rule to classify traffic into FREE and PAID
> classes/types...
>
> Do you remember this thread where Tridge explained his dual-link setup?
> <http://lists.samba.org/archive/linux/2009-August/025050.html>
>
> He classified his traffic on inbound interface and was able to route
> packets back out that way.
>
> Trying to understand your setup and what you're trying to achieve is
> difficult for my aging brain without a diagram :-(
> And it's off for a home network to have multiple links, or face
> significant congestion problems... Any hints on the scale/size of this
> network?
>
> Normally networks prioritise traffic on type - FTP at the bottom,
> real-time (VoIP) at the top. You're operating in another dimension.
>
> I've seen reverse-NAT used for Load-Balancing, this would give you a
> single point to manage/separate packets.
>
> I've worked on a network that successfully used VLAN's (and worked in a
> couple of places that to this day still use extensive VLAN's to manage
> their 'security').
> What impressed me was the simplicity of setting them up (eth0.1 not eth0:1).
>
> If each of your border gateways can push inbound traffic onto the VLAN
> they'd like it to be returned on, then you can create simple routing
> rules (using iproute2) in the linux hosts.
>
> Alternatively, if you create something like 'fail2ban' that actively
> tracks external connections and classifies IP's into FREE/PAID classes
> on your border gateways, you might be able to use iptables to direct
> each IP onto
>
> The thing Tridge didn't tease out was how an internal host knew that the
> alternate link was up.
> Re-reading the piece, I'm confused: he explicitly says PPP on the 3G
> link comes up on his server, but also talks about using a cheap Linksys
> device for the 3G.
>
> Perhaps the linksys is the default route for all internal hosts and
> passes on all normal traffic 'up-the-line' to the ADSL link.
>
> Worth shooting him a note to clarify.
> Could be his setup will work for you if yours isn't too large.
>
> HTH.
>
> cheers
> steve
>