Re: BGP Experiment
I did realise a little after this that it would be a no no to talk this security wise. On Sat, 26 Jan 2019 at 12:47, Mark Tees wrote: > I might be reading this wrong but it appears only one person has raised an > issue and then not actually backed it up with data. > > Out of the eyes that have views inside the major networks did anyone see > any issues? > > Surely cross posting this to other NOG lists is sufficienct. > > > On Sat, 26 Jan 2019 at 09:15, Randy via NANOG wrote: > >> OP is yet to clarify how a single /24 advertisement caused a >> "massive-prefix spike/flap"; in OP's words. >> >> The Experiment should continue. >> -Randy >> >> >> On Friday, January 25, 2019, 2:32:47 PM PST, Tom Beecher >> wrote: >> >> If I understand this thread correctly, the test cause no actual change in >> the routing table size or route announcement. That was all a result of the >> incorrect behavior of the software. >> >> Instead of throwing rocks, how about some data instead. We can >> collaborate and better understand the whole thing so make it better and >> move on to the next thing. Yelling about "North America" when 4 of the 7 >> listed researchers on the test are NOT IN NORTH AMERICA doesn't really help >> anything. >> >> >> >> >> >> On Thu, Jan 24, 2019 at 10:25 AM Ben Cooper wrote: >> > Can you stop this? >> > >> > You caused again a massive prefix spike/flap, and as the internet is >> not centered around NA (shock horror!) a number of operators in Asia and >> Australia go effected by your “expirment” and had no idea what was >> happening or why. >> > >> > Get a sandbox like every other researcher, as of now we have black >> holed and filtered your whole ASN, and have reccomended others do the same. >> > >> > On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha wrote: >> >> NANOG, >> >> >> >> This is a reminder that this experiment will resume tomorrow >> >> (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a >> >> BGP attribute of type 0xff (reserved for development) between 14:00 >> >> and 14:15 GMT. >> >> >> >> On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha >> wrote: >> >>> >> >>> NANOG, >> >>> >> >>> We would like to inform you of an experiment to evaluate alternatives >> >>> for speeding up adoption of BGP route origin validation (research >> >>> paper with details [A]). >> >>> >> >>> Our plan is to announce prefix 184.164.224.0/24 with a valid >> >>> standards-compliant unassigned BGP attribute from routers operated by >> >>> the PEERING testbed [B, C]. The attribute will have flags 0xe0 >> >>> (optional transitive [rfc4271, S4.3]), type 0xff (reserved for >> >>> development), and size 0x20 (256bits). >> >>> >> >>> Our collaborators recently ran an equivalent experiment with no >> >>> complaints or known issues [A], and so we do not anticipate any >> >>> arising. Back in 2010, an experiment using unassigned attributes by >> >>> RIPE and Duke University caused disruption in Internet routing due to >> >>> a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other >> >>> similar bugs have been patched [e.g., CVE-2013-6051], and new BGP >> >>> attributes have been assigned (BGPsec-path) and adopted (large >> >>> communities). We have successfully tested propagation of the >> >>> announcements on Cisco IOS-based routers running versions 12.2(33)SRA >> >>> and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and >> >>> 1.6.3. >> >>> >> >>> We plan to announce 184.164.224.0/24 from 8 PEERING locations for a >> >>> predefined period of 15 minutes starting 14:30 GMT, from Monday to >> >>> Thursday, between the 7th and 22nd of January, 2019 (full schedule and >> >>> locations [E]). We will stop the experiment immediately in case any >> >>> issues arise. >> >>> >> >>> Although we do not expect the experiment to cause disruption, we >> >>> welcome feedback on its safety and especially on how to make it safer. >> >>> We can be reached at disco-experim...@googlegroups.com. >> >>> >> >>> Amir Herzberg, University of Connecticut >> >>> Ethan Katz-Bassett, Columbia University >> >>> Haya Shulman, Fraunhofer SIT >> >>> Ítalo Cunha, Universidade Federal de Minas Gerais >> >>> Michael Schapira, Hebrew University of Jerusalem >> >>> Tomas Hlavacek, Fraunhofer SIT >> >>> Yossi Gilad, MIT >> >>> >> >>> [A] https://conferences.sigcomm.org/hotnets/2018/program.html >> >>> [B] http://peering.usc.edu >> >>> [C] https://goo.gl/AFR1Cn >> >>> [D] >> https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment >> >>> [E] https://goo.gl/nJhmx1 >> >> >> > -- >> > Ben Cooper >> > Chief Executive Officer >> > PacketGG - Multicast >> > M(Telstra): 0410 411 301 >> > M(Optus): 0434 336 743 >> > E: b...@packet.gg & b...@multicast.net.au >> > W: https://packet.gg >> > W: https://multicast.net.au >> > >> > >> > >> > -- > Regards, > > Mark L. Tees > -- Regards, Mark L. Tees
Re: BGP Experiment
I might be reading this wrong but it appears only one person has raised an issue and then not actually backed it up with data. Out of the eyes that have views inside the major networks did anyone see any issues? Surely cross posting this to other NOG lists is sufficienct. On Sat, 26 Jan 2019 at 09:15, Randy via NANOG wrote: > OP is yet to clarify how a single /24 advertisement caused a > "massive-prefix spike/flap"; in OP's words. > > The Experiment should continue. > -Randy > > > On Friday, January 25, 2019, 2:32:47 PM PST, Tom Beecher > wrote: > > If I understand this thread correctly, the test cause no actual change in > the routing table size or route announcement. That was all a result of the > incorrect behavior of the software. > > Instead of throwing rocks, how about some data instead. We can collaborate > and better understand the whole thing so make it better and move on to the > next thing. Yelling about "North America" when 4 of the 7 listed > researchers on the test are NOT IN NORTH AMERICA doesn't really help > anything. > > > > > > On Thu, Jan 24, 2019 at 10:25 AM Ben Cooper wrote: > > Can you stop this? > > > > You caused again a massive prefix spike/flap, and as the internet is not > centered around NA (shock horror!) a number of operators in Asia and > Australia go effected by your “expirment” and had no idea what was > happening or why. > > > > Get a sandbox like every other researcher, as of now we have black holed > and filtered your whole ASN, and have reccomended others do the same. > > > > On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha wrote: > >> NANOG, > >> > >> This is a reminder that this experiment will resume tomorrow > >> (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a > >> BGP attribute of type 0xff (reserved for development) between 14:00 > >> and 14:15 GMT. > >> > >> On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha wrote: > >>> > >>> NANOG, > >>> > >>> We would like to inform you of an experiment to evaluate alternatives > >>> for speeding up adoption of BGP route origin validation (research > >>> paper with details [A]). > >>> > >>> Our plan is to announce prefix 184.164.224.0/24 with a valid > >>> standards-compliant unassigned BGP attribute from routers operated by > >>> the PEERING testbed [B, C]. The attribute will have flags 0xe0 > >>> (optional transitive [rfc4271, S4.3]), type 0xff (reserved for > >>> development), and size 0x20 (256bits). > >>> > >>> Our collaborators recently ran an equivalent experiment with no > >>> complaints or known issues [A], and so we do not anticipate any > >>> arising. Back in 2010, an experiment using unassigned attributes by > >>> RIPE and Duke University caused disruption in Internet routing due to > >>> a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other > >>> similar bugs have been patched [e.g., CVE-2013-6051], and new BGP > >>> attributes have been assigned (BGPsec-path) and adopted (large > >>> communities). We have successfully tested propagation of the > >>> announcements on Cisco IOS-based routers running versions 12.2(33)SRA > >>> and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and > >>> 1.6.3. > >>> > >>> We plan to announce 184.164.224.0/24 from 8 PEERING locations for a > >>> predefined period of 15 minutes starting 14:30 GMT, from Monday to > >>> Thursday, between the 7th and 22nd of January, 2019 (full schedule and > >>> locations [E]). We will stop the experiment immediately in case any > >>> issues arise. > >>> > >>> Although we do not expect the experiment to cause disruption, we > >>> welcome feedback on its safety and especially on how to make it safer. > >>> We can be reached at disco-experim...@googlegroups.com. > >>> > >>> Amir Herzberg, University of Connecticut > >>> Ethan Katz-Bassett, Columbia University > >>> Haya Shulman, Fraunhofer SIT > >>> Ítalo Cunha, Universidade Federal de Minas Gerais > >>> Michael Schapira, Hebrew University of Jerusalem > >>> Tomas Hlavacek, Fraunhofer SIT > >>> Yossi Gilad, MIT > >>> > >>> [A] https://conferences.sigcomm.org/hotnets/2018/program.html > >>> [B] http://peering.usc.edu > >>> [C] https://goo.gl/AFR1Cn > >>> [D] > https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment > >>> [E] https://goo.gl/nJhmx1 > >> > > -- > > Ben Cooper > > Chief Executive Officer > > PacketGG - Multicast > > M(Telstra): 0410 411 301 > > M(Optus): 0434 336 743 > > E: b...@packet.gg & b...@multicast.net.au > > W: https://packet.gg > > W: https://multicast.net.au > > > > > > > -- Regards, Mark L. Tees
Re: Quick Script to check the uptime of ASR920's
Good stuff! Thanks for sharing this will come in handy. Quick note for those running it would be a little more portable by changing the shebang line to #!/bin/sh as bash on a lot of systems does not exist in /bin -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Jan 25, 2019, at 18:44, Erik Sundberg wrote: > > It was a script I created in regards to this thread below... Interface > counters and some other things stop working after a Cisco ASR920 is up 889 > days Fun Fun > > https://puck.nether.net/pipermail/cisco-nsp/2019-January/106558.html > > > -Original Message- > From: Mel Beckman > Sent: Friday, January 25, 2019 6:39 PM > To: Erik Sundberg > Cc: nanog@nanog.org > Subject: Re: Quick Script to check the uptime of ASR920's > > Erik, > > That’s a nice little script. Thanks! > > So you want a warning if a router hasn’t been rebooted in a long time? Just > out of curiosity, why? I’m kind of glad that my routers don’t reboot, pretty > much ever. Usually I want to know if the uptime suddenly became less than the > most recent uptime, indicting a possibly unplanned reboot. > > -mel > >> On Jan 25, 2019, at 4:29 PM, Erik Sundberg wrote: >> >> All, >> >> I just created a quick script to check the uptime of a ASR920 via SNMP >> if you have a fairly long list of devices. It's a simple bash script >> and snmpwalk version 2c. Figured I would share it with you. Happy >> Friday >> >> Grab the code from GitHub: >> https://github.com/esundberg/CiscoRouterUptime >> It's a quick and dirty script and my first repo on github. Let me know if >> there any issues with it. >> >> >> Output Format in CSV >> DeviceName, IP, Uptime in Days, OK/Warning >> >> I set my warning to 800 Days, you can change this in the code >> >> >> ASR920list.txt >> - >> ASR920-1.SEA1, 192.168.28.1, SuperSecretSNMPKey ASR920-2.SEA1, >> 192.168.28.2, SuperSecretSNMPKey snip you get the idea >> >> >> Output >> >> [user@Linux]$ ./CiscoRouterUptime.sh ASR920list.txt ASR920-1.SEA1, >> 192.168.28.1, 827, WARNING ASR920-2.SEA1, 192.168.28.2, 827, WARNING >> ASR920-2.ATL1, 192.168.23.2, 828, WARNING ASR920-1.ATL1, 192.168.23.1, >> 813, WARNING ASR920-1.CHI1, 192.168.21.3, 828, WARNING ASR920-1.NYC1, >> 192.168.25.1, 787, OK ASR920-2.CHI1, 192.168.21.4, 720, OK >> ASR920-3.CHI1, 192.168.21.5, 720, OK ASR920-1.DAL1, 192.168.26.3, 488, >> OK ASR920-4.CHI1, 192.168.21.6, 142, OK >> >> >> >> >> >> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files >> or previous e-mail messages attached to it may contain confidential >> information that is legally privileged. If you are not the intended >> recipient, or a person responsible for delivering it to the intended >> recipient, you are hereby notified that any disclosure, copying, >> distribution or use of any of the information contained in or attached to >> this transmission is STRICTLY PROHIBITED. If you have received this >> transmission in error please notify the sender immediately by replying to >> this e-mail. You must destroy the original transmission and its attachments >> without reading or saving in any manner. Thank you. > > > > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or > previous e-mail messages attached to it may contain confidential information > that is legally privileged. If you are not the intended recipient, or a > person responsible for delivering it to the intended recipient, you are > hereby notified that any disclosure, copying, distribution or use of any of > the information contained in or attached to this transmission is STRICTLY > PROHIBITED. If you have received this transmission in error please notify the > sender immediately by replying to this e-mail. You must destroy the original > transmission and its attachments without reading or saving in any manner. > Thank you.
RE: Quick Script to check the uptime of ASR920's
It was a script I created in regards to this thread below... Interface counters and some other things stop working after a Cisco ASR920 is up 889 days Fun Fun https://puck.nether.net/pipermail/cisco-nsp/2019-January/106558.html -Original Message- From: Mel Beckman Sent: Friday, January 25, 2019 6:39 PM To: Erik Sundberg Cc: nanog@nanog.org Subject: Re: Quick Script to check the uptime of ASR920's Erik, That’s a nice little script. Thanks! So you want a warning if a router hasn’t been rebooted in a long time? Just out of curiosity, why? I’m kind of glad that my routers don’t reboot, pretty much ever. Usually I want to know if the uptime suddenly became less than the most recent uptime, indicting a possibly unplanned reboot. -mel > On Jan 25, 2019, at 4:29 PM, Erik Sundberg wrote: > > All, > > I just created a quick script to check the uptime of a ASR920 via SNMP > if you have a fairly long list of devices. It's a simple bash script > and snmpwalk version 2c. Figured I would share it with you. Happy > Friday > > Grab the code from GitHub: > https://github.com/esundberg/CiscoRouterUptime > It's a quick and dirty script and my first repo on github. Let me know if > there any issues with it. > > > Output Format in CSV > DeviceName, IP, Uptime in Days, OK/Warning > > I set my warning to 800 Days, you can change this in the code > > > ASR920list.txt > - > ASR920-1.SEA1, 192.168.28.1, SuperSecretSNMPKey ASR920-2.SEA1, > 192.168.28.2, SuperSecretSNMPKey snip you get the idea > > > Output > > [user@Linux]$ ./CiscoRouterUptime.sh ASR920list.txt ASR920-1.SEA1, > 192.168.28.1, 827, WARNING ASR920-2.SEA1, 192.168.28.2, 827, WARNING > ASR920-2.ATL1, 192.168.23.2, 828, WARNING ASR920-1.ATL1, 192.168.23.1, > 813, WARNING ASR920-1.CHI1, 192.168.21.3, 828, WARNING ASR920-1.NYC1, > 192.168.25.1, 787, OK ASR920-2.CHI1, 192.168.21.4, 720, OK > ASR920-3.CHI1, 192.168.21.5, 720, OK ASR920-1.DAL1, 192.168.26.3, 488, > OK ASR920-4.CHI1, 192.168.21.6, 142, OK > > > > > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or > previous e-mail messages attached to it may contain confidential information > that is legally privileged. If you are not the intended recipient, or a > person responsible for delivering it to the intended recipient, you are > hereby notified that any disclosure, copying, distribution or use of any of > the information contained in or attached to this transmission is STRICTLY > PROHIBITED. If you have received this transmission in error please notify the > sender immediately by replying to this e-mail. You must destroy the original > transmission and its attachments without reading or saving in any manner. > Thank you. CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
Re: Quick Script to check the uptime of ASR920's
Erik, That’s a nice little script. Thanks! So you want a warning if a router hasn’t been rebooted in a long time? Just out of curiosity, why? I’m kind of glad that my routers don’t reboot, pretty much ever. Usually I want to know if the uptime suddenly became less than the most recent uptime, indicting a possibly unplanned reboot. -mel > On Jan 25, 2019, at 4:29 PM, Erik Sundberg wrote: > > All, > > I just created a quick script to check the uptime of a ASR920 via SNMP if you > have a fairly long list of devices. It's a simple bash script and snmpwalk > version 2c. Figured I would share it with you. Happy Friday > > Grab the code from GitHub: https://github.com/esundberg/CiscoRouterUptime > It's a quick and dirty script and my first repo on github. Let me know if > there any issues with it. > > > Output Format in CSV > DeviceName, IP, Uptime in Days, OK/Warning > > I set my warning to 800 Days, you can change this in the code > > > ASR920list.txt > - > ASR920-1.SEA1, 192.168.28.1, SuperSecretSNMPKey > ASR920-2.SEA1, 192.168.28.2, SuperSecretSNMPKey > snip you get the idea > > > Output > > [user@Linux]$ ./CiscoRouterUptime.sh ASR920list.txt > ASR920-1.SEA1, 192.168.28.1, 827, WARNING > ASR920-2.SEA1, 192.168.28.2, 827, WARNING > ASR920-2.ATL1, 192.168.23.2, 828, WARNING > ASR920-1.ATL1, 192.168.23.1, 813, WARNING > ASR920-1.CHI1, 192.168.21.3, 828, WARNING > ASR920-1.NYC1, 192.168.25.1, 787, OK > ASR920-2.CHI1, 192.168.21.4, 720, OK > ASR920-3.CHI1, 192.168.21.5, 720, OK > ASR920-1.DAL1, 192.168.26.3, 488, OK > ASR920-4.CHI1, 192.168.21.6, 142, OK > > > > > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or > previous e-mail messages attached to it may contain confidential information > that is legally privileged. If you are not the intended recipient, or a > person responsible for delivering it to the intended recipient, you are > hereby notified that any disclosure, copying, distribution or use of any of > the information contained in or attached to this transmission is STRICTLY > PROHIBITED. If you have received this transmission in error please notify the > sender immediately by replying to this e-mail. You must destroy the original > transmission and its attachments without reading or saving in any manner. > Thank you.
RE: Quick Script to check the uptime of ASR920's
Doh.. Sent this to the wrong list.:facepalm: Check out c-nsp if you want to find out about Cisco Bug CSCvk35460 on ASR920. Counters stop working at 889 days of uptime. -Original Message- From: NANOG On Behalf Of Erik Sundberg Sent: Friday, January 25, 2019 6:30 PM To: nanog@nanog.org Subject: Quick Script to check the uptime of ASR920's All, I just created a quick script to check the uptime of a ASR920 via SNMP if you have a fairly long list of devices. It's a simple bash script and snmpwalk version 2c. Figured I would share it with you. Happy Friday Grab the code from GitHub: https://github.com/esundberg/CiscoRouterUptime It's a quick and dirty script and my first repo on github. Let me know if there any issues with it. Output Format in CSV DeviceName, IP, Uptime in Days, OK/Warning I set my warning to 800 Days, you can change this in the code ASR920list.txt - ASR920-1.SEA1, 192.168.28.1, SuperSecretSNMPKey ASR920-2.SEA1, 192.168.28.2, SuperSecretSNMPKey snip you get the idea Output [user@Linux]$ ./CiscoRouterUptime.sh ASR920list.txt ASR920-1.SEA1, 192.168.28.1, 827, WARNING ASR920-2.SEA1, 192.168.28.2, 827, WARNING ASR920-2.ATL1, 192.168.23.2, 828, WARNING ASR920-1.ATL1, 192.168.23.1, 813, WARNING ASR920-1.CHI1, 192.168.21.3, 828, WARNING ASR920-1.NYC1, 192.168.25.1, 787, OK ASR920-2.CHI1, 192.168.21.4, 720, OK ASR920-3.CHI1, 192.168.21.5, 720, OK ASR920-1.DAL1, 192.168.26.3, 488, OK ASR920-4.CHI1, 192.168.21.6, 142, OK CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
Quick Script to check the uptime of ASR920's
All, I just created a quick script to check the uptime of a ASR920 via SNMP if you have a fairly long list of devices. It's a simple bash script and snmpwalk version 2c. Figured I would share it with you. Happy Friday Grab the code from GitHub: https://github.com/esundberg/CiscoRouterUptime It's a quick and dirty script and my first repo on github. Let me know if there any issues with it. Output Format in CSV DeviceName, IP, Uptime in Days, OK/Warning I set my warning to 800 Days, you can change this in the code ASR920list.txt - ASR920-1.SEA1, 192.168.28.1, SuperSecretSNMPKey ASR920-2.SEA1, 192.168.28.2, SuperSecretSNMPKey snip you get the idea Output [user@Linux]$ ./CiscoRouterUptime.sh ASR920list.txt ASR920-1.SEA1, 192.168.28.1, 827, WARNING ASR920-2.SEA1, 192.168.28.2, 827, WARNING ASR920-2.ATL1, 192.168.23.2, 828, WARNING ASR920-1.ATL1, 192.168.23.1, 813, WARNING ASR920-1.CHI1, 192.168.21.3, 828, WARNING ASR920-1.NYC1, 192.168.25.1, 787, OK ASR920-2.CHI1, 192.168.21.4, 720, OK ASR920-3.CHI1, 192.168.21.5, 720, OK ASR920-1.DAL1, 192.168.26.3, 488, OK ASR920-4.CHI1, 192.168.21.6, 142, OK CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
Re: BGP Experiment
OP is yet to clarify how a single /24 advertisement caused a "massive-prefix spike/flap"; in OP's words. The Experiment should continue. -Randy On Friday, January 25, 2019, 2:32:47 PM PST, Tom Beecher wrote: If I understand this thread correctly, the test cause no actual change in the routing table size or route announcement. That was all a result of the incorrect behavior of the software. Instead of throwing rocks, how about some data instead. We can collaborate and better understand the whole thing so make it better and move on to the next thing. Yelling about "North America" when 4 of the 7 listed researchers on the test are NOT IN NORTH AMERICA doesn't really help anything. On Thu, Jan 24, 2019 at 10:25 AM Ben Cooper wrote: > Can you stop this? > > You caused again a massive prefix spike/flap, and as the internet is not > centered around NA (shock horror!) a number of operators in Asia and > Australia go effected by your “expirment” and had no idea what was happening > or why. > > Get a sandbox like every other researcher, as of now we have black holed and > filtered your whole ASN, and have reccomended others do the same. > > On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha wrote: >> NANOG, >> >> This is a reminder that this experiment will resume tomorrow >> (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a >> BGP attribute of type 0xff (reserved for development) between 14:00 >> and 14:15 GMT. >> >> On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha wrote: >>> >>> NANOG, >>> >>> We would like to inform you of an experiment to evaluate alternatives >>> for speeding up adoption of BGP route origin validation (research >>> paper with details [A]). >>> >>> Our plan is to announce prefix 184.164.224.0/24 with a valid >>> standards-compliant unassigned BGP attribute from routers operated by >>> the PEERING testbed [B, C]. The attribute will have flags 0xe0 >>> (optional transitive [rfc4271, S4.3]), type 0xff (reserved for >>> development), and size 0x20 (256bits). >>> >>> Our collaborators recently ran an equivalent experiment with no >>> complaints or known issues [A], and so we do not anticipate any >>> arising. Back in 2010, an experiment using unassigned attributes by >>> RIPE and Duke University caused disruption in Internet routing due to >>> a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other >>> similar bugs have been patched [e.g., CVE-2013-6051], and new BGP >>> attributes have been assigned (BGPsec-path) and adopted (large >>> communities). We have successfully tested propagation of the >>> announcements on Cisco IOS-based routers running versions 12.2(33)SRA >>> and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and >>> 1.6.3. >>> >>> We plan to announce 184.164.224.0/24 from 8 PEERING locations for a >>> predefined period of 15 minutes starting 14:30 GMT, from Monday to >>> Thursday, between the 7th and 22nd of January, 2019 (full schedule and >>> locations [E]). We will stop the experiment immediately in case any >>> issues arise. >>> >>> Although we do not expect the experiment to cause disruption, we >>> welcome feedback on its safety and especially on how to make it safer. >>> We can be reached at disco-experim...@googlegroups.com. >>> >>> Amir Herzberg, University of Connecticut >>> Ethan Katz-Bassett, Columbia University >>> Haya Shulman, Fraunhofer SIT >>> Ítalo Cunha, Universidade Federal de Minas Gerais >>> Michael Schapira, Hebrew University of Jerusalem >>> Tomas Hlavacek, Fraunhofer SIT >>> Yossi Gilad, MIT >>> >>> [A] https://conferences.sigcomm.org/hotnets/2018/program.html >>> [B] http://peering.usc.edu >>> [C] https://goo.gl/AFR1Cn >>> [D] >>> https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment >>> [E] https://goo.gl/nJhmx1 >> > -- > Ben Cooper > Chief Executive Officer > PacketGG - Multicast > M(Telstra): 0410 411 301 > M(Optus): 0434 336 743 > E: b...@packet.gg & b...@multicast.net.au > W: https://packet.gg > W: https://multicast.net.au > > >
Re: BGP Experiment
If I understand this thread correctly, the test cause no actual change in the routing table size or route announcement. That was all a result of the incorrect behavior of the software. Instead of throwing rocks, how about some data instead. We can collaborate and better understand the whole thing so make it better and move on to the next thing. Yelling about "North America" when 4 of the 7 listed researchers on the test are NOT IN NORTH AMERICA doesn't really help anything. On Thu, Jan 24, 2019 at 10:25 AM Ben Cooper wrote: > Can you stop this? > > You caused again a massive prefix spike/flap, and as the internet is not > centered around NA (shock horror!) a number of operators in Asia and > Australia go effected by your “expirment” and had no idea what was > happening or why. > > Get a sandbox like every other researcher, as of now we have black holed > and filtered your whole ASN, and have reccomended others do the same. > > On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha wrote: > >> NANOG, >> >> This is a reminder that this experiment will resume tomorrow >> (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a >> BGP attribute of type 0xff (reserved for development) between 14:00 >> and 14:15 GMT. >> >> On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha wrote: >> > >> > NANOG, >> > >> > We would like to inform you of an experiment to evaluate alternatives >> > for speeding up adoption of BGP route origin validation (research >> > paper with details [A]). >> > >> > Our plan is to announce prefix 184.164.224.0/24 with a valid >> > standards-compliant unassigned BGP attribute from routers operated by >> > the PEERING testbed [B, C]. The attribute will have flags 0xe0 >> > (optional transitive [rfc4271, S4.3]), type 0xff (reserved for >> > development), and size 0x20 (256bits). >> > >> > Our collaborators recently ran an equivalent experiment with no >> > complaints or known issues [A], and so we do not anticipate any >> > arising. Back in 2010, an experiment using unassigned attributes by >> > RIPE and Duke University caused disruption in Internet routing due to >> > a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other >> > similar bugs have been patched [e.g., CVE-2013-6051], and new BGP >> > attributes have been assigned (BGPsec-path) and adopted (large >> > communities). We have successfully tested propagation of the >> > announcements on Cisco IOS-based routers running versions 12.2(33)SRA >> > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and >> > 1.6.3. >> > >> > We plan to announce 184.164.224.0/24 from 8 PEERING locations for a >> > predefined period of 15 minutes starting 14:30 GMT, from Monday to >> > Thursday, between the 7th and 22nd of January, 2019 (full schedule and >> > locations [E]). We will stop the experiment immediately in case any >> > issues arise. >> > >> > Although we do not expect the experiment to cause disruption, we >> > welcome feedback on its safety and especially on how to make it safer. >> > We can be reached at disco-experim...@googlegroups.com. >> > >> > Amir Herzberg, University of Connecticut >> > Ethan Katz-Bassett, Columbia University >> > Haya Shulman, Fraunhofer SIT >> > Ítalo Cunha, Universidade Federal de Minas Gerais >> > Michael Schapira, Hebrew University of Jerusalem >> > Tomas Hlavacek, Fraunhofer SIT >> > Yossi Gilad, MIT >> > >> > [A] https://conferences.sigcomm.org/hotnets/2018/program.html >> > [B] http://peering.usc.edu >> > [C] https://goo.gl/AFR1Cn >> > [D] >> https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment >> > [E] https://goo.gl/nJhmx1 >> > -- > Ben Cooper > Chief Executive Officer > PacketGG - Multicast > M(Telstra): 0410 411 301 > M(Optus): 0434 336 743 > E: b...@packet.gg & b...@multicast.net.au > W: https://packet.gg > W: https://multicast.net.au > >
Re: BGP Experiment
It does, Ytti. And not just in testing. In feature development too. Often in design discussions, someone pipes up: "someone does bla bla, Let's not break it". One I remember from years ago was setting two route reflectors as clients of each other and thinking route reflection wasn't designed for that. It's being aware of such customer "creativity" that keeps us on our toes. Regards, Jakob. -Original Message- From: Saku Ytti Lot of vendor, maybe all, accept your configuration and test them for releases. I think this is only viable solution vendors have for blackbox, gather configs from customers and test those, instead of try to guess what to test. I've done that with Cisco in two companies, unfortunately I can't really tell if it impacted quality, but I like to think it did. -- ++ytti
RE: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS
Nah, statics everywhere. That way only I can fix it. ...sometimes... lol -Aaron -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy Bush Sent: Friday, January 25, 2019 12:41 PM To: Tom Beecher Cc: North American Network Operators' Group Subject: Re: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS > Next thing we know someone is going to start pumping up EIGRP. > >> there's an old saying, is-is is deployed in few networks, just some of >> the world's largest ones. there might be a reason for that. >> >> personally, i prefer emacs. idrp please randy
Re: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS
> Next thing we know someone is going to start pumping up EIGRP. > >> there's an old saying, is-is is deployed in few networks, just some of >> the world's largest ones. there might be a reason for that. >> >> personally, i prefer emacs. idrp please randy
Re: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS
Next thing we know someone is going to start pumping up EIGRP. On Fri, Jan 25, 2019 at 1:34 PM Randy Bush wrote: > there's an old saying, is-is is deployed in few networks, just some of > the world's largest ones. there might be a reason for that. > > personally, i prefer emacs. > > randy >
Re: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS
there's an old saying, is-is is deployed in few networks, just some of the world's largest ones. there might be a reason for that. personally, i prefer emacs. randy
Weekly Routing Table Report
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 26 Jan, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 735087 Prefixes after maximum aggregation (per Origin AS): 282856 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 353977 Total ASes present in the Internet Routing Table: 63043 Prefixes per ASN: 11.66 Origin-only ASes present in the Internet Routing Table: 54340 Origin ASes announcing only one prefix: 23554 Transit ASes present in the Internet Routing Table:8703 Transit-only ASes present in the Internet Routing Table:266 Average AS path length visible in the Internet Routing Table: 4.2 Max AS path length visible: 31 Max AS path prepend of ASN ( 16327) 25 Prefixes from unregistered ASNs in the Routing Table:21 Number of instances of unregistered ASNs:23 Number of 32-bit ASNs allocated by the RIRs: 25565 Number of 32-bit ASNs visible in the Routing Table: 20801 Prefixes from 32-bit ASNs in the Routing Table: 90165 Number of bogon 32-bit ASNs visible in the Routing Table:16 Special use prefixes present in the Routing Table:1 Prefixes being announced from unallocated address space:280 Number of addresses announced to Internet: 2842185859 Equivalent to 169 /8s, 104 /16s and 80 /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.1 Total number of prefixes smaller than registry allocations: 246520 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 200062 Total APNIC prefixes after maximum aggregation: 57154 APNIC Deaggregation factor:3.50 Prefixes being announced from the APNIC address blocks: 197213 Unique aggregates announced from the APNIC address blocks:81461 APNIC Region origin ASes present in the Internet Routing Table:9401 APNIC Prefixes per ASN: 20.98 APNIC Region origin ASes announcing only one prefix: 2654 APNIC Region transit ASes present in the Internet Routing Table: 1385 Average APNIC Region AS path length visible:4.1 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4402 Number of APNIC addresses announced to Internet: 769479202 Equivalent to 45 /8s, 221 /16s and 82 /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-139577 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:217564 Total ARIN prefixes after maximum aggregation: 103205 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 216843 Unique aggregates announced from the ARIN address blocks:103859 ARIN Region origin ASes present in the Internet Routing Table:18333 ARIN Prefixes per ASN:11.83 ARIN
Re: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS
I'm personally aware of dozens and dozens of OSPF deployments, but not aware of a single IS-IS deployment. This is among smaller consumer ISPs, with typically up to around 10K customers. I'm sure a big reason for this is that IS-IS support isn't all that common in the lower end routing gear often used by these providers. On Fri, Jan 25, 2019, 7:16 AM Steven Bahnsen Hi, > > First time poster looking for some input on a debate and I apologise if > I've > done this completely wrong, but I don't think my colleague will be > convinced > until he hears it from this community. > > Granted I'm relatively green when it comes to networking, but it was my > understand that other than BGP, the most widely used/implemented IGP > would be > OSPF. However, my colleague insists that I'm 100 percent wrong and that is > IS-IS. > > I want to be clear, I'm not debating which protocol is better or worse, as > they > both have their strengths and weaknesses and ultimately it comes down to > several > factors based on a particular use-case on which routing protocol is the > best way > forward for a network. > > However in saying that, I believe that, when it comes to sheer numbers of > where > an IGP is implemented, OSPF is far more widely used in the world today, > whether > it be in small to medium to large businesses, Enterprise networks and even > Service Provider networks (where as per my understanding, is where IS-IS > really > shines) > > I understand that this isn't really quantifiable, but I would like to get > the > opinions/experiences from this list and see what the outcome of this > question is > out of sheer curiosity. > > Thanks! > > Steve > >
RE: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS
In my isp network of ~50,000 subscribers, I run about (200) mpls p/pe nodes in one ospf area with dual rr cluster for mp-ibgp type mpls overlay services. seems fine to me. -Aaron
Re: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS
Q: why do we have to start this debate every other day? A: because i don't have time to start it every day On Fri, 25 Jan 2019 at 16:18, Steven Bahnsen wrote: > > Hi, > > First time poster looking for some input on a debate and I apologise if I've > done this completely wrong, but I don't think my colleague will be convinced > until he hears it from this community. > > Granted I'm relatively green when it comes to networking, but it was my > understand that other than BGP, the most widely used/implemented IGP would be > OSPF. However, my colleague insists that I'm 100 percent wrong and that is > IS-IS. > > I want to be clear, I'm not debating which protocol is better or worse, as > they > both have their strengths and weaknesses and ultimately it comes down to > several > factors based on a particular use-case on which routing protocol is the best > way > forward for a network. > > However in saying that, I believe that, when it comes to sheer numbers of > where > an IGP is implemented, OSPF is far more widely used in the world today, > whether > it be in small to medium to large businesses, Enterprise networks and even > Service Provider networks (where as per my understanding, is where IS-IS > really > shines) > > I understand that this isn't really quantifiable, but I would like to get the > opinions/experiences from this list and see what the outcome of this question > is > out of sheer curiosity. > > Thanks! > > Steve > -- ++ytti
Re: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS
Why would you want to settle a pointless debate? :) -mel beckman > On Jan 25, 2019, at 6:45 AM, Tom Hill wrote: > >> On 25/01/2019 04:47, Steven Bahnsen wrote: >> First time poster looking for some input on a debate > > > This won't settle anything. You've just started the same old debate > again, from the beginning. Again. :) > > There are almost certainly indexed threads of this mailing list with > enough answers to this question to last a life time of arguments. (See > also, c-nsp, probably j-nsp, UKNOF, etc.) > > -- > Tom
Re: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS
On 25/01/2019 04:47, Steven Bahnsen wrote: > First time poster looking for some input on a debate This won't settle anything. You've just started the same old debate again, from the beginning. Again. :) There are almost certainly indexed threads of this mailing list with enough answers to this question to last a life time of arguments. (See also, c-nsp, probably j-nsp, UKNOF, etc.) -- Tom
Re: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS
You’re probably right that there a lot more in service devices that are running OSPF. But IS-IS assuredly is involved in routing way more traffic volume. In the end , right tool for the job is all that matters. On Fri, Jan 25, 2019 at 09:17 Steven Bahnsen wrote: > Hi, > > First time poster looking for some input on a debate and I apologise if > I've > done this completely wrong, but I don't think my colleague will be > convinced > until he hears it from this community. > > Granted I'm relatively green when it comes to networking, but it was my > understand that other than BGP, the most widely used/implemented IGP > would be > OSPF. However, my colleague insists that I'm 100 percent wrong and that is > IS-IS. > > I want to be clear, I'm not debating which protocol is better or worse, as > they > both have their strengths and weaknesses and ultimately it comes down to > several > factors based on a particular use-case on which routing protocol is the > best way > forward for a network. > > However in saying that, I believe that, when it comes to sheer numbers of > where > an IGP is implemented, OSPF is far more widely used in the world today, > whether > it be in small to medium to large businesses, Enterprise networks and even > Service Provider networks (where as per my understanding, is where IS-IS > really > shines) > > I understand that this isn't really quantifiable, but I would like to get > the > opinions/experiences from this list and see what the outcome of this > question is > out of sheer curiosity. > > Thanks! > > Steve > >
[ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS
Hi, First time poster looking for some input on a debate and I apologise if I've done this completely wrong, but I don't think my colleague will be convinced until he hears it from this community. Granted I'm relatively green when it comes to networking, but it was my understand that other than BGP, the most widely used/implemented IGP would be OSPF. However, my colleague insists that I'm 100 percent wrong and that is IS-IS. I want to be clear, I'm not debating which protocol is better or worse, as they both have their strengths and weaknesses and ultimately it comes down to several factors based on a particular use-case on which routing protocol is the best way forward for a network. However in saying that, I believe that, when it comes to sheer numbers of where an IGP is implemented, OSPF is far more widely used in the world today, whether it be in small to medium to large businesses, Enterprise networks and even Service Provider networks (where as per my understanding, is where IS-IS really shines) I understand that this isn't really quantifiable, but I would like to get the opinions/experiences from this list and see what the outcome of this question is out of sheer curiosity. Thanks! Steve
Looking for contact from AS24218
Hello, I've already send to all address I could get from whois/web page and got nothing :(. Please be so kinde and write to me privately. Regards, -- Grzegorz Dabrowski
