- Test - lists.nanog.org

Customer Interface Reporting / Portal
by Serge Vautour 17 Jun '10

17 Jun '10

Hello, What are people using to provide customer interface usage reports to customers? There seems to be lots of RRD based tools that can gather the data and store it for long term viewing. We use ZenOSS for internal purposes for example. How do we go about providing each customer access to their data in a secure way? A portal type access. Is anyone aware of a tool that includes a front end that can partition the data on a per customer basis? Each customer would have their own login ID and only see their data? How do we link the data to that customer? Some customer ID on the interface description? Thanks, Serge

3 2

AT&T's blue network SMS<->SMTP off the air
by John Todd 17 Jun '10

17 Jun '10

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(a)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(a)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… 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

2 1

help
by T Kawasaki 17 Jun '10

17 Jun '10

________________________________ From: "nanog-request(a)nanog.org" <nanog-request(a)nanog.org> To: nanog(a)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(a)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(a)nanog.org You can reach the person managing the list at nanog-owner(a)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(a)lewis.org> Subject: Re: Todd Underwood was a little late To: Mark Andrews <marka(a)isc.org> Cc: nanog(a)nanog.org Message-ID: <Pine.LNX.4.61.1006162237180.5148(a)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(a)isc.org> Subject: Re: Todd Underwood was a little late To: Jon Lewis <jlewis(a)lewis.org> Cc: nanog(a)nanog.org Message-ID: <201006170327.o5H3R9fA072599(a)drugs.dv.isc.org> In message <Pine.LNX.4.61.1006162237180.5148(a)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(a)isc.org ------------------------------ Message: 3 Date: Wed, 16 Jun 2010 21:38:42 -0700 From: Roy <r.engehausen(a)gmail.com> Subject: Re: Todd Underwood was a little late Cc: nanog(a)nanog.org Message-ID: <4C19A6D2.6030603(a)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(a)skjelstad.org> Subject: Re: Todd Underwood was a little late To: Roy <r.engehausen(a)gmail.com> Cc: nanog(a)nanog.org Message-ID: <AANLkTim-6WCFwrPNyBwXV1P7CwWReCa6DauH-rHvvo_a(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(a)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? 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: 5 Date: Wed, 16 Jun 2010 23:26:30 -0700 From: John Todd <jtodd(a)loligo.com> Subject: AT&T's blue network SMS<->SMTP off the air To: nanog(a)nanog.org Message-ID: <7A699AC1-EF4E-4731-8D81-FAEDC3CE1C01(a)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(a)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(a)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… 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(a)kurtis.pp.se> Subject: AAAA being added for i.root-servers.net To: NANOG list <nanog(a)nanog.org> Message-ID: <E85117CB-7A03-488E-A8DB-A8764A5C3CD1(a)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(a)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

1 0

pls help about mtu setting
by Deric Kwok 17 Jun '10

17 Jun '10

Hi My DSL company asks me to set the modem 146 2 and my old company used 14 92 What is the different? Why it is not standard 1 500? Thank you

4 3

AAAA being added for i.root-servers.net
by Lindqvist Kurt Erik 17 Jun '10

17 Jun '10

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(a)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

1 0

Anybody from Shaw Cable
by Antoine Reversat 16 Jun '10

16 Jun '10

We are having a strange routing issue. If anybody from Shaw cable could contact me offlist I'd be very thankfull.

1 0

2010.06.16 NANOG49 day 3 notes
by Matthew Petach 16 Jun '10

16 Jun '10

Alas, another great NANOG has come to an end; it went by so quickly this time. Notes from today, including the inimitable duo of Todd Underwood and Odd Tunderwood, are now up at http://kestrel3.netflight.com/2010.06.16-NANOG49-day3.txt As always, I'm sure I got a bunch of things wrong, including people's names, etc. Email me with corrections, I'll update and increment version number. Maybe newNOG could have a twiki I could upload these to, so people could just update and fix them themselves for future meetings? Thanks again for another top-notch meeting--and big thanks for the v6 hidef video stream--it rocked!! Matt

1 0

Live streaming from NANOG49
by T.J. Kniveton 16 Jun '10

16 Jun '10

First off, thanks to the staffers who set up live streaming. I'm using HD unicast, and the quality is great. That said, is it possible to have the camera zoom in to the presenter a bit? The whole room is shown, and even on a 24" screen I still can't really see the presenters very clearly, since there's some pixellation. Thanks, TJ

5 6

Literatur hint needed
by Matthias Flittner 16 Jun '10

16 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Folks, I'm searching an fundamental book about how to (inter)connect two networks. It should be about how to connect your business network in a secure and reliable way to the internet. The book should contain some theoretical basics and common used practices. Focus is how to design such an network transfer point. Does anyone know such a book? best regards and thanks, FliTTi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMGImiAAoJEIZn8Rym6s4A5lMH/ReMDeGegtPUXJOuWW96yepR k3PyBaKOm7LcYwHrcNN0TEl1LfBPp1qItq1xw8Pcgv32E1BhlbpaNUpqh3fRrN8O qVca/SaKM5CGW4CHEfqZm1BAcRE5uY8icL0n8LxBFrHqRNgmuDkq3MfBQiGC0GQI /jcGb052DHSbApMhFqBcTgiJr19ow3Gmxr+jzNQzgz5SHOC/XWF7vmCYCkGAfhpG ibqdVVb5lUp7er66uBX4GfNQyN+iMiDDi0d0+dRvE0lDZ+hpFQZlKDDeZCOLpRpH TqU2hGCZx0/LQorl/VwfvpSeaMjeUb4Pe4RQ8NIqKwkoMqjcWZVDa2ikueW7BLQ= =EpXH -----END PGP SIGNATURE-----

3 3

BGP Multihoming Partial vs. Full Routes
by James Smallacombe 16 Jun '10

16 Jun '10

I know this topic must have been covered before, but I can find no search tool for the NANOG archives. I did google and reference Halabi's book as well as Avi's howto, but I still don't feel I fully understand the pros and cons of Full vs. Partial routes in a dual/multihomed network. Cisco's position these days seems to be "you don't need to carry full views unless you like tinkering with optimizig paths and such." Tinkering isn't the issue. Full reachability to servers on this network from EVERYone, including both upstreams' customers, regardless of the status of each upstream connection is. Ditto in the event that one upstream has some kind of core or regional router meltdown, which I've seen more than once. I see conflicting advice as to whether partial routes will suffice for this. Helpful links and/or synopsese appreciated. James Smallacombe PlantageNet, Inc. CEO and Janitor up(a)3.am http://3.am =========================================================================

4 3