Re: Destination Preference Attribute for BGP
On 8/21/23 17:44, Tom Beecher wrote: So, while this all sounds good, without any specifics on vendor, box, code, code revision number, fix, year it happened, current status, e.t.c., I can't offer any meaningful engagement. If you clicked Matt's link to the Google search, you could tell from the results what vendor , model, and year it was pretty quickly. I did. Those are headlines. The solider that was on the battlefield won't speak to the exact details. I won't press, especially because nobody that needed a T1600 back then probably still runs one today. Assertion Made : "Networks can scrub communities for memory or convergence reasons." Others : "That doesn't seem like a concern. " Matt : "Here was a real situation that happened where it was a concern, and the specifics on the reason why." How is that not 'moving the needle? Because you didn't get full transcripts of his conversation with the vendor?. I'm sure a lot of people didn't even know that hashing / memory hotspotting was even a thing. Now they do. There are a lot of things that vendors have fixed in BGP that we shall never know. What I am saying is that for those that have been fixed, unless someone can offer up any additional evidence in 2023, the size of the number of BGP communities attached to a path does not scream "danger" in 2023 hardware. And the T1600 is a long time ago. Mark.
Re: MX204 Virtual Chassis Setup
On 8/21/23 16:51, Ryan Hamel wrote: Paschal, It is not supported, nor is it recommended for redundancy in a routed setup. Please describe your (desired) topology, that way the community can discuss alternatives. Sounds like the OP wants to build a chassis-based system out of non-redundant hardware. Mark.
Re: Internet Exchange Visualization
I hear the cybergeography project is making a comeback. https://personalpages.manchester.ac.uk/staff/m.dodge/cybergeography/atlas/atlas.html On Mon, Aug 21, 2023 at 5:17 PM Matthew Petach wrote: > > > > On Sun, Aug 20, 2023 at 11:06 PM Thomas Beer wrote: >> >> Hi Matt, >> >>> >>> You might mean "exchange inter-connections" as "how are the different >>> internet exchanges connected to each other?" >>> in which case the answer is generally "through the Internet". ^_^; >> >> >> I meant ix internet exchange path visualization and an online tool to take a >> look at it in (near) real time! >> >> Cheers >> > > > Ah, thank you for the enlightening clarification. > > No such tool exists, sorry. > > Thanks! > > Matt > -- Podcast: https://www.youtube.com/watch?v=bxmoBr4cBKg Dave Täht CSO, LibreQos
Re: JunOS config yacc grammar?
Diogo Montagner writes: > --728632060377d0b2 > Content-Type: text/plain; charset="UTF-8" > > I would first try to understand what you are trying to achieve. JUNOS is > very flexible on this front and I am wondering why you think yacc is the > right way to achieve what you are trying to do. Because I've been writing yacc grammars for decades. I just wanted to see if someone had already done it, as that would save me some time. But if there's nothing out there I'll just roll one myself. --lyndon
Re: JunOS config yacc grammar?
> > We already > have cron jobs running on the switches that tftp the config file > to a server, and I'd prefer to leverage off that. > Use the same cron jobs to save a copy as xml/json and pull the file off. On Mon, Aug 21, 2023 at 7:52 PM Lyndon Nerenberg (VE7TFX/VE6BBM) < lyn...@orthanc.ca> wrote: > Nick Hilliard writes: > > > No need to reinvent that wheel: > > > > root@foo> show configuration | display xml > > root@foo> show configuration | display json > > That doesn't quite work for this scenario. It would mean ssh-ing > to the switch to grab it, and that's pretty locked down. We already > have cron jobs running on the switches that tftp the config file > to a server, and I'd prefer to leverage off that. > > Also, the yacc parser would let me do some validation checks > before we push new configs. > > --lyndon >
Re: Internet Exchange Visualization
On Sun, Aug 20, 2023 at 11:06 PM Thomas Beer wrote: > Hi Matt, > > >> You might mean "exchange inter-connections" as "how are the different >> internet exchanges connected to each other?" >> in which case the answer is generally "through the Internet". ^_^; >> > > I meant ix internet exchange path visualization and an online tool to take > a look at it in (near) real time! > > Cheers > > Ah, thank you for the enlightening clarification. No such tool exists, sorry. Thanks! Matt
Re: JunOS config yacc grammar?
Nick Hilliard writes: > No need to reinvent that wheel: > > root@foo> show configuration | display xml > root@foo> show configuration | display json That doesn't quite work for this scenario. It would mean ssh-ing to the switch to grab it, and that's pretty locked down. We already have cron jobs running on the switches that tftp the config file to a server, and I'd prefer to leverage off that. Also, the yacc parser would let me do some validation checks before we push new configs. --lyndon
Re: JunOS config yacc grammar?
Lyndon Nerenberg (VE7TFX/VE6BBM) wrote on 21/08/2023 22:14: Any chance somebody out there has a yacc grammar that will parse a Juniper config files? My immediate interest involves v19.X on our EX4300s, but anything in the ballpark would save me having to write one from scratch. No need to reinvent that wheel: root@foo> show configuration | display xml root@foo> show configuration | display json ... then slurp into an ingestion engine in your favourite language. Nick
JunOS config yacc grammar?
Any chance somebody out there has a yacc grammar that will parse a Juniper config files? My immediate interest involves v19.X on our EX4300s, but anything in the ballpark would save me having to write one from scratch. --lyndon
RE: California hurricane and earthquake telecommunication impacts
13,733 cell sites in the declared area. Percentage out of service Imperial 6.2% Riverside 1.7% Los Angeles 0.5% Kern 0.4% San Diego 0.4% San Bernardino 0.3% Orange 0.2% On Mon, 21 Aug 2023, Kain, Becki (.) via NANOG wrote: Less than 1%? That's better than Detroit Edison on a sunny day -Original Message- From: NANOG On Behalf Of Sean Donelan Sent: Monday, August 21, 2023 3:01 PM To: nanog@nanog.org Subject: California hurricane and earthquake telecommunication impacts WARNING: This message originated outside of Ford Motor Company. Use caution when opening attachments, clicking links, or responding. For California only (I don't have sources for Hawaii). no reported loss of life 58,555 telecom subscribers out of service 54,514 power subscribers out of service 85 cell sites out of service (7 damanged, 52 transport, 20 no power) Less than 1% OOS in declared area 2 PSAPs (911) out of service 3 PSAPs (911) available without auto-location
RE: California hurricane and earthquake telecommunication impacts
Less than 1%? That's better than Detroit Edison on a sunny day -Original Message- From: NANOG On Behalf Of Sean Donelan Sent: Monday, August 21, 2023 3:01 PM To: nanog@nanog.org Subject: California hurricane and earthquake telecommunication impacts WARNING: This message originated outside of Ford Motor Company. Use caution when opening attachments, clicking links, or responding. For California only (I don't have sources for Hawaii). no reported loss of life 58,555 telecom subscribers out of service 54,514 power subscribers out of service 85 cell sites out of service (7 damanged, 52 transport, 20 no power) Less than 1% OOS in declared area 2 PSAPs (911) out of service 3 PSAPs (911) available without auto-location
California hurricane and earthquake telecommunication impacts
For California only (I don't have sources for Hawaii). no reported loss of life 58,555 telecom subscribers out of service 54,514 power subscribers out of service 85 cell sites out of service (7 damanged, 52 transport, 20 no power) Less than 1% OOS in declared area 2 PSAPs (911) out of service 3 PSAPs (911) available without auto-location
Re: Internet Exchange Visualization
Yep seen this. Awful bollo On Tue, 15 Aug 2023, 20:30 Randy Bush, wrote: > > You might instead be thinking of "how are different participants in a > > single internet exchange cross-connected to each other?" -- in which > > case the answer is "through in-building wiring that often even the > > building owner isn't entirely aware of what path the connections are > > taking." ^_^; > > actually, i am amazed by the extent of "remote peering." if one > measures rtt to all the peers on the six, for example, the curve goes > out to well over 200ms. the six has seen remote peers from the gulf > states, and i do not mean louisiana. > > graph below is one way to visualize ix connectivity, the op's question. > > randy > >
Fwd: Internet Exchange Visualization
-- Forwarded message - From: Delron Troy Date: Mon, 21 Aug 2023, 18:43 Subject: Re: Internet Exchange Visualization To: Ideally I think you need to go right back and study BGP. Looking glasses etc will show you everything you need to know combined with the other tools if you study. Cheers On Tue, 15 Aug 2023, 16:24 Thomas Beer, wrote: > Hi All! > > Has anybody a link to a cost-free service for visualizations of internet > exchange inter-connections? > > Thanks & cheers > Tom >
Re: Internet Exchange Visualization
> On Aug 21, 2023, at 8:32 AM, heasley wrote: > > Mon, Aug 21, 2023 at 08:06:11AM +0200, Thomas Beer: >> >> I meant ix internet exchange path visualization and an online tool to take >> a look at it in (near) real time! We currently do not have any near real time path visualizations. If you are happy with AS level you could consider ThousandEyes or RIPE’s BGPlay. You would need to get a list of IXP ASes. > ISTR caida has some IX visualisation tools? > > https://catalog.caida.org/search?query=t%20links%3Dtag%3Acaida%20internet%20exchange If you remove ’t’ from your filters you will double the number of matches. Bradley
[HELP] Opinion the Sparkle Scrubbing Center (AS6762)
Hello folks, I would like colleagues' opinion on Sparkle/Telecom Italia's scrubbing center services (AS6762). I am interested in this type of service in Brazil, I heard reports that they will have a scrubbing center there in the next few days. What makes me curious is knowing the experiences of other colleagues, I met someone who used it and the report on their SOC did not make me excited to hire the service, it may have been a bad experience, so I ask my colleagues for their opinion. Best Regards.
Re: Destination Preference Attribute for BGP
> > So, while this all sounds good, without any specifics on vendor, box, > code, code revision number, fix, year it happened, current status, e.t.c., > I can't offer any meaningful engagement. > If you clicked Matt's link to the Google search, you could tell from the results what vendor , model, and year it was pretty quickly. > It's just not moving the needle on this thread, though. > Assertion Made : "Networks can scrub communities for memory or convergence reasons." Others : "That doesn't seem like a concern. " Matt : "Here was a real situation that happened where it was a concern, and the specifics on the reason why." How is that not 'moving the needle? Because you didn't get full transcripts of his conversation with the vendor?. I'm sure a lot of people didn't even know that hashing / memory hotspotting was even a thing. Now they do. On Sat, Aug 19, 2023 at 1:17 AM Mark Tinka wrote: > > > On 8/19/23 00:22, Matthew Petach wrote: > > Hi Mark, > > I know it's annoying that I won't mention specifics. > Unfortunately, the last time I mentioned $vendor-specific information on > NANOG, it was picked up by the press, and turned into a multimillion dollar > kerfuffle with me at the center of the cross-hairs: > > https://www.google.com/search?q=petach+kablooie_esv=558180114=petah+kablooie=0=1580=1008=2 > > After that, I've learned it's best to not name specific very-big-name > vendors on NANOG posts. > > What I *can* say is that this was one of the primary vendors in the > Internet backbone space, running mainstream code. > The only reason it didn't affect more networks was a function of the > particular cluster of signalling communities being applied to all inbound > prefixes, and how they interacted with the vendor's hash algorithm. > > Corner cases, while valid, do not speak to the majority. If this was a >> major issue, there would have been more noise about it by now. >> > > I prefer to look at it the other way; the reason you didn't hear more > noise about it, is that we stubbed our toes on it early, and had relatively > fast, direct access to the development engineers to get it fixed within two > days. It's precisely *bcause* people trip over corner cases and get them > fixed that they don't end up causing more widespread pain across the rest > of the Internet. > > >> There has been quite some noise about lengthy AS_PATH updates that bring >> some routers down, which has usually been fixed with improved BGP code. But >> even those are not too common, if one considers a 365-day period. >> > > Oh, absolutely. Bugs in implementations that either crash the router or > reset the BGP session are much more immediately visible than "that's odd, > it's taking my routers longer to converge than it should". > > How many networks actually track their convergence time in a time series > database, and look at unusual trends, and then diagnose why the convergence > time is increasing, versus how many networks just note an increasing number > of "hey, your network seems to be slowing down" and throw more hardware at > the problem, while grumbling about why their big expensive routers seem to > be less powerful than a *nix box running gated? > > I suspect there's more of these type of "corner cases" out there than you > recognize. > It's just that most networks don't dig into routing performance issues > unless it actually breaks the router, or kills BGP adjacencies. > > If you *are* one of the few networks that tracks your router's convergence > time over time, and identifies and resolves unexpected increases in > convergence time, then yes, you absolutely have standing to tell me to pipe > down and go back into my corner again. ;D > > > So, while this all sounds good, without any specifics on vendor, box, > code, code revision number, fix, year it happened, current status, e.t.c., > I can't offer any meaningful engagement. > > We all run into odd stuff as we operate this Internet, but the point of a > list like this is to share those details so we can learn, fix and move > forward. > > Your ambiguity does not lend itself to a helpful discussion, > notwithstanding my understanding of your caution. > > I am less concerned about keeping smiles on vendors' faces. I tell them in > public and private if they are great or not. But since you've been burned, > I get. It's just not moving the needle on this thread, though. > > Mark. >
Re: Internet Exchange Visualization
Mon, Aug 21, 2023 at 08:06:11AM +0200, Thomas Beer: > Hi Matt, > > > > You might mean "exchange inter-connections" as "how are the different > > internet exchanges connected to each other?" > > in which case the answer is generally "through the Internet". ^_^; > > > > I meant ix internet exchange path visualization and an online tool to take > a look at it in (near) real time! ISTR caida has some IX visualisation tools? https://catalog.caida.org/search?query=t%20links%3Dtag%3Acaida%20internet%20exchange
Re: Internet Exchange Visualization
> On Aug 15, 2023, at 3:35 PM, Randy Bush wrote: > >> actually, i am amazed by the extent of "remote peering." if one >> measures rtt to all the peers on the six, for example, the curve goes >> out to well over 200ms. the six has seen remote peers from the gulf >> states, and i do not mean louisiana. >> >> graph below is one way to visualize ix connectivity, the op's >> question. > > i guess the list does not like graphs. decline of net predicted; news > at eleven. if you care, unicast. At $priorjob we had a latency requirement, must be I think it was ~2ms away. The number of IX that are effectively a global transit backbone is quite odd. I would be interested in seeing the graphic, if you can unicast or post URL. - Jared
Re: Internet Exchange Visualization
> > I meant ix internet exchange path visualization and an online tool to take > a look at it in (near) real time! I'm still not sure I follow your question. Are you asking 'How does IX-FOO connect to IX-BAR?' Or are you asking 'What ASNs connect to IX-FOO AND IX-BAR?' On Mon, Aug 21, 2023 at 7:53 AM Thomas Beer wrote: > Hi Matt, > > >> You might mean "exchange inter-connections" as "how are the different >> internet exchanges connected to each other?" >> in which case the answer is generally "through the Internet". ^_^; >> > > I meant ix internet exchange path visualization and an online tool to take > a look at it in (near) real time! > > Cheers > >
Re: MX204 Virtual Chassis Setup
Paschal, It is not supported, nor is it recommended for redundancy in a routed setup. Please describe your (desired) topology, that way the community can discuss alternatives. Thanks, Ryan Hamel From: NANOG on behalf of Pascal Masha Sent: Monday, August 21, 2023 7:41 AM To: nanog@nanog.org Subject: MX204 Virtual Chassis Setup Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. Hello, Does the MX204 support virtual chassis setup? Regards, Paschal Masha
MX204 Virtual Chassis Setup
Hello, Does the MX204 support virtual chassis setup? Regards, Paschal Masha
Re: Internet Exchange Visualization
Hi Matt, > You might mean "exchange inter-connections" as "how are the different > internet exchanges connected to each other?" > in which case the answer is generally "through the Internet". ^_^; > I meant ix internet exchange path visualization and an online tool to take a look at it in (near) real time! Cheers
