Re: "Tactical" /24 announcements

[Amir Herzberg]

On Thu, Aug 12, 2021 at 4:32 PM Baldur Norddahl 
wrote:

>
>
> On Thu, Aug 12, 2021 at 7:39 PM Amir Herzberg 
> wrote:
>
>> Bill, I beg to respectfully differ, knowing that I'm just a researcher
>> and working `for real' like you guys, so pls take no offence.
>>
>> I don't think A would be right to filter these packets to 10.0.1.0/24; A
>> has announced 10.0.0.0/16 so should route to that (entire) prefix, or A
>> is misleading its peers.
>>
>
> You are right that it is wrong but it happens. Some years back I tried a
> setup where we wanted to reduce the size of the routing table. We dropped
> everything but routes received from peers and added a default to one of our
> IP transit providers. This should have been ok because either we had a
> route to a peer or the packet would go to someone who had the full routing
> table, yes?
>

Baldur, thanks, but, sorry, this isn't the same, or I miss something. If I
get you right, you dropped all announcements from _providers_ except making
one provider your default gateway (essentially, 0.0.0.0/0). But this is
very different from what I understood from what Bill wrote. Your change
could (and, from what you say next, did) cause a problem if one of these
announcements you dropped from providers was a legit subprefix of a prefix
announced by one of your peers, causing you to route to the peer traffic
whose destination is in the subprefix. But let me be concrete using what
you wrote:

>
> So we got complaints. One was a company who would advertise a /20 on a
> peering with us. But somewhere else far away they had a site from where
> they would announce a /24 from the same prefix. With no internal routing
> between the peering site with the /20 to the other site with the /24. We
> therefore lost the ability to communicate with that /24.
>

exactly; but this is since you incorrectly dropped the subprefix
announcement which you evidently received from one of your providers.

If this analysis is correct, you could have solved the problem - reducing
the FIB while avoiding such loss of connectivity - if you retained (only)
the announcements from your providers which were to subprefixes of
announcements you got from your peers. A bit of scripting required, of
course... I'm sure you can do it 100 times faster and better than me :)

>
> You see variants of this. For example a large telco has a /16 from which
> they many years ago allocated a /24 to a multihomed customer. This customer
> left but took their /24 with them. This fact will seldom make the large
> telco split up their /16. They will keep it as a /16 but will no longer
> route to that /24. The question is also if we really would want a large
> telco to explode a large subnet due to this case.
>

No way, agreed!

But, as I explained, it's also unnecessary; I mean, that's exactly why we
do `most specific' routing. Just don't kill the subprefix announcement!

btw... yes, this is a possible issue with ROV, when sometimes there's a ROA
for a prefix (say /16) but no roa to a (legitimately announced) subprefix
(e.g. /20). We show such case in our 2015 ROV paper, and also measured how
many such issues exist; it appears their number is much reduced now, based
on more recent measurements. (ah and here, our ROV++ doesn't help; in fact,
it would disconnection even more likely than with ROV, since ROV protection
against subprefix hijacks is rather weak).

Regards,
--
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
 https://sites.google.com/site/amirherzberg/applied-crypto-textbook


>

Re: "Tactical" /24 announcements

[Baldur Norddahl]

On Thu, Aug 12, 2021 at 7:39 PM Amir Herzberg  wrote:

> Bill, I beg to respectfully differ, knowing that I'm just a researcher and
> working `for real' like you guys, so pls take no offence.
>
> I don't think A would be right to filter these packets to 10.0.1.0/24; A
> has announced 10.0.0.0/16 so should route to that (entire) prefix, or A
> is misleading its peers.
>

You are right that it is wrong but it happens. Some years back I tried a
setup where we wanted to reduce the size of the routing table. We dropped
everything but routes received from peers and added a default to one of our
IP transit providers. This should have been ok because either we had a
route to a peer or the packet would go to someone who had the full routing
table, yes?

So we got complaints. One was a company who would advertise a /20 on a
peering with us. But somewhere else far away they had a site from where
they would announce a /24 from the same prefix. With no internal routing
between the peering site with the /20 to the other site with the /24. We
therefore lost the ability to communicate with that /24.

You see variants of this. For example a large telco has a /16 from which
they many years ago allocated a /24 to a multihomed customer. This customer
left but took their /24 with them. This fact will seldom make the large
telco split up their /16. They will keep it as a /16 but will no longer
route to that /24. The question is also if we really would want a large
telco to explode a large subnet due to this case.

Regards,

Baldur

RE: [EXTERNAL] Re: PeeringDB Hackathon - looking for feature requests

[Knopps, Brian]

I agree that this would be an interesting feature as it is something we 
commonly do over here using two or more queries. 

-B 

-Original Message-
From: NANOG  On Behalf Of 
Alarig Le Lay
Sent: Thursday, August 12, 2021 3:10 PM
To: nanog@nanog.org
Subject: [EXTERNAL] Re: PeeringDB Hackathon - looking for feature requests

CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.

On Thu 12 Aug 2021 15:27:48 GMT, Steve McManus wrote:
> PeeringDB is looking at participating at an upcoming NANOG Hackathon.
> One of the ideas for a theme is to improve the API. Specifically by 
> adding API calls for common use cases that people need to handle 
> outside of the API. Typically, by dumping the entire database to SQL 
> For example - given two IXes, which networks are present at both? We'd 
> like to make a list of such useful queries such that people don't have 
> to dump the database just to run them. A stretch goal would be to 
> expose into the website instead of requiring API calls.
> 
> This issue has some more detail, including a few existing ideas:
> https://github.com/peeringdb/peeringdb/issues/1020
> 
> Comments there or in email to me would be super helpful. As always, if 
> there are other feature requests for PeeringDB, feel free to create an 
> issue in github ( 
> https://github.com/peeringdb/peeringdb/issues/new/choose ) or in 
> email, even if they're not strictly Hackathon ideas. They are always 
> appreciated!
> 
> Thanks! 
> 
> -Steve
> PeeringDB Product Committee chair

A nice feature could be, while logged in, to highlight the IXPs shared with the 
ASN currently displayed.

--
Alarig
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

Re: PeeringDB Hackathon - looking for feature requests

[Alarig Le Lay]

On Thu 12 Aug 2021 15:27:48 GMT, Steve McManus wrote:
> PeeringDB is looking at participating at an upcoming NANOG Hackathon.
> One of the ideas for a theme is to improve the API. Specifically by
> adding API calls for common use cases that people need to handle
> outside of the API. Typically, by dumping the entire database to SQL
> For example - given two IXes, which networks are present at both? We'd
> like to make a list of such useful queries such that people don't have
> to dump the database just to run them. A stretch goal would be to
> expose into the website instead of requiring API calls.
> 
> This issue has some more detail, including a few existing ideas:
> https://github.com/peeringdb/peeringdb/issues/1020
> 
> Comments there or in email to me would be super helpful. As always, if
> there are other feature requests for PeeringDB, feel free to create an
> issue in github (
> https://github.com/peeringdb/peeringdb/issues/new/choose ) or in
> email, even if they're not strictly Hackathon ideas. They are always
> appreciated!
> 
> Thanks! 
> 
> -Steve
> PeeringDB Product Committee chair

A nice feature could be, while logged in, to highlight the IXPs shared
with the ASN currently displayed.

-- 
Alarig

PeeringDB Hackathon - looking for feature requests

[Steve McManus]

PeeringDB is looking at participating at an upcoming NANOG Hackathon. One of 
the ideas for a theme is to improve the API. Specifically by adding API calls 
for common use cases that people need to handle outside of the API. Typically, 
by dumping the entire database to SQL For example - given two IXes, which 
networks are present at both? We'd like to make a list of such useful queries 
such that people don't have to dump the database just to run them. A stretch 
goal would be to expose into the website instead of requiring API calls.

This issue has some more detail, including a few existing ideas: 
https://github.com/peeringdb/peeringdb/issues/1020

Comments there or in email to me would be super helpful. As always, if there 
are other feature requests for PeeringDB, feel free to create an issue in 
github ( https://github.com/peeringdb/peeringdb/issues/new/choose ) or in 
email, even if they're not strictly Hackathon ideas. They are always 
appreciated!

Thanks! 

-Steve
PeeringDB Product Committee chair

Re: "Tactical" /24 announcements

[Jon Lewis]

On Thu, 12 Aug 2021, William Herrin wrote:


On Thu, Aug 12, 2021 at 9:41 AM Hank Nussbacher  wrote:

On 12/08/2021 17:59, William Herrin wrote:

If you prune the routes from the Routing Information Base instead, for
any widely accepted size (i.e. /24 or shorter netmask) you break the
Internet.


How does this break the Internet?  I would think it would just result in
sub-optimal routing (provided there is a covering larger prefix) but
everything should continue to work.  Clue me in, please.


A originates 10.0.0.0/16 to paid transit C
B originates 10.0.1.0/24 also to paid transit C
C offers both routes to D. D discards 10.0.1.0/24 from the RIB based
on same-next-hop
You peer with A and D. You receive only 10.0.0.0/16 since A doesn't
originate 10.0.1.0/24 and D has discarded it.
You send packets for 10.0.1.0/24 to A (the shortest path for
10.0.0.0/16), stealing A's paid transit to C to get to B.
Unless A filters C-bound packets purportedly from 10.0.1.0/24. B
doesn't currently transit for A so from B's perspective that's not an
allowed path. In which case, your path to 10.0.1.0/24 is black holed.

D broke the Internet. If packets from you reach A at all, they do so
through an unpermitted path.


A originated the /16 and should be prepared to deal with all bits to IPs 
within it.


What's worse is when A originates/advertises the /16 to C.  A also 
advertises the /24(s) only to other transits D, E, and F.  C's peers that 
don't see the subnets send traffic to C that C then has to send out via 
transit to reach D, E, or F.  I've been C :(  We asked A to make it stop.



--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: "Tactical" /24 announcements

[William Herrin]

On Thu, Aug 12, 2021 at 10:39 AM Amir Herzberg  wrote:
> On Thu, Aug 12, 2021 at 1:22 PM William Herrin  wrote:
>> A originates 10.0.0.0/16 to paid transit C
>> B originates 10.0.1.0/24 also to paid transit C

> Bill, I beg to respectfully differ, knowing that I'm just a researcher and 
> working `for real' like you guys, so pls take no offence.

Hi Amir,

Why would I take offense? How do any of us learn except by trying to
poke holes in claims to see what holds up and what doesn't?


> I don't think A would be right to filter these packets to 10.0.1.0/24; A has 
> announced 10.0.0.0/16 so should route to that (entire) prefix, or A is 
> misleading its peers.

The alternative is that A has to disaggregate 10.0.0.0/16 into at
least 8 prefixes on the -possibility- that some jackass might filter
the one /24 that B announces. If trying to filter one route results in
7 extra routes being added to the table, that's net badness.

Filtering may not even be intentional on A's part. If A's peering
router only receives A's customer-originated routes (a common enough
architecture) then the peering router won't even have a route to B
while B's route only arrives from C.

Regards,
Bill Herrin


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

Re: "Tactical" /24 announcements

[Jon Lewis]

On Thu, 12 Aug 2021, Nick Hilliard wrote:


Jon Lewis wrote on 12/08/2021 18:09:

 Arista.  They call it FIB compression.  They mention it's a trade-off,
 more memory and CPU utilization (keeping track of things) in exchange for
 being able to keep hardware that might otherwise be out of FIB space able
 to cope with full tables.


it also causes non-deterministic fib resource consumption. On most edge 
deployments this won't matter, but it wouldn't be hard to cook up a topology 
that could fail in interesting ways.  Overall fib compression is a net win, 
but you need to be careful with it.


Yeah...changes to the network could suddenly run such a box out of FIB 
resources, and you could easily be wrong when predicting how much longer a 
box has for it's "full routes" days...but the alternatives are "don't do 
full routes" or replace the box much sooner.
In that respect, it's somewhat remarkable that Arista even developed the 
feature.  "We can sell them newer hardware with larger FIB capabilities, 
or offer a software update that extends the life of the gear they've 
already bought."  What company chooses the latter? :)


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: "Tactical" /24 announcements

[Amir Herzberg]

On Thu, Aug 12, 2021 at 1:22 PM William Herrin  wrote:

> On Thu, Aug 12, 2021 at 9:41 AM Hank Nussbacher 
> wrote:
> > On 12/08/2021 17:59, William Herrin wrote:
> > > If you prune the routes from the Routing Information Base instead, for
> > > any widely accepted size (i.e. /24 or shorter netmask) you break the
> > > Internet.
> >
> > How does this break the Internet?  I would think it would just result in
> > sub-optimal routing (provided there is a covering larger prefix) but
> > everything should continue to work.  Clue me in, please.
>
> A originates 10.0.0.0/16 to paid transit C
> B originates 10.0.1.0/24 also to paid transit C
> C offers both routes to D. D discards 10.0.1.0/24 from the RIB based
> on same-next-hop
> You peer with A and D. You receive only 10.0.0.0/16 since A doesn't
> originate 10.0.1.0/24 and D has discarded it.
> You send packets for 10.0.1.0/24 to A (the shortest path for
> 10.0.0.0/16), stealing A's paid transit to C to get to B.

Unless A filters C-bound packets purportedly from 10.0.1.0/24. B
> doesn't currently transit for A so from B's perspective that's not an
> allowed path. In which case, your path to 10.0.1.0/24 is black holed.
>

Bill, I beg to respectfully differ, knowing that I'm just a researcher and
working `for real' like you guys, so pls take no offence.

I don't think A would be right to filter these packets to 10.0.1.0/24; A
has announced 10.0.0.0/16 so should route to that (entire) prefix, or A is
misleading its peers.

If A doesn't, though, then B receives a packet from A to 10.0.1.0/24.
Unless B is filtering based on the specific IP prefixes of A - which seems
to me unlikely - then B has no way to know that this packet is from `you'
rather than from A itself (or a customer of A). So B will carry this
traffic, imho.

So A is just paying for the traffic since it announced the prefix.

Such situations, to best of my knowledge, actually happen on the Internet
when a subprefix is filtered for different reasons. We observed it happens
with ROV , in our ROV++ simulations, but I'll refrain
from attaching the URL again so not to be `plugging' that paper (and since
I'm lazy to look it up hhh)

have great day and I'll be happy to learn if I'm wrong. Amir

Re: "Tactical" /24 announcements

[Nick Hilliard]

Jon Lewis wrote on 12/08/2021 18:09:
Arista.  They call it FIB compression.  They mention it's a trade-off, 
more memory and CPU utilization (keeping track of things) in exchange 
for being able to keep hardware that might otherwise be out of FIB space 
able to cope with full tables.


it also causes non-deterministic fib resource consumption. On most edge 
deployments this won't matter, but it wouldn't be hard to cook up a 
topology that could fail in interesting ways.  Overall fib compression 
is a net win, but you need to be careful with it.


Nick

Re: "Tactical" /24 announcements

[William Herrin]

On Thu, Aug 12, 2021 at 10:19 AM William Herrin  wrote:
> On Thu, Aug 12, 2021 at 9:41 AM Hank Nussbacher  wrote:
> > On 12/08/2021 17:59, William Herrin wrote:
> > > If you prune the routes from the Routing Information Base instead, for
> > > any widely accepted size (i.e. /24 or shorter netmask) you break the
> > > Internet.
> >
> > How does this break the Internet?  I would think it would just result in
> > sub-optimal routing (provided there is a covering larger prefix) but
> > everything should continue to work.  Clue me in, please.
>
> A originates 10.0.0.0/16 to paid transit C
> B originates 10.0.1.0/24 also to paid transit C
> C offers both routes to D. D discards 10.0.1.0/24 from the RIB based
> on same-next-hop
> You peer with A and D. You receive only 10.0.0.0/16 since A doesn't
> originate 10.0.1.0/24 and D has discarded it.
> You send packets for 10.0.1.0/24 to A (the shortest path for
> 10.0.0.0/16), stealing A's paid transit to C to get to B.
>Unless A filters C-bound packets purportedly from 10.0.1.0/24.

I mashed this sentence together wrong. I meant say: "Unless A filters
packets from peers which would use their paid transit," a common
policy restriction placed on settlement-free peering.

>B
> doesn't currently transit for A so from B's perspective that's not an
> allowed path. In which case, your path to 10.0.1.0/24 is black holed.
>
> D broke the Internet. If packets from you reach A at all, they do so
> through an unpermitted path.



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

Re: "Tactical" /24 announcements

[Tom Hill]

On 12/08/2021 18:09, Jon Lewis wrote:
>> 
>> Having an upstream provider that did it, in a very aggressive
>> fashion.
> 
> Odds are, they did it wrong, and you had no control and limited, if
> any, visibility into what they did.  Obviously, if you're going to
> blindly filter routes based on prefix-length, you need to point
> default at something that doesn't...and if you're acting as a transit
> provider, you're likely no longer able to provide "full routes" to
> customers from devices doing this or fed the "not so full table" from
> devices doing it.


Yes. This is precisely why I wrote my initial email, and perhaps I
wasn't specific enough, but it was a fairly generic warning against
"bright ideas" that don't include the proper scrutiny (or _do_ include
unnecessary amounts of arrogance).


> Arista.  They call it FIB compression.  They mention it's a
> trade-off, more memory and CPU utilization (keeping track of things)
> in exchange for being able to keep hardware that might otherwise be
> out of FIB space able to cope with full tables.

Ah, thank you, noted.

-- 
Tom

Re: "Tactical" /24 announcements

[William Herrin]

On Thu, Aug 12, 2021 at 9:41 AM Hank Nussbacher  wrote:
> On 12/08/2021 17:59, William Herrin wrote:
> > If you prune the routes from the Routing Information Base instead, for
> > any widely accepted size (i.e. /24 or shorter netmask) you break the
> > Internet.
>
> How does this break the Internet?  I would think it would just result in
> sub-optimal routing (provided there is a covering larger prefix) but
> everything should continue to work.  Clue me in, please.

A originates 10.0.0.0/16 to paid transit C
B originates 10.0.1.0/24 also to paid transit C
C offers both routes to D. D discards 10.0.1.0/24 from the RIB based
on same-next-hop
You peer with A and D. You receive only 10.0.0.0/16 since A doesn't
originate 10.0.1.0/24 and D has discarded it.
You send packets for 10.0.1.0/24 to A (the shortest path for
10.0.0.0/16), stealing A's paid transit to C to get to B.
Unless A filters C-bound packets purportedly from 10.0.1.0/24. B
doesn't currently transit for A so from B's perspective that's not an
allowed path. In which case, your path to 10.0.1.0/24 is black holed.

D broke the Internet. If packets from you reach A at all, they do so
through an unpermitted path.

Regards,
Bill Herrin


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

Re: "Tactical" /24 announcements

[Amir Herzberg]

On Thu, Aug 12, 2021 at 12:43 PM Hank Nussbacher 
wrote:

> On 12/08/2021 17:59, William Herrin wrote:
>
> > If you prune the routes from the Routing Information Base instead, for
> > any widely accepted size (i.e. /24 or shorter netmask) you break the
> > Internet.
>
> How does this break the Internet?  I would think it would just result in
> sub-optimal routing (provided there is a covering larger prefix) but
> everything should continue to work.  Clue me in, please.
>

Hi Hank, I think you're right, it could result in sub-optimal routing and
in particular, in your AS not being used for these subprefixes (the traffic
will go instead to a competing provider who sent the subprefix), hence, as
you said, sub-optimal routing.

I think some people (maybe Bill included) may consider the resulting harm
to routing to be sufficiently severe to consider this `breaking'. It
becomes a judgement call, I guess.

Cheers, Amir

>
> -Hank
>
>

Re: "Tactical" /24 announcements

[Jon Lewis]

On Thu, 12 Aug 2021, Tom Hill wrote:


On 11/08/2021 14:09, Jon Lewis wrote:

What sort of hands-on experience is this opinion based on?


Having an upstream provider that did it, in a very aggressive fashion.


Odds are, they did it wrong, and you had no control and limited, if any, 
visibility into what they did.  Obviously, if you're going to blindly 
filter routes based on prefix-length, you need to point default at 
something that doesn't...and if you're acting as a transit provider, 
you're likely no longer able to provide "full routes" to customers from 
devices doing this or fed the "not so full table" from devices doing it. 
I can work though, and on pretty much any platform.



Limiting the pruning to cases with the same next-hop does indeed sound
like it would be safer than what I've seen done in the past.

Doing this with per-peer prefix-lists would not (certainly not in
classic IOS) provide you with the ability to compare the next-hop before
rejecting those more-specific prefixes, and likely why the attempts to
do this caused the problems that I'm referring to.

I'm glad to hear a vendor has implemented a useful knob. Which vendor?


Arista.  They call it FIB compression.  They mention it's a trade-off, 
more memory and CPU utilization (keeping track of things) in exchange for 
being able to keep hardware that might otherwise be out of FIB space able 
to cope with full tables.


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: "Tactical" /24 announcements

[Hank Nussbacher]

On 12/08/2021 17:59, William Herrin wrote:


If you prune the routes from the Routing Information Base instead, for
any widely accepted size (i.e. /24 or shorter netmask) you break the
Internet. 


How does this break the Internet?  I would think it would just result in 
sub-optimal routing (provided there is a covering larger prefix) but 
everything should continue to work.  Clue me in, please.


-Hank

Re: "Tactical" /24 announcements

[William Herrin]

On Thu, Aug 12, 2021 at 7:44 AM Tom Hill  wrote:
> On 11/08/2021 14:09, Jon Lewis wrote:
> > At least one major network hardware vendor has implemented it as a
> > feature.  Turn it on, and the "deaggregates" with same next-hop as an
> > aggregate are not programmed into the FIB.  The savings will vary
> > depending on the device's connectivity, but I've seen >40%.
>
> Limiting the pruning to cases with the same next-hop does indeed sound
> like it would be safer than what I've seen done in the past.

Hi Tom,

To be clear, Jon was talking about pruning it from the FIB not the
RIB. You can always safely prune overlapping routes with the same next
hop from the Forwarding Information Base because the FIB lookup will
still select the same next hop regardless. This is valuable because
the main cost driver is carrying the routes in the FIB table that's
consulted for every packet handled.

If you prune the routes from the Routing Information Base instead, for
any widely accepted size (i.e. /24 or shorter netmask) you break the
Internet. Just because it's the same next hop for you doesn't mean the
routes actually share fate. The routers past you need both routes to
figure out their own position in a valid path. And it doesn't save you
much anyway because the RIB is only consulted when routes change and
need to be reprocessed into FIB entries. A $10 virtual server can
handle today's BGP RIB with ease and equipment with only a little more
power could handle one much larger. It's the FIB which drives the
limits.

Regards,
Bill Herrin


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

Re: "Tactical" /24 announcements

[Tom Hill]

On 11/08/2021 14:09, Jon Lewis wrote:
> What sort of hands-on experience is this opinion based on?

Having an upstream provider that did it, in a very aggressive fashion.


> I've done this manually in the past (quite some time ago), and done
> properly, it works fine.
> 
> At least one major network hardware vendor has implemented it as a
> feature.  Turn it on, and the "deaggregates" with same next-hop as an
> aggregate are not programmed into the FIB.  The savings will vary
> depending on the device's connectivity, but I've seen >40%.


Limiting the pruning to cases with the same next-hop does indeed sound
like it would be safer than what I've seen done in the past.

Doing this with per-peer prefix-lists would not (certainly not in
classic IOS) provide you with the ability to compare the next-hop before
rejecting those more-specific prefixes, and likely why the attempts to
do this caused the problems that I'm referring to.

I'm glad to hear a vendor has implemented a useful knob. Which vendor?

-- 
Tom

Re: Does anybody here have a problem

[Denys Fedoryshchenko]

List-Id: North American Network Operators Group 
IMO good enough for mail filters.

On 2021-08-10 19:20, Mike Hammett wrote:

Are you referring to mailing lists that lack some kind of added prefix
to the subject?

-
Mike Hammett
Intelligent Computing Solutions [1]
 [2] [3] [4] [5]
Midwest Internet Exchange [6]
 [7] [8] [9]
The Brothers WISP [10]
 [11] [12]

-

From: "C. A. Fillekes" 
To: "NANOG mailing list" 
Sent: Monday, August 9, 2021 6:43:50 PM
Subject: Does anybody here have a problem

telling the difference between their NANOG and SCA mail?

since I stopped getting both in digest form, maybe it's easier to mix
the two up by mistake.



Links:
--
[1] http://www.ics-il.com/
[2] https://www.facebook.com/ICSIL
[3] https://plus.google.com/+IntelligentComputingSolutionsDeKalb
[4] https://www.linkedin.com/company/intelligent-computing-solutions
[5] https://twitter.com/ICSIL
[6] http://www.midwest-ix.com/
[7] https://www.facebook.com/mdwestix
[8] https://www.linkedin.com/company/midwest-internet-exchange
[9] https://twitter.com/mdwestix
[10] http://www.thebrotherswisp.com/
[11] https://www.facebook.com/thebrotherswisp
[12] https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg