February 2014 - Test - lists.nanog.org

Re: BCP38.info
by Nick Olsen 05 Feb '14

05 Feb '14

Agreed. Our's listed for AS36295 are two customers, Which I know for a fact have their default route set out of a GRE tunnel interface. So while we hand them the request to their interface IP we've assigned them. The response is actually sent, And transported via the customers GRE Tunnel, And HQ's Dedicated internet access where their tunneling to. Making it appear that the reply has been spoofed. When in reality. it was just silent transported to another area before being sent to the src. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "David Miller" <dmiller(a)tiggee.com> Sent: Tuesday, January 28, 2014 2:47 PM To: "Jared Mauch" <jared(a)puck.nether.net>, Valdis.Kletnieks(a)vt.edu Cc: "NANOG" <nanog(a)nanog.org> Subject: Re: BCP38.info On 1/28/2014 2:16 PM, Jared Mauch wrote: > > On Jan 28, 2014, at 1:50 PM, Valdis.Kletnieks(a)vt.edu wrote: > >> On Tue, 28 Jan 2014 08:06:31 -0500, Jared Mauch said: >> >>> 52731 ASN7922 >> >>> It includes IP address where you send a DNS packet to it and another IP address responds to the query, e.g.: >> >>> The data only includes those where the "source-ASN" and "dest-asn" of these packets don't match. >> >> Hang on Jared, I'm trying to wrap my head around this. You're saying that >> AS7922 has over 50K IP addresses which, if you send a DNS query to that IP, >> you get an answer back from *an entirely different ASN*? How the heck does >> *that* happen? > > Yup. Jared, What you detected is a misconfiguration of devices on those networks, but that misconfiguration (in and of itself) is not necessarily what is commonly referred to as "IP spoofing" in the context of BCP38. You have *not* "shown" that these ASNs "allow IP spoofing". You have collected one data point that indicates the mere possibility that these ASNs allow IP spoofing. In the example that you provided, you sent a DNS query to a Pacenet (India) IP and received a response from a Vodafone (India) IP address. The IP from which you received the invalid response is an open resolver (bad thing). It is completely plausible that whatever device is being queried has interfaces on both networks. To have "shown" that this ASN "allows IP spoofing" you must have demonstrated that this response packet, sourced from a Vodafone IP, entered the "Internet" from a Pacenet router interface. Unless I am missing something here, you haven't come close to showing that. -DMM

7 9

RE: Route Server Filters at IXPs and 4-byte ASNs
by Jakob Heitz 05 Feb '14

05 Feb '14

I would support that. http://tools.ietf.org/search/draft-raszuk-wide-bgp-communities-03 How would you modify it? To me, that draft looks hugely complicated, like everything you could possibly think of was thrown in. I would support a simplified version (and be able to code it without bugs) if it contained just useful stuff. -- Jakob Heitz. ________________________________________ Date: Sat, 25 Jan 2014 18:37:42 +0000 From: Nick Hilliard <nick(a)foobar.org> To: Sebastian Spies <s+Mailinglisten.nanog(a)sloc.de>, nanog(a)nanog.org Subject: Re: Route Server Filters at IXPs and 4-byte ASNs Message-ID: <52E40476.20200(a)foobar.org> Content-Type: text/plain; charset=ISO-8859-1 On 25/01/2014 15:48, Sebastian Spies wrote: > To make things worse: even if the IXPs ASN is 2-byte, I would assume, > that RS implementors chose to interpret extended community strings as > always being in the format 4-byte:2-byte (see RFC5668). some ixp operators (e.g. me) are rather enthusiastic about the idea of a modified form of draft-raszuk-wide-bgp-communities getting more traction. This would solve this particular problem and many others. Nick

4 4

MMF optics for Juniper EX4550
by Davey Goode 05 Feb '14

05 Feb '14

Hi All, Can anyone recommend where to get some 10G SFP+ MMF optics what will work in a Juno. Im in San Jose right now and I'm flying back to NZ on friday.... replies off list would be appreciated. thanks in advanced. davey

1 0

Verizon Fios Issue in Massachusetts
by Brian Loveland 04 Feb '14

04 Feb '14

Is anyone from Verizon available to help me chase down an issue off-list? Since Sunday morning, we've been seeing what looks to be a bad link aggregation (10+% packet loss on one IP, 0% on an adjacent IP) to all of the networks we control (on various providers, various AS's, various locations) and to common things like 8.8.8.8 and 8.8.4.4 from my Fios connection at home. Colleagues are seeing the same from other towns in MA. A couple of them have opened tickets with Fios support but haven't gotten anywhere. Unfortunately not a AS701 IP customer for our work networks, so can't follow normal support channels on that side. Thanks.

1 0

Cogent <-> Verizon peering congestion
by John Zettlemoyer 04 Feb '14

04 Feb '14

I got that same response from Cogent in August and October when we complained (word for word). Sometimes it's bad, sometimes it's "ok". Happens with Comcast sometimes too, but the peer to Verizon is usually worse. I can show packet loss with an MTR anytime of day. Today is an "ok" day.... just 5% loss on average. |------------------------------------------------------------------------------------------| | MTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | gw2-j.phl1.wcit.net - 0 | 101 | 101 | 1 | 6 | 98 | 2 | | gi3-6.ccr01.phl05.atlas.cogentco.com - 0 | 101 | 101 | 1 | 17 | 179 | 16 | | te7-4.ccr01.phl01.atlas.cogentco.com - 0 | 101 | 101 | 1 | 31 | 205 | 1 | | te4-1.ccr01.bwi01.atlas.cogentco.com - 0 | 101 | 101 | 3 | 34 | 192 | 3 | |te0-1-0-7.mpd21.dca01.atlas.cogentco.com - 0 | 101 | 101 | 5 | 6 | 11 | 6 | | be2113.ccr41.iad02.atlas.cogentco.com - 0 | 101 | 101 | 6 | 6 | 12 | 7 | | verizon.iad01.atlas.cogentco.com - 5 | 85 | 81 | 0 | 48 | 95 | 47 | | No response from host - 100 | 21 | 0 | 0 | 0 | 0 | 0 | | l100.cmdnnj-vfttp-01.verizon-gni.net - 5 | 85 | 81 | 55 | 62 | 136 | 56 | |________________________________________________|______|______|______|______|______|______| John Zettlemoyer

1 0

NANOG 60 ATL Data Center Track Update
by Martin Hannigan 04 Feb '14

04 Feb '14

All, We are planning to experiment with a change in the way "personals", a long standing tradition in the Peering Track, are done and in the Data Center track at NANOG 60 in Atlanta. The track is being held Monday starting at 4:45 and running through 6:15. Instead of data center operators presenting, the hosts or a member of the data center community will present a brief summary of regional data center bullet points. If you operate a data center in Georgia, North Carolina, South Carolina and Alabama, respond with the following bullet point answers by Friday. If we can't fit everyone, apologies in advance. 1. mW committed from utility? 2. mW currently available? 3. Any Facility Certifications? 4. Gross Square Footage of Data Center? 5. Net Square Footage available in Data Center? 6. Design PUE? 7. Wholesale, Retail Colo or Both? 8. Date Active? 9. Number of dual routed providers operational? Along with this, we'll be presenting short summaries related to recent, interesting, developments in the industry related to space, power and people. See the track agenda at http://bit.ly/1jbZ9aY Best Regards, -M<

2 1

Re: TWC (AS11351) blocking all NTP?
by Scott Weeks 04 Feb '14

04 Feb '14

----------------------------- > We block all outbound UDP for our ~200,000 Users for this very reason > (with the exception of some whitelisted NTP and DNS servers). So far > we have had 0 complaints ----------------------------- Because those that might complain switched providers when their internet broke instead of complaining and hoping something might change? scott

1 0

Visual tools for RSVP-TE
by Rampley Jr, Jim F 04 Feb '14

04 Feb '14

I'm curious what tools different organizations are using to provision, manage, and visually see how constraint based LSP's are routed over your network. Jim

1 0

Re: TWC (AS11351) blocking all NTP?
by Larry Sheldon 04 Feb '14

04 Feb '14

On 2/2/2014 9:17 PM, ryangard(a)gmail.com wrote: > I'd hate to think that NetOps would be so heavy handed in blocking > all of UDP, as this would essentially halt quite a bit of audio/video > traffic. That being said, there's still quite the need for protocol > improvement when making use of UDP, but blocking UDP as a whole is > definitely not a resolution, and simply creating a wall that not only > keeps the abusive traffic out, but keeps legitimate traffic from > flowing freely as it should. "We had to burn down the village to save it." -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

12 24

FW: Updated ARIN allocation information
by Leslie Nobile 04 Feb '14

04 Feb '14

ARIN would like to share two items of information that may be of interest to the community. First, ARIN has recently begun to issue address space from its last contiguous /8, 104.0.0.0 /8. The minimum allocation size for this /8 will be a /24. You may wish to adjust any filters you have in place accordingly. More information on the IP address space administered by ARIN can be found on our web site at: https://www.arin.net/knowledge/ip_blocks.html Additionally, ARIN has placed 23.128.0.0/10 in its reserves in accordance with the policy "Dedicated IPv4 block to facilitate IPv6 Deployment" (NRPM 4.10). There have been no allocations made from this block as of yet, however, once we do begin issuing from this block, the minimum allocation size for this /10 will be a /28 and the maximum allocation size will be a /24. You may wish to adjust any filters you have in place accordingly. More information on this policy can be found on our website here: https://www.arin.net/policy/nrpm.html#four10 Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN)

21 39