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 <t...@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
