Re: Partial vs Full tables

[William Herrin]

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 at the edge with a small
> > number of more or less equivalent upstream transits. The FIB is the
> > expensive memory. The RIB sits in the cheap part of the hardware.
>
> fib optimize => using LPM table for LEM
> https://www.arista.com/en/um-eos/eos-section-28-11-ipv4-commands#ww1173031

Cool. So for folks who want a nutshell version about FIB compression,
here it is:

Your router has routing information bases (RIB) and a forwarding
information base (FIB). The FIB is what picks where to move the
packet. For each packet you look up the destination address in the FIB
and then send the packet to the next hop that you found in the FIB.
This is the expensive part of the router hardware because it has to do
this for every packet at line speed.

When we talk about the BGP table, we're talking about the RIB. That's
what has AS paths, communities, distances, etc. It's stored in
ordinary DRAM and computed by an ordinary CPU. Before the router can
route packets, the data in the RIB is reduced to a forwarding table
that's stored in the FIB. Normally, this means you take every route in
the RIB, pick the "best" one, figure out the next hop and then store
the result in the FIB.

FIB compression replaces that process with one that's more selective
about which RIB routes get installed in the FIB. The simplest version
works like this:

1. Figure out which next hop has the most routes pointing to it.
2. Add a default route to that next hop
3. Remove all the now-unnecessary more specific routes that go to the
same next hop.

If you have two upstream transit services, you've probably just cut
your FIB table size by more than half. Which means you don't need as
much of the pricey part of the router.

The actual algorithm gets more complex, the computational cost goes up
and the reduction in fib routes improves.

The down side is something you don't usually think about: default is
implicitly routed to reject (respond with icmp unreachable). 0.0.0.0/0
-> reject. You don't see it in your configuration but it's there all
the same. FIB compression eliminates the implicit reject and instead
routes the unroutable packets to a more or less random next hop. If
that next hop is also using FIB compression, it may route them right
back to you, creating a routing loop until the packet's TTL expires.

Happy weekend everybody,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Partial vs Full tables

[Yang Yu]

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 equivalent upstream transits. The FIB is the
> expensive memory. The RIB sits in the cheap part of the hardware.


fib optimize => using LPM table for LEM
https://www.arista.com/en/um-eos/eos-section-28-11-ipv4-commands#ww1173031

FIB compression => install only 1 entry into FIB for compressable
routes with shared nexthop
https://eos.arista.com/eos-4-21-3f/fib-compression/

The feature itself works as intended. version/platform/config
compatibility needs some considerations.

Re: Partial vs Full tables

[Baldur Norddahl]

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 accept any prefix on your transit link that is covered by
anything received from your peers.

Re: Partial vs Full tables

[Ryan Rawdon]

> 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 and some peering. 
> 
> 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 on the transit providers. I've 
> thought of straight preferencing one over another. I've thought of using BGP 
> filtering and community magic to basically allow Transit AS + 1 additional AS 
> (Transit direct customer) as specific routes, with summarization to default 
> for the rest. I'm sure there are other thoughts that I haven't had about this 
> as well
> 
> And before I get asked why not just run full tables, I'm looking at regional 
> approaches to being able to use smaller, less powerful routers (or even 
> layer3 switches) to run some areas of the network where we can benefit from 
> summarization and full tables are really overkill. 
> 

We started filtering certain mixes of long and specific routes on transit, at 
least while some upgrades to our edge capability are in progress.  We are a mix 
of transit providers, and public/private peering at our edge.

Shortly after filtering, we started occasionally finding destinations that were 
unreachable over the Internet (generally /24) due to:
- We filtered them on transit, probably due to long paths
- They were filtered from all of our transits, so their /24 was not in our table
- We did not receive their /24 on peering
- However, we did receive a covering prefix on peering
- Lastly, that actual destination network with the /24 no longer was connected 
to the network we received a covering route from, like a datacenter network 
that used to host them and SWIPed them their /24 to make it portable.

A 3rd party SaaS netflix platform’s BGP/netflow/SNMP collectors were impacted 
by this, which was one of the first instances we encountered of this problem.

We now have some convoluted scripting and routing policy in place, trying to 
proactively discover prefixes that may be impacted by this and then explicitly 
accepting that prefix or ASN on transit.  It is not a desirable solution, but 
this  seems like it could become more common over time with v4 prefix 
sales/swaps/deaggregation (with covering prefixes left in place); as well as 
increased TE where parties announce aggregates and specifics from disjoint 
locations.  

Our long term solution will be taking full tables again.

Ryan

Weekly Routing Table Report

[Routing Analysis Role Account]

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 bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 06 Jun, 2020

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  813692
Prefixes after maximum aggregation (per Origin AS):  308952
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  396724
Total ASes present in the Internet Routing Table: 68243
Prefixes per ASN: 11.92
Origin-only ASes present in the Internet Routing Table:   58615
Origin ASes announcing only one prefix:   24432
Transit ASes present in the Internet Routing Table:9628
Transit-only ASes present in the Internet Routing Table:316
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  46
Max AS path prepend of ASN ( 22394)  38
Prefixes from unregistered ASNs in the Routing Table:   836
Number of instances of unregistered ASNs:   838
Number of 32-bit ASNs allocated by the RIRs:  31936
Number of 32-bit ASNs visible in the Routing Table:   26324
Prefixes from 32-bit ASNs in the Routing Table:  121260
Number of bogon 32-bit ASNs visible in the Routing Table:14
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:549
Number of addresses announced to Internet:   2842667264
Equivalent to 169 /8s, 111 /16s and 169 /24s
Percentage of available address space announced:   76.8
Percentage of allocated address space announced:   76.8
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  274022

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   214366
Total APNIC prefixes after maximum aggregation:   62356
APNIC Deaggregation factor:3.44
Prefixes being announced from the APNIC address blocks:  207911
Unique aggregates announced from the APNIC address blocks:85914
APNIC Region origin ASes present in the Internet Routing Table:   10591
APNIC Prefixes per ASN:   19.63
APNIC Region origin ASes announcing only one prefix:   2953
APNIC Region transit ASes present in the Internet Routing Table:   1562
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 27
Number of APNIC region 32-bit ASNs visible in the Routing Table:   5670
Number of APNIC addresses announced to Internet:  767894400
Equivalent to 45 /8s, 197 /16s and 35 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-141625
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:237767
Total ARIN prefixes after maximum aggregation:   109331
ARIN Deaggregation factor: 2.17
Prefixes being announced from the ARIN address blocks:   235106
Unique aggregates announced from the ARIN address blocks:119598
ARIN Region origin ASes present in the Internet Routing Table:18520
ARIN Prefixes per ASN:12.69
ARIN 

Re: Partial vs Full tables

[Chuck Anderson]

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 you cannot route around. But if
> > you need default, you should not want to use dynamic default.
> 
> 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" I mean tell BGP that 0.0.0.0/0 is
> reachable by some address inside a representative route you've picked
> that is NOT the next hop. That way the default goes away if your
> transit loses the representative route and the default pinned to one
> of your other transits takes over.

I do the above using routes to *.root-servers.net to contribute to the
aggregate 0/0.

Re: Partial vs Full tables

[William Herrin]

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.

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 equivalent upstream transits. The FIB is the
expensive memory. The RIB sits in the cheap part of the hardware.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Partial vs Full tables

[Tore Anderson]

* 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 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.

For example, simple RIB lookups like «show route $dest» would not have
given truthful answers, which would likely have confused colleagues.

Even though we filter on the BGP sessions towards our transits, we
still all get the routes in our RIB and can look them up explicitly we
need to (e.g., in JunOS: «show route hidden $dest»).

Tore

Re: Partial vs Full tables

[Saku Ytti]

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" I mean tell BGP that 0.0.0.0/0 is
> reachable by some address inside a representative route you've picked
> that is NOT the next hop. That way the default goes away if your
> transit loses the representative route and the default pinned to one
> of your other transits takes over.

That is a great idea. Get all the utility of default with fewer risks.

-- 
  ++ytti

Re: Partial vs Full tables

[William Herrin]

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 to use dynamic default.

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" I mean tell BGP that 0.0.0.0/0 is
reachable by some address inside a representative route you've picked
that is NOT the next hop. That way the default goes away if your
transit loses the representative route and the default pinned to one
of your other transits takes over.

You can craft and tune an effective solution here, but there has to be
an awful lot of money at stake before the manpower is cheaper than
just buying a better router.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Partial vs Full tables

[Saku Ytti]

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 
> nearby PEs..?
>
> We currently take a full RIB and I am currently doing full FIB.  I'm 
> currently choosing to create a default aggregate for downstream default-only 
> connectors based on something like

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 to use dynamic default.

-- 
  ++ytti

RE: Partial vs Full tables

[Michael Hare via NANOG]

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
> router.

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 nearby 
PEs..?   

We currently take a full RIB and I am currently doing full FIB.  I'm currently 
choosing to create a default aggregate for downstream default-only connectors 
based on something like

 from {
protocol bgp;
as-path-group transit-providers;
route-filter 0.0.0.0/0 prefix-length-range /8-/10;
route-type external;
}

Of course there is something functionally equivalent for v6.  I have time 
series data on the count of routes contributing to the aggregate which helps a 
bit with ease of mind of default being pulled when it shouldn't be.  Like all 
tricks of this type I recognize this is susceptible to default being 
synthesized when it shouldn't be.

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?

-Michael

Re: Partial vs Full tables

[Tom Beecher]

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 definitely make sure you consider what your fallback options are in
case of partitions as Bill mentioned in another reply. The less routes you
have to start with the harder it gets though.

On Fri, Jun 5, 2020 at 9:19 AM Mike Hammett  wrote:

> 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 CRS317 now has in v7 beta. That many routes
> should cover the peering tables for most operators, maybe even transit's
> customers.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"James Breeden" 
> *To: *nanog@nanog.org
> *Sent: *Thursday, June 4, 2020 10:00:51 PM
> *Subject: *Partial vs Full tables
>
> 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 and some peering.
>
> 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 on the transit providers. I've
> thought of straight preferencing one over another. I've thought of using
> BGP filtering and community magic to basically allow Transit AS + 1
> additional AS (Transit direct customer) as specific routes, with
> summarization to default for the rest. I'm sure there are other thoughts
> that I haven't had about this as well
>
> And before I get asked why not just run full tables, I'm looking at
> regional approaches to being able to use smaller, less powerful routers (or
> even layer3 switches) to run some areas of the network where we can benefit
> from summarization and full tables are really overkill.
>
>
> *James W. Breeden*
>
> *Managing Partner*
>
>
>
> *[image: logo_transparent_background]*
>
> *Arenal Group:* Arenal Consulting Group | Acilis Telecom | Pines Media
>
> PO Box 1063 | Smithville, TX 78957
>
> Email: ja...@arenalgroup.co | office 512.360. | www.arenalgroup.co
>
>

Re: Partial vs Full tables

[William Herrin]

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 I'm not sure where to draw the line on the transit providers. I've
> thought of straight preferencing one over another. I've thought of using
> BGP filtering and community magic to basically allow Transit AS + 1
> additional AS (Transit direct customer) as specific routes, with
> summarization to default for the rest. I'm sure there are other thoughts
> that I haven't had about this as well
>

Hi James,

When I was at the DNC in 2007, we considered APNIC-region /8s lower
priority than ARNI region (for obvious reasons) so I got some extra life
out of our router by pinning most APNIC /8s to a few stable announcements,
preferring one transit to the other with a fallback static route. This
worked in the short term but I wouldn't want to do it as a long term
solution.

As a more generic approach: filter distant (long AS path) routes because
there's a higher probability that they're reachable from any transit with
about the same efficiency.

Any time you summarize routes, you WILL lose connectivity during network
partitions. Which defeats part of the purpose of having BGP with multiple
transits. Partitions are rare but they can persist for days (*cough* cogent
*cough*). So that's a risk you should plan for.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us

https://bill.herrin.us/

ACX5448

[JASON BOTHE via NANOG]

Hi all

Just curious if anyone on is using the ACX5448 and what their thoughts are on 
it. 

Thanks

J~

Re: Partial vs Full tables

[Mike Hammett]

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 CRS317 now has in v7 beta. That many routes should 
cover the peering tables for most operators, maybe even transit's customers. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "James Breeden"  
To: nanog@nanog.org 
Sent: Thursday, June 4, 2020 10:00:51 PM 
Subject: Partial vs Full tables 


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 and 
some peering. 


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 on the transit providers. I've 
thought of straight preferencing one over another. I've thought of using BGP 
filtering and community magic to basically allow Transit AS + 1 additional AS 
(Transit direct customer) as specific routes, with summarization to default for 
the rest. I'm sure there are other thoughts that I haven't had about this as 
well 


And before I get asked why not just run full tables, I'm looking at regional 
approaches to being able to use smaller, less powerful routers (or even layer3 
switches) to run some areas of the network where we can benefit from 
summarization and full tables are really overkill. 







James W. Breeden 
Managing Partner 

logo_transparent_background
Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media 
PO Box 1063 | Smithville, TX 78957 
Email: ja...@arenalgroup.co | office 512.360. | www.arenalgroup.co 

Re: Partial vs Full tables

[Tore Anderson]

* 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 doesn't actually work like
> they think it does. I personally always design my reliance to other
> people's clue to be as little as operationally feasible.

The way they answered the question showed that they had already
considered this particular failure case and engineered their
implementation accordingly. That is good enough for us.

Incorrect origination of a default route is, after all, just one of the
essentially infinite ways our transit providers can screw up our
services. Therefore it would make no sense to me to entrust the
delivery of our business critical packets to a transit provider, yet at
the same time not trust them to originate a default route reliably.

If we did not feel I could trust my transit provider, we would simply
find another one. There are plenty to choose from.

Tore

Re: Partial vs Full tables

[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 doesn't actually work like
they think it does. I personally always design my reliance to other
people's clue to be as little as operationally feasible.

-- 
++ytti

Re: Partial vs Full tables

[Tore Anderson]

* 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 verbatim?

I do not understand this question, sorry.

> you cannot know how the operator originates default

Sure you can, you just ask them. (We did.)

Tore

Re: Partial vs Full tables

[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 verbatim? I don't think there is a use case to ever carry
default route in dynamic routing.

In eBGP it should be some reliable indicator of operator network being
up, like their own aggregate route, they have incentive to originate
this correctly, as it affects their own services and products. So
recurse static default to this route. Otherwise you cannot know how
the operator originates default, they may just blindly generate it in
the edge, and if edge becomes disconnected from core, you'll
blackhole, compared to static route solution where the aggregate would
not be generated by edge routers by any sane operator due to
self-preservation instinct, you'd be able to converge instead of
blackhole.

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
router.

-- 
  ++ytti

Re: Partial vs Full tables

[Tore Anderson]

* 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 on the transit providers. I've thought of straight preferencing
> one over another. I've thought of using BGP filtering and community
> magic to basically allow Transit AS + 1 additional AS (Transit direct
> customer) as specific routes, with summarization to default for the
> rest. I'm sure there are other thoughts that I haven't had about this
> as well

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.

Transit providers worth their salt typically include BGP communities
you can use to selectively accept more-specific routes that you are
interested in. You could, for example, accept routes learned by your
transits from IX-es in in your geographic vicinity.

Here's a PoC where we used communities to filter out all routes except
for any routes learned by our primary transit provider anywhere in
Scandinavia, while using defaults for everything else:

https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html

(Note that we went away from the RIB->FIB filtering approach described
in the post, what we have in production is traditional filtering on the
BGP sessions.)

Tore