Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Quagga: Users

ospf load balancing

  

 
Quagga users RSS feed   Index | Next | Previous | View Threaded


sclark at netwolves

May 16, 2012, 9:15 AM

Post #1 of 9 (1228 views)
Permalink
ospf load balancing
Hello List.

Cisco says that with their OSPF implementation if the route cost are the same
they do CEF, Does quagga on Linux 2.6.32 or later do any kind of load balancing
if the costs are the same?

Thanks for any info.

--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark [at] netwolves
http://www.netwolves.com


lsorense at csclub

May 16, 2012, 9:49 AM

Post #2 of 9 (1179 views)
Permalink
Re: ospf load balancing [In reply to]
On Wed, May 16, 2012 at 12:15:51PM -0400, Steve Clark wrote:
> Hello List.
>
> Cisco says that with their OSPF implementation if the route cost are the same
> they do CEF, Does quagga on Linux 2.6.32 or later do any kind of load balancing
> if the costs are the same?

quagga on linux will create multipath routes if you have equal cost
routes to the same place. Linux will then pick one route for each flow
(where as I believe cisco does per packet multipath routing).

It works quite well.

--
Len Sorensen
_______________________________________________
Quagga-users mailing list
Quagga-users [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-users


straterra at fuhell

May 16, 2012, 9:59 AM

Post #3 of 9 (1175 views)
Permalink
Re: ospf load balancing [In reply to]
I know that if the interface speeds are the same and you don't have a
manually defined cost (IE, Quagga derives the same cost on multiple
interface), Quagga will add the route on both interfaces, but with identical
weights and metrics. The kernel should do some kind of load balancing (not
perfectly) in this scenario (as far as I know, someone feel free to correct
me)





192.168.1.0/30 dev eth0 proto kernel scope link src 192.168.1.1

192.168.1.4/30 dev eth1 proto kernel scope link src 192.168.1.5

10.1.17.0/24 proto zebra metric 20

nexthop via 192.168.1.2 dev eth0 weight 1

nexthop via 192.168.1.6 dev eth1 weight 1

10.1.1.0/24 proto zebra metric 20

nexthop via 192.168.1.2 dev eth0 weight 1

nexthop via 192.168.1.6 dev eth1 weight 1

169.254.0.0/16 dev eth0 scope link metric 1002

169.254.0.0/16 dev eth1 scope link metric 1003



In my lab (where I was coincidentally testing this very thing), router 1 has
this routing table. Router 2 has 10.1.1.0/24 and 10.1.17.0/24 attached. Both
of the links here are gigabit with no manual costing involved. Router 1
isn't distributing any routes. Also, this is RHEL 6.2 with 00.99.15.





From: quagga-users-bounces [at] lists
[mailto:quagga-users-bounces [at] lists] On Behalf Of Steve Clark
Sent: Wednesday, May 16, 2012 12:16 PM
To: Quagga Users Lists
Subject: [quagga-users 12893] ospf load balancing



Hello List.

Cisco says that with their OSPF implementation if the route cost are the
same
they do CEF, Does quagga on Linux 2.6.32 or later do any kind of load
balancing
if the costs are the same?

Thanks for any info.


--
Stephen Clark
NetWolves
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark [at] netwolves
http://www.netwolves.com
Attachments: smime.p7s (6.97 KB)


sclark at netwolves

May 16, 2012, 10:14 AM

Post #4 of 9 (1179 views)
Permalink
Re: ospf load balancing [In reply to]
On 05/16/2012 12:59 PM, Thomas York wrote:
>
> I know that if the interface speeds are the same and you don't have a manually defined cost (IE, Quagga derives the same cost on multiple interface), Quagga will add the route on both interfaces, but with identical weights and metrics. The kernel should do some kind of load balancing (not perfectly) in this scenario (as far as I know, someone feel free to correct me)
>
> 192.168.1.0/30 dev eth0 proto kernel scope link src 192.168.1.1
>
> 192.168.1.4/30 dev eth1 proto kernel scope link src 192.168.1.5
>
> 10.1.17.0/24 proto zebra metric 20
>
> nexthop via 192.168.1.2 dev eth0 weight 1
>
> nexthop via 192.168.1.6 dev eth1 weight 1
>
> 10.1.1.0/24 proto zebra metric 20
>
> nexthop via 192.168.1.2 dev eth0 weight 1
>
> nexthop via 192.168.1.6 dev eth1 weight 1
>
> 169.254.0.0/16 dev eth0 scope link metric 1002
>
> 169.254.0.0/16 dev eth1 scope link metric 1003
>
> In my lab (where I was coincidentally testing this very thing), router 1 has this routing table. Router 2 has 10.1.1.0/24 and 10.1.17.0/24 attached. Both of the links here are gigabit with no manual costing involved. Router 1 isn't distributing any routes. Also, this is RHEL 6.2 with 00.99.15.
>
Thanks Lennart and Thomas for taking the time to reply.


--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark [at] netwolves
http://www.netwolves.com


lsorense at csclub

May 16, 2012, 10:32 AM

Post #5 of 9 (1176 views)
Permalink
Re: ospf load balancing [In reply to]
On Wed, May 16, 2012 at 01:14:23PM -0400, Steve Clark wrote:
> On 05/16/2012 12:59 PM, Thomas York wrote:
> >
> >I know that if the interface speeds are the same and you don't have a manually defined cost (IE, Quagga derives the same cost on multiple interface), Quagga will add the route on both interfaces, but with identical weights and metrics. The kernel should do some kind of load balancing (not perfectly) in this scenario (as far as I know, someone feel free to correct me)
> >
> >192.168.1.0/30 dev eth0 proto kernel scope link src 192.168.1.1
> >
> >192.168.1.4/30 dev eth1 proto kernel scope link src 192.168.1.5
> >
> >10.1.17.0/24 proto zebra metric 20
> >
> > nexthop via 192.168.1.2 dev eth0 weight 1
> >
> > nexthop via 192.168.1.6 dev eth1 weight 1
> >
> >10.1.1.0/24 proto zebra metric 20
> >
> > nexthop via 192.168.1.2 dev eth0 weight 1
> >
> > nexthop via 192.168.1.6 dev eth1 weight 1
> >
> >169.254.0.0/16 dev eth0 scope link metric 1002
> >
> >169.254.0.0/16 dev eth1 scope link metric 1003
> >
> >In my lab (where I was coincidentally testing this very thing), router 1 has this routing table. Router 2 has 10.1.1.0/24 and 10.1.17.0/24 attached. Both of the links here are gigabit with no manual costing involved. Router 1 isn't distributing any routes. Also, this is RHEL 6.2 with 00.99.15.
> >
> Thanks Lennart and Thomas for taking the time to reply.

Make sure to turn off rp_filter when using multipath. Otherwise the
kernel will drop incoming traffic in many cases.

--
Len Sorensen
_______________________________________________
Quagga-users mailing list
Quagga-users [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-users


quagga-users at alexis

May 16, 2012, 1:04 PM

Post #6 of 9 (1170 views)
Permalink
Re: ospf load balancing [In reply to]
On May 16, 2012, at 12:49 PM, Lennart Sorensen wrote:
> quagga on linux will create multipath routes if you have equal cost
> routes to the same place. Linux will then pick one route for each flow
> (where as I believe cisco does per packet multipath routing).

Last time I looked, which was admittedly quite a long time ago, Ciscos would only do per-flow, if you were running CEF. Asking a Cisco to do per-packet would cause the packets to be process-switched. So the Linux behavior is the same as the standard Cisco behavior.

/a
_______________________________________________
Quagga-users mailing list
Quagga-users [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-users


lsorense at csclub

May 16, 2012, 2:29 PM

Post #7 of 9 (1169 views)
Permalink
Re: ospf load balancing [In reply to]
On Wed, May 16, 2012 at 04:04:59PM -0400, Alexis Rosen wrote:
> Last time I looked, which was admittedly quite a long time ago, Ciscos would only do per-flow, if you were running CEF. Asking a Cisco to do per-packet would cause the packets to be process-switched. So the Linux behavior is the same as the standard Cisco behavior.

That's good. Per packet was a bad idea (made out of order packets
much more frequent and made link failures affect all flows rather than
just some).

--
Len Sorensen
_______________________________________________
Quagga-users mailing list
Quagga-users [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-users


quagga-users at alexis

May 16, 2012, 6:17 PM

Post #8 of 9 (1161 views)
Permalink
Re: ospf load balancing [In reply to]
On May 16, 2012, at 5:29 PM, Lennart Sorensen wrote:
> On Wed, May 16, 2012 at 04:04:59PM -0400, Alexis Rosen wrote:
>> Last time I looked, which was admittedly quite a long time ago, Ciscos would only do per-flow, if you were running CEF. Asking a Cisco to do per-packet would cause the packets to be process-switched. So the Linux behavior is the same as the standard Cisco behavior.
>
> That's good. Per packet was a bad idea (made out of order packets
> much more frequent and made link failures affect all flows rather than
> just some).

There are circumstances (basically, extremely asymmetric or variable flows, generally coupled with narrow pipes) where that's not true, so it's good to have the option. But yes, most of the time it would cause way more harm than good.

/a
_______________________________________________
Quagga-users mailing list
Quagga-users [at] lists
http://lists.quagga.net/mailman/listinfo/quagga-users


hjp+quagga at wsr

May 18, 2012, 2:35 AM

Post #9 of 9 (1161 views)
Permalink
Re: ospf load balancing [In reply to]
On 2012-05-16 13:32:51 -0400, Lennart Sorensen wrote:
> On Wed, May 16, 2012 at 01:14:23PM -0400, Steve Clark wrote:
> > On 05/16/2012 12:59 PM, Thomas York wrote:
> > >I know that if the interface speeds are the same and you don't have
> > >a manually defined cost (IE, Quagga derives the same cost on
> > >multiple interface), Quagga will add the route on both interfaces,
> > >but with identical weights and metrics. The kernel should do some
> > >kind of load balancing (not perfectly) in this scenario (as far as
> > >I know, someone feel free to correct me)
> > >
> > >192.168.1.0/30 dev eth0 proto kernel scope link src 192.168.1.1
> > >
> > >192.168.1.4/30 dev eth1 proto kernel scope link src 192.168.1.5
> > >
> > >10.1.17.0/24 proto zebra metric 20
> > >
> > > nexthop via 192.168.1.2 dev eth0 weight 1
> > >
> > > nexthop via 192.168.1.6 dev eth1 weight 1
[...]
> > Thanks Lennart and Thomas for taking the time to reply.
>
> Make sure to turn off rp_filter when using multipath. Otherwise the
> kernel will drop incoming traffic in many cases.

And in another mail you mentioned that the routes are chosen per flow.

Is this per-flow routing symmetric?

Consider this scenario:

C
.
.
.
R
/ \
/ \
F1 F2
\ /
\ /
S

R is router, F1 and F2 are firewalls (routers with packet filters), S is
a server. The links between R, F1, F2 and S all have the same cost.

A Client C tries to establish a TCP connection to S. The SYN packet
arrives at R which chooses to forward the packet to F1 which in turn
forwards it S. S then replies with a SYN-ACK packet. How does it
determine where the send this packet?

1) By receiving the SYN packet from F1 a flow was established. The
SYN-ACK packet belongs to the same flow, so it is sent to F1.

2) This is the first packet to be sent in this connection, so no flow
has been established yet. The packet will be sent to either F1 or F2
with equal probability.

If F1 and F2 are stateful packet filters, only case 1 would work (unless
F1 and F2 have a way to share state).

hp

PS: Does it matter whether S can reach F1 through the same or different
interfaces?

--
_ | Peter J. Holzer | Auf jedem Computer sollte der Satz Ludwigs II
|_|_) | Sysadmin WSR | eingeprägt stehen: "Ein ewig Rätsel will ich
| | | hjp [at] wsr | bleiben, mir und andern."
__/ | http://www.hjp.at/ | -- Wolfram Heinrich in desd
Attachments: signature.asc (0.19 KB)

Quagga users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.