>or even by normal load from someone deciding to split a /8 prefix into /24's
If that kind of happening directly from load of added 25 routes it's quite hard to believe it.
# 10/8 prefix here only to show how to get number of new routes added.
$ sipcalc -n 24 10.0.0.0/8 | grep -c Network
25
$
BGP peering routing policies have then been for the good reason constructed in way that they expect advertisements "exact accept" with a prefix-list with that /8 prefix, because that's is expected when peering is agreed even when not explicitly stated by many. This expected best practice following goal to manage and prevent internet routing table being filled with superfluous routes.
But anyway, sudden change from /8 to 25 x /24 without first noticing your peers and giving them time to change that "exact accept;" to "orlonger accept;" is quite sure footgun if you don't know common principles of network management. But usually that kind of screwup blast radius is local mostly local only to that /8 prefix.
Not sure though how that could be technically avoided in BGP protocol or router control-plane (router OS config) design. Policy filters and best practices how to use them have been set for good reason. Not just to irritate and make things harder than they need to be. We certainly did not do that while I was still working.
Right, something else what could happen with that kind of sudden change is. If that peered had also other peers which had instead "orlonger" in place traffic would then switch to that, what could have some side effects like saturated links, slowness or even increased costs. Too bad, and may happen. But principle is that communicate your routing changes in good time before you actually make the changes. That will prevent most of this kind of problems ever happening to you.
Oh, my bad. How didn't I notice my mistake right away. That 25 is grossly wrong, I should have checked before using that. The correct line to get subnets is
Which increases significantly global routing table size of course. I apologise my mistake on that matter that I should have noticed before posting.
Anything else I wrote about changing prefix advertisement is correct. You should and need to communicate your advertisement changes in good time to your peers and let them time to make changes.
Most BGP peers have router filters in place. It's not 1996 anymore. I remember the days of logging into a Cisco connected to a Sprint T1 and seeing a coworker had fat fingered a spammer's route, sending it to null0. Oops. How did that happen?
Considering the routing table size has been increasing and IPv6 need anyone shouldn't be running global routing with gear not supporting RPKI any more, the routing polices and announcing those RIR they operate.
or even by normal load from someone deciding to split a /8 prefix into /24's
>or even by normal load from someone deciding to split a /8 prefix into /24's
If that kind of happening directly from load of added 25 routes it's quite hard to believe it.
BGP peering routing policies have then been for the good reason constructed in way that they expect advertisements "exact accept" with a prefix-list with that /8 prefix, because that's is expected when peering is agreed even when not explicitly stated by many. This expected best practice following goal to manage and prevent internet routing table being filled with superfluous routes.
But anyway, sudden change from /8 to 25 x /24 without first noticing your peers and giving them time to change that "exact accept;" to "orlonger accept;" is quite sure footgun if you don't know common principles of network management. But usually that kind of screwup blast radius is local mostly local only to that /8 prefix.
Not sure though how that could be technically avoided in BGP protocol or router control-plane (router OS config) design. Policy filters and best practices how to use them have been set for good reason. Not just to irritate and make things harder than they need to be. We certainly did not do that while I was still working.
Right, something else what could happen with that kind of sudden change is. If that peered had also other peers which had instead "orlonger" in place traffic would then switch to that, what could have some side effects like saturated links, slowness or even increased costs. Too bad, and may happen. But principle is that communicate your routing changes in good time before you actually make the changes. That will prevent most of this kind of problems ever happening to you.
Oh, my bad. How didn't I notice my mistake right away. That 25 is grossly wrong, I should have checked before using that. The correct line to get subnets is
Which increases significantly global routing table size of course. I apologise my mistake on that matter that I should have noticed before posting.
Anything else I wrote about changing prefix advertisement is correct. You should and need to communicate your advertisement changes in good time to your peers and let them time to make changes.
Most BGP peers have router filters in place. It's not 1996 anymore. I remember the days of logging into a Cisco connected to a Sprint T1 and seeing a coworker had fat fingered a spammer's route, sending it to null0. Oops. How did that happen?
Also RPKI has been available long time already.
Considering the routing table size has been increasing and IPv6 need anyone shouldn't be running global routing with gear not supporting RPKI any more, the routing polices and announcing those RIR they operate.
https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastruc...
1 reply →
I worked as a contractor for a IoT gig that sold sim cards services for buses, trains et cetera.
The radio towers we used to access to obtain the accounting data (CDRs) all had the same very weak password.