October 2020 - Test - lists.nanog.org

plea for comcast/sprint handoff debug help
by Randy Bush 11 Nov '20

11 Nov '20

tl;dr: comcast: does your 50.242.151.5 westin router receive the announcement of 147.28.0.0/20 from sprint's westin router 144.232.9.61? details: 3130 in the westin announces 147.28.0.0/19 and 147.28.0.0/20 to sprint, ntt, and the six and we want to remove the /19 when we stop announcing the /19, a traceroute to comcast through sprint dies at the handoff from sprint to comcast. r0.sea#traceroute 73.47.196.134 source 147.28.7.1 Type escape sequence to abort. Tracing the route to c-73-47-196-134.hsd1.ma.comcast.net (73.47.196.134) VRF info: (vrf in name/id, vrf out name/id) 1 r1.sea.rg.net (147.28.0.5) 0 msec 1 msec 0 msec 2 sl-mpe50-sea-ge-0-0-3-0.sprintlink.net (144.232.9.61) [AS 1239] 1 msec 1 msec 0 msec 3 * * * 4 * * * 5 * * * 6 * * * this would 'normally' (i.e. when the /19 is announced) be r0.sea#traceroute 73.47.196.134 source 147.28.7.1 Type escape sequence to abort. Tracing the route to c-73-47-196-134.hsd1.ma.comcast.net (73.47.196.134) VRF info: (vrf in name/id, vrf out name/id) 1 r1.sea.rg.net (147.28.0.5) 0 msec 1 msec 0 msec 2 sl-mpe50-sea-ge-0-0-3-0.sprintlink.net (144.232.9.61) [AS 1239] 1 msec 0 msec 1 msec 3 be-207-pe02.seattle.wa.ibone.comcast.net (50.242.151.5) [AS 7922] 1 msec 0 msec 0 msec 4 be-10847-cr01.seattle.wa.ibone.comcast.net (68.86.86.225) [AS 7922] 1 msec 1 msec 2 msec etc specifically, when 147.28.0.0/19 is announced, traceroute from 147.28.7.2 through sprint works to comcast. withdraw 147.28.0.0/19, leaving only 147.28.0.0/20, and the traceroute enters sprint but fails at the handoff to comcast. Bad next-hop? not propagated? covid? magic? which is why we wonder what comcast (50.242.151.5) hears from sprint at that handoff note that, at the minute, both the /19 and the /20 are being announced, as we want things to work. so you will not be able to reproduce. so, comcast, are you receiving the announcement of the /20 from sprint? with a good next-hop? randy

8 28

Asus wifi AP re-writing DNS packets
by Anurag Bhatia 04 Nov '20

04 Nov '20

Hello, Wondering anyone from Asus here or anyone who could connect me to the developers there? Using Asus RT-AC58U in Access Point(AP) mode and expect it to simply bridge wired with wireless but seems like it's re-writing DNS packets source as well as the destination. 1. DNS port 53 traffic going out, the source is re-written with the management IP of the AP on the LAN. So virtually all DNS traffic hits the router from the (management) IP of the Asus AP instead of real clients. 2. If I define DNS as x.x.x.x on DHCP, the Asus AP picks that up and re-writes destination to x.x.x.x and hence even if any client uses y.y.y.y, the packets are simply re-written. I see the rule in iptables on Asus AP. All these issues give an idea that someone created AP mode (besides regular routing mode) and missed to disable the DNS related NATing features in the AP mode. So far my discussions with their support have been going quite slow and would greatly appreciate if someone could connect me to right folks in there so they can release a firmware fix for it. Thanks. -- Anurag Bhatia anuragbhatia.com

9 13

Newbie Questions: How-to remove spurious IRR records (and keep them out for good)?
by Pirawat WATANAPONGSE 02 Nov '20

02 Nov '20

Dear Guru(s), I am seeking advice concerning someone else announcing IRR records on resources belonging to me. [I was referred to this mailing list from the DNS-OARC community.] Context: I have already registered all my IP address blocks with ROA/RPKI [evidence: https://stat.ripe.net/widget/as-routing-consistency#w.resource=AS9411] However, HE reports a lot of spurious IRR records on my resources [example: https://bgp.he.net/net/158.108.0.0/16#_irr] Question #1: Should I worry about those spurious records [Yes | No | Depends]? My fear is that other sites might accept those records without checking and thus be misled somewhere else, since ROV is not yet the behavior-in-majority. My other reasoning is that, if we are not going to keep accurate records, why bother keeping them at all anyway. Question #2: What can I do about it [in case the answer to Question #1 is Yes]? Should I notify those Database Admins? Will they consider me a nuisance? And most importantly: Will they erase those records for me, or will they just ignore me? Question #3: Did I not do something that can prevent those spurious records from happening in the first place? And, anything I can do now to prevent it from ever happening again? Thanks in advance for your advice(s), Pirawat.

4 3

100G over 100 km of dark fiber
by Jared Brown 31 Oct '20

31 Oct '20

Hello NANOG! I need to push 100G over 100 km of dark fiber. Since there are no 100G pluggable optics with this reach (~25 dB), I have been offered coherent transport systems to solve my problem. This is all good and well, except total system costs start from high five figures. So, my question is, do I have any other options? I can't help noticing that you can break out a 100G QSFP into four 25G QSFPs. 25G DWDM systems are relatively inexpensive (low five figures), but can you make 25G DWDM go 100 km? I only need the one 100G, so I don't really need a highly scalable DWDM system. I can't put anything midspan, or if I could it would cost more than just going with a coherent system. Jared

11 12

Re: 100G over 100 km of dark fiber
by Jürgen Jaritsch 31 Oct '20

31 Oct '20

Hi Jared, Easiest thing would be breaking into sub-100G channels (e.g. 4x 25G) and using DWDM optics + Amp + Compensation + Pre-Amp to transport it across the 100km. Same parts for all configs: *) 1x Amplifier => 1 slot *) 1x 100km dispersion compensation => separate 1U *) 1x Pre-Amplifier => 1 slot Sample config per site: *) 1U chassis (4 slots) *) 1x Mgmt card => 1 slot *) [same parts for all configs] *) 1x 25G converter (100G client port split into 4x 25G SFP28 line ports) => 1 slot *) 1x 8 channel DWDM Mux/Demux => separate 1U *) 4x 25G SFP28 DWDM 10km *) 1x 100G QSFP28 SR/LR (this is only for the client port on the converter - you need a second one for your device) => footprint per site ~6200 USD for 1x 100G The above setup requires 3U of rack space per site and provides 4 more DWDM channels as spares for further upgrades and the DWDM unit will have an separate upgrade port, to expand the number of filters (if you do not want to replace the whole filter with a bigger one). If you you want to go for a solution which starts with 4x 100G you're on the 13k USD range (per site): *) 2U chassis (8 slots) *) 1x Mgmt card => 1 slot *) [same parts for all configs] *) 4x 25G converter (100G client port split into 4x 25G SFP28 line ports) => 4 slots *) 1x 16 channel DWDM Mux/Demux => separate 1U *) 16x 25G SFP28 DWDM 10km *) 4x 100G QSFP28 SR/LR (this is only for the client port on the converter - you need a second one for your device) => footprint per site ~13000 USD for 4x 100G Even expansion to 12x 100G is more or less "cheap": *) 5U chassis (16 slots) *) 1x Mgmt card => 1 slot *) [same parts for all configs] *) 12x 25G converter (100G client port split into 4x 25G SFP28 line ports) => 12 slots *) 1x 48 channel DWDM Mux/Demux => separate 1U *) 48x 25G SFP28 DWDM 10km *) 12x 100G QSFP28 SR/LR (this is only for the client port on the converter - you need a second one for your device) => footprint per site ~31000 USD for 12x 100G I typically go for Sintai, FS.com and Edgeoptics components. Regarding the compensation and AMPs stuff: it's just math, nothing else :). Best regards Jürgen

1 0

outlook inbound email issues?
by nanog 31 Oct '20

31 Oct '20

I have a client who is receiving 50% of their mail on outlook servers for the past few hours. MX records point to: xxxxx-com.mail.protection.outlook.com has address 104.47.38.36 xxxxx-com.mail.protection.outlook.com has address 104.47.36.36 Anyone aware of outlook issues or have someone they can poke to check into this? (Both answer smtp requests, guessing a queue is backed up somewhere.) thanks bill -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

Incorrect GeoIP filtering of 185.83.72.0/22
by Adam Pavlidis 30 Oct '20

30 Oct '20

Hello, We are reaching out to NANOG since the following issue is mostly observed in US-based service providers. We are advertising the prefix *185.83.72.0/22 <http://185.83.72.0/22>*, that seems to be blocked by various popular US-based services, thus our customers originating from this prefix have trouble reaching such services. Indicatively: Atlassian (AMAZON), Adobe (AKAMAI) . To the best of our understanding, the blocking is enforced due to US / EU sanctions against Iran. The prefix was purchased by us - Lamda Hellix SA ( *AS56910* based in *GREECE, EUROPE* ) - approximately 8 months ago. We followed the necessary process as instructed by RIPE for changing the ownership of the prefix. Therefore, we kindly ask those of you that use/maintain/operate GeoIP databases to update your records. Most importantly, we would be grateful if you could share with us ( net(a)lamdahellix.com) which Geo databases are mainly used in the US for this purpose. Kind regards, Adam Pavlidis

3 2

dark fiber connection between 111 E 8th and Coresite NYC1 or NYC2
by Eric Germann 30 Oct '20

30 Oct '20

Looking for a recommendation of a provider who can give us a dark fiber cross connect or an L2 connection between the two in the subject for an AWS Direct Connect out of Coresite Thanks Eric

3 2

urpf - evil?
by Baldur Norddahl 30 Oct '20

30 Oct '20

Hello While working on my ACLs I noticed that I was successful in blocking some apparently spoofed IPv6 traffic. The destination was Facebook and the source was IPv6 range belonging to a mobile operator that sells 4G Wifi router based solutions. So thinking about how and why a few customers end up sending packets to our network with the wrong source, I came up with a theory (not validated): What if the customer connects his 4G Wifi router to one of the LAN ports of our CPE (or visa versa)? His computer would then pick up an IPv6 range from both ISPs along with two default routes. But only one default route would be used, and in this case that was apparently the default route going to our network. But still his computer might use the IPv6 address from the other ISP as source and therefore he ends up "spoofing" by sending that to us. We deliver the packets to Facebook and I assume Facebook will route the replies just fine through the other ISP. Now the thing is that my impression is that it actually works so long I do not actively block it with uRPF or ACLs on our edge. I have learned that spoofing is evil and I should be blocking this - but why am I sabotaging something that apparently is doing just fine at some customers? Regards, Baldur

2 1

Anyone have a contact at Microsoft RE: Microsoft Defender SmartScreen removal?
by Matt Rauch 30 Oct '20

30 Oct '20

Hello, We have a hosting customer who had a brand new domain flagged from day one. Reported the site safe several weeks ago, and still no change. Microsoft Support chat said it could take a couple weeks to review. Matt Rauch

1 0