[quagga-users 14901] Re: Zebra / quagga with BGP combined with policy based routes.

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 <[email protected]> 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
>>> [email protected]
>>> https://lists.quagga.net/mailman/listinfo/quagga-users
>> _______________________________________________
>> Quagga-users mailing list
>> [email protected]
>> https://lists.quagga.net/mailman/listinfo/quagga-users
> _______________________________________________
> Quagga-users mailing list
> [email protected]
> https://lists.quagga.net/mailman/listinfo/quagga-users

_______________________________________________
Quagga-users mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-users