- Test - lists.nanog.org

I-D on operational MTU/fragmentation issues in tunneling
by Pekka Savola 19 Oct '04

19 Oct '04

Hi all, I've written a very short (about 5 pages of meat) Internet-Draft describing the issues and operational approaches to the problems faced with doing tunneling in the network -- as these issues kept coming up again and again with IP-in-IP, GRE, L2TP, etc. The approaches may be different for passive monitoring ('wiretapping' etc.) and 'active' tunneling. The document is about to be IETF Last Called for Informational RFC, but prior to that, I'd like to solicit comments/feedback/review from the people here because I'm 100% sure a lot of people have been faced with these issues (we certainly have..). Please send comments to me by the end of this week, either on- of off-list, as you deem appropriate. Find it at: http://www.ietf.org/internet-drafts/draft-savola-mtufrag-network-tunneling-… Abstract Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided. This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

7 9

Enterprise Access Log Scanning Tools
by Cullen, Michael 19 Oct '04

19 Oct '04

Greetings all, Does anyone have (1) any experience, (2) any suggestions, or (3) an appropriate contact to these types of tools? The requirements include ACE and NT Domain access logs. Thank You, Michael Cullen Senior Security Engineer Technical Architecture, Policy and Web Services Universal Music Group (818) 777-4049

1 0

Philadelphia MCI/UU PoP?
by Dave Temkin 19 Oct '04

19 Oct '04

Does anyone know the address of the Philadelphia MCI/UU (legacy?) POP? Replies off list are fine. Thanks, -Dave

2 1

People being removed from the list and such
by Malayter, Christopher 19 Oct '04

19 Oct '04

It has come to my attention that recently several people have been censored from posting to the nanog@ list. I find it a bit unusual that from such an open discussion list that membership would be censored without notice and reason to the rest of the membership. I wouldn't normally be the one to post this, but the people who have been censored in some cases I believe to be extremely valuable people to the list. My question is this: When people are removed/censored, be it temporary or permanent, could we have a notice posted to the membership as to the person, reason, and duration? Also, I realize that this sounds odd, could we add an appeals process? The idea of a single person with unilateral control over such a group, without taking into consideration the needs and desires of the group, does not seem fair. I believe that there is need for recourse in this community for a person who is removed or censored unfairly. Regards, Chris Malayter TDS Telecom - Network Services Network Management and Operations chris.malayter(a)tdstelecom.com Phone: (608) 664-4878 FAX: (608) 664-4644

9 8

RE: Level 3 US east coast "issues"
by Niaz, Wajahat 19 Oct '04

19 Oct '04

Level3 had issues while upgrading the code on their Junipers. According to their tech support they have isolated those routers and things should be normal. Wajahat -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mike Callahan Sent: Tuesday, October 19, 2004 9:46 AM To: nanog(a)nanog.org Subject: RE: Level 3 US east coast "issues" Anyone have the latest update on this? We seem to still be experiencing routing issues from Level3 this morning and we never did get notification from them that the previously reported issue had been resolved. Thanks, Mike Callahan -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Grant A. Kirkwood Sent: Monday, October 18, 2004 12:15 PM To: nanog(a)nanog.org Subject: Level 3 US east coast "issues" Level 3 experiencing widespread "unspecified routing issues" on the US east coast. Master ticket 1086844. Anyone have more specific information? -- Grant A. Kirkwood - grant(at)tnarg.org Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED

1 0

RE: Level 3 US east coast "issues"
by Mike Callahan 19 Oct '04

19 Oct '04

Anyone have the latest update on this? We seem to still be experiencing routing issues from Level3 this morning and we never did get notification from them that the previously reported issue had been resolved. Thanks, Mike Callahan -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Grant A. Kirkwood Sent: Monday, October 18, 2004 12:15 PM To: nanog(a)nanog.org Subject: Level 3 US east coast "issues" Level 3 experiencing widespread "unspecified routing issues" on the US east coast. Master ticket 1086844. Anyone have more specific information? -- Grant A. Kirkwood - grant(at)tnarg.org Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED

1 0

ICMP weirdness
by Jim Popovitch 19 Oct '04

19 Oct '04

>From Comcast Cable, at my home in Atlanta, I can ping 10.10.1.1.... which is pong'ed from a private client network hanging somewhere off of Insight Broadband's network in the North Central part of the US. Why on god's green earth do network operators allow such nonsense as this? -Jim P. Traceroute -I 10.10.1.1 produces the following: traceroute to 10.10.1.1 (10.10.1.1), 30 hops max, 38 byte packets 1 10.238.10.1 (10.238.10.1) 29.089 ms 25.387 ms 28.574 ms 2 66.56.22.66 (66.56.22.66) 30.923 ms 31.305 ms 33.142 ms 3 66.56.22.70 (66.56.22.70) 35.945 ms 35.874 ms 36.832 ms 4 c-66-56-23-38.atl.client2.attbi.com (66.56.23.38) 34.740 ms 35.041 ms 37.537 ms 5 12.118.184.41 (12.118.184.41) 41.967 ms 45.584 ms 43.997 ms 6 gbr2-p70.attga.ip.att.net (12.123.21.6) 44.988 ms 44.706 ms 43.033 ms 7 tbr2-p013602.attga.ip.att.net (12.122.12.37) 49.353 ms 44.010 ms 45.244 ms 8 12.122.10.138 (12.122.10.138) 62.244 ms 62.269 ms 62.148 ms 9 gbr1-p40.sl9mo.ip.att.net (12.122.11.114) 60.922 ms 67.005 ms 60.264 ms 10 gar1-p360.sl9mo.ip.att.net (12.123.24.209) 59.572 ms 64.013 ms 60.198 ms 11 12-220-0-69.client.insightBB.com (12.220.0.69) 77.000 ms 76.050 ms 77.926 ms 12 12-220-7-198.client.insightBB.com (12.220.7.198) 95.437 ms 80.068 ms 84.076 ms 13 10.10.1.1 (10.10.1.1) 93.612 ms 97.280 ms 192.994 ms

4 3

Re: ICMP weirdness
by Robert Bonomi 18 Oct '04

18 Oct '04

> From owner-nanog(a)merit.edu Mon Oct 18 16:01:42 2004 > Subject: Re: ICMP weirdness > From: Jim Popovitch <jimpop(a)yahoo.com> > To: "Stephen J. Wilcox" <steve(a)telecomplete.co.uk> > Cc: nanog(a)merit.edu > Date: Mon, 18 Oct 2004 17:01:39 -0400 > > > On Mon, 2004-10-18 at 15:54, Stephen J. Wilcox wrote: > > why not that seems ok to me.. ? > > > > assuming you accept the 1918 assignment to your cable then its not unreasonable > > that you can get to other end users on that network > > Across other non-private IP space? I am not all that familiar w/ > RFC1918, but I would think that this goes against it, or should I assume > that Insight Broadband is part of Comcast? It appears likely that that _is_ the case. It is numbered in historical 'Class A' space that AT&T owns. Comcast did buy up a bunch of AT&T's cable operations. Both the cable TV _and_ the internet services. By strict definitions, your home is a _separate_ network from Comcast's internal network. As such: Per RFC 1918, _you_ should be doing egress filtering, to prohibit RFC 1918 _destination_ addresses from exiting your network _to_ Comcast's network, as well as egress filtering of RFC 1918 _source_ address packets (with a few special-case exceptions), to be a 'good neighbor'. In self- defense, you should be ingress filtering any RFC 1918 destination addresses, and any RFC 1918 source addressed packets (except for the special-case exectptions -- ICMP redirect, unreachable, TTL exceeded, etc.). Similarly, Comcast should be at the 'gateway' to your network, be =egress= filtering any packets with RFC 1918 destination addresses, as well as any RFC 1918 source address packets (except for the aforementioned special-case exceptions) The should *also*, be _ingress_ filtering any RFC 1918 destination addresses coming from your network, _and_ filtering out any RFC 1918 _source_ address packets (with the same few special-case execptions) from your network. RFC 1918 restricts use of the 'private' address-blocks to networks under a _single_ administrative control. It is perfectly legitimate to use different segments of that address-space in different locations *on*the* *same*network*, even _with_ 'routable' addresses in between them. The RFC 1918 rule is that the 'private' addresses must not escape _from_ the network under the adminsistrative control of that party to a network that is controlled by 'somebody else'. That said, a *LOT* of the world doesn't use 'strict' definitions. Unfortunately. Comcast apparently considers the end-user machines as simply nodes _on_their_ _network_. And, as such, does route RFC 1918 addresses 'internally' between different locales, where different portions of that address-space are used _on_the_Comcast_network_. > > -Jim P. > > > > > Steve > > > > On Mon, 18 Oct 2004, Jim Popovitch wrote: > > > > > > > > >From Comcast Cable, at my home in Atlanta, I can ping 10.10.1.1.... > > > which is pong'ed from a private client network hanging somewhere off of > > > Insight Broadband's network in the North Central part of the US. Why on > > > god's green earth do network operators allow such nonsense as this? > > > > > > -Jim P. > > > > > > Traceroute -I 10.10.1.1 produces the following: > > > > > > traceroute to 10.10.1.1 (10.10.1.1), 30 hops max, 38 byte packets > > > 1 10.238.10.1 (10.238.10.1) 29.089 ms 25.387 ms 28.574 ms > > > 2 66.56.22.66 (66.56.22.66) 30.923 ms 31.305 ms 33.142 ms > > > 3 66.56.22.70 (66.56.22.70) 35.945 ms 35.874 ms 36.832 ms > > > 4 c-66-56-23-38.atl.client2.attbi.com (66.56.23.38) 34.740 ms 35.041 > > > ms 37.537 ms > > > 5 12.118.184.41 (12.118.184.41) 41.967 ms 45.584 ms 43.997 ms > > > 6 gbr2-p70.attga.ip.att.net (12.123.21.6) 44.988 ms 44.706 ms > > > 43.033 ms > > > 7 tbr2-p013602.attga.ip.att.net (12.122.12.37) 49.353 ms 44.010 ms > > > 45.244 ms > > > 8 12.122.10.138 (12.122.10.138) 62.244 ms 62.269 ms 62.148 ms > > > 9 gbr1-p40.sl9mo.ip.att.net (12.122.11.114) 60.922 ms 67.005 ms > > > 60.264 ms > > > 10 gar1-p360.sl9mo.ip.att.net (12.123.24.209) 59.572 ms 64.013 ms > > > 60.198 ms > > > 11 12-220-0-69.client.insightBB.com (12.220.0.69) 77.000 ms 76.050 > > > ms 77.926 ms > > > 12 12-220-7-198.client.insightBB.com (12.220.7.198) 95.437 ms 80.068 > > > ms 84.076 ms > > > 13 10.10.1.1 (10.10.1.1) 93.612 ms 97.280 ms 192.994 ms > > > > > > > > > >

1 0

Re: ICMP weirdness
by Jim Popovitch 18 Oct '04

18 Oct '04

On Mon, 2004-10-18 at 15:54, Stephen J. Wilcox wrote: > why not that seems ok to me.. ? > > assuming you accept the 1918 assignment to your cable then its not unreasonable > that you can get to other end users on that network Across other non-private IP space? I am not all that familiar w/ RFC1918, but I would think that this goes against it, or should I assume that Insight Broadband is part of Comcast? -Jim P. > > Steve > > On Mon, 18 Oct 2004, Jim Popovitch wrote: > > > > > >From Comcast Cable, at my home in Atlanta, I can ping 10.10.1.1.... > > which is pong'ed from a private client network hanging somewhere off of > > Insight Broadband's network in the North Central part of the US. Why on > > god's green earth do network operators allow such nonsense as this? > > > > -Jim P. > > > > Traceroute -I 10.10.1.1 produces the following: > > > > traceroute to 10.10.1.1 (10.10.1.1), 30 hops max, 38 byte packets > > 1 10.238.10.1 (10.238.10.1) 29.089 ms 25.387 ms 28.574 ms > > 2 66.56.22.66 (66.56.22.66) 30.923 ms 31.305 ms 33.142 ms > > 3 66.56.22.70 (66.56.22.70) 35.945 ms 35.874 ms 36.832 ms > > 4 c-66-56-23-38.atl.client2.attbi.com (66.56.23.38) 34.740 ms 35.041 > > ms 37.537 ms > > 5 12.118.184.41 (12.118.184.41) 41.967 ms 45.584 ms 43.997 ms > > 6 gbr2-p70.attga.ip.att.net (12.123.21.6) 44.988 ms 44.706 ms > > 43.033 ms > > 7 tbr2-p013602.attga.ip.att.net (12.122.12.37) 49.353 ms 44.010 ms > > 45.244 ms > > 8 12.122.10.138 (12.122.10.138) 62.244 ms 62.269 ms 62.148 ms > > 9 gbr1-p40.sl9mo.ip.att.net (12.122.11.114) 60.922 ms 67.005 ms > > 60.264 ms > > 10 gar1-p360.sl9mo.ip.att.net (12.123.24.209) 59.572 ms 64.013 ms > > 60.198 ms > > 11 12-220-0-69.client.insightBB.com (12.220.0.69) 77.000 ms 76.050 > > ms 77.926 ms > > 12 12-220-7-198.client.insightBB.com (12.220.7.198) 95.437 ms 80.068 > > ms 84.076 ms > > 13 10.10.1.1 (10.10.1.1) 93.612 ms 97.280 ms 192.994 ms > > > > > >

2 1

RE: Level 3 US east coast "issues"
by Chris Ranch 18 Oct '04

18 Oct '04

> Sent: Monday, October 18, 2004 9:32 AM PDT > > Level3 states that they have isolated the problem down to equipment in > their Washington DC Point of Presence. They believe that they have > resolved the problem and things should be normalizing in > their network.

1 0