Re: Verizon NJ <-> Hetzner DE, routes via LA?
On Wed, May 18, 2022 at 2:29 PM Tomas Jonsson wrote: > Since yesterday, I've started to see an increase in latency between my > self in NJ on Verizon FIOS and Hetzner in DE. Even using Verizon:s > looking glass is giving me 250ms. This is an increase of about 150ms > (Seems to be true for most of the US East Coast) > A traceroute seems to tell me that the traffic is routed via LA, which > could explain the increase in latency. > > Traceroute from Verizon looking glass page, sourcing Newark > https://www.verizon.com/business/why-verizon/looking-glass/ > > traceroute to 144.76.94.10 (144.76.94.10), 30 hops max, 52 byte packets > 1 0.et-10-3-0.GW7.LAX15.ALTER.NET (140.222.235.147) 61.052 ms 61.522 > ms 61.063 ms > 2 152.179.21.22 (152.179.21.22) 158.708 ms 158.683 ms 158.681 ms > 3 * * pd900ccde.dip0.t-ipconnect.de (217.0.204.222) 263.187 ms > that's odd to see, I had thought DTAG was a peer of 701 at some point. maybe that's an incorrect 15 yr old memory :( (or maybe things changed!) it happens that from IAD area ... same path via LAX :( It also seems strange that 3320 would ONLY appear in LAX... maybe their east-coast landings are feeling under the weather? 4 62.157.248.138 (62.157.248.138) 249.071 ms 248.570 ms 248.737 ms > 5 * * * > 6 ex9k2.dc10.fsn1.hetzner.com (213.239.229.62) 250.333 ms 252.488 ms > 250.232 ms > > > Does anyone have any more insight? (Verizon status pages says everything > is fine, ofc) > the link you see above is a customer link ,so.. sure, everything for VZ is fine :) their customer though MAY be having a sad day.
Wave/Astound (AS11404) contact?
Hi list, If anyone has a valid contact for or is lurking from Wave/Astound (AS11404), would you please contact me off list? I'm having trouble getting a response from any of the ARIN addresses about stale PTR records causing issues, which I'd really like to get resolved. Thanks in advance // jkl
Verizon NJ <-> Hetzner DE, routes via LA?
Since yesterday, I've started to see an increase in latency between my self in NJ on Verizon FIOS and Hetzner in DE. Even using Verizon:s looking glass is giving me 250ms. This is an increase of about 150ms (Seems to be true for most of the US East Coast) A traceroute seems to tell me that the traffic is routed via LA, which could explain the increase in latency. Traceroute from Verizon looking glass page, sourcing Newark https://www.verizon.com/business/why-verizon/looking-glass/ traceroute to 144.76.94.10 (144.76.94.10), 30 hops max, 52 byte packets 1 0.et-10-3-0.GW7.LAX15.ALTER.NET (140.222.235.147) 61.052 ms 61.522 ms 61.063 ms 2 152.179.21.22 (152.179.21.22) 158.708 ms 158.683 ms 158.681 ms 3 * * pd900ccde.dip0.t-ipconnect.de (217.0.204.222) 263.187 ms 4 62.157.248.138 (62.157.248.138) 249.071 ms 248.570 ms 248.737 ms 5 * * * 6 ex9k2.dc10.fsn1.hetzner.com (213.239.229.62) 250.333 ms 252.488 ms 250.232 ms Does anyone have any more insight? (Verizon status pages says everything is fine, ofc)
Re: MSA’s and network architecture
On Wed, May 18, 2022 at 01:59 Mark Tinka wrote: > > > On 5/18/22 03:55, Martin Hannigan wrote: > > > > > > > All, > > > > Why do MSA’s matter as related to network architecture? > > As in "Master Services Agreement"? Admittedly vague, but deliberate. Perhaps the thread answered the question. :-) Metropolitan Statistical Area.The easy answer is "its where the eyeballs are". If so, that's great and it is (was) that simple. A lot of companies are predicting where the "edge" will actually shake out and most are using MSA. It's not that simple, there are certainly other attributes, but it may be that simple. Sorting by MSA and descending population you would think it is a no-brainer. Not necessarily? So perhaps a bolt on to the question, "and what attributes influence that importance?". Thanks -- -M<
Re: MSA’s and network architecture
> > Considered that, but that would be obvious - we need optics :-). > Agreed - but wouldn't it be fair to say that, nonetheless, the availability of an MSA supports the development of network architecture? With an MSA, there is some limited, common basis for a discussion in an ecosystem of vendors and network operators. That should support development of architecture. Cheers, Etienne On Wed, May 18, 2022 at 10:32 AM Mark Tinka wrote: > > > On 5/18/22 08:28, Etienne-Victor Depasquale via NANOG wrote: > > > Just to add a bit of fun to the mix - perhaps multi-source agreement > > was intended :) > > Considered that, but that would be obvious - we need optics :-). > > Mark. > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: MSA’s and network architecture
On Wed, 18 May 2022 at 11:35, Mark Tinka wrote: > Unless you are truly desperate and/or happy to get stuck in vendor-land, > always wise to be slightly behind the curve when it comes to optics. Agreed, if possible do boring things and get boring results. Even in vendor land, a boring result is not guaranteed. Vendor had one 100GE LR4 SKU approved for their platform and it had problems performing under some conditions. Issue was with something LBW (loop bandwidth?) some optics have this at 10MHz others 20MHz, and the former does not perform with certain jitter, latter does and the former was only one approved by the vendor. Vendor addressed this by removing approval for the only version that was approved and approved another one. It was not blatantly broken, it would almost certainly work fine in your lab, as environmental conditions needed to apply. Also testing goes only so far, because vendors change suppliers and hardware all the time, without changing SKU. Cisco is the only vendor I know who has very detailed change logs of what they are doing to the SKUs with each change. Single order might contain multiple versions of the SKU and the versions may not behave the same. We recently had this problem with 3rd party optic, where a new version of SKU didn't work for us, and we had to discover it in the field and we only knew of the SKU change after the problem occurred. Of course probably more than 99 SKU changes out of 100 are invisible to end users. -- ++ytti
Re: MSA’s and network architecture
On 5/18/22 08:39, Saku Ytti wrote: We could also add an explanation to our proposals for the acronym. :) In your fair proposal, MSA is related to network architecture as a way to standardise pluggable (optics). But as always standards are incomplete, ambiguous and do not guarantee interoperability, so it will take some time for industry to decide what is 'correct' interpretation of MSA. Implying when you buy early in life cycle new optics, you may want to source more carefully and test, compared to buying later in life cycle sourcing pluggables anywhere with 0 testing is relatively low risk. Unless you are truly desperate and/or happy to get stuck in vendor-land, always wise to be slightly behind the curve when it comes to optics. Mark.
Re: MSA’s and network architecture
On 5/18/22 08:28, Etienne-Victor Depasquale via NANOG wrote: Just to add a bit of fun to the mix - perhaps multi-source agreement was intended :) Considered that, but that would be obvious - we need optics :-). Mark.
Re: MSA’s and network architecture
> > In your fair proposal, MSA is related to network architecture as a way > to standardise pluggable (optics). But as always standards are > incomplete, ambiguous and do not guarantee interoperability, so it > will take some time for industry to decide what is 'correct' > interpretation of MSA. Implying when you buy early in life cycle new > optics, you may want to source more carefully and test, compared to > buying later in life cycle sourcing pluggables anywhere with 0 testing > is relatively low risk. > Amen to that. Cheers, Etienne On Wed, May 18, 2022 at 8:39 AM Saku Ytti wrote: > We could also add an explanation to our proposals for the acronym. :) > > In your fair proposal, MSA is related to network architecture as a way > to standardise pluggable (optics). But as always standards are > incomplete, ambiguous and do not guarantee interoperability, so it > will take some time for industry to decide what is 'correct' > interpretation of MSA. Implying when you buy early in life cycle new > optics, you may want to source more carefully and test, compared to > buying later in life cycle sourcing pluggables anywhere with 0 testing > is relatively low risk. > > > On Wed, 18 May 2022 at 09:32, Etienne-Victor Depasquale via NANOG > wrote: > > > > Just to add a bit of fun to the mix - perhaps multi-source agreement was > intended :) > > > > Cheers, > > > > Etienne > > > > On Wed, May 18, 2022 at 3:59 AM Martin Hannigan > wrote: > >> > >> > >> > >> All, > >> > >> Why do MSA’s matter as related to network architecture? > >> > >> Thanks all — > >> > >> -M< > >> > >> > >> > > > > > > -- > > Ing. Etienne-Victor Depasquale > > Assistant Lecturer > > Department of Communications & Computer Engineering > > Faculty of Information & Communication Technology > > University of Malta > > Web. https://www.um.edu.mt/profile/etiennedepasquale > > > > -- > ++ytti > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: MSA’s and network architecture
We could also add an explanation to our proposals for the acronym. :) In your fair proposal, MSA is related to network architecture as a way to standardise pluggable (optics). But as always standards are incomplete, ambiguous and do not guarantee interoperability, so it will take some time for industry to decide what is 'correct' interpretation of MSA. Implying when you buy early in life cycle new optics, you may want to source more carefully and test, compared to buying later in life cycle sourcing pluggables anywhere with 0 testing is relatively low risk. On Wed, 18 May 2022 at 09:32, Etienne-Victor Depasquale via NANOG wrote: > > Just to add a bit of fun to the mix - perhaps multi-source agreement was > intended :) > > Cheers, > > Etienne > > On Wed, May 18, 2022 at 3:59 AM Martin Hannigan wrote: >> >> >> >> All, >> >> Why do MSA’s matter as related to network architecture? >> >> Thanks all — >> >> -M< >> >> >> > > > -- > Ing. Etienne-Victor Depasquale > Assistant Lecturer > Department of Communications & Computer Engineering > Faculty of Information & Communication Technology > University of Malta > Web. https://www.um.edu.mt/profile/etiennedepasquale -- ++ytti
Re: MSA’s and network architecture
Just to add a bit of fun to the mix - perhaps multi-source agreement was intended :) Cheers, Etienne On Wed, May 18, 2022 at 3:59 AM Martin Hannigan wrote: > > > All, > > Why do MSA’s matter as related to network architecture? > > Thanks all — > > -M< > > > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: MSA’s and network architecture
Asking good questions is much harder than answering good questions. You could have improved the quality of question here by staging what MSA is and in what context you've run into this. I am assuming MSA here is a metro statistical area, and if so, I can answer for the context of my employer, where MSA has similar functions as your region (roughly continent), country and pop. MSA is a way to discuss and name areas, between pop and country for us, not much different to city in our use. On Wed, 18 May 2022 at 04:59, Martin Hannigan wrote: > > > > All, > > Why do MSA’s matter as related to network architecture? > > Thanks all — > > -M< > > > -- ++ytti
