nanog mailing list archives
help
From: T Kawasaki <nanog2011 () yahoo com>
Date: Thu, 17 Jun 2010 07:55:01 -0700 (PDT)
________________________________
From: "nanog-request () nanog org" <nanog-request () nanog org>
To: nanog () nanog org
Sent: Thu, June 17, 2010 8:00:02 AM
Subject: NANOG Digest, Vol 29, Issue 51
Send NANOG mailing list submissions to
nanog () nanog org
To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.nanog.org/mailman/listinfo/nanog
or, via email, send a message with subject or body 'help' to
nanog-request () nanog org
You can reach the person managing the list at
nanog-owner () nanog org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of NANOG digest..."
Today's Topics:
1. Re: Todd Underwood was a little late (Jon Lewis)
2. Re: Todd Underwood was a little late (Mark Andrews)
3. Re: Todd Underwood was a little late (Roy)
4. Re: Todd Underwood was a little late (Garrett Skjelstad)
5. AT&T's blue network SMS<->SMTP off the air (John Todd)
6. AAAA being added for i.root-servers.net (Lindqvist Kurt Erik)
----------------------------------------------------------------------
Message: 1
Date: Wed, 16 Jun 2010 22:43:11 -0400 (EDT)
From: Jon Lewis <jlewis () lewis org>
Subject: Re: Todd Underwood was a little late
To: Mark Andrews <marka () isc org>
Cc: nanog () nanog org
Message-ID: <Pine.LNX.4.61.1006162237180.5148 () soloth lewis org>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Thu, 17 Jun 2010, Mark Andrews wrote:
Why was this traffic hitting your DNS server in the first place? It should have been rejected by the ingress filters preventing spoofing of the local network.
When I ran a smaller simpler network, I did have input filters on our transit providers rejecting packets from our IP space. With a larger network, multiple IP blocks, numerous multihomed customers, some of which use IP's we've assigned them, it gets a little more complicated to do. I could reject at our border, packets sourced from our IP ranges with exceptions for any of the IP blocks we've assigned to multihomed customers. The ACLs wouldn't be that long, or that hard to maintain. Is this common practice? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ ------------------------------ Message: 2 Date: Thu, 17 Jun 2010 13:27:09 +1000 From: Mark Andrews <marka () isc org> Subject: Re: Todd Underwood was a little late To: Jon Lewis <jlewis () lewis org> Cc: nanog () nanog org Message-ID: <201006170327.o5H3R9fA072599 () drugs dv isc org> In message <Pine.LNX.4.61.1006162237180.5148 () soloth lewis org>, Jon Lewis write s:
On Thu, 17 Jun 2010, Mark Andrews wrote:Why was this traffic hitting your DNS server in the first place? It should have been rejected by the ingress filters preventing spoofing of the local network.When I ran a smaller simpler network, I did have input filters on our transit providers rejecting packets from our IP space. With a larger network, multiple IP blocks, numerous multihomed customers, some of which use IP's we've assigned them, it gets a little more complicated to do.
One can never do a perfect job but one can stop a large percentage of the crap. You should know the multi-homed customers and their address ranges so they become exceptions. You also run filters on internal routers. There are internal ingress/egress points as well as interconnects.
I could reject at our border, packets sourced from our IP ranges with exceptions for any of the IP blocks we've assigned to multihomed customers. The ACLs wouldn't be that long, or that hard to maintain. Is this common practice? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka () isc org ------------------------------ Message: 3 Date: Wed, 16 Jun 2010 21:38:42 -0700 From: Roy <r.engehausen () gmail com> Subject: Re: Todd Underwood was a little late Cc: nanog () nanog org Message-ID: <4C19A6D2.6030603 () gmail com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 6/16/2010 7:43 PM, Jon Lewis wrote:
On Thu, 17 Jun 2010, Mark Andrews wrote:Why was this traffic hitting your DNS server in the first place? It should have been rejected by the ingress filters preventing spoofing of the local network.When I ran a smaller simpler network, I did have input filters on our transit providers rejecting packets from our IP space. With a larger network, multiple IP blocks, numerous multihomed customers, some of which use IP's we've assigned them, it gets a little more complicated to do. I could reject at our border, packets sourced from our IP ranges with exceptions for any of the IP blocks we've assigned to multihomed customers. The ACLs wouldn't be that long, or that hard to maintain. Is this common practice? -
Sounds like a good use of URPF.
------------------------------
Message: 4
Date: Wed, 16 Jun 2010 22:07:10 -0700
From: Garrett Skjelstad <garrett () skjelstad org>
Subject: Re: Todd Underwood was a little late
To: Roy <r.engehausen () gmail com>
Cc: nanog () nanog org
Message-ID:
<AANLkTim-6WCFwrPNyBwXV1P7CwWReCa6DauH-rHvvo_a () mail gmail com>
Content-Type: text/plain; charset=ISO-8859-1
RFC 2827 anyone?
On Wed, Jun 16, 2010 at 9:38 PM, Roy <r.engehausen () gmail com> wrote:
On 6/16/2010 7:43 PM, Jon Lewis wrote:On Thu, 17 Jun 2010, Mark Andrews wrote: Why was this traffic hitting your DNS server in the first place? Itshould have been rejected by the ingress filters preventing spoofing of the local network.When I ran a smaller simpler network, I did have input filters on our transit providers rejecting packets from our IP space. With a larger network, multiple IP blocks, numerous multihomed customers, some of which use IP's we've assigned them, it gets a little more complicated to do. I could reject at our border, packets sourced from our IP ranges with exceptions for any of the IP blocks we've assigned to multihomed customers. The ACLs wouldn't be that long, or that hard to maintain. Is this common practice? -Sounds like a good use of URPF.
------------------------------ Message: 5 Date: Wed, 16 Jun 2010 23:26:30 -0700 From: John Todd <jtodd () loligo com> Subject: AT&T's blue network SMS<->SMTP off the air To: nanog () nanog org Message-ID: <7A699AC1-EF4E-4731-8D81-FAEDC3CE1C01 () loligo com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes To those of you who may rely upon AT&T to deliver your email-to-SMS messages for monitoring: some of you may be currently out of luck. I would just send this to the "outages () puck nether net" list, but it does seem to be a meta-network failure in that for better or worse many of us use SMS as a method to monitor outages, so this perhaps moves it up a notch in the importance hierarchy enough to warrant a NANOG post. I am experiencing failures on my email transmissions to my older "blue" (aka: Cingular) AT&T devices at the moment, for both incoming and outgoing. Many of you may be using older "blue" cards in your NOC phones, SMS gateway devices, or perhaps even your personal mobile devices for those of you who still live in the dark ages of phones that aren't [2.5,3,4,x]G capable. I am unable to diagnose the problems fully, but at least some (if not all) of the SMS-to-email gateway failures are due to mmode.com's MX hosts (in the "airdata.com" zone) being unreachable due to absence of functioning authoritative resolvers for that zone, and possibly other failures as well. This appears to be causing "550 Access Denied" messages being returned to my mobile devices that are sending to email addresses, and mail spooling on my Internet SMTP hosts that are trying to send to the "NPAxxxyyyy () mmode com" addresses for SMTP-to-SMS relay. There is a rumor that this is NOT related to the deactivation of the "downloads" components of the blue network on the 15th, but I suspect that someone just decided to pull the plug on everything. Reading to the end of the thread below, there is someone who states AT&T claims it will be back online by the evening of the 17th at the surprisingly accurate time of 9:55 PM (timezone unstated.) More speculation: http://forums.wireless.att.com/t5/mMode/URGENT-mmode-down-again-Their-mta01-cdpd-airdata-com-mail-server/td-p/1939480 I don't know if this is causing problems with anyone using TAP interfaces, or with any of AT&T's other SMTP<->SMS gateway services like @txt.att.net. SMS, and mobile devices in general, are a single point of failure for contacting on-call staff for various problems - perhaps it's time to insist that everyone carries two mobile devices, on different frequency and technology platforms, with different carriers, and split messages to both due to the anecdotally increasing failure rates of mobile networks. Conspiracy theories of how collusive unreliability would increase ARPU across the board for all carriers would be interesting to hear... but not in this forum, I suspect. :-) JT ------------------------------ Message: 6 Date: Thu, 17 Jun 2010 10:31:57 +0200 From: Lindqvist Kurt Erik <kurtis () kurtis pp se> Subject: AAAA being added for i.root-servers.net To: NANOG list <nanog () nanog org> Message-ID: <E85117CB-7A03-488E-A8DB-A8764A5C3CD1 () kurtis pp se> Content-Type: text/plain; charset="iso-8859-1" All, This is to inform you that, we (Netnod/Autonomica, operators of i.root-servers.net) have been notified by IANA that on our request an AAAA record will be added to the root-zone with serial number 2010061700. Best regards, - kurtis - --- Kurt Erik Lindqvist, CEO kurtis () netnod se, Direct: +46-8-562 860 11, Switch: +46-8-562 860 00 Please note our new address: Franz?ngatan 5 | SE-112 51 Stockholm | Sweden -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://mailman.nanog.org/pipermail/nanog/attachments/20100617/ab0ea84a/attachment-0001.pgp ------------------------------ _______________________________________________ NANOG mailing list NANOG () nanog org https://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 29, Issue 51 *************************************
Current thread:
- help T Kawasaki (Jun 17)