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

Thanks a bunch.



On Fri, Jan 12, 2018 at 7:03 PM, Tim Bray <[email protected]> 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 <[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
>