- NANOG - lists.nanog.org

IDIG subscription message error
by Sean Donelan 18 Nov '98

18 Nov '98

When subscribing to the LISTSERV for the IDIG lists, the subscription message will include information about a WWW interface. Please ignore those paragraphs. The Web interface hasn't been set up, only the e-mail interface. Please e-mail the "ok" command as described in the subscription confirmation message. Sorry, but my LISTSERV guys have left for today and I haven't figured out how to change the subscription message file in LISTSERV. Actually, I haven't even found where it stores it yet. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

IPF.NET has currently problems at MAE-EAST / WEST
by Jan Czmok 18 Nov '98

18 Nov '98

Currently we have problems with our Ethernet Connections on our Switches at MAE-EAST and MAE-WEST. Currently no ETA. We keep you informed about changes and news. We will be still routed over our uplinks from germany. Greetings Jan Czmok IPF.NET Senior Network Engineer

1 0

Re: Cache-as-cache-can
by Paul Vixie 17 Nov '98

17 Nov '98

stevenh(a)inet.unisource.nl (steven hessing) writes: > There seem to be three solutions for transparent web-caching: > 1 a web-cache between two routers, all traffic is routed through it. > 2 a l4 switch between two routers, all traffic is routed through it. > The l4 switch redirects web-requests to a www-cache. > 3 a web-cache connected to a router which uses policy routing to > direct web-requests to it. There's a fourth. I used to manufacture something called the Web Gateway Interceptor which was topologically a router. It wasn't competitive as a router, either in price, performance, or number/kind of interfaces. But you could put it in parallel with another router and integrate it into your OSPF mesh and use OSPF link costs to make it be the primary path only while it was up. HSRP would have worked the same way, and I'll admit that it's a lot simpler to do (though I'm not sure it's an open standard yet?) -- Paul Vixie <paul(a)vix.com>

1 0

AS_PATH length and route selection (WAS: Strange BGP announcement)
by I Am Not An Isp 17 Nov '98

17 Nov '98

At 06:03 PM 11/17/98 -0500, Vijay Gill wrote: >You appear to have misunderstood the problem. The issue has nothing to do >with route selection, or are you talking about FastPath(TM, Pat Pending) >here? Cute, Vijay. Really cute. Of course, if everyone had only licenced it, we wouldn't have this problem now, would we? :p >The issue is that an invalid as-path attribute was injected from >somewhere. The cisco as-path sanity check code failed to pick it up. [SNIP] I have not misunderstood the problem, you have misunderstood my response. Someone posted that the routers should follow the RFC. I was commenting that you should be careful what you wish for. If we magically made all routers strictly conform to the RFC instantly, it would have solved this particular problem, but it would have caused *much* larger problems for the 'Net at large. I was also hoping to start a debate by those more knowledgeable than I about the ... wisdom of intentionally removing what is currently far and away the most used metric for route selection from the next version of BGP; namely: AS_PATH length. (At least I was under the impression that AS_PATH length was the used more than all other metrics combined for route selection in the backbone.) RFC1771 does not list AS_PATH length as a selection criteria - but at least RFC1771 does not specifically forbid use of AS_PATH length, as the draft for the next version does. Or perhaps I'm just misinformed. I have not actually read the draft for BGP 4+ (or whatever they're calling it now). This is second hand information, but I consider it to be from a very reliable source (even if he doesn't like ciscos ;). I am also not saying removal of this metric is a gigantic mistake, but my thought process to date leads me to tentatively believe it would be ... suboptimal. However, the people writing the spec obviously know more about it than I do, perhaps I've overlooked something. So, would anyone care to discuss (from an operational POV) what removing AS_PATH length from the BGP route selection algorithm will do to the Internet? >/vijay TTFN, patrick P.S. Before anyone goes off on me, I once again *agree* that the least cisco could do is deal with malformed announcements and the errors they generate properly. There are just other parts of the RFC with which I'm not so sure I agree. I Am Not An Isp www.ianai.net "Think of it as evolution in action." - Niven & Pournelle

2 1

IDIG-L Internet Distrubance Investigative Group mailing list
by Sean Donelan 17 Nov '98

17 Nov '98

I have set up a yet another mailing list (don't you just hate those words).... to discuss setting up an Internet Disturbance analysis forum. The most important thing is a catchy name. I came up with "IDIG", pronounced (eye-dig). For non-native english speakers it is a pun on "digging for answers" a slang term for some investigative methods, or it may refer to our mechanical backhoe friends which also "dig" either of which may be appropriate. I thought ITSB (a take off of the US NTSB, National Traffic Safety Board) would be asking for trouble. I believe I missed the IETF cut-off dates for a BOF, so if we did come up with something it would be at least the following meeting before it hit the IETF. It is actually two lists IDIG-L Internet Disturbance Analaysis Group Discussion An open (must subscribe to post) discussion list IDIG-ANNOUNCE Internet Disturbance Analaysis Group Announcements An moderated list LISTSERV instructions (yes, it is a real LISTSERV) send mail to "listserv(a)listserv.dra.com" containing the line SUBSCRIBE IDIG-L Your Name SUBSCRIBE IDIG-ANNOUNCE Your Name as always, replacing "Your Name" with your name. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Strange BGP announcement
by Enke Chen 17 Nov '98

17 Nov '98

Andrew, > In each case the ASPath attribute says it consists of an AS_SEQUENCE of > N ASes, but the data only shows N-1 ASes. Yep, an invalid as-path attribute was injected from somewhere. Our as-path sanity check code failed to catch this case. We have opened the following ddts: ====== Bug ID : CSCdk63586 Project: CSC.sys Status : O 3 encls Product : all Found : customer-use Care Update: N Versions : 11.1CC Headline : BGP: Tighten as-path sanity check -- Release-note -- When the total bytes (2*seglen) of an as-path segment is equal to the as-path attribute length, the as-path sanity check would fail and such a bad attribute would be accepted. The workaround is to identify and get rid of the announcement of prefixes with the bad attributes. ====== We have a fix and it is is being reviewed. -- Enke ---------------------------------------------------------------------------- * To: "Craig A. Huegen" <chuegen(a)quadrunner.com> * Subject: Re: Strange BGP announcement. * From: Andrew Bangs <andrewb(a)demon.net> * Date: Mon, 9 Nov 1998 13:24:55 +0000 (GMT) * Cc: nanog(a)merit.edu * Content-Transfer-Encoding: 7bit * Content-Type: text/plain; charset=US-ASCII * In-Reply-To: <19981108143028.A8630(a)quadrunner.com> from "Craig A. Huegen" at Nov 8, 98 02:30:28 pm * Sender: owner-nanog(a)merit.edu ---------------------------------------------------------------------------- Craig A. Huegen wrote: > > After looking over the RFC, I see that 0 can be used for non-routed > networks, so no one's implementation should be hanging up on it. I agree. I'm not sure that that is what is happening, though.... see below. > > (Regardless, the use of AS 0 as a prepend should be discouraged =) Yup. However, I'm not seeing AS0 in the stuff I posted: > > ==>==>> Nov 8 17:45:26 BGP RECV flags 0x40 code ASPath(2): (0x02 0x07 0x0f 0x7f 0x02 0xbd 0x0d 0xa5 0x03 0x30 0x03 0x2f 0x03 0x2e) John Scudder at IENG gave me the clue by decoding the above ASPath: 0x02 = AS_SEQUENCE 0x07 = 7 ASes in sequence 0x0f7f = 3967 0x02bd = 701 0x0da5 = 3493 0x0330 = 816 0x032f = 815 0x032e = 814 and I decided to take a closer look at the other's I'd logged: Nov 8 19:29:35 BGP RECV flags 0x40 code ASPath(2): (0x02 0x08 0x18 0xcb 0x0d 0xe9 0x02 0xbd 0x0d 0xa5 0x03 0x30 0x03 0x2f 0x03 0x2e) 0x02 AS_SEQUENCE 0x08 8 ASes in sequence 0x18cb 6347 0x0de9 3561 0x02bd 701 0x0da5 3493 0x0330 816 0x032f 815 0x032e 814 Nov 8 16:56:32 BGP RECV flags 0x40 code ASPath(2): (0x02 0x03 0x18 0xcb 0x0d 0xe9) 0x02 AS_SEQUENCE 0x03 3 ASes in sequence 0x18cb 6347 0x0de9 3561 In each case the ASPath attribute says it consists of an AS_SEQUENCE of N ASes, but the data only shows N-1 ASes. Could it be that your router somehow 'pads' the tail of the AS_PATH with enough zeros until it makes the right length ? I think it's hiding the truth from you. When I was talking through the problem with one of my upstreams they mentioned 'AS0' at the end of the AS_PATH. It seems that their routers were happy to pad the AS to the right length internally, but the Update that was sent to my router was definitely malformed (and not padded with AS0) which caused a (correct IMHO) NOTIFY message to be sent back. Did anyone else capture any problematic Update messages yesterday ? Do they show the same problem ? I'm beginning to believe that this is a bug in at least the Cisco BGP implementation (since that's what my upstreams use to peer with me). (I haven't seen any mention of how the bad routes got into the world in the first place. Anyone know ?) Regards, Andrew -- Andrew Bangs, Network Engineering Manager, Demon Internet Ltd andrewb(a)demon.net http://www.demon.net/ http://www.demon.nl/ Network Engineering: +44 (0)181 371 1204 networks(a)demon.net ---------------------------------------------------------------------------- * References: o Re: Strange BGP announcement. + From: "Craig A. Huegen" <chuegen(a)quadrunner.com> ---------------------------------------------------------------------------- * Prev: Cisco IOS 12.0 x 11.1CC * Next: Re: Strange BGP announcement. * Index(es): o Main o Thread [ Merit | Subject Index ]

6 8

Re: Exodus: this is bad
by Kevin Houle 17 Nov '98

17 Nov '98

-----BEGIN PGP SIGNED MESSAGE----- The CERT Coordination Center is aware of the widespread scanning activity which has been discussed in the past 24 hours on the NANOG mailing list. The CERT/CC has published two incidents note containing details about scanning techniques which may be of interest. * IN-98.04, "Advanced Scanning" http://www.cert.org/incident_notes/IN-98.04.html * IN-98.02, "New Tools Used for Widespread Scans" http://www.cert.org/incident_notes/IN-98.02.html Based on the reports we have received directly, the activity appears to fall within the scope of these two documents. If there is activity which appears to be different than what's covered in these documents, we'd certainly like to receive detailed reports from sites involved. In general, we encourage sites to report scanning activity to the CERT/CC to aid us in understanding the nature and scope of security incidents on the Internet. Our incident reporting guidelines can be found at: http://www.cert.org/tech_tips/incident_reporting.html Regards, Kevin - -- Kevin J. Houle Technical Coordinator _________________________________________________________ CERT* Coordination Center | cert(a)cert.org Software Engineering Institute | Hotline: +1-412-268-7090 Carnegie Mellon University | Fax: +1-412-268-6989 - --------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: PGP for Business Security 5.5 iQCVAwUBNlHrn3VP+x0t4w7BAQEvfAP/TbrJozmQZ/4UUrn/pCO7QiSrTzla74YK NLy1o1hkbmsPOSU91x0ShqG0CKGjlaZu+DQrEnJHJY7q1zgUa+UVF/CPNvRGJhyc MpbOa1ZgSy1wVhS5FCKbc0kBDcgQVDgjvfkizSgX38RlCviGN5jaaQgsutimRfFT 8LVFgFS2Rig= =rUg5 -----END PGP SIGNATURE-----

1 0

Re: RBL quandry - opinions hereby solicited
by Paul Vixie 17 Nov '98

17 Nov '98

> it's spam. in my humble opinion, paul, they should be warned that they are > in danger of being added to the blackhole list...if and only because so > many of us DO have to rely on them. we don't rely on the server they use to send this spam, though. if we have to blackhole that one server, it will NOT affect their registry functions. a little bit of work with "show ip bgp" on a core router will demonstrate that "netsol" and "internic" have different connectivity -- different address blocks, different autonomous system numbers, and different transit connections. fyi, we're now in discussions with their sales/marketing management. they have agreed to stop sending this type of mail until at least the conclusion of our discussions with them. i view this as the best possible outcome, far better than blackholing them. (though that possibility still exists, if they won't change their marketing practices.) now as to whether they own the data they resell, or whether they're abusing public funds or trust, or whether they're trying to take over the internet, hell i don't know any more than the rest of you. but those are not the reasons they'd be blackholed so i don't need to know any more than i do. -- Paul Vixie <paul(a)vix.com>

2 1

Re: Journal of Internet Disasters
by Dave Crocker 17 Nov '98

17 Nov '98

At 10:20 AM 11/15/98 -0500, Deborah Ann Smith wrote: >But We as an industry and consumers need to start demanding - via writing >to the congress people (They will read letters, not email- and they will >listen if enough people contact them), complaints to the FCC and other The Internet is global, rather than subject strictly to US controls. Much more importantly is that the Internet has done quite well, over the last 10 years, with LESS government involvement, not more. That does not mean no oversight. It merely means finding non-governmental methods of achieving the oversight. I suggest, for example, that a competent and careful effort of the type Sean is suggesting would go a long, long way towards helping things, by providing public and clear explanations of problems. Yes, it is possible that some ISPs would choose to ignore the public disclosure, but let's worry about that problem after give simple, public discourse a try. Such an approach has a good track on the Internet. d/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Dave Crocker Tel: +60 (19) 3299 445 <mailto:dcrocker@brandenburg.com> Post Office Box 296, U.P.M. Serdang, Selangor 43400 MALAYSIA Brandenburg Consulting <http://www.brandenburg.com> Tel: +1 (408) 246 8253 Fax: +1(408)273 6464 675 Spruce Dr., Sunnyvale, CA 94086 USA

3 2

Here's the new Netsol Target...
by Rodney Joffe 17 Nov '98

17 Nov '98

Netsol has just announced a new Director of Marketing for its consulting division... Jeffrey W. Johnson, From Bell Atlantic. Perhaps you'd like to send him a welcome message? http://biz.yahoo.com/bw/981117/network_so_2.html

2 1