- NANOG - lists.nanog.org

Any problems with Sprint LasVegas
by Philip Lavine 28 Jun '04

28 Jun '04

Is anybody experiencing issues with Sprint in Ls Vegas? --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage!

1 0

Persistent DNS Zone Transfer Attempts from IP 128.232.0.31
by Jon R. Kibler 28 Jun '04

28 Jun '04

Greetings, Anyone know anything about IP 128.232.0.31? > # host 128.232.0.31 > 31.0.232.128.in-addr.arpa domain name pointer dns-probe.srg.cl.cam.ac.uk. > We have been getting persistent zone transfer attempts that originate from this IP address. We have had repeated zone transfer attempts against all of our DNS zones -- and against all 7 name servers that we manage. This has been going on now for about a month or two -- more or less. Recently, we have also seen attempts to do zone transfers for non-authoritative domains. Logging shows that this IP apparently never attempts to make legitimate DNS queries, only zone transfers. Anyone know anything about this IP? Anyone else have the appropriate logging enabled and also seeing this IP make zone transfer attempts? Thoughts/comments/suggestions? Thanks! Jon -- Jon R. Kibler Chief Technical Officer A.S.E.T., Inc. Charleston, SC USA (843) 849-8214 ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.

4 3

Level 3 Issues?
by Cody Lerum 28 Jun '04

28 Jun '04

Depending on the Yahoo you get...66.218.71.198 traceroute to 66.218.71.198 (66.218.71.198), 30 hops max, 38 byte packets 1 ge-0-3-0-7-1q-4crn-bzn.mt.core.cutthroatcom.net (209.137.232.209) 0.398 ms 0.297 ms 0.315 ms 2 fe-0-0-0-rf-45m-silo-bzn.mt.core.cutthroatcom.net (209.137.235.194) 0.812 ms 0.750 ms 0.642 ms 3 fe-0-0-0-rf-45m-bxt-bzn.mt.core.cutthroatcom.net (209.137.235.202) 1.811 ms 1.593 ms 1.082 ms 4 t3-0-0-3-ta-hln.mt.core.cutthroatcom.net (209.137.235.218) 7.689 ms 6.538 ms 7.005 ms 5 t3-1-2-0.ar2.SEA1.gblx.net (64.211.206.113) 20.444 ms 20.485 ms 18.041 ms 6 so1-1-0-2488M.ar1.SJC2.gblx.net (67.17.64.65) 44.443 ms 41.470 ms 37.794 ms 7 so-4-0-0.edge1.SanJose1.Level3.net (4.68.127.53) 41.383 ms 40.958 ms 41.587 ms 8 so-1-2-0.bbr1.SanJose1.Level3.net (209.244.3.137) 48.844 ms 46.521 ms 41.600 ms 9 ge-9-1.ipcolo3.SanJose1.Level3.net (64.159.2.73) 43.877 ms ge-10-1.ipcolo3.SanJose1.Level3.net (64.159.2.105) 43.767 ms 46.232 ms 10 unknown.Level3.net (64.152.69.30) 476.219 ms 476.244 ms 480.827 ms 11 * UNKNOWN-66-218-82-230.yahoo.com (66.218.82.230) 495.937 ms 12 * alteon4.68.scd.yahoo.com (66.218.68.13) 486.236 ms 495.863 ms Anyone else seeing this? >From www.dnsstuff.com as well Pinging 66.218.71.198 [66.218.71.198]: Ping #1: Got reply from 66.218.71.198 in 551ms [TTL=234] Ping #2: Got reply from 66.218.71.198 in 590ms [TTL=234] Ping #3: Got reply from 66.218.71.198 in 552ms [TTL=234] Ping #4: Got reply from 66.218.71.198 in 550ms [TTL=234] Done pinging 66.218.71.198! -C

1 0

The use of .0/.255 addresses.
by Jonathan McDowell 28 Jun '04

28 Jun '04

Have just spent some time trying to track down what seemed to be an elusive problem, I thought I'd mention it here. I've had problems accessing www.level3.net, www.ebay.co.uk and www.dabs.com (and a few others I don't recall). As I'm the first user of a reasonably new netblock I thought it might be something to do with filters on our upstreams or similar. Trying an IP from our older netblock worked without problems, which seemed to back this up. However eventually I tracked it down to the use of the .0 address from the new netblock; changing to use the .1 address meant I could access the above sites without any difficulty. Various people I've asked about this have said they wouldn't use the .0 or .255 addresses themselves, though couldn't present any concrete info about why not; my experience above would seem to suggest a reason not to use them. J. -- /-\ | This is not a daffodil! This is |@/ Debian GNU/Linux Developer | not a daffodil! \- |

12 15

Re: The use of .0/.255 addresses.
by sthaug＠nethelp.no 27 Jun '04

27 Jun '04

> This is what happens when your educational system continues to teach > classful routing as anything other than a HISTORICAL FOOTNOTE > *coughCiscocough*. Yes, it sure would be nice if Cisco would revise some of their CCNA course material and exams. Plenty of classful stuff still left there, I'm afraid. It's kind of stupid when you have to tell fellow workers trying to get a certification "This isn't real life, you just have to learn it for the exam. In real life we use CIDR." Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

Re: The use of .0/.255 addresses.
by Fergie (Paul Ferguson) 27 Jun '04

27 Jun '04

Amen, brother. - ferg -- Richard A Steenbergen <ras(a)e-gerbil.net> wrote: Do you part to help control the ignorant population: whenever you hear someone say "class [ABC]" in reference to anything other than a historical allocation, smack them. Hard. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

3 2

Teaching/developing troubleshooting skills
by Pete Kruckenberg 26 Jun '04

26 Jun '04

I'm working on trying to teach others in my group (usually less-experienced, but not always) how to improve their large-network troubleshooting skills (the techniques of isolating a problem, etc). It's been so long since I learned network troubleshooting techniques I can't remember how I learned them or even how I used to do it (so poorly). Does anyone have experience with developing a skills-improvement program on this topic? If you've tried such a thing, what worked/didn't work for you? Outside training? Books? Mentoring? Motivational posters? I'm particularly sensitive to the "I got my CCNA, therefore I know everything there is to know about troubleshooting" perspective, and how to encourage improving troubleshooting skills without making it insultingly basic. Thanks for your help. Pete.

5 4

RE: Unplugging spamming PCs
by Larry Pingree 26 Jun '04

26 Jun '04

Authentication and Authorization are two separate and distinct issues. TLS and Authentication have been around for quite a while, but without centralized authorization it will never be deployed by disparate corporations for inter-domain mail! This will not stop spam. Unless of course you want to manage user accounts or certificates with every single customer that you want to have conversations with. Authorization must still be authorized by a third party agency which verifies validity between everyone involved in communications. LP Best Regards, Larry Larry Pingree "Visionary people, are visionary, partly because of the great many things they never get to see." - Larry Pingree -----Original Message----- From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Friday, June 25, 2004 12:14 PM To: Larry Pingree Cc: jshen(a)spymac.com; nanog(a)merit.edu Subject: Re: Unplugging spamming PCs On Fri, 25 Jun 2004 09:11:36 PDT, Larry Pingree said: > > What I am proposing is have a registry that you must register > with before other mail servers will accept mail from you. Similar to how > MAPS RBL works, but the mail server itself, enforces it, rather than a > firewall or a ancillary device ACL. This could be made a standard of > SMTP. Yet another "it won't do any good till everybody deploys it". http://www.rhyolite.com/anti-spam/you-might-be.html

3 2

Question from NETCONF working group
by Rob Enns 25 Jun '04

25 Jun '04

Hi, The IETF's NETCONF WG is trying to select a retrieval filter mechanism for use with <get-config> and <get> operations. The fundamental issue is whether to use a subset of the XPath language or whether to define a mechanism based on XML subtree matching. Your comments can help us decide which propsal to choose. Here's the basic NETCONF <get> protocol operation exchange: <rpc message-id="101" xmlns="netconf-uri"> <get> <filter filter-type="filter-uri"> ... filter data ... </filter> </get> </rpc> <rpc-reply message-id="101" xmlns="netconf-uri"> <data> ... XML selected by the filter criteria ... </data> </rpc-reply> There are two options under consideration for the mandatory filter mechanism (i.e., standard values for the 'filter-type' attribute). If we can't get consensus on the mandatory to implement filter, then we will probably make both optional. A) XML sub-tree filtering A mechanism that allows exact match of element and attribute content, as well as the selection of specific subtrees. (This is implemented in Junoscript.) B) Xpath subset A small subset of the Xpath standard that provides essentially the same (or more) filtering functions as the subtree filter. (Note that full implementation of the Xpath 1.0 standard will be optional, and identified by the #xpath capability.) Operator and application programmer preference is really the deciding factor here. Approach (A) uses XML encoding that looks like the data model XML that will be returned in the response. Approach (B) uses an Xpath string encoding in the request, and the corresponding XML is returned in the response. Here are some example requests in both formats, followed by the response that would be returned in both cases. ------------------------------------------------------------------------ - E1) Select the entire <users> sub-tree Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree-uri"> <users xmlns="http://example.com/schema-1"/> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-1"/> t://users </filter> </data> </get> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <users xmlns="http://example.com/schema-1"> <user> <name>root</name> <type>superuser</type> <full-name>Charlie Root</full-name> <company-info> <dept>1</dept> <id>1</id> </company-info> </user> <user> <name>fred</name> <type>admin</type> <full-name>Fred Flintstone</full-name> <company-info> <dept>2</dept> <id>2</id> </company-info> </user> <user> <name>barney</name> <type>admin</type> <full-name>Barney Rubble</full-name> <company-info> <dept>2</dept> <id>3</id> </company-info> </user> </users> </data> </rpc-reply> ------------------------------------------------------------------------ - E2) Select all 'name' elements within the 'users' sub-tree Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree-uri"> <users xmlns="http://example.com/schema-1"> <user> <name/> </user> </users> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-1"> t://users/user/name </filter> </data> </get> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <users xmlns="http://example.com/schema-1"> <user> <name>root</name> </user> <user> <name>fred</name> </user> <user> <name>barney</name> </user> </users> </data> </rpc-reply> ------------------------------------------------------------------------ - E3) One specific <user> entry Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree"> <users xmlns="http://example.com/schema-1"> <user> <name>fred</name> </user> </users> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-1"> t://users/user[name="fred"] </filter> </data> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <users xmlns="http://example.com/schema-1"> <user> <name>fred</name> <type>admin</type> <full-name>Fred Flintstone</full-name> <company-info> <dept>2</dept> <id>2</id> </company-info> </user> </users> </data> </rpc-reply> ------------------------------------------------------------------------ - E4) Specific elements from a specific <user> entry Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree"> <users xmlns="http://example.com/schema-1"> <user> <name>fred</name> <type/> <full-name/> </user> </users> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-1"> t://users/user[name="fred"]/name | t://users/user[name="fred"]/type | t://users/user[name="fred"]/full-name </filter> </data> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <users xmlns="http://example.com/schema-1"> <user> <name>fred</name> <type>admin</type> <full-name>Fred Flintstone</full-name> </user> </users> </data> </rpc-reply> ------------------------------------------------------------------------ - C.7) Multiple sub-trees Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree"> <users xmlns="http://example.com/schema-1"/> <user> <name>root</name> <company-info/> </user> <user> <name>fred</name> <company-info> <id/> </company-info> </user> <user> <name>barney</name> <type>superuser</type> <company-info> <dept/> </company-info> </user> </users> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-1"> t://users/user[name="root"]/company-info | t://users/user[name="fred"]/company-info/id | t://users/user[name="barney" and type="superuser"]/company-info </filter> </data> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <users xmlns="http://example.com/schema-1"/> <user> <name>root</name> <company-info> <dept>1</dept> <id>1</id> </company-info> </user> <user> <name>fred</name> <company-info> <id>2</id> </company-info> </user> </users> </data> </rpc-reply> ------------------------------------------------------------------------ - C.8) Table with attribute naming Request: (A) subtree <rpc message-id="101" xmlns="netconf-uri"> <get> <data> <filter filter-type="subtree"> <t:interfaces xmlns:t="http://example.com/schema-2"/> <t:interface t:ifName="eth0"/> </t:interfaces> </filter> </data> </get> </rpc> (B) xpath <rpc message-id="101" xmlns="netconf-uri"> <data> <filter filter-type="xpath-subset-uri" xmlns:t="http://example.com/schema-2"> t://interfaces/interface/[@ifName="eth0"] </filter> </data> </rpc> Reply: <rpc-reply message-id="101" xmlns="netconf-uri"> <data> <t:interfaces xmlns:t="http://example.com/schema-2"> <t:interface t:ifName="eth0"> <t:ifInOctets>45621</t:ifInOctets> <t:ifOutOctets>774344</t:ifOutOctets> </t:interface> </t:interfaces> </data> </rpc-reply>

1 0

Can a customer take IP's with them?
by Alex Rubenstein 25 Jun '04

25 Jun '04

Should a customer be allowed to force a carrier to allow them to announce non-portable IP space as they see fit to any other carriers of their choosing when they are no longer buying service from the original carrier [that the space is assigned to]? According to ARIN regulations, the space does not "belong" to us but we have the right to assign or revoke the space to our customers as we see fit. In addition ARIN regulations specifically prohibit us from transferring or selling the IP space to another customer (even if we want to). NAC has a customer who is leaving NAC. As part of normal procedure (and also because the space provided to us by ARIN is non portable), the customer has been informed that the IP space used by the customer will not be available to be used by the customer subsequent to them leaving us. It should be mentioned that the following facts exist, and cannot be disputed: a) customer has obtained space directly from ARIN over a year ago, but has chosen not to renumber from space allocated from us. This was solely their choice, and we did not restrict this in any way. b) customer is exercising the right not to renew the business agreement, and is leaving NAC voluntarily. Thus, they are attempting to file for and obtain a temporary restraining order (TRO), and ask for the following: -- start -- "NAC shall permit CUSTOMER to continue utilization through any carrier or carriers of CUSTOMER's choice of any IP addresses that were utilized by, through or on behalf of CUSTOMER under the current agreement during the term thereof (the "Prior CUSTOMER Addresses") and shall not interfere in any way with the use of the Prior CUSTOMER Addresses, including, but not limited to: (i) by reassignment of IP address space to any customer; aggregation and/or BGP announcement modifications (ii) by directly or indirectly causing the occurrence of superseding or conflicting BGP Global Routing Table entries; filters and/or access lists, and/or (iii) by directly or indirectly causing reduced prioritization of access to and/or from the Prior CUSTOMER Addresses. NAC shall provide CUSTOMER with a LOA within 7 days of CUSTOMERS's written request for sale, NAC shall permit announcement of the Prior CUSTOMER Address to ANY carrier, IP transit, or IP peering network." -- end -- In other words, customer is asking a court to rule whether or not IP space should be portable, when an industry-supported organization (ARIN) has made policy that the space is in fact not portable. It can be further argued that the court could impose a TRO that would potentially negatively affect the operation of my network. NAC does not want to be forced to rely on a customer's ability to properly make complex routing updates that if done improperly could disrupt the entire NAC network. We believe there is a great danger to NAC that their routing mistakes could take down some or all of our network infrastructure. Another VERY important issue to bring up: If customer is granted the legal right to continue to use IP space that is registered to NAC by ARIN, NAC runs into the very serious problem of being liable for all of the Spam that could be generated by the customer and all of the RBLs that the carrier may be added to [that of course will effect all of NAC's customers] with no ability to revoke the IP space to protect itself. This has to potential to effect the NAC network in a catastrophic manner. I'd love any comments from anyone.

19 27