- NANOG - lists.nanog.org

Ethernet LayerOne Dallas
by Beprojects.com 13 Jan '04

13 Jan '04

If there are any sales-types that can offer Ethernet connectivity at the LayerOne facility on Bryan St in Dallas, please contact me off-list. Thanks.

2 1

NISCC vulnerability note, Cisco advisory on H.323 issues
by Huopio Kauto 13 Jan '04

13 Jan '04

Following documents are recommended reading: http://www.uniras.gov.uk/vuls/2004/006489/h323.htm http://www.cisco.com/warp/public/707/cisco-sa-20040113-h323.shtml --Kauto Kauto Huopio - kauto.huopio(a)ficora.fi Information Security Adviser / CERT-FI -coordinator Finnish Communications Regulatory Authority / CERT-FI tel. +358-9-6966772, fax. +358-9-6966515 CERT-FI duty desk +358-9-6966510 / http://www.cert.fi

1 0

RE: GSR, 7600, Juniper M?, oh my!
by Jason Frisvold 13 Jan '04

13 Jan '04

> -----Original Message----- > From: Alex Rubenstein [mailto:alex@nac.net] > > On the 7500, you have RSPs and VIPs; the former performing routing > protocol work, vty's, RIB's, etc., the latter doing actually packet > forwarding. While this sounds great on paper, our experience has us shying away from dCEF and looking for something bigger and better... dCEF pushed the RSP processor down to about 5%, but pushed up the VIP processors to about 90-95%... > VIP-Slot0>sh proc c > CPU utilization for five seconds: 13%/12%; one minute: 14%; five minutes: > 15% I wish we could get our routers to do this... > Obviously, we run dCEF, which puts the VIP's in the position of forwarding > everything on their own, as evidenced by the CPU measurements. But each VIP is responsible for it's own traffic, so if a particular VIP runs most of the traffic, it has much higher CPU usage... In our case, we have a router loaded with VIP 4-50's and Enhanced ATM OC-3 adapters... Originally, we had a single OC-3 running about 120-130 Megs constant and the VIP CPU was at 90-95%.... To combat this, we had to put in additional OC-3 cards with additional VIPs and distribute the load... Still, high CPU is a problem .. For instance : CPU utilization for five seconds: 63%/63%; one minute: 63%; five minutes: 65% 30 second input rate 78227000 bits/sec, 17858 packets/sec 30 second output rate 47944000 bits/sec, 12778 packets/sec It seems to me that we should be able to do sooo much better... *sigh* OC-12 adapters are an option, but they are rather expensive ... > However, to answer your question, even a modestly configured 7507 with > RSP4, and VIP2-50's will be substantially more capable than a 7206-NPE300. > Things may change on the NPE-400 or G1, but I have no direct experience > with that. The G1 processors, so far, have proven to be wonderful... We only have experience with them running in the 7200 uBR chassis, but they've shown a huge reduction in CPU utilization... > PS. Regards to stability; we have SUBSTANTIAL improvements in IOS > stability, especially in 12.3.5a mainline. Heh.. *old* Cisco code scares me enough... Bleeding edge is simply terrifying... *sigh* > -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben -- > -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- Jason Frisvold Backbone Engineering Supervisor Penteledata

7 7

Good network sniffer?
by Borger, Ben 13 Jan '04

13 Jan '04

Hi Nanog, Can anyone recommend a good network monitor that can replay captured packets? Windows or *nix. Free is great, commercial is ok too. TIA, Ben

7 6

Re: Good network sniffer?
by Dr. Jeffrey Race 13 Jan '04

13 Jan '04

On Mon, 12 Jan 2004 14:48:46 -0600, Borger, Ben wrote: >Can anyone recommend a good network monitor that can replay captured >packets? Windows or *nix. Free is great, commercial is ok too. TCP/IP connection logger Windows and Linux (GNU freeware) <www.ethereal.com> Windows <www.westbrooksoftware.com> Jeffrey Race

1 0

RE: Good network sniffer?
by Braun, Mike 13 Jan '04

13 Jan '04

You should also take a look at EtherPeek http://www.wildpackets.com/products/etherpeek_nx. It has more power than Sniffer Pro and comes at a reasonable price. I like that you can analyze packets while the trace is still running. Mike Braun -----Original Message----- From: Andy Grosser [mailto:andy@sugar.meniscus.org] Sent: Monday, January 12, 2004 2:56 PM To: Borger, Ben Cc: nanog(a)merit.edu Subject: Re: Good network sniffer? > Can anyone recommend a good network monitor that can replay captured > packets? Windows or *nix. Free is great, commercial is ok too. Ethereal. Free. http://www.ethereal.com You gotta love their catchy little descriptive sub-heading: "Sniffing the glue that holds the Internet together." :-) --- Andy Grosser, CCNP andy at meniscus dot org --- "MMS <firstam.com>" made the following annotations on 01/12/2004 03:06:49 PM ------------------------------------------------------------------------------ "THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM." ==============================================================================

2 1

Sales Droid from SBC?
by Drew Weaver 12 Jan '04

12 Jan '04

Any sales droids from SBC lurking? I'm having some problems with our usual reseller, thinking about going direct this time. Thanks, -Drew

1 0

comcast abuse/admin?
by Mark Jeftovic 12 Jan '04

12 Jan '04

If anyone from comcast is here, we would like to talk to someone on your end about abuse from your network (mainly inbound spam from a lot of your netblocks to our mail pool.) Basically we would just like to blot out a number of netblocks in your space from our mailservers that just feed us a constant spew of spam, but we welcome dialog from your side to ensure legit email is unimpeded (by telling us where your outbound mailhubs are, etc) -mark -- Mark Jeftovic <markjr(a)easydns.com> Co-founder, easyDNS Technologies Inc. ph. +1-(416)-535-8672 ext 225 fx. +1-(416)-535-0237

1 0

pending renumbering for "B"
by bill 12 Jan '04

12 Jan '04

we believe we are ready to make the addressing change for b.root-servers.net. the old address is: 128.9.0.107 the new address is: 192.228.79.201 The formal requests have been submitted and there have been no negative comments in those venues. Before the offical changes are made, it would be helpful to have any substantive comments. I expect ICANN to publish a transition date shortly so timely replies are most useful. --bill <bmanning(a)karoshi.com> +1.310.322.8102

1 0

RE: updating bogon filters for 83/8 and 84/8
by Michel Py 11 Jan '04

11 Jan '04

> Sean Donelan wrote: > Don't forget about the other half of the problem. > ISPs need to verify the network announcements by > their downstream BGP networks. Indeed, and it is clear to me that the future solution is some kind of a certificate or something that can authenticate the block being advertised. However, we're not there yet. > Eventually most of the current "bogons" will be assigned, > and bogon filters will continue to be less and less useful. Indeed. I will point out two things though: 1. This is in 10+ years, likely. Nobody really knows when, one of the reasons being: 2. As we allocate new blocks, part of them is for new use and part of them is used to replace existing assignments. In this very case, at least one of the ISPs concerned is getting a single new block and releasing a bunch of other smaller blocks to RIPE. So we are actually seing defragmentation of the routing table, which is good for everyone. This leads to pushing back even further the exhaustion of space, because we are allocating new space now but the space being freed by new allocations that consolidate several blocks will be made available only later. Since everyone is gaining routing table size reduction in this deal, we must encourage all that are willing to consolidate, and part of this is removing the current inconvenience brought by slow updates of the bogon filters, which in turn means more automation. > On the other hand, positive verification will continue > to improve the stability of the network. Which is why the mechanism we are recommending is not limited to bogons but targeted at more generic prefix filtering. http://arneill-py.sacramento.ca.us/draft-py-idr-redisfilter-01.txt Michel.

1 0