- NANOG - lists.nanog.org

Re: 3rd party network monitoring
by Ethan Katz-Bassett 11 Mar '08

11 Mar '08

Another you might want to look at is our system Hubble (http:// hubble.cs.washington.edu) which monitors reachability problems. I presented a preliminary study at NANOG40 (http://www.nanog.org/ mtg-0706/bassett.html), and now it is running continuously. Some of the other changes since the talk: - It monitors 78,000+ prefixes, with pings from 100 sites and traceroutes from 35 sites around the world. Once we roll over to the list used by the sister project iPlane, the number of prefixes will be 142,000+. - We developed a technique using source-spoofed probes to isolate the failures to forward or reverse paths. - The website lets you query for the status of an address. For now, failed pings trigger traceroutes, but we plan to start looking at latency changes as well. If you look at the site, I'd appreciate any feedback on what we have and where we should be going with it, as we'd like this to become a useful tool. If you have a prefix we can start monitoring, please feel free to write me or use the feedback form on the website to give us a pingable address to use, and I should be able to incorporate it. Thanks. ethan > > -------- Original Message -------- > Subject: 3rd party network monitoring > Date: Tue, 04 Mar 2008 12:02:27 -0500 > From: Darrell Hyde <dhyde(a)hostmysite.com> > To: nanog(a)merit.edu > > > In light of the recent major outages experienced by XO and Abovenet, I > have become very interested in finding a 3rd party vendor to > monitor the > availability of my network from a variety of locations. > > I've looked at keynote / redalert, but oddly enough they don't seem to > be able to monitor simple ICMP round-trip times - they (or at least > the > sales folk that I've spoken with) insist on checking the status of > a TCP > port or the response time of a web server. > > Google searches have yielded a few leads, but nothing terribly > promising. > > Can anybody recommend a vendor for this type of service? I suppose I > could always just get a bunch of VPS accounts here and there and run > smokeping, but I'd really like to avoid that. > > - Darrell

1 0

Customer-facing ACLs
by Ang Kah Yik 11 Mar '08

11 Mar '08

Hi Justin (and all others on-list) I understand your grounds for blocking outbound SMTP for your customers (especially those on dynamic IP connections). It probably will do good to block infected customers that are spewing spam all over the world. However, considering the number of mobile workers out there who send email via their laptops to corporate SMTP servers, won't blocking outbound SMTP affect them? Since these corporate types (I'm guessing here) are probably unaware of how to change their email client's SMTP configurations, chances are that blocking outbound SMTP will probably cause quite a lot of pain. After all, there are also those who frequently move from place to place so they're going to have to keep changing SMTP servers every time they go to a new place that's on a different ISP. Cheers -- ANG Kah Yik (bangky)

6 6

Re: Customer-facing ACLs
by Scott Weeks 11 Mar '08

11 Mar '08

Long response with answers inline... --- sean(a)donelan.com wrote:--------------------------- > Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery! Depends on how you ask the questions. How about: Should a statefull firewall be provided for casual broadband dynamic Internet access connections by default? Users may change the default settings of the stateful firewall as they choose. 1. Unsolicited inbound (to user LAN) traffic ----------------------------------------------------- The ultimate answer is: It depends. :-) As you know, it depends on your network and who your users are. My experiences are with a global network of cold potato routing for high-end enterprises, a 10,000 person university and, currently, a state-wide ILEC. In these networks no, internet access should not be closed partially by default and then allowed to be opened by a user. Little tutus out in Hana are not going to be able to figure it out when trying to use things their keiki on the mainland are telling them to use that're not on port 80. College students are just going to open everything so they don't have to worry blockages of the newest, kewlest thing to start up that they want to try. Enterprises want to be in as complete control of their services as possible, so perhaps there, if they all have technically adept network folks. ----------------------------------------------------- Are there LAN-only protocols and other data packets which shouldn't be accepted on WAN Internet access links without prior coordination (if ever)? 1. Anti-spoofing controls of source addresses 2. Proxy/gratitious ARP, ICMP redirects, DHCP server->client, RIP? 3. "Local" multicast data and broadcasts 4. "Sanity" checks of IP headers (i.e. source==destination, loopback, etc) which should never appear on the wire 5. Layer 2 non-Internet (non-IP, non-IPv6, non-ARP, non-PPPOE) Are there some protocols that should have prior coordination when using some Internet access types, e.g. dynamic or unauthenticated connections? 1. outbound to off-net SMTP (port 25) instead of MSA (port 587) 2. NetBios over TCP, the exploding Microsoft protocol? ------------------------------------------------------ The first 1-5...OK, possibly, but that isn't what the person was speaking about. The second 1-2, no, unless it's VERY clear to your customers upfront. I used to be of the 'second 1-2' opnion, but I've since changed my mind on the kind of networks I help operate. It's funny (in a sick kind of way) how much stuff you can break when you filter unless you have the time to do a *very complete* traffic analysis over an extended time period. Folks do all sorts of crazy crap that I think they shouldn't do (off-LAN Micro$loth file sharing, for example), but are doing and some have done for a long time. The hard part is I now always take over networks that have been in operation a long time and enabling these policies can be very painful after the fact. Establishing them when the network is new is a different story. scott

3 2

Peering with the Internet Alert Registry
by Josh Karlin 11 Mar '08

11 Mar '08

All, Some of you are aware of the site for network operators: http://iar.cs.unm.edu/ which has running for two years now. The purpose of the site is to detect and distribute network anomaly information to the network operators that need to know. The flip side of our proposed security system, Pretty Good BGP (PGBGP), lowers the local preference of anomalous routes on BGP routers for 24 hours, giving operators time to respond to anomalous routes before they can fully propagate. Now, PGBGP is in actual routing software (Quagga), which we soon hope to distribute. As an initial means of test, we will switch the IAR to it (instead of scraping RIPE/RouteViews with a script). This means that we will need peers to provide the IAR with BGP updates (we will not propagate any route updates to your routers). Currently we have three BGP streams, more would be appreciated. If you would like to contribute to our research project, please reply directly to me. More information about the project can be found here: http://cs.unm.edu/~karlinjf/pgbgp/ <http://cs.unm.edu/%7Ekarlinjf/pgbgp/> Thanks! Josh

2 2

Re: Customer-facing ACLs
by Scott Weeks 11 Mar '08

11 Mar '08

---------- sean(a)donelan.com wrote: ---------- On Mon, 10 Mar 2008, Scott Weeks wrote: > The hard part is I now always take over networks that have been in > operation a long time and enabling these policies can be very painful > after the fact. Establishing them when the network is new is a > different story. Whatever you decide, whether you know what the policies are or not, there are always have a set of default network policies. The question is do you explain to you customers just as carefully what your default policy doesn't do, as well as what it does. Do you take just as much time to carefully explain the risks and what may break to your customers of allowing that traffic as you would of not allowing that traffic. It seems to be very painful whatever decision is made. ------------------------------------------------- The default policy is we allow eveything. It takes no explaining. I understand the port 25 issue and am reconsidering it for dynamic addresses on outbound traffic, but at least one person on NANOG showed me a use of that. Like network engineers at many other companies, I'm spread so thin that it's hard to find the time to do work like this and I keep putting it on the back burner. VZ had it completely open and I have followed that as we seperated this network from their network, as I can't take on the extra work of fixing brokenness that would result from applying the filter. scott

2 1

Customer-facing ACLs
by mack 11 Mar '08

11 Mar '08

> ------------------------------ > > Date: Tue, 11 Mar 2008 07:58:01 +0800 > From: Ang Kah Yik <mailinglist(a)bangky.net> > Subject: Customer-facing ACLs > > Hi Justin (and all others on-list) > > I understand your grounds for blocking outbound SMTP for your customers > (especially those on dynamic IP connections). > It probably will do good to block infected customers that are spewing > spam all over the world. > > However, considering the number of mobile workers out there who send > email via their laptops to corporate SMTP servers, won't blocking > outbound SMTP affect them? > > Since these corporate types (I'm guessing here) are probably unaware of > how to change their email client's SMTP configurations, chances are > that > blocking outbound SMTP will probably cause quite a lot of pain. > > After all, there are also those who frequently move from place to place > so they're going to have to keep changing SMTP servers every time they > go to a new place that's on a different ISP. > > Cheers > - -- > ANG Kah Yik (bangky) > > ------------------------------ One would hope mobile commuters are using something more secure than just raw SMTP to send e-mail if their network admins have any sense. The usual combination requires a POP connection first or uses a port other than 25 to send. As a customer my home DSL service provider (SBC) blocks port 25 by default. Many firewalls can be programmed to allow 'related' connections. Ie. if a POP connection is opened then allow the SMTP connection. The real solution is to move to imap or msa (port 587) or the latest MS exchange protocol (whatever it is). As for blocking FTP and SSH, it would depend A LOT on your customer base. As a content provider we do not allow raw NetBios into our network. Anyone that wants to use remote file sharing to work on their windows server is encouraged (Whips and Chains if necessary) to use a VPN tunnel. If you are going to block something, block port 135 both directions. -- LR Mack McBride Network Administrator Alpha Red, Inc.

1 0

ARIN & CAIDA IPv6 Survey
by Member Services 10 Mar '08

10 Mar '08

The American Registry for Internet Numbers (ARIN), in cooperation with the Cooperative Association for Internet Data Analysis (CAIDA), is conducting a survey to gather data regarding the current and future use of IPv6 throughout the ARIN Region. For a complete list of countries go to: http://www.arin.net/community/ARINcountries.html We encourage all organizations in the ARIN region to participate in the survey so we can establish a comprehensive view of present IPv6 penetration and future plans of IPv6 deployment. The survey will open on 10 March and remain available until noon ET on 24 March. The results of the survey will be presented and discussed at the ARIN XXI Public Policy and Members Meeting to be held in Denver 6-9 April 2008, and the survey data will support ongoing research. The survey is composed of 20 questions that can be answered in a few minutes. When you complete the survey you will be entered in a drawing for prizes. You must provide your contact information to win. This is a secure survey and all data will be presented in summary form only, and kept confidential between ARIN and CAIDA. Please take a few moments to complete the survey located at: https://www.surveymonkey.com/s.aspx?sm=2x5j2OlJl0cq44iYfQadrw_3d_3d Regards, Member Services American Registry for Internet Numbers (ARIN)

1 0

Tools to measure TCP connection speed
by Joe Shen 10 Mar '08

10 Mar '08

hi, is there any tool could measue e2e TCP connection speed? e.g. we want to measue the delay between the TCP SYN and receiving SYN ACK packet. Joe ______________________________________________________________________ Search, browse and book your hotels and flights through Yahoo! Travel. http://sg.travel.yahoo.com

8 8

bandwidth providers and pricing in China
by matthew zeier 10 Mar '08

10 Mar '08

Looking for anyone who has experience deploying a network in China. I'm getting 1500RMB/Mbps with a 10Mbps commit that I'm already bumping up against. Moving to 20Mbps is going to drop me to 1200RMB/Mbps or about $3400 USD a month which seems excessive compared to my US pricing (or even what I'm seeing in Amsterdam). Are these prices what others see? Where can I get better pricing?

3 2

RE: bandwidth providers and pricing in China
by Neil J. McRae 10 Mar '08

10 Mar '08

Going rate in Asia and India is much higher than US and Europe. -----Original Message----- From: matthew zeier <mrz(a)velvet.org> Sent: 07 March 2008 18:22 To: nanog(a)nanog.org Subject: bandwidth providers and pricing in China Looking for anyone who has experience deploying a network in China. I'm getting 1500RMB/Mbps with a 10Mbps commit that I'm already bumping up against. Moving to 20Mbps is going to drop me to 1200RMB/Mbps or about $3400 USD a month which seems excessive compared to my US pricing (or even what I'm seeing in Amsterdam). Are these prices what others see? Where can I get better pricing?

3 2