Re: Opt-in national WEA test in the United States on Aug 11 at 2:20pm EDT
A reminder, by default consumer cell phones do NOT have WEA tests enabled. Your phone would NOT display today's WEA test, unless you manually opt-in. Alerts are enabled by default -- Tests are disabled by default. On Tue, 10 Aug 2021, Sean Donelan wrote: Tommorrow, Wednesday, August 11, 2021 at 2:20 p.m. EDT the Federal Emergency Management Agency (FEMA) will be testing the national emergency alert system and wireless emergency alert system. [...] You can provide feedback, if you opted-in, about how well the test worked. email to FEMA-National-Test [@] fema.dhs.gov
Re: "Tactical" /24 announcements
On 8/11/21 12:24, Tom Hill wrote: Such anti-disaggregation/save-my-TCAM efforts really do not work, and will spawn all manner of support tickets. I'm saying this in the hope that it may prevent someone from reading this thread and concluding that it may be a good idea to try. It is not. We've been doing this on low-FIB platforms (mainly for our Metro, where we want to hold a full table in RIB and a few internal routes in RIB) since about 2014, and it works - as Scar in "The Lion King" would say - rather well. The only downside is when your IGP and LDP database grows larger than the available FIB. But that's another issue; although not an insignificant one. Mark.
Re: "Tactical" /24 announcements
On Wed, 11 Aug 2021, Tom Hill wrote: On 10/08/2021 07:15, Lukas Tribus wrote: Are there any big networks that drop or penalize announcements like this? It's possible you could get your peering request denied for this. I have put *reasonable* prefix aggregation into peering requirements for some years now. If you are a small eyeball network with 8192 IP addresses and originate 32 /24's, that is *not* reasonable. It is quite an issue when a network tries to programmatically filter-out the /24 more-specifics advertisements made from an allocated, .e.g, /20. Such anti-disaggregation/save-my-TCAM efforts really do not work, and will spawn all manner of support tickets. I'm saying this in the hope that it may prevent someone from reading this thread and concluding that it may be a good idea to try. It is not. What sort of hands-on experience is this opinion based on? 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%. -- 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
On Wed, 11 Aug 2021 at 12:24, Tom Hill wrote: > > On 10/08/2021 07:15, Lukas Tribus wrote: > >> Are there any big networks that drop or penalize announcements like this? > > It's possible you could get your peering request denied for this. I > > have put *reasonable* prefix aggregation into peering requirements for > > some years now. If you are a small eyeball network with 8192 IP > > addresses and originate 32 /24's, that is *not* reasonable. > > It is quite an issue when a network tries to programmatically filter-out > the /24 more-specifics advertisements made from an allocated, .e.g, /20. > > Such anti-disaggregation/save-my-TCAM efforts really do not work, and > will spawn all manner of support tickets. I'm saying this in the hope > that it may prevent someone from reading this thread and concluding that > it may be a good idea to try. It is not. For the record: I did not suggest anything like this. Denying peering requests due to lack of *reasonable* prefix aggregation does not mean installing fancy, impossibile to maintain prefix-lists on transit ingress. I agree with you here, that would be very bad. This save-my-TCAM effort is successful when the peer on the other site actually realizes that there are consequences to decisions like this and reverts it, which is a long shot, sure, but at least I'm not encouraging this. I don't get to dictate other peoples configurations. I do get to decide who is directly exchanging traffic with my network and who isn't. lukas
Re: "Tactical" /24 announcements
On 8/11/21 12:07, Tom Hill wrote: 2914 permit you to leak prefixes as specific as a /28 between your own ports with them. Someone once referred to it as a 'sneaky backhaul', believe. Given that there's no default in 2914, I guess that counts? :D I suppose some arrangement between you and your provider is alright. But since I (and I'm guessing, several other) operators that purchase from NTT will not accept anything longer than a /24 from them, it only serves internal forwarding within NTT for their customers that leak /25's or longer into them. I was wondering why we haven't seen this take off in the global DFZ :-). Mark.
Re: "Tactical" /24 announcements
On 10/08/2021 07:15, Lukas Tribus wrote: >> Are there any big networks that drop or penalize announcements like this? > It's possible you could get your peering request denied for this. I > have put *reasonable* prefix aggregation into peering requirements for > some years now. If you are a small eyeball network with 8192 IP > addresses and originate 32 /24's, that is *not* reasonable. It is quite an issue when a network tries to programmatically filter-out the /24 more-specifics advertisements made from an allocated, .e.g, /20. Such anti-disaggregation/save-my-TCAM efforts really do not work, and will spawn all manner of support tickets. I'm saying this in the hope that it may prevent someone from reading this thread and concluding that it may be a good idea to try. It is not. Speaking to your peers is good, as I think you're encouraging there. I would of course default to asking them if they've read from the Good Book of RPKI. :) I also often find that very outdated "Good Security Practice" is as much to blame for this as anything else, and so when we do talk to our peers and/or customers, we should always be asking the question: "who told you this was a good idea?" -- Tom
Re: "Tactical" /24 announcements
On 10/08/2021 12:31, Mark Tinka wrote: > Been waiting for the day when /27's, /28's and /29's are going to make > it into the DFZ, as was promised 5 or more years ago :-). 2914 permit you to leak prefixes as specific as a /28 between your own ports with them. Someone once referred to it as a 'sneaky backhaul', believe. Given that there's no default in 2914, I guess that counts? :D -- I'm really not being serious. A nice feature by NTT, but please let's never make it OK to populate the _actual_ DFZ with an IPv4 prefix greater than a /24. -- Tom
