September 2008 - Test - lists.nanog.org

Jay Shao is out of the office.
by Jay Shao 15 Sep '08

15 Sep '08

I will be out of the office starting 09/15/2008 and will not return until 09/21/2008. I will respond to your message when I return. Please contact with NETTCP(a)DTCC.COM for any production issues ----------------------------------------- ________________________________________________________ DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

1 0

NANOG List Monthly Post.
by NANOG Mail List Committee 15 Sep '08

15 Sep '08

General Information =================== About NANOG: http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP: http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins(a)nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: https://puck.nether.net/mailman/listinfo/outages * Spam Please use SPAM-L - http://www.claws-and-paws.com/spam-l * Contacting People * http://puck.nether.net/netops/ * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555-3333 but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact admins(a)nanog.org Please also avoid ================= * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists ========================= * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists =================== Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php

1 0

ARP Table Timeout and Mac-Address-Table Timeout
by Steven King 15 Sep '08

15 Sep '08

I am a network engineer for a large web hosting company. We are having an issue with our distribution routers flooding traffic in one of our VLANs. We have a customer with a routed mode ASA 5550. They have their own private VLAN that is a /23 This VLAN is 145. The outside interface of the firewall is in VLAN 132. We are routing all traffic for VLAN 145 to the IP of the outside interface of the firewall in VLAN 132. VLAN 132 is Layer3 routable and VLAN 145 is only Layer2 switchable. We have two distribution switches which are redundant with HSRP. Dist1 is the active forwarder in this case. Traffic coming into these two routers are load balanced between Dist1 and Dist2 with EIGRP routes with equal cost. We have found that traffic coming into Dist2 (the standby) is flooding traffic destined for the firewall outside interface. But Dist1 is not. We have tracked down the cause of this to the MAC-Address-Table timing out before the ARP table times out. We leave these values at the Cisco default. ARP = 4hr MAC = 5 minutes. Since Dist2 is not receiving any traffic from the firewall going out to the internet, it is not updating the MAC-Address-Table after it expires. Instead, it waits 4 hours for the ARP cache to expire for that IP, and then updates everything. But Dist2 ends up flooding traffic for that 4 hours causing latency. We have done some research on this problem and have found so far the best solution to be to make the ARP timeout less than the MAC-Address-Table aging-timer.We have set the ARP = 1hr and MAC = 2hrs in this case to correct the problem. So when the ARP entry times out before the MAC entry, the forced update of the ARP entry before the MAC timeout causes the MAC entry age to reset. Indeed this does correct the problem. Is this the best solution to the problem, or is there another preferred solution? Has anyone ran into this in their own Enterprise Networks? Please let me know if I didn't explain anything well enough. -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA Network+ Certified Professional CompTIA A+ Certified Professional

2 2

Re: Internet Traffic Begins to Bypass the U.S.
by Paul Ferguson 15 Sep '08

15 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Jim Mercer <jim(a)reptiles.org> wrote: >UAE/Dubai is a major landing point for many asian/indian ocean fibers, but >there is no equivilent of One Wilshire/60 Hudson/etc. > >so, as the data finds more and better direct routes to the end user, >reducing the need to route through the US, there is still a penchant for >hosting the primary data there. A direct route to the criminals, too: http://www.arabianbusiness.com/530800-uae-banks-step-up-security-after-card - -theft - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIzf5Nq1pz9mNUZTMRAjcnAKC6o9PncwyXAQ3P8kIZC1Ca0n60nACeNLzV P/rKYAjJGGKbp1GDaMvgx2Y= =lbak -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

RE: community real-time BGP hijack notification service
by Hank Nussbacher 14 Sep '08

14 Sep '08

>> The best system so far would be IAR: http://iar.cs.unm.edu/ >> The email notices are pretty much on time and accurate. Problem is they >> have changed the system and I believe some forum page/link has gone lost >> that allows one to manage existing subscriptions as per: >> http://iar.cs.unm.edu/alerts.php#email Correction: the page exists although difficult to find. As per Josh: "Once you login on the IAR forums, toward the top left of the page is a "user control panel" button. Click that and go to the "profile" tab. At the bottom of that page is a field: "user_ases". -Hank

1 0

ingress SMTP
by hobbit＠avian.org 14 Sep '08

14 Sep '08

I've been blackholing NANOG mail for a while due to other things displacing the time I'd need to read it, so I might be a little out of touch on this, but I did grovel through some of the archives looking for any discussion on this before posting. Didn't find a really coherent answer yet. What I'm trying to get a feel for is this: what proportion of edge customers have a genuine NEED to send direct SMTP traffic to TCP 25 at arbitrary destinations? I'm thinking mostly of cable-modem and DSL/fiber swamps, dialup pools [do they even exist anymore?], and other clouds basically containing end-users rather than the more "bidirectional" business-class customers. The big providers -- comcast, verizon, RR, charter, bellsouth, etc -- seem to be some of the most significant sources of spam and malware attempts, mostly from compromised end-user machines, and it seems that simply denying *INGRESS* of TCP 25 traffic except to the given ISP's outbound relay servers would cut an awful lot of it off at the pass. Decent anti-header-spoofing configuration on said mailservers would take care of even more. I realize this might be a total hot-button but I'm not talking about filtering TOWARD customers, I'm talking about filtering FROM them, upstream -- possibly less often discussed. And only SMTP. Not censorship, just a simple technical policy that the vast majority of customers wouldn't even notice. I've got a paper out about this that was put together quite a while ago, in fact: http://www.usenix.org/publications/login/2005-10/openpdfs/hobbit.pdf I can weigh the decision to trust a PTR lookup, but most of the big players seem to have their inverse DNS automated fairly well which helps such little hacks work. But really, I'd like to see more done at the SOURCE of the problem, which should be as simple as two ACL lines dropped into some edge routers. What is preventing this from being an operational no-brainer, including making a few exceptions for customers that prove they know how to lock down their own mail infrastructure? And why do the largest players seem to have the least clue about it? _H*

29 55

Re: ingress SMTP
by hobbit＠avian.org 13 Sep '08

13 Sep '08

> How do you alert mail server operators who are smarthosting their > e-mail through you that their outbound messages contain spam? You don't let them falsify their envelope or headers to contain fields utterly unrelated to your own infrastructure, for starters. They try it, their mail bounces. It's a very rare piece of spam that actually comes from who it says it comes from anymore. Do that before thinking about rate-limiting or any other fanciness, and you've likely licked 90% of the problem right there. A smarthost with a strong "sense of self" backed up by port-25 rules is exactly what I'm talking about, and if certain large providers ever *read* their abuse boxes they'd find the same advice from me in more than one instance followed by a clear example of why. _H*

2 1

Identifying when netblocks have been assigned
by Frank Bulk 13 Sep '08

13 Sep '08

Perhaps there's no answer to this, or it's obvious and I ought to know. How can I find out when ARIN or the applicable registry has assigned a block to a certain organization, and I don't know the block, just the organization. If that's not possible, is there a site/way that has a timeline for the first time a certain AS announced a block? Frank

4 8

Re: New Intercage upstream
by Andrew Clover 13 Sep '08

13 Sep '08

Marco d'Itri wrote: > Look at what else this AS is announcing: Cernel, UkrTeleGroup and Inhoster are all aliases of Esthost. These are their blocks that are physically operated by Intercage, so it's not surprising they're to be found together. PIE is another colo operation housed at the same facility as Intercage (200 Paul Avenue, SF). Their focus appears to be hosting Japanese sites in the US (colo inside Japan itself has historically been quite expensive). They may well be unaware of the nature of their datacentre-neighbours. --

2 1

Re: New Intercage upstream
by md＠Linux.IT 13 Sep '08

13 Sep '08

On Sep 13, "Jon O." <nanog(a)networkcommand.com> wrote: > Looks like this might be somewhat bulletproof, check the other sites off this "AS" > http://www.robtex.com/dns/pacificinternetexchange.net.html#a2 It may be, yes. Look at what else this AS is announcing: http://www.spamhaus.org/sbl/sbl.lasso?query=SBL36453 (cernel/esthost) http://www.spamhaus.org/sbl/sbl.lasso?query=SBL36702 (the infamous UkrTeleGroup network) http://www.spamhaus.org/sbl/sbl.lasso?query=SBL53319 (inhoster) Interested parties can consult http://www.bofh.it/~md/drop-stats.txt (randomly updated, I am still looking for a permanent home for it) for a detailed list of who is announcing the networks listed in SBL DROP, what else they announce and who is providing transit to the ASes announcing them. The code used to generate it is available on request. Hint: there is not just Intercage. -- ciao, Marco

2 1