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