Mailing List Archive: Zebra / quagga with BGP combined with policy based routes.

Zebra / quagga with BGP combined with policy based routes.

Jan 11, 2018, 1:30 AM

Post #1 of 7 (1357 views)

Hi There,

I'm fairly new to working with dynamic routing protocols and would
appreciate it if someone is willing to give me some advice with the
following scenario.

I've configured an edge router with three wan connection on it.

1: The first link goes to my primary upstream provider which acts as
my default gw .. nothing special here.
2: The second link goes to a secondary upstream provider where I'm
using policy based routes for only certain internal pre-fixes .
3: The third link is where things gets interesting :) This is a local
peering connection with other service providers using BGP .. so I've
configured Zebra / quagga with BGP which works pretty good.

So my question is , is it possible to give the routes received via BGP
priority over the policy based routes ? So for instance , if a
customer comes from an ip-prefix with a policy based route in place is
it possible to follow
the BGP route first before following the policy set for it ? I did
find a cumbersome way around the problem but I'm pretty sure this is
an unnecessary step. I ended up configuring a second based policy for
all those pre-fixes
with a lower priority for the BGP routes . So if a customer wants to
access content via the peering link it will try and route there first
following the lower priority route but this comes with it's own
problems like when a peering host is down
it's still going to try and follow the route configured via policy
based which kinda makes the whole idea behind using BGP useless.

Small example.

500: from 10.0.243.0/24 lookup PEERING : This I feel is
unnecessary and would like to configure the incoming BGP pre-fixes
with a higher priority so this route will get followed first instead
of creating a policy based route for each of the incoming pre-fixes
which renders the BGP setup useless.
ip route list table PEERING
168.167.252.0/24 via 192.168.179.40 dev enp2s0f1.555
168.167.253.0/24 via 192.168.179.40 dev enp2s0f1.555
168.167.254.0/24 via 192.168.179.40 dev enp2s0f1.555
168.167.255.0/24 via 192.168.179.40 dev enp2s0f1.555

510: from 10.0.243.0/24 lookup UPSTREAM2
default via 41.191.x.x dev enp2s0f0.210 : Gateway to second upstream;

I really hope I'm making some sense here.

Thanks in advance,
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: Zebra / quagga with BGP combined with policy based routes. [ In reply to ]

tim at kooky

Jan 11, 2018, 1:49 AM

Post #2 of 7 (1357 views)

Permalink

Hi,

What IP space are using? Is it provider independent space? presuming PI.

I would be tempted to lose the default gateway, and BGP to the first and
second links.

Then for 2, use a local preference in quagga BGP to send the outbound
traffic this way.       Then add AS-prepend to avoid inbound traffic on
this connection.

You will need a higher local preference on 3, to avoid traffic going down 2.

So 1. unchanged except routes coming over BGP

2, routes will come on BGP but you will pick and choose what you send
out this way.

3, peer, so should have fewer BGP hops. And set a higher local preference.

Actually, i'm not sure this will work or is the right way. You might
still need policy routes.   But a good way to think.

The reason for doing it this way is that you get a better route.   If
provider one loses some routes that provider 2 happens to still have,
then stuff still works.

On 11/01/18 09:30, Stephan Viljoen wrote:
> Hi There,
>
> I'm fairly new to working with dynamic routing protocols and would
> appreciate it if someone is willing to give me some advice with the
> following scenario.
>
> I've configured an edge router with three wan connection on it.
>
> 1: The first link goes to my primary upstream provider which acts as
> my default gw .. nothing special here.
> 2: The second link goes to a secondary upstream provider where I'm
> using policy based routes for only certain internal pre-fixes .
> 3: The third link is where things gets interesting :) This is a local
> peering connection with other service providers using BGP .. so I've
> configured Zebra / quagga with BGP which works pretty good.
>
> So my question is , is it possible to give the routes received via BGP
> priority over the policy based routes ? So for instance , if a
> customer comes from an ip-prefix with a policy based route in place is
> it possible to follow
> the BGP route first before following the policy set for it ? I did
> find a cumbersome way around the problem but I'm pretty sure this is
> an unnecessary step. I ended up configuring a second based policy for
> all those pre-fixes
> with a lower priority for the BGP routes . So if a customer wants to
> access content via the peering link it will try and route there first
> following the lower priority route but this comes with it's own
> problems like when a peering host is down
> it's still going to try and follow the route configured via policy
> based which kinda makes the whole idea behind using BGP useless.
>
> Small example.
>
> 500: from 10.0.243.0/24 lookup PEERING : This I feel is
> unnecessary and would like to configure the incoming BGP pre-fixes
> with a higher priority so this route will get followed first instead
> of creating a policy based route for each of the incoming pre-fixes
> which renders the BGP setup useless.
> ip route list table PEERING
> 168.167.252.0/24 via 192.168.179.40 dev enp2s0f1.555
> 168.167.253.0/24 via 192.168.179.40 dev enp2s0f1.555
> 168.167.254.0/24 via 192.168.179.40 dev enp2s0f1.555
> 168.167.255.0/24 via 192.168.179.40 dev enp2s0f1.555
>
> 510: from 10.0.243.0/24 lookup UPSTREAM2
> default via 41.191.x.x dev enp2s0f0.210 : Gateway to second upstream;
>
> I really hope I'm making some sense here.
>
> Thanks in advance,
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-users

_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: Zebra / quagga with BGP combined with policy based routes. [ In reply to ]

steph at bbi

Jan 11, 2018, 3:45 AM

Post #3 of 7 (1357 views)

Permalink

am I correct to assume that Zebra falls under the routing table main ?
In other words , if none of my lower priority tables isn't HIT it
will fall through to my main routing table ? And if this is the case ,
can I tell it to use a different routing table with a lower priority.

500: from 10.0.243.0/24 lookup PEERING
510: from 10.0.243.0/24 lookup UPSTREAM2
32766: from all lookup main (Seems my pre-fixes received via zebra
(bgp) falls under this table. )
32767: from all lookup default

ip route show table main
168.167.253.0/24 via 192.168.179.40 dev enp2s0f1.555 proto zebra
168.167.254.0/24 via 192.168.179.40 dev enp2s0f1.555 proto zebra
168.167.255.0/24 via 192.168.179.40 dev enp2s0f1.555 proto zebra

On Thu, Jan 11, 2018 at 11:49 AM, Tim Bray <tim@kooky.org> wrote:
> Hi,
>
>
> What IP space are using? Is it provider independent space? presuming PI.
>
> I would be tempted to lose the default gateway, and BGP to the first and
> second links.
>
> Then for 2, use a local preference in quagga BGP to send the outbound
> traffic this way. Then add AS-prepend to avoid inbound traffic on
> this connection.
>
> You will need a higher local preference on 3, to avoid traffic going down 2.
>
> So 1. unchanged except routes coming over BGP
>
> 2, routes will come on BGP but you will pick and choose what you send
> out this way.
>
> 3, peer, so should have fewer BGP hops. And set a higher local preference.
>
>
> Actually, i'm not sure this will work or is the right way. You might
> still need policy routes. But a good way to think.
>
>
> The reason for doing it this way is that you get a better route. If
> provider one loses some routes that provider 2 happens to still have,
> then stuff still works.
>
>
>
> On 11/01/18 09:30, Stephan Viljoen wrote:
>> Hi There,
>>
>> I'm fairly new to working with dynamic routing protocols and would
>> appreciate it if someone is willing to give me some advice with the
>> following scenario.
>>
>> I've configured an edge router with three wan connection on it.
>>
>> 1: The first link goes to my primary upstream provider which acts as
>> my default gw .. nothing special here.
>> 2: The second link goes to a secondary upstream provider where I'm
>> using policy based routes for only certain internal pre-fixes .
>> 3: The third link is where things gets interesting :) This is a local
>> peering connection with other service providers using BGP .. so I've
>> configured Zebra / quagga with BGP which works pretty good.
>>
>> So my question is , is it possible to give the routes received via BGP
>> priority over the policy based routes ? So for instance , if a
>> customer comes from an ip-prefix with a policy based route in place is
>> it possible to follow
>> the BGP route first before following the policy set for it ? I did
>> find a cumbersome way around the problem but I'm pretty sure this is
>> an unnecessary step. I ended up configuring a second based policy for
>> all those pre-fixes
>> with a lower priority for the BGP routes . So if a customer wants to
>> access content via the peering link it will try and route there first
>> following the lower priority route but this comes with it's own
>> problems like when a peering host is down
>> it's still going to try and follow the route configured via policy
>> based which kinda makes the whole idea behind using BGP useless.
>>
>> Small example.
>>
>> 500: from 10.0.243.0/24 lookup PEERING : This I feel is
>> unnecessary and would like to configure the incoming BGP pre-fixes
>> with a higher priority so this route will get followed first instead
>> of creating a policy based route for each of the incoming pre-fixes
>> which renders the BGP setup useless.
>> ip route list table PEERING
>> 168.167.252.0/24 via 192.168.179.40 dev enp2s0f1.555
>> 168.167.253.0/24 via 192.168.179.40 dev enp2s0f1.555
>> 168.167.254.0/24 via 192.168.179.40 dev enp2s0f1.555
>> 168.167.255.0/24 via 192.168.179.40 dev enp2s0f1.555
>>
>> 510: from 10.0.243.0/24 lookup UPSTREAM2
>> default via 41.191.x.x dev enp2s0f0.210 : Gateway to second upstream;
>>
>> I really hope I'm making some sense here.
>>
>> Thanks in advance,
>> _______________________________________________
>> Quagga-users mailing list
>> Quagga-users@lists.quagga.net
>> https://lists.quagga.net/mailman/listinfo/quagga-users
>
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-users
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: Zebra / quagga with BGP combined with policy based routes. [ In reply to ]

tim at kooky

Jan 11, 2018, 5:48 AM

Post #4 of 7 (1357 views)

Permalink

Hi,

Yes. You can tell zebra which table to update (linux only), but the
default is main.

Tim

On 11/01/18 11:45, Stephan Viljoen wrote:
> am I correct to assume that Zebra falls under the routing table main ?
> In other words , if none of my lower priority tables isn't HIT it
> will fall through to my main routing table ? And if this is the case ,
> can I tell it to use a different routing table with a lower priority.
>
> 500: from 10.0.243.0/24 lookup PEERING
> 510: from 10.0.243.0/24 lookup UPSTREAM2
> 32766: from all lookup main (Seems my pre-fixes received via zebra
> (bgp) falls under this table. )
> 32767: from all lookup default
>
> ip route show table main
> 168.167.253.0/24 via 192.168.179.40 dev enp2s0f1.555 proto zebra
> 168.167.254.0/24 via 192.168.179.40 dev enp2s0f1.555 proto zebra
> 168.167.255.0/24 via 192.168.179.40 dev enp2s0f1.555 proto zebra
>
> On Thu, Jan 11, 2018 at 11:49 AM, Tim Bray <tim@kooky.org> wrote:
>> Hi,
>>
>>
>> What IP space are using? Is it provider independent space? presuming PI.
>>
>> I would be tempted to lose the default gateway, and BGP to the first and
>> second links.
>>
>> Then for 2, use a local preference in quagga BGP to send the outbound
>> traffic this way. Then add AS-prepend to avoid inbound traffic on
>> this connection.
>>
>> You will need a higher local preference on 3, to avoid traffic going down 2.
>>
>> So 1. unchanged except routes coming over BGP
>>
>> 2, routes will come on BGP but you will pick and choose what you send
>> out this way.
>>
>> 3, peer, so should have fewer BGP hops. And set a higher local preference.
>>
>>
>> Actually, i'm not sure this will work or is the right way. You might
>> still need policy routes. But a good way to think.
>>
>>
>> The reason for doing it this way is that you get a better route. If
>> provider one loses some routes that provider 2 happens to still have,
>> then stuff still works.
>>
>>
>>
>> On 11/01/18 09:30, Stephan Viljoen wrote:
>>> Hi There,
>>>
>>> I'm fairly new to working with dynamic routing protocols and would
>>> appreciate it if someone is willing to give me some advice with the
>>> following scenario.
>>>
>>> I've configured an edge router with three wan connection on it.
>>>
>>> 1: The first link goes to my primary upstream provider which acts as
>>> my default gw .. nothing special here.
>>> 2: The second link goes to a secondary upstream provider where I'm
>>> using policy based routes for only certain internal pre-fixes .
>>> 3: The third link is where things gets interesting :) This is a local
>>> peering connection with other service providers using BGP .. so I've
>>> configured Zebra / quagga with BGP which works pretty good.
>>>
>>> So my question is , is it possible to give the routes received via BGP
>>> priority over the policy based routes ? So for instance , if a
>>> customer comes from an ip-prefix with a policy based route in place is
>>> it possible to follow
>>> the BGP route first before following the policy set for it ? I did
>>> find a cumbersome way around the problem but I'm pretty sure this is
>>> an unnecessary step. I ended up configuring a second based policy for
>>> all those pre-fixes
>>> with a lower priority for the BGP routes . So if a customer wants to
>>> access content via the peering link it will try and route there first
>>> following the lower priority route but this comes with it's own
>>> problems like when a peering host is down
>>> it's still going to try and follow the route configured via policy
>>> based which kinda makes the whole idea behind using BGP useless.
>>>
>>> Small example.
>>>
>>> 500: from 10.0.243.0/24 lookup PEERING : This I feel is
>>> unnecessary and would like to configure the incoming BGP pre-fixes
>>> with a higher priority so this route will get followed first instead
>>> of creating a policy based route for each of the incoming pre-fixes
>>> which renders the BGP setup useless.
>>> ip route list table PEERING
>>> 168.167.252.0/24 via 192.168.179.40 dev enp2s0f1.555
>>> 168.167.253.0/24 via 192.168.179.40 dev enp2s0f1.555
>>> 168.167.254.0/24 via 192.168.179.40 dev enp2s0f1.555
>>> 168.167.255.0/24 via 192.168.179.40 dev enp2s0f1.555
>>>
>>> 510: from 10.0.243.0/24 lookup UPSTREAM2
>>> default via 41.191.x.x dev enp2s0f0.210 : Gateway to second upstream;
>>>
>>> I really hope I'm making some sense here.
>>>
>>> Thanks in advance,
>>> _______________________________________________
>>> Quagga-users mailing list
>>> Quagga-users@lists.quagga.net
>>> https://lists.quagga.net/mailman/listinfo/quagga-users
>> _______________________________________________
>> Quagga-users mailing list
>> Quagga-users@lists.quagga.net
>> https://lists.quagga.net/mailman/listinfo/quagga-users
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-users

_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: Zebra / quagga with BGP combined with policy based routes. [ In reply to ]

steph at bbi

Jan 12, 2018, 3:26 AM

Post #5 of 7 (1356 views)

Permalink

Hi Tim,

Thanks for the reply . Is there perhaps some documentation you can
refer me to ? Perhaps I'm restarted but I've been googling all morning
without much success.

thanks again.
-steph

On Thu, Jan 11, 2018 at 3:48 PM, Tim Bray <tim@kooky.org> wrote:
> Hi,
>
> Yes. You can tell zebra which table to update (linux only), but the
> default is main.
>
>
> Tim
>
>
> On 11/01/18 11:45, Stephan Viljoen wrote:
>> am I correct to assume that Zebra falls under the routing table main ?
>> In other words , if none of my lower priority tables isn't HIT it
>> will fall through to my main routing table ? And if this is the case ,
>> can I tell it to use a different routing table with a lower priority.
>>
>> 500: from 10.0.243.0/24 lookup PEERING
>> 510: from 10.0.243.0/24 lookup UPSTREAM2
>> 32766: from all lookup main (Seems my pre-fixes received via zebra
>> (bgp) falls under this table. )
>> 32767: from all lookup default
>>
>> ip route show table main
>> 168.167.253.0/24 via 192.168.179.40 dev enp2s0f1.555 proto zebra
>> 168.167.254.0/24 via 192.168.179.40 dev enp2s0f1.555 proto zebra
>> 168.167.255.0/24 via 192.168.179.40 dev enp2s0f1.555 proto zebra
>>
>> On Thu, Jan 11, 2018 at 11:49 AM, Tim Bray <tim@kooky.org> wrote:
>>> Hi,
>>>
>>>
>>> What IP space are using? Is it provider independent space? presuming PI.
>>>
>>> I would be tempted to lose the default gateway, and BGP to the first and
>>> second links.
>>>
>>> Then for 2, use a local preference in quagga BGP to send the outbound
>>> traffic this way. Then add AS-prepend to avoid inbound traffic on
>>> this connection.
>>>
>>> You will need a higher local preference on 3, to avoid traffic going down 2.
>>>
>>> So 1. unchanged except routes coming over BGP
>>>
>>> 2, routes will come on BGP but you will pick and choose what you send
>>> out this way.
>>>
>>> 3, peer, so should have fewer BGP hops. And set a higher local preference.
>>>
>>>
>>> Actually, i'm not sure this will work or is the right way. You might
>>> still need policy routes. But a good way to think.
>>>
>>>
>>> The reason for doing it this way is that you get a better route. If
>>> provider one loses some routes that provider 2 happens to still have,
>>> then stuff still works.
>>>
>>>
>>>
>>> On 11/01/18 09:30, Stephan Viljoen wrote:
>>>> Hi There,
>>>>
>>>> I'm fairly new to working with dynamic routing protocols and would
>>>> appreciate it if someone is willing to give me some advice with the
>>>> following scenario.
>>>>
>>>> I've configured an edge router with three wan connection on it.
>>>>
>>>> 1: The first link goes to my primary upstream provider which acts as
>>>> my default gw .. nothing special here.
>>>> 2: The second link goes to a secondary upstream provider where I'm
>>>> using policy based routes for only certain internal pre-fixes .
>>>> 3: The third link is where things gets interesting :) This is a local
>>>> peering connection with other service providers using BGP .. so I've
>>>> configured Zebra / quagga with BGP which works pretty good.
>>>>
>>>> So my question is , is it possible to give the routes received via BGP
>>>> priority over the policy based routes ? So for instance , if a
>>>> customer comes from an ip-prefix with a policy based route in place is
>>>> it possible to follow
>>>> the BGP route first before following the policy set for it ? I did
>>>> find a cumbersome way around the problem but I'm pretty sure this is
>>>> an unnecessary step. I ended up configuring a second based policy for
>>>> all those pre-fixes
>>>> with a lower priority for the BGP routes . So if a customer wants to
>>>> access content via the peering link it will try and route there first
>>>> following the lower priority route but this comes with it's own
>>>> problems like when a peering host is down
>>>> it's still going to try and follow the route configured via policy
>>>> based which kinda makes the whole idea behind using BGP useless.
>>>>
>>>> Small example.
>>>>
>>>> 500: from 10.0.243.0/24 lookup PEERING : This I feel is
>>>> unnecessary and would like to configure the incoming BGP pre-fixes
>>>> with a higher priority so this route will get followed first instead
>>>> of creating a policy based route for each of the incoming pre-fixes
>>>> which renders the BGP setup useless.
>>>> ip route list table PEERING
>>>> 168.167.252.0/24 via 192.168.179.40 dev enp2s0f1.555
>>>> 168.167.253.0/24 via 192.168.179.40 dev enp2s0f1.555
>>>> 168.167.254.0/24 via 192.168.179.40 dev enp2s0f1.555
>>>> 168.167.255.0/24 via 192.168.179.40 dev enp2s0f1.555
>>>>
>>>> 510: from 10.0.243.0/24 lookup UPSTREAM2
>>>> default via 41.191.x.x dev enp2s0f0.210 : Gateway to second upstream;
>>>>
>>>> I really hope I'm making some sense here.
>>>>
>>>> Thanks in advance,
>>>> _______________________________________________
>>>> Quagga-users mailing list
>>>> Quagga-users@lists.quagga.net
>>>> https://lists.quagga.net/mailman/listinfo/quagga-users
>>> _______________________________________________
>>> Quagga-users mailing list
>>> Quagga-users@lists.quagga.net
>>> https://lists.quagga.net/mailman/listinfo/quagga-users
>> _______________________________________________
>> Quagga-users mailing list
>> Quagga-users@lists.quagga.net
>> https://lists.quagga.net/mailman/listinfo/quagga-users
>
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-users
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: Zebra / quagga with BGP combined with policy based routes. [ In reply to ]

tim at kooky

Jan 12, 2018, 9:03 AM

Post #6 of 7 (1356 views)

Permalink

http://www.nongnu.org/quagga/docs/quagga.html#Static-Route-Commands

And scroll down a bit

Command: *table tableno* //

Select the primary kernel routing table to be used. This only works
for kernels supporting multiple routing tables (like GNU/Linux 2.2.x
and later). After setting tableno with this command, static routes
defined after this are added to the specified table.

On 12/01/18 11:26, Stephan Viljoen wrote:
> Hi Tim,
>
> Thanks for the reply . Is there perhaps some documentation you can
> refer me to ? Perhaps I'm restarted but I've been googling all morning
> without much success.
>
> thanks again.
> -steph
>
>
> On Thu, Jan 11, 2018 at 3:48 PM, Tim Bray <tim@kooky.org> wrote:
>> Hi,
>>
>> Yes. You can tell zebra which table to update (linux only), but the
>> default is main.
>>
>>
>> Tim
>>
>>
>> On 11/01/18 11:45, Stephan Viljoen wrote:
>>> am I correct to assume that Zebra falls under the routing table main ?
>>> In other words , if none of my lower priority tables isn't HIT it
>>> will fall through to my main routing table ? And if this is the case ,
>>> can I tell it to use a different routing table with a lower priority.
>>>
>>> 500: from 10.0.243.0/24 lookup PEERING
>>> 510: from 10.0.243.0/24 lookup UPSTREAM2
>>> 32766: from all lookup main (Seems my pre-fixes received via zebra
>>> (bgp) falls under this table. )
>>> 32767: from all lookup default
>>>
>>> ip route show table main
>>> 168.167.253.0/24 via 192.168.179.40 dev enp2s0f1.555 proto zebra
>>> 168.167.254.0/24 via 192.168.179.40 dev enp2s0f1.555 proto zebra
>>> 168.167.255.0/24 via 192.168.179.40 dev enp2s0f1.555 proto zebra
>>>
>>> On Thu, Jan 11, 2018 at 11:49 AM, Tim Bray <tim@kooky.org> wrote:
>>>> Hi,
>>>>
>>>>
>>>> What IP space are using? Is it provider independent space? presuming PI.
>>>>
>>>> I would be tempted to lose the default gateway, and BGP to the first and
>>>> second links.
>>>>
>>>> Then for 2, use a local preference in quagga BGP to send the outbound
>>>> traffic this way. Then add AS-prepend to avoid inbound traffic on
>>>> this connection.
>>>>
>>>> You will need a higher local preference on 3, to avoid traffic going down 2.
>>>>
>>>> So 1. unchanged except routes coming over BGP
>>>>
>>>> 2, routes will come on BGP but you will pick and choose what you send
>>>> out this way.
>>>>
>>>> 3, peer, so should have fewer BGP hops. And set a higher local preference.
>>>>
>>>>
>>>> Actually, i'm not sure this will work or is the right way. You might
>>>> still need policy routes. But a good way to think.
>>>>
>>>>
>>>> The reason for doing it this way is that you get a better route. If
>>>> provider one loses some routes that provider 2 happens to still have,
>>>> then stuff still works.
>>>>
>>>>
>>>>
>>>> On 11/01/18 09:30, Stephan Viljoen wrote:
>>>>> Hi There,
>>>>>
>>>>> I'm fairly new to working with dynamic routing protocols and would
>>>>> appreciate it if someone is willing to give me some advice with the
>>>>> following scenario.
>>>>>
>>>>> I've configured an edge router with three wan connection on it.
>>>>>
>>>>> 1: The first link goes to my primary upstream provider which acts as
>>>>> my default gw .. nothing special here.
>>>>> 2: The second link goes to a secondary upstream provider where I'm
>>>>> using policy based routes for only certain internal pre-fixes .
>>>>> 3: The third link is where things gets interesting :) This is a local
>>>>> peering connection with other service providers using BGP .. so I've
>>>>> configured Zebra / quagga with BGP which works pretty good.
>>>>>
>>>>> So my question is , is it possible to give the routes received via BGP
>>>>> priority over the policy based routes ? So for instance , if a
>>>>> customer comes from an ip-prefix with a policy based route in place is
>>>>> it possible to follow
>>>>> the BGP route first before following the policy set for it ? I did
>>>>> find a cumbersome way around the problem but I'm pretty sure this is
>>>>> an unnecessary step. I ended up configuring a second based policy for
>>>>> all those pre-fixes
>>>>> with a lower priority for the BGP routes . So if a customer wants to
>>>>> access content via the peering link it will try and route there first
>>>>> following the lower priority route but this comes with it's own
>>>>> problems like when a peering host is down
>>>>> it's still going to try and follow the route configured via policy
>>>>> based which kinda makes the whole idea behind using BGP useless.
>>>>>
>>>>> Small example.
>>>>>
>>>>> 500: from 10.0.243.0/24 lookup PEERING : This I feel is
>>>>> unnecessary and would like to configure the incoming BGP pre-fixes
>>>>> with a higher priority so this route will get followed first instead
>>>>> of creating a policy based route for each of the incoming pre-fixes
>>>>> which renders the BGP setup useless.
>>>>> ip route list table PEERING
>>>>> 168.167.252.0/24 via 192.168.179.40 dev enp2s0f1.555
>>>>> 168.167.253.0/24 via 192.168.179.40 dev enp2s0f1.555
>>>>> 168.167.254.0/24 via 192.168.179.40 dev enp2s0f1.555
>>>>> 168.167.255.0/24 via 192.168.179.40 dev enp2s0f1.555
>>>>>
>>>>> 510: from 10.0.243.0/24 lookup UPSTREAM2
>>>>> default via 41.191.x.x dev enp2s0f0.210 : Gateway to second upstream;
>>>>>
>>>>> I really hope I'm making some sense here.
>>>>>
>>>>> Thanks in advance,
>>>>> _______________________________________________
>>>>> Quagga-users mailing list
>>>>> Quagga-users@lists.quagga.net
>>>>> https://lists.quagga.net/mailman/listinfo/quagga-users
>>>> _______________________________________________
>>>> Quagga-users mailing list
>>>> Quagga-users@lists.quagga.net
>>>> https://lists.quagga.net/mailman/listinfo/quagga-users
>>> _______________________________________________
>>> Quagga-users mailing list
>>> Quagga-users@lists.quagga.net
>>> https://lists.quagga.net/mailman/listinfo/quagga-users
>> _______________________________________________
>> Quagga-users mailing list
>> Quagga-users@lists.quagga.net
>> https://lists.quagga.net/mailman/listinfo/quagga-users
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-users

Re: Zebra / quagga with BGP combined with policy based routes. [ In reply to ]

steph at bbi

Jan 12, 2018, 9:08 AM

Post #7 of 7 (1356 views)

Permalink

Thanks a bunch.

On Fri, Jan 12, 2018 at 7:03 PM, Tim Bray <tim@kooky.org> wrote:
>
> http://www.nongnu.org/quagga/docs/quagga.html#Static-Route-Commands
>
> And scroll down a bit
>
>
> Command: table tableno
>
> Select the primary kernel routing table to be used. This only works for
> kernels supporting multiple routing tables (like GNU/Linux 2.2.x and later).
> After setting tableno with this command, static routes defined after this
> are added to the specified table.
>
>
>
> On 12/01/18 11:26, Stephan Viljoen wrote:
>
> Hi Tim,
>
> Thanks for the reply . Is there perhaps some documentation you can
> refer me to ? Perhaps I'm restarted but I've been googling all morning
> without much success.
>
> thanks again.
> -steph
>
>
> On Thu, Jan 11, 2018 at 3:48 PM, Tim Bray <tim@kooky.org> wrote:
>
> Hi,
>
> Yes. You can tell zebra which table to update (linux only), but the
> default is main.
>
>
> Tim
>
>
> On 11/01/18 11:45, Stephan Viljoen wrote:
>
> am I correct to assume that Zebra falls under the routing table main ?
> In other words , if none of my lower priority tables isn't HIT it
> will fall through to my main routing table ? And if this is the case ,
> can I tell it to use a different routing table with a lower priority.
>
> 500: from 10.0.243.0/24 lookup PEERING
> 510: from 10.0.243.0/24 lookup UPSTREAM2
> 32766: from all lookup main (Seems my pre-fixes received via zebra
> (bgp) falls under this table. )
> 32767: from all lookup default
>
> ip route show table main
> 168.167.253.0/24 via 192.168.179.40 dev enp2s0f1.555 proto zebra
> 168.167.254.0/24 via 192.168.179.40 dev enp2s0f1.555 proto zebra
> 168.167.255.0/24 via 192.168.179.40 dev enp2s0f1.555 proto zebra
>
> On Thu, Jan 11, 2018 at 11:49 AM, Tim Bray <tim@kooky.org> wrote:
>
> Hi,
>
>
> What IP space are using? Is it provider independent space? presuming PI.
>
> I would be tempted to lose the default gateway, and BGP to the first and
> second links.
>
> Then for 2, use a local preference in quagga BGP to send the outbound
> traffic this way. Then add AS-prepend to avoid inbound traffic on
> this connection.
>
> You will need a higher local preference on 3, to avoid traffic going down 2.
>
> So 1. unchanged except routes coming over BGP
>
> 2, routes will come on BGP but you will pick and choose what you send
> out this way.
>
> 3, peer, so should have fewer BGP hops. And set a higher local preference.
>
>
> Actually, i'm not sure this will work or is the right way. You might
> still need policy routes. But a good way to think.
>
>
> The reason for doing it this way is that you get a better route. If
> provider one loses some routes that provider 2 happens to still have,
> then stuff still works.
>
>
>
> On 11/01/18 09:30, Stephan Viljoen wrote:
>
> Hi There,
>
> I'm fairly new to working with dynamic routing protocols and would
> appreciate it if someone is willing to give me some advice with the
> following scenario.
>
> I've configured an edge router with three wan connection on it.
>
> 1: The first link goes to my primary upstream provider which acts as
> my default gw .. nothing special here.
> 2: The second link goes to a secondary upstream provider where I'm
> using policy based routes for only certain internal pre-fixes .
> 3: The third link is where things gets interesting :) This is a local
> peering connection with other service providers using BGP .. so I've
> configured Zebra / quagga with BGP which works pretty good.
>
> So my question is , is it possible to give the routes received via BGP
> priority over the policy based routes ? So for instance , if a
> customer comes from an ip-prefix with a policy based route in place is
> it possible to follow
> the BGP route first before following the policy set for it ? I did
> find a cumbersome way around the problem but I'm pretty sure this is
> an unnecessary step. I ended up configuring a second based policy for
> all those pre-fixes
> with a lower priority for the BGP routes . So if a customer wants to
> access content via the peering link it will try and route there first
> following the lower priority route but this comes with it's own
> problems like when a peering host is down
> it's still going to try and follow the route configured via policy
> based which kinda makes the whole idea behind using BGP useless.
>
> Small example.
>
> 500: from 10.0.243.0/24 lookup PEERING : This I feel is
> unnecessary and would like to configure the incoming BGP pre-fixes
> with a higher priority so this route will get followed first instead
> of creating a policy based route for each of the incoming pre-fixes
> which renders the BGP setup useless.
> ip route list table PEERING
> 168.167.252.0/24 via 192.168.179.40 dev enp2s0f1.555
> 168.167.253.0/24 via 192.168.179.40 dev enp2s0f1.555
> 168.167.254.0/24 via 192.168.179.40 dev enp2s0f1.555
> 168.167.255.0/24 via 192.168.179.40 dev enp2s0f1.555
>
> 510: from 10.0.243.0/24 lookup UPSTREAM2
> default via 41.191.x.x dev enp2s0f0.210 : Gateway to second upstream;
>
> I really hope I'm making some sense here.
>
> Thanks in advance,
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-users
>
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-users
>
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-users
>
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-users
>
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-users
>
>
>
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-users
>
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users