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

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

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