Re: db9f to usb-c serial
> https://www.amazon.com/Console-Compatible-Windows-Switch-Router/dp/B08BCQ8LLR/ have that. and the one that goes from rj45m to db9f. it was the usb to db9f for which i hungered. ordered the pink one from china; how could i resist? :) randy
Re: db9f to usb-c serial
> https://www.metabee.com/usb-type-c-to-rs-232-serial-db09-female-adapter-cable-with-100cm-round-black-cable.html !
Re: db9f to usb-c serial
> Try B0CL4T6NN9 at Amazon looks as closeas i'm gonna get. a bit clunky and thick wires. but i guess i am not in japan where smaller is more appreciated. thanks. randy
Re: db9f to usb-c serial
Probably not much bulkier to just add a DB9-RJ45 adapter shell like this: https://www.monoprice.com/product?p_id=1153 Then, you can just use your existing USB-C to RJ45 cable and have both options. thanks, -Randy - On Sep 23, 2024, at 9:41 PM, Randy Bush ra...@psg.com wrote: > i know this is geeky, and not telling anyone else how thry should run > their network. but i gotta try. :) > > so i have this nice (i.e. small and simple) ftdi usb-c to rj45m blue > router craft/console cable. i also have a db9f to rj45m cable, also > robin's egg blue. i i also have an old and clunky keyspan to usb-a; > old, clunky, usb-a. > > i want the equivalent usb-c ftdi (mac compat) to db9f *server* serial > console cable. 1-2m. integrated, slick, and sexy. magenta preferred, > of course :) > > know any nice ones? > > randy
db9f to usb-c serial
i know this is geeky, and not telling anyone else how thry should run their network. but i gotta try. :) so i have this nice (i.e. small and simple) ftdi usb-c to rj45m blue router craft/console cable. i also have a db9f to rj45m cable, also robin's egg blue. i i also have an old and clunky keyspan to usb-a; old, clunky, usb-a. i want the equivalent usb-c ftdi (mac compat) to db9f *server* serial console cable. 1-2m. integrated, slick, and sexy. magenta preferred, of course :) know any nice ones? randy
Re: pgp keyservers
>> very intentionally wearing my end luser hat, i did not find a simple >> hkps://entry to put in my `~/.gnupg/gpg.conf`. probably my fault. > > That’s a fair point and we’d be open to ideas on how to improve that > aspect to make it more accessible to end users, especially the less > technically savvy ones. Please feel free to reach out directly either > on or off list to discuss further. Currently there is no single > hostname like the old SKS network to direct the client towards one of > the currently operating peer nodes listed @ > https://spider.pgpkeys.eu/sks-peers yay! i chose randomly, and hkps://pgp.cyberbits.eu worked. thank you! we have been very good at making pgp hard to use. we probably want to not do that so much. randy
Re: pgp keyservers
> While the sks-keyservers.net domain and many of the old hostnames that > powered it are dead & gone, the actual SKS keyserver network does in > fact live on, complete with new & improved DOS mitigations and active > development of the underlying server software powering it, Hockeypuck. > More information can be found @ https://spider.pgpkeys.eu/ & > https://github.com/hockeypuck/hockeypuck respectively. i did a mild descent through the links on that web page. very intentionally wearing my end luser hat, i did not find a simple hkps://entry to put in my `~/.gnupg/gpg.conf`. probably my fault. randy
Re: pgp keyservers
> I think the hipster thing to do now, though, is --auto-locate-key with > the Web Key Distribution or the DNSSEC Key Distribution mechanism. i have done wkd for a fair while. but some folk like to pull keyrings, so i try to keep them updated. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
pgp keyservers
are there any old keyservers still working? or only the new hipster ones? i tried three and no love hkps://pgp.mit.edu hkps://pgp.uni-mainz.de hkps://hkps.pool.sks-keyservers randy
Re: HE.net problem
>> what foss dns monitoring tools do folk use to alert of >> - iminent delegation expiry >> - inconsistent service (lame, soa mismatches, ...) >> - dnssec signing and timer issues >> - etc. > https://github.com/berthubert/simplomon thanks. may play hak whacked me to add http://dns.measurement-factory.com/tools/nagios-plugins/check_zone_rrsig_expiration.html to my nagios deployment. anyone have some known sick in various ways dns zones against which to test? randy
Re: HE.net problem
not to distract from everyone diagnosing someone else's problem, but ... what foss dns monitoring tools do folk use to alert of - iminent delegation expiry - inconsistent service (lame, soa mismatches, ...) - dnssec signing and timer issues - etc. randy
Re: Geolocation IP - www.firstinterstatebank.com
> https://datatracker.ietf.org/doc/html/rfc8805 https://datatracker.ietf.org/doc/html/rfc9092 will show you how to use 8805 randy
charging for config changess
has charging for config changes a la https://www.arelion.com/customer-excellence/customer-support/online-technical-change-pricing become common while i was not looking? admittedly, i have not looked for a long time. randy
Re: comcast v4 in pnw
kinda summary: comcast and cogent/sprint very helpful. likely cause a misconfig in cogent norcal when trying to route around a power outage in seattle. fwiw, HE and IIJ IPv6 transit (tyvm) in seattle allowed us to keep working through the outage. randy
comcast v4 in pnw
a bunch of us comcast soho folk, and monitoring gear, are seeing v4 breakage in orygon and maybe washington but only for seattle destinations. v6 works. johnb, is comcast going v6-only? :) ryuu.rg.net:/Users/randy> ping r0.iad PING r0.iad.rg.net (198.180.150.120): 56 data bytes 64 bytes from 198.180.150.120: icmp_seq=0 ttl=54 time=83.186 ms 64 bytes from 198.180.150.120: icmp_seq=1 ttl=54 time=81.450 ms ^C --- r0.iad.rg.net ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 81.450/82.318/83.186/0.868 ms ryuu.rg.net:/Users/randy> ping r0.sea PING r0.sea.rg.net (147.28.0.4): 56 data bytes Request timeout for icmp_seq 0 ^C --- r0.sea.rg.net ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss ryuu.rg.net:/Users/randy> ping6 r0.sea PING6(56=40+8+8 bytes) 2601:1c0:5600:9f4d:b500:3942:c8bd:ff16 --> 2001:418:1::4 16 bytes from 2001:418:1::4, icmp_seq=0 hlim=55 time=21.339 ms 16 bytes from 2001:418:1::4, icmp_seq=1 hlim=55 time=17.544 ms ^C --- r0.sea.rg.net ping6 statistics --- my guess is that it is up in seattle. but portland folk always blame seattle :) ryuu.rg.net:/Users/randy> traceroute r1.sea traceroute to r1.sea.rg.net (147.28.0.5), 64 hops max, 40 byte packets 1 192.168.0.1 (192.168.0.1) 5.382 ms 2.555 ms 1.978 ms 2 100.93.174.2 (100.93.174.2) 14.301 ms 100.93.174.3 (100.93.174.3) 16.307 ms 100.93.174.2 (100.93.174.2) 15.785 ms 3 po-332-364-rur202.beaverton.or.bverton.comcast.net (96.108.64.189) 19.839 ms po-332-363-rur201.beaverton.or.bverton.comcast.net (96.108.64.181) 11.312 ms po-332-364-rur202.beaverton.or.bverton.comcast.net (96.108.64.189) 17.453 ms 4 po-2-rur202.beaverton.or.bverton.comcast.net (24.124.129.106) 14.082 ms po-200-xar02.beaverton.or.bverton.comcast.net (96.216.60.165) 13.606 ms po-2-rur202.beaverton.or.bverton.comcast.net (24.124.129.106) 17.979 ms 5 ae-69-ar01.troutdale.or.bverton.comcast.net (68.85.243.197) 20.961 ms po-200-xar02.beaverton.or.bverton.comcast.net (96.216.60.165) 15.522 ms * 6 ae-69-ar01.troutdale.or.bverton.comcast.net (68.85.243.197) 12.324 ms * * 7 be-2312-pe12.seattle.wa.ibone.comcast.net (96.110.34.138) 20.785 ms be-36211-cs01.seattle.wa.ibone.comcast.net (68.86.93.49) 18.071 ms be-2212-pe12.seattle.wa.ibone.comcast.net (96.110.34.134) 15.331 ms 8 be-2212-pe12.seattle.wa.ibone.comcast.net (96.110.34.134) 26.953 ms * be-2412-pe12.seattle.wa.ibone.comcast.net (96.110.34.142) 19.355 ms 9 * * * 10 * * * ^C randy
Re: Geolocation IP help
> There is always talk to the local politician route so it gets raised > in the state legislature. this is illinois/chicago. you slip them a $100 bill under youe drivers' license
Re: Geolocation IP help
> You could try publishing Geo loc data per RFC8805 > https://datatracker.ietf.org/doc/html/rfc8805 or, more specifically, 9092 randy
Re: Announcing N91 Monday Keynote + New on NANOG TV: "Community Deep Dive"
> *Abstract: *Once upon a time it was unthinkable to have a company > meaningfully more complicated than a local florist that didn't have a > network engineer on staff, or at least retainer. Today the world is > vastly different... folk interested in this might find https://berthub.eu/articles/posts/cyber-security-pre-war-reality-check/ interesting randy
Re: Q: is RFC3531 still applicable?
> The minimum addressable on a LAN is a /64. not really randy
Re: NOAA Space Weather Prediction Center issued a Severe (G4) Geomagnetic Storm Watch
> (Low but distinct possibility of effects to radio and transmission > systems) no one will notice as we will all be outside looking at the aurora! randy
Re: 2600:: No longer pings
> Wonderful news, this has now been fixed :) > Thank you to Cogent for fixing this indee. otoh, i still can not resist https://www.kame.net/ randy
Re: Anyone got a contact at OpenAI. They have a spider problem.
> Amazon's spider got stuck there a month or two ago but fortunately I was > able to find someone to pass the word and it stopped. Got any contacts > at OpenAI? why? you are doing a societal good by ensnaring them. dig a deeper hole. randy
Re: N91 Women mixer on Sunday?
> I'm sure that your time was better spent gathering the "credentials" > in your signature, but I checked the last 20 or so NANOG meetings and > didn't see a single registration from you, so perhaps stay out of > things you know literally nothing about. https://en.wikipedia.org/wiki/Ad_hominem anne has been a constructive list participant for years randy
Re: N91 Women mixer on Sunday?
we definitely need more men's opinions on what women should want and do randy
Re: NANOG 90 Attendance?
> We actually had an IETF "Help Desk" at NANOG 63 (San Antonio, 2015) and > NANOG 64 or 65 ― > https://www.internetsociety.org/blog/2015/01/chris-grundemann-nanog-63-talking-bcop-ietf-and-more/ > and > https://www.internetsociety.org/blog/2014/11/operators-and-the-ietf-update-from-ietf-91/ > > We hoped to answer questions such as: > “Why should I participate in the IETF?” > “How do I get involved in the IETF?” > “What is the difference between an Internet-Draft and an RFC?” > “How do I submit an idea to the IETF?” > “What is the IETF working on in space?” > “How do I comment on an existing IETF document?” > perhaps the internet would benefit more from the inverse, a help desk at the ietf for "what is internet operation and how does it actually work?" randy
Re: Ongoing ARIN consultation on Resource Public Key Infrastructure/BGP intelligence
john: > I’d tend to agree with you, but ARIN already once attempted to rollout > such functionality – alas, with overly ambitious scope that not only > provided increased visibility after potentially affected routes but > functionality that also created default linkage to matching IRR > objects whoops! i still code around another RIR doing that. vendors have a long history of thinking they know best what operators should do. some RIRs seem to have such hubris. ok, i can see opening up discussion to reduce foot shooting risks. sorry for skepticism. randy
Re: Ongoing ARIN consultation on Resource Public Key Infrastructure/BGP intelligence
john, > Read the full text of the consultation at: > https://www.arin.net/participate/community/acsp/consultations/2024/2024-1/ please explain the need for bureaucrazy to do what RPKI CAs have been doing since dirt was invented. randy
Re: ru tld down?
> For taking care of referrals and delegations, ietf has started > preliminary work. More info here - > > https://mailarchive.ietf.org/arch/msg/dd/srNtevzS-jrPzMxYv1nATCY5JkM/ dns is not complex enough that folk have assured careers. need to make it more complex. randy
Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block
> My apologies! For an uninitiated, I misread your message as if > IPv6 was originally designed with a plan to assure smooth transition > from IPv4. i'll try again there was a transition plan; it was dual stack. i did not say it was a *good* transition plan. the plan's fatal flaw was that it assumed there was sufficient ipv4 to be congruent until ipv6 was widely enough deplayed that the ipv4 could be turned off. this was in the face of very real data (props to frank kastenholz) projecting the ipv4 run out rate. the v6 fantasy was that ipv6 would be quickly deployed. i guess it has been from the perspective of geologic time. randy
Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block
> Some of us still use pine… i thought most pine users had moved to mutt randy, who uses wanderlust under emacs :)
Re: IPv4 address block
>> If you limit each requesting organization to a /22 per year, we can >> keep the internet mostly functional for decades to come, > > at least in the ripe ncc service region, all this proved was that if > the cost of registering a company (or LIR) and applying for an > allocation was lower than the market rate of ipv4 addresses, then > people would do that. > > The root problem is unavoidable: ipv4 is a scarce resource with an > inherent demand. Every policy designed to mitigate against this will > create workarounds, and the more valuable the resource, the more > inventive the workaround. and complex policies lead to more complex workarounds which make the internet crappier > In terms of hard landings vs soft landings, what will make ipv6 > succeed is how compelling ipv6 is, rather than whether someone created > a policy to make ipv4 less palatable. In particular, any effect from a > hard landing compared would have been ephemeral. amen randy
Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block
interesting side note: when iij was deploying the v6 backbone in '97, commercial routers did not support dual stack. so it was a parallel backbone built on netbsd with the kame stack, which was developed in iij lab. we remember itojun. randy
okta probing
can someone explain what some child out there hopes to gain by repeatedly failing to authenticate to okta in my accound name? a couple of times a day, i have to take 40 seconds to unlock the account the kiddie has triggered. seems silly as they do not have the 2fa. it's -3c here, so i guess the clue level is going down as well as the temp. randy
Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block
> I go into my cave to finish the todo list for the week, and I come out > to see Mr. Chen : > - Telling Randy Bush he should "read some history" on IPv6 > - Implying that Vint Cerf ever said anything about EzIP > > Fairly impressive sequence of self ownage. but it sure is a change to have a n00b troll. i was really looking forward to it making me young. sigh. randy
Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block
> Perhaps you are too young to realize that the original IPv6 plan was > not designed to be backward compatible to IPv4, and Dual-Stack was > developed (through some iterations) to bridge the transition between > IPv4 and IPv6? You may want to spend a few moments to read some > history on this. ROFL!!! if there is anything you can do to make me that young, you could have a very lucrative career outside of the internet. hint: unfortunately i already had grey hair in the '90s and was in the room for all this, and spent a few decades managing to get some of the worst stupidities (TLA, NLA, ...) pulled out of the spec. at iij, we rolled ipv6 on the backbone in 1997. randy
Re: 202401100645.AYC Re: IPv4 address block
>>> We don't need to extend IPv4, we need to figure out why we are in this >>> dual-stack mess, which was never intended, and how to get out of it. >> >> it was intended. it was the original transition plan. like many things >> about ipv6, it could have been a bit better thought out. > > What was not intended though was the transition period to last for 30 > years and counting… If things go reasonably well we’re gonna be dual > stack for another 20, at least. like many things about ipv6, it could have been a bit better thought out. randy
Re: 202401100645.AYC Re: IPv4 address block
> We don't need to extend IPv4, we need to figure out why we are in this > dual-stack mess, which was never intended, and how to get out of it. it was intended. it was the original transition plan. like many things about ipv6, it could have been a bit better thought out. randy
Re: swedish dns zone enumerator
> I might be reading this wrong, but I don't think the point Randy was > trying to make was 'NS queries are an attack', 'UDP packets are an > attack' or 'IP packets are an attack' . I base this on the list of > queries Randy decided to include as relevant to the thesis Randy was > trying to make, instead of wholesale warning of IP, UDP or NS queries. i was warning of an ndrek3 enumeration attack from the source netblock's ip space i am far from an expert in ndrek3 enumeration. but i naïvely assume that most tld rrs are ns so that is what they're after. but, as you say, that is beside the point. randy
Re: swedish dns zone enumerator
ya, right, and at a whole bunch of other cctld servers from a network called domaincrawler-hosting shall we smoke another? /home/randy> sudo tcpdump -pni vtnet0 -c 500 port 53 and net 193.235.141 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes 05:12:30.563268 IP 193.235.141.169.32768 > 666.42.7.11.53: 14 NS? cgatcity.com.cu. (33) 05:12:30.565017 IP 193.235.141.215.32768 > 666.42.7.11.53: 14 NS? christ-jockel.jo. (34) 05:12:30.565660 IP 193.235.141.209.32768 > 666.42.7.11.53: 14 NS? cgatcity.al. (29) 05:12:30.566490 IP 193.235.141.209.32768 > 666.42.7.11.53: 14 NS? cgatcity.org.al. (33) 05:12:30.566694 IP 193.235.141.3.32768 > 666.42.7.11.53: 14 NS? christian-luber-jr.net.al. (43) 05:12:30.569474 IP 193.235.141.239.32768 > 666.42.7.11.53: 14 NS? clearing-muenchen.eg. (38) 05:12:30.571870 IP 193.235.141.160.32768 > 666.42.7.11.53: 14 NS? clearing-muenchen.com.ps. (42) 05:12:30.573436 IP 193.235.141.23.32768 > 666.42.7.11.53: 14 NS? cofls-welt.xn--pgbs0dh. (40) 05:12:30.573914 IP 193.235.141.173.32768 > 666.42.7.11.53: 14 NS? club-lederwerk-neustadt.net.al. (48) 05:12:30.574608 IP 193.235.141.60.32768 > 666.42.7.11.53: 14 NS? cofls-welt.az. (31) 05:12:30.575203 IP 193.235.141.183.32768 > 666.42.7.11.53: 14 NS? cofls-welt.lb. (31) 05:12:30.575356 IP 193.235.141.215.32768 > 666.42.7.11.53: 14 NS? conomix.eg. (28) 05:12:30.575950 IP 193.235.141.171.32768 > 666.42.7.11.53: 14 NS? conomix.net.ps. (32) 05:12:30.577242 IP 193.235.141.90.32768 > 666.42.7.11.53: 14 NS? computercheck-online.tn. (41) 05:12:30.577800 IP 193.235.141.134.32768 > 666.42.7.11.53: 14 NS? conomix.cu. (28) 05:12:30.578272 IP 193.235.141.177.32768 > 666.42.7.11.53: 14 NS? conomix.net.lb. (32) 05:12:30.578480 IP 193.235.141.114.32768 > 666.42.7.11.53: 14 NS? cstreibel.lr. (30) 05:12:30.578896 IP 193.235.141.114.32768 > 666.42.7.11.53: 14 NS? cstreibel.org.lb. (34) 05:12:30.579060 IP 193.235.141.244.32768 > 666.42.7.11.53: 14 NS? cristallcard.az. (33) 05:12:30.580681 IP 193.235.141.11.32768 > 666.42.7.11.53: 14 NS? d-cypher.tn. (29) 05:12:30.581812 IP 193.235.141.160.32768 > 666.42.7.11.53: 14 NS? d-cypher.al. (29) 05:12:30.582157 IP 193.235.141.162.32768 > 666.42.7.11.53: 14 NS? dailycatesse.sz. (33) 05:12:30.582381 IP 193.235.141.142.32768 > 666.42.7.11.53: 14 NS? d-cypher.eg. (29) 05:12:30.583340 IP 193.235.141.125.32768 > 666.42.7.11.53: 14 NS? damensattel-duesseldorf.net.ps. (48) 05:12:30.583439 IP 193.235.141.181.32768 > 666.42.7.11.53: 14 NS? dailycatesse.az. (33) 05:12:30.584078 IP 193.235.141.160.32768 > 666.42.7.11.53: 14 NS? dailycatesse.mw. (33) 05:12:30.584330 IP 193.235.141.160.32768 > 666.42.7.11.53: 14 NS? dailycatesse.org.al. (37) 05:12:30.584730 IP 193.235.141.3.32768 > 666.42.7.11.53: 14 NS? darkroom24.net.al. (35) 05:12:30.585506 IP 193.235.141.7.32768 > 666.42.7.11.53: 14 NS? damensattel-duesseldorf.jo. (44) 05:12:30.585995 IP 193.235.141.127.32768 > 666.42.7.11.53: 14 NS? dassehen.lr. (29) 05:12:30.587759 IP 193.235.141.173.32768 > 666.42.7.11.53: 14 NS? darkroom24.tn. (31) 05:12:30.588076 IP 193.235.141.162.32768 > 666.42.7.11.53: 14 NS? dgurock.org.al. (32) 05:12:30.589055 IP 193.235.141.212.32768 > 666.42.7.11.53: 14 NS? dictys.jo. (27) 05:12:30.589640 IP 193.235.141.240.32768 > 666.42.7.11.53: 14 NS? dgurock.az. (28) 05:12:30.591432 IP 193.235.141.172.32768 > 666.42.7.11.53: 14 NS? dictys.com.ps. (31) 05:12:30.592608 IP 193.235.141.213.32768 > 666.42.7.11.53: 14 NS? disko-thema.org.al. (36) 05:12:30.593365 IP 193.235.141.247.32768 > 666.42.7.11.53: 14 NS? diesling-1.net.al. (35) 05:12:30.593814 IP 193.235.141.147.32768 > 666.42.7.11.53: 14 NS? diesling-1.ps. (31) 05:12:30.595057 IP 193.235.141.240.32768 > 666.42.7.11.53: 14 NS? disko-thema.net.al. (36) 05:12:30.595722 IP 193.235.141.157.32768 > 666.42.7.11.53: 14 NS? disko-thema.xn--mgbayh7gpa. (44) 05:12:30.596496 IP 193.235.141.135.32768 > 666.42.7.11.53: 14 NS? downbeat-band.com.lb. (38) 05:12:30.596898 IP 193.235.141.185.32768 > 666.42.7.11.53: 14 NS? dj-hc-team.sz. (31) 05:12:30.598077 IP 193.235.141.177.32768 > 666.42.7.11.53: 14 NS? dnd-testdomain.net.al. (39) 05:12:30.598203 IP 193.235.141.146.32768 > 666.42.7.11.53: 14 NS? dnd-testdomain.net.ps. (39) 05:12:30.598338 IP 193.235.141.215.32768 > 666.42.7.11.53: 14 NS? druck-hamster.lr. (34) 05:12:30.599224 IP 193.235.141.168.32768 > 666.42.7.11.53: 14 NS? druckerei-hilden.az. (37) 05:12:30.602031 IP 193.235.141.45.32768 > 666.42.7.11.53: 14 NS? druckerei-hilden.com.lb. (41) 05:12:30.604763 IP 193.235.141.210.32768 > 666.42.7.11.53: 14 NS? drumandy.xn--pgbs0dh. (38) 05:12:30.605420 IP 193.235.141.212.32768 > 666.42.7.11.53: 14 NS? dugehoerstmir.tz. (34) 05:12:30.607074 IP 193.235.141.142.32768 > 666.42
swedish dns zone enumerator
i have blocked a zone enumerator, though i guess they will be a whack-a-mole others have reported them as well /home/randy> sudo tcpdump -pni vtnet0 -c 10 port 53 and net 193.235.141 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes 22:42:39.516849 IP 193.235.141.90.32768 > 666.42.7.11.53: 14 NS? 33j4h.org.al. (30) 22:42:39.517640 IP 193.235.141.17.32768 > 666.42.7.11.53: 14 NS? 33m6d.xn--mgbayh7gpa. (38) 22:42:39.519169 IP 193.235.141.17.32768 > 666.42.7.11.53: 14 NS? 33lxd.tn. (26) 22:42:39.520064 IP 193.235.141.171.32768 > 666.42.7.11.53: 14 NS? 33md6.jo. (26) 22:42:39.521081 IP 193.235.141.247.32768 > 666.42.7.11.53: 14 NS? 33lxd.lb. (26) 22:42:39.523981 IP 193.235.141.162.32768 > 666.42.7.11.53: 14 NS? 33pd2.az. (26) 22:42:39.525043 IP 193.235.141.60.32768 > 666.42.7.11.53: 14 NS? 33nc5.com.al. (30) 22:42:39.526185 IP 193.235.141.209.32768 > 666.42.7.11.53: 14 NS? 33nc5.sz. (26) 22:42:39.527931 IP 193.235.141.150.32768 > 666.42.7.11.53: 14 NS? 33q5p.com.al. (30) 22:42:39.529516 IP 193.235.141.210.32768 > 666.42.7.11.53: 14 NS? 33qbq.com.al. (30) 10 packets captured 124 packets received by filter 0 packets dropped by kernel inetnum:193.235.141.0 - 193.235.141.255 netname:domaincrawler-hosting descr: domaincrawler hosting org:ORG-ABUS1196-RIPE country:SE admin-c:VIJE1-RIPE tech-c: VIJE1-RIPE status: ASSIGNED PA notify: c+1...@resilans.se mnt-by: RESILANS-MNT mnt-routes: ETTNET-LIR created:2008-04-03T11:21:00Z last-modified: 2017-04-10T12:47:06Z source: RIPE randy
itojun
this day in 2007 dr jun-ichiro (itojun) hagino died. a gentle soul, an engineer's engineer, the ipv6 samurai, iab member, and fiat 500 lover. the v6 stack you're running could have descended from his netbsd one. http://www.itojun.org/ randy
Re: emily postnews
> wish this was included with every subscription to internet services > you did not get it with your AOL CD? ask for a refund. as a bonus, https://neal.fun/internet-artifacts/ randy
emily postnews
another old dog doing a search wrote to tell me they really appreciated that i still had some antique advice up. i had long forgotten this one. but found it amusing and still more relevant than i might wish. https://psg.com/emily.html randy
Re: RPKI unknown for superprefixes of existing ROA ?
> Believe it or not, Job, there are parts of the internet that exchange > traffic and move packets that are not IXPs. in fact, measurements had shown that the majority of inter-domain traffic is over pnis randy
remembering abha
another tragic october death was that of abha ahuja, researcher, operator, and amazing person, this day in 2001. worth a search. jake's http://www.neebu.net/~khuon/abha/ is a start. randy
Re: Acceptance of RPKI unknown in ROV
>> has arin not made it easier, lowering the legal insanity, for legacy >> holders to obtain services? > Yes but they need to jump now if they want to take advantage of it, as > I understand it. arin has deep expertise in hurdles randy
Re: Acceptance of RPKI unknown in ROV
> For legacy resource holders it is a problem but then it’s a > bureaucratic issue rather technical and technology has a solution > called SLURM. has arin not made it easier, lowering the legal insanity, for legacy holders to obtain services? randy
Re: jon postel
> I wonder if he knew it would have become what it is today. one of my favorite postel quotes It's perfectly appropriate to be upset. I thought of it in a slightly different way--like a space that we were exploring and, in the early days, we figured out this consistent path through the space: IP, TCP, and so on. What's been happening over the last few years is that the IETF is filling the rest of the space with every alternative approach, not necessarily any better. Every possible alternative is now being written down. And it's not useful. think of the folk making careers complicating dns, rpki, bgp, ... randy
jon postel
25 years ago, jon postel died. we stand on the shoulders of jon and others, a number of whom died in october. not a cheering month for old timers. randy
Re: ARIN whois contact abuse from ipv4depot aka Silicon Desert International Inc
i received an arin board electioneering "vote for me" today. i guess now i have to go vote against then. randy
Re: constraining RPKI Trust Anchors
> So while each RP should be able to make policy decisions based on its > own local criteria, managing a default set of constraints is something > that is best done centralized. Who do you envision should manage these > lists? RP software maintainers? RIRs? Others? and how will this pain-to-maintain list be distributed? how do i know a copy is authentic not an attack? i am all for a single root of trust. it's just that i thought it was the iana's job. but i am easily confused. randy
Re: Using RFC1918 on Global table as Loopbacks
> I have recently encountered some operational differences at my new > organization that are not what I have been exposed to before, where > the loopback of the core network devices is being set from RFC1918 > while on the global routing table. I'm sure this is not a major issue > but I have mostly seen that ISPs use global IPs for loopbacks on > devices that would and hold global routing. > > My question is, what is the most used or recommended way to do this, > if I continue to use RFC1918 I will save some very much desired public > address space, but would this come back to bite me in the future? loopback addressing does not have to be used for router ids. so decouple that consideraton. make up router ids; 1, 42, 3, 4, ... whatever. they just need to be unique within the AS. < corner case > you may want to have your loopbacks in real global space for routers which are on an IX. i have been having fun where an IX router is sourcing packets from the IX interface, and responses can not come back because the IX space is not announced globally. so one wants to tell the protocol originating those packets (ntp, dns, whatever) to source from the loopback. and, for replies to get back to that loopback, it needs to be in real global space. randy
Re: maximum ipv4 bgp prefix length of /24 ?
> About 60% of the table is /24 routes. > Just going to /25 will probably double the table size. or maybe just add 60%, not 100%. and it would take time. agree it would be quite painful. would rather not go there. sad to say, i suspect some degree of lengthening is inevitable. we have ourselves to blame; but blame does not move packets. randy, who was in the danvers cabal for the /19 agreement
Re: Zayo woes
The problem we have run into is that there does not appear to be a "Zayo." There are dozens of acquisitions of regional providers with completely different infrastructure and teams and they have done a very poor job at gluing it all together. I have seen service orders that have gone *years* without being complete. There are also currently some breaking-the-entire-regional-network sorts of outages going on currently. I am guessing what clued employees they still have are quite tied up. -Randy - On Sep 18, 2023, at 7:06 PM, JASON BOTHE via NANOG nanog@nanog.org wrote: > Does anyone know what’s happening at Zayo? Tickets are taking weeks and months > to get resolved, much less get a tech assigned to them. > > The folks answering the noc phone are mere order takers and are only reading > from a script, manager on duty/escalation lines go to voicemail. > > If anyone can help get to a human in the transport group, that would be great. > I’ve given up all hope at this point. > > Appreciated. > > Jason
Re: So what do you think about the scuttlebutt of Musk interfering in Ukraine?
perhaps this is not a nanog operational topic
Re: Lossy cogent p2p experiences?
i am going to be foolish and comment, as i have not seen this raised if i am running a lag, i can not resist adding a bit of resilience by having it spread across line cards. surprise! line cards from vendor do not have uniform hashing or rotating algorithms. randy
Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More
> It is totally possible to turn off the spyware in MailChimp. You just > need to buy an actual commercial account rather than using their > "free" service. To save $13 or $20 per month, you are instead selling > the privacy of every recipient of your emails. See: > > https://mailchimp.com/help/enable-and-view-click-tracking/ > > "Check the Track clicks box to enable click tracking, or uncheck the > box to disable click tracking. ... Mailchimp will continue to > redirect URLs for users with free account plans to protect against > malicious links. ... When a paid user turns off click tracking, > Mailchimp will continue to redirect their URLs until certain account > activity thresholds are met." > > Don't forget to turn off the spyware 1x1 pixel "web bugs" that > MailChimp inserts by default, too: > > https://mailchimp.com/help/about-open-tracking/ as usual, the problem is not technical. there is no need for mailchump at all. nanog management has made a very intentional decision to sell my privacy. nanog has come a long way, not all of it good. randy
Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More
> *READ MORE > <https://www.google.com/url?q=https://nanog.us20.list-manage.com/track/click?u%3D4d708401d0e69d9dc73d1c204%26id%3Dd77e95d2fb%26e%3De429f79d5a&source=gmail&ust=1694187666719000&usg=AOvVaw3Cfz_DNu6fUMvOglI_i3nd>Last can we please get URLs without all the invasive tracking? randy
Re: it's mailman time again
> Mail in transit is mostly TLS transport these days, yep. mostly. opsec folk are not fond of 'mostly.' > BUT mail in storage and idle state isn't always secured. I'm sure > that most any of us could find a public s3 bucket with an mbox file on > it if we cared to look. sigh randy
it's mailman time again
and i just have to wonder about sending passords over the net in cleartext in 2023. really? randy
Re: v6 route mess frm AS266970
> We saw no impact to v6 traffic during the leak (and we have quite a > lot of v6 traffic). I guess testament that RPKI works? the packetviz (props massimo) reports i received would seem to indicate that the blast radius was mostly contained to america latina collectors. yes, likely due to route origin validation. randy
v6 route mess frm AS266970
is a massive route leak not even menntioned when it is only ipv6? the guess i heard was it looked like a classic config reorigination disaster. randy
Re: Internet Exchange Visualization
> 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. randy
Re: Internet Exchange Visualization
> 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
Re: Dodgy AS327933 ...?
> We are seeing some weird routing from them, and the AS2 they are > attached to (University of Delaware) seems odd. classic microtik prepend syntax confusion? randy
Re: malware warning
i did not think i was special, and assumed everybody is getting them. but i figured that if i kept one or three people from falling for the trap it was worth the pollution. randy
Re: My first ARIN Experience but probably not the last, unfortunately..
> #define SOAPBOX > > Please remember ARIN covers more than just the relatively prosperous > United States. There are places like Jamaica, which are also in the > ARIN region, where the average annual income is $2,337. indeed i find this thread to be depressing. the economics you mention, of course. but also folk being rude, judgemental, and blaming the user for being confused by the complex and jargon-infested bureaucrazy we have created in the rirs. and yes, props to the rirs for trying to document rules and processes. but that often seems to create even more documents. and, of course, if you have to deal with multiple rirs, expect no parallelism, similar nomenclature, etc. it is very easy for a new rir user to get confused by corner cases, terminology, quirks of history, and the detritus of our amateur policy wonkage. give 'em a break. and see if we can round off the rough edges where they got caught. randy --- note that i use the first person plural
Re: whois server
> the memo: > https://web.archive.org/web/20230523204911/http://www.geektools.com/ 404
whois server
``` % host whois.geektools.com Host whois.geektools.com not found: 3(NXDOMAIN) ``` i guess i missed the memo :( randy
Re: [Attendee] Welcome to NANOG 88 - Sunday Edition
let's get to the protein. where is the most reasonable parking near the venue? randy, who will soon start driving up from portland
Re: BGP routing ARIN space in APNIC region
> Everyone should check out Massimo Candela's presentation "Geolocation > problems: Do we have a solution?" for how to provide your own > geolocation data... > > https://www.netnod.se/sites/default/files/2023-03/Massimo_Webpage.pdf > > I've seen it at recent RIPE and LACNIC conferences. Supposedly all of > the big geolocation providers support it or are planning on supporting > it. we're working on an small update. see https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/ randy
Re: 128/9 cite
thanks aftab i remember a bit more. the hidden command was there to help debug CEF, which was new at the time. the CEFlapods wanted a large blob of prefixes to push the FIB. it kinda pushed the operational FIBs a bit too far :) randy
128/9 cite
doug madory is asking me for a cite for the exciting 1997/8 128/9 bgp event. my memory as reported to doug is soon after the 7007 incident, an engineer in a UUNET lab, not realizing they were connected to the real internet, used the hidden bgp test command to generate 128/9 chopped into /24s. took uunet down, but not before it propagated. does anyone have a useful cite? randy
Re: Soliciting suggestions and experiences from the community for RPKI-invalid filtering deployment
> some ASes may perform RPKI-invalid filtering only at partial > interfaces (e.g., provider interfaces, customer interfaces, and peer > interfaces). i have heard it said that "my customer pays me to propagate their announcement, so i do not apply rov. let my peers filter it." randy
Re: Standard DC rack rail distance, front to back question
> It's super annoying, and somewhat terrifying to be banging on a rack > containing a bunch of spinning rust, but all too often it's necessary we just moved a rack's content from the westin to komo plaza [0] and only had one questionable drive. terrifying is the right word. randy [0] - we may be the first rat off the sad westin ship
Re: Standard DC rack rail distance, front to back question
> "small mounting shelf" we use mounting shelves for all sorts of recalcitrant devices randy
Re: Reverse DNS for eyeballs?
> I would say the absence of reverse DNS tells useful info to receiving > MTAs - to preferably not accept. yep
Re: Spamhaus flags any IP announced by our ASN as a criminal network
this company(s) is in the business of spam. they're just trying to game nanog. discussing further a waste of pixels. ranady
Re: Spamhaus flags any IP announced by our ASN as a criminal network
>> I don't think any ISP would reject an IP that is on the Spamhaus >> list. > you, clearly, have been living under several rocks for a very long > time. we reject automagically on spamhaus, mail-abuse.org, and sorbs. really appreciate their services. randy
Re: BGP Engines with support to "RTFilter address-family"
> RFC4364 ... I believe - Arccus has implemented it (Keyur to confirm) i am not keyur and do not play one on the net, but ...
Re: A straightforward transition plan (was: Re: V6 still not supported)
> It was assumed that IPng would include a standard straightforward > technological solution to support communication with IPv4 hosts – this > was a defined hard requirement. > > This transition mechanism wasn’t available at the time of the > selection of IPng, and instead was left as a future deliverable. three of the promises of ipng which ipv6 did not deliver o compatibility/transition, o security, and o routing & renumbering the real goal of those who made the ipv6 decision was to stop the press from screaming about the end of the internet. in this they succeeded. and the ops community has paid an insane penalty ere since. randy
Re: Geoip database update
> > darn shame there is no general automatable mechanism for this too many folk have written to ask. here is the clue by four https://www.rfc-archive.org/getrfc?rfc=9092 and note that massimo has a collio toolset https://github.com/massimocandela/geofeed-finder randy
Re: Geoip database update
darn shame there is no general automatable mechanism for this randy
Re: AS3356 Announcing 2000::/12
> I know of a few people in a Discord that filter out anything bigger > than /16 routes, would this be wise to implement as a best practice? once upon a time, a very large provider took two /8s and announced as a /7. a vendor who thought a /8 was as short as they would ever see had routers fall over in a receiving large provider. do not hard code social theories. remember 640k. randy
Re: AS3356 Announcing 2000::/12
while i think the announcement is, shall we say, embarrassing, i do not see how it would be damaging. real/correct announcements would be for longer prefixes, yes? randy
Re: Newbie Concern: (BGP) AS-Path Oscillation
[ i would have written privately except the damned dmark crap obscured your email address. gr. ] > On one of our prefixes, we are detecting continuous “BGP AS-Path > Changes” in the order of 1,000 announcements per hour---practically > one every 3-4 seconds. where is this being 'detected?' i.e. from what vantage point? is it safe to assume that your outbound announcements to your two upstreams are stable? of course, if you would care to divulge a prefix showing this symptom, folk might be able to find clues. randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery
afrinic rpki issue
From: PacketVis Date: Sun, 20 Nov 2022 04:30:44 + Possible TA malfunction or incomplete VRP file: 73.95% of the ROAs disappeared from afrinic See more details about the event: https://packetvis.com/#/bgp/event/905ec8b7d37e89a2d7b547bca99fd57e-372b0bf3-9056-407e-9e8d-e986567155fc/4f309cb51ba9314fafa64da53d007e342faca613
Re: Verizon Email to SMS gateway
That is the understanding I got when discussing the situation with our engineering contact there. thanks, -Randy - On Nov 17, 2022, at 12:12 PM, Eric Tykwinski eric-l...@truenet.com wrote: > As a side note, will the email to text gateways be subject to the FCC's A2P > 10DLC registration requirements? > I'm wondering if that's part of the reason for not officially supporting email > to text. > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > >> -Original Message- >> From: NANOG On Behalf Of >> Randy >> Carpenter >> Sent: Thursday, November 17, 2022 12:09 PM >> To: Justin H. >> Cc: NANOG >> Subject: Re: Verizon Email to SMS gateway >> >> >> We did a few months back and were told that they are no longer officially >> supporting it. It may have to do with the volume that is being sent, > >> particularly from a single IP address. >> >> We moved to using Twilio's API and it has been much more solid. >> >> >> thanks, >> -Randy >> >> >> - On Nov 17, 2022, at 11:56 AM, Justin H. justindh...@gmail.com wrote: >> >> > Anyone else seeing massive delays in Verizon's email to SMS gateway >> > lately? I'm seeing delays on emails to @vtext and @vzwpix addresses >> > at anywhere form 45 minutes to 12 hours. >> > > > > Justin H.
Re: Verizon Email to SMS gateway
We did a few months back and were told that they are no longer officially supporting it. It may have to do with the volume that is being sent, particularly from a single IP address. We moved to using Twilio's API and it has been much more solid. thanks, -Randy - On Nov 17, 2022, at 11:56 AM, Justin H. justindh...@gmail.com wrote: > Anyone else seeing massive delays in Verizon's email to SMS gateway > lately? I'm seeing delays on emails to @vtext and @vzwpix addresses at > anywhere form 45 minutes to 12 hours. > > Justin H.
Re: Why do ROV-ASes announce some invalid route?
> ROV belongs on the input path, let's not ROV on the output towards > customers / route collectors. 8893 randy
Re: Why do ROV-ASes announce some invalid route?
aside from technical reasons for an ROV-supporting AS (RAS) to announce an ROV invalid prefix, there is an administrative one. the RAS's customers *pay* RAS to announce the customers' prefixes. so RAS is configured to propagate their customers' announcements without dropping invalids. randy
Re: Understanding impact of RPKI and ROA on existing advertisements
for the 312th time. origin validation was never designed to stop attacks. it was designed to ameliorate mistakes. if you want to use the rpki to reduce attacks, use bgpsec. randy
Re: Understanding impact of RPKI and ROA on existing advertisements
> Thanks everyone for your inputs. So bottomline setup RPKI and setup ROA's > for all our subnets being advertised. if the BGP advertisements are correct, then mirror them in ROAs. most, if not all, CA UIs make that easy. randy
itojun
and the third giant to have died in october, itojun hagino died on this day in 2007. ipv6 owes a great debt to itojun; as do a bunch of other technoogies and many people. a wise and gentle soul. i dread october. randy http://www.itojun.org/itojun.html http://www.itojun.org/personal.html https://asiajin.com/blog/2007/10/jun-ichiro-itojun-hagino-dies-at-37-ipv6-developer-and-evangelist/
abha
abha ahuja died 21 years ago today; a force in routing, ops, and trying to liberate the culture. fort hose who want to pull threads, http://www.neebu.net/~khuon/abha/ https://archive.nanog.org/resources/scholarships/abha_ahuja there are others here who will have much better cites (hint hint). randy
Re: jon postel
> Does anyone have any stories about working with or near John they > would like to share with the list? It would definitely make my day > to hear more about the early internet somewhere around i have a protocol violation ticket he issued. --- Who says that routing unallocated address space is ungood? -- Randy Bush Routing unallocated address space is ungood! -- Jon Postel randy
Re: jon postel
my favorite is It's perfectly appropriate to be upset. I thought of it in a slightly different way--like a space that we were exploring and, in the early days, we figured out this consistent path through the space: IP, TCP, and so on. What's been happening over the last few years is that the IETF is filling the rest of the space with every alternative approach, not necessarily any better. Every possible alternative is now being written down. And it's not useful. -- Jon Postel
jon postel
it's been 24 years, and we still live in his shadow and stand on his shoulders. we try not to stand on his toes. randy
Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?
< rant > there once used to be 'swamp' space, down in the low 190s where /24s were expected. and folk/rirs tried to keep shorter aggregates, e.g. /19s, as the norm above swamp (negotiated at ietf/danvers). in those days, one could actually filter above swamp on /19. for a while, one could even have classful filters in A and B space. and a soda pop used to be a nickel or a dime. those days are long gone. i expect that we will accept prefixes longer than /24 as things get tighter. and i doubt we can socialize constraining that fragmentation to one section of the space. it is a tragedy that cidr and an open market has helped us more than ipv6 has. randy
Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?
> we're thinking to deny all /24s to save the memory i recommend this to all my competitors randy