On Fri, Jun 5, 2020 at 6:08 PM Yang Yu wrote:
> On Fri, Jun 5, 2020 at 10:39 AM William Herrin wrote:
> > Speak of which, did anyone ever implement FIB compression? I seem to
> > remember the calculations looked really favorable for the leaf node
> > use case (like James') where the router sits
On Fri, Jun 5, 2020 at 10:39 AM William Herrin wrote:
> Speak of which, did anyone ever implement FIB compression? I seem to
> remember the calculations looked really favorable for the leaf node
> use case (like James') where the router sits at the edge with a small
> number of more or less
fre. 5. jun. 2020 20.12 skrev Ryan Rawdon :
>
>
> Shortly after filtering, we started occasionally finding destinations that
> were unreachable over the Internet (generally /24) due to:
I have observed this too.
I know of no router that can do this, but you need the router to
automatically
> On Jun 4, 2020, at 11:00 PM, James Breeden wrote:
>
> I have been doing a lot of research recently on operating networks with
> partial tables and a default to the rest of the world. Seems like an easy
> enough approach for regional networks where you have maybe only 1 upstream
> transit
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.
Daily listings are sent to
On Fri, Jun 05, 2020 at 10:20:00AM -0700, William Herrin wrote:
> On Fri, Jun 5, 2020 at 9:49 AM Saku Ytti wrote:
> > The comparison isn't between full or default, the comparison is
> > between static default or dynamic default. Of course with any default
> > scenario there are more failure modes
On Fri, Jun 5, 2020 at 10:30 AM Tore Anderson wrote:
> In the end I felt that running in production with the RIB and the FIB
> perpetually out of sync was too much of a hack, something that I would
> likely come to regret at a later point in time. That approach never
> made it out of the lab.
* Michael Hare
> I'm considering an approach similar to Tore's blog where at some
> point I keep the full RIB but selectively populate the FIB. Tore,
> care to comment on why you decided to filter the RIB as well?
Not «as well», «instead».
In the end I felt that running in production with the
On Fri, 5 Jun 2020 at 20:20, William Herrin wrote:
> It's a little more nuanced than that. You probably don't want to
> accept a default from your transit but you may want to pin defaults
> (or a set of broad routes as I did) to "representative" routes you do
> accept from your transit. By "pin"
On Fri, Jun 5, 2020 at 9:49 AM Saku Ytti wrote:
> The comparison isn't between full or default, the comparison is
> between static default or dynamic default. Of course with any default
> scenario there are more failure modes you cannot route around. But if
> you need default, you should not want
Hey Michael,
On Fri, 5 Jun 2020 at 19:37, Michael Hare wrote:
> Just because DFZ role device can advertise loopback unconditionally in IGP
> doesn't mean the DFZ actually has a valid eBGP or iBGP session to another
> DFZ. It may be contrived but could this not be a possible way to blackhole
Saku-
> In internal network, instead of having a default route in iBGP or IGP,
> you should have the same loopback address in every full DFZ router and
> advertise that loopback in IGP. Then non fullDFZ routers should static
> route default to that loopback, always reaching IGP closest full DFZ
>
Agree with Mike on looking at communities first. Depending on the provider,
that could be a very nice tool, or completely worthless.
For your planned idea on smaller "regional" nodes, you could do something
like :"default || ( customer && specific cities/states/regions/countries )"
, d
I would
On Thu, Jun 4, 2020 at 8:02 PM James Breeden wrote:
> I come to NANOG to get feedback from others who may be doing this. We have
> 3 upstream transit providers and PNI and public peers in 2 locations. It'd
> obviously be easy to transition to doing partial routes for just the peers,
> etc, but
Hi all
Just curious if anyone on is using the ACX5448 and what their thoughts are on
it.
Thanks
J~
Maybe instead of transit + 1, you use communities to just allow all customer
prefixes, regardless of how deep they are. Obviously that community would need
to be supported by that provider.
I've been wondering a similar thing for how to take advantage of the 150k -
250k hardware routes the
* Saku Ytti
> On Fri, 5 Jun 2020 at 11:23, Tore Anderson wrote:
>
> > Sure you can, you just ask them. (We did.)
>
> And is it the same now? Some Ytti didn't 'fix' the config last night?
> Or NOS change which doesn't do conditional routes? Or they
> misunderstood their implementation and it
On Fri, 5 Jun 2020 at 11:23, Tore Anderson wrote:
> Sure you can, you just ask them. (We did.)
And is it the same now? Some Ytti didn't 'fix' the config last night?
Or NOS change which doesn't do conditional routes? Or they
misunderstood their implementation and it doesn't actually work like
* Saku Ytti
> On Fri, 5 Jun 2020 at 10:48, Tore Anderson wrote:
>
> > We started taking defaults from our transits and filtering most of the
> > DFZ over three years ago. No regrets, it's one of the best decisions we
> > ever made. Vastly reduced both convergence time and CapEx.
>
> Is this
On Fri, 5 Jun 2020 at 10:48, Tore Anderson wrote:
> We started taking defaults from our transits and filtering most of the
> DFZ over three years ago. No regrets, it's one of the best decisions we
> ever made. Vastly reduced both convergence time and CapEx.
Is this verbatim? I don't think there
* James Breeden
> I come to NANOG to get feedback from others who may be doing this. We
> have 3 upstream transit providers and PNI and public peers in 2
> locations. It'd obviously be easy to transition to doing partial
> routes for just the peers, etc, but I'm not sure where to draw the
> line
21 matches
Mail list logo
