- NANOG - lists.nanog.org

Re: Broken 3640?
by Jason Slagle 13 Jun '00

13 Jun '00

Heres a followup. This is a show int on the interface. FastEthernet2/0 is up, line protocol is up Hardware is AmdFE, address is 0050.547b.e8c0 (bia 0050.547b.e8c0) Internet address is x.x.x.x/24 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 5/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/240, 905945 drops; input queue 0/240, 286 drops 30 second input rate 3397000 bits/sec, 1750 packets/sec 30 second output rate 2246000 bits/sec, 1989 packets/sec 55263194 packets input, 4227545542 bytes Received 185916 broadcasts, 0 runts, 0 giants, 286 throttles 1158 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast 0 input packets with dribble condition detected 52516038 packets output, 801075852 bytes, 0 underruns 0 output errors, 0 collisions, 4 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out Now, those input errors are not reflected on the switch. Also, a show controller fastether 2/0 shows the following: Interface FastEthernet2/0 Hardware is AMD Laguna ADDR: 60D7F840, FASTSEND: 6002AEB4, MCI_INDEX: 0 DIST ROUTE ENABLED: 0 Route Cache Flag: 1 LADRF=0x0080 0x0100 0x0002 0x0000 CSR0 =0x00000072, CSR3 =0x00001044, CSR4 =0x0000491D, CSR15=0x00000180 CSR80 =0x00009900, CSR114=0x00000000, CRDA =0x0257CA40, CXDA=0x0257CFE0 CSR5 =0x00000001, CSR7 =0x00000820, CSR100=0x0000F000, CSR125=0x00005C3C BCR2 =0x00000000, BCR9 =0x00000001, BCR18 =0x000019E0, BCR22 =0x0000FF06 BCR25 =0x000000FF, BCR26 =0x00000080, BCR27 =0x00000010, BCR32=0x00004000 HW filtering information: Promiscuous Mode Disabled, PHY Addr Enabled, Broadcast Addr Enabled PHY Addr=0050.547B.E8C0, Multicast Filter=0x0080 0x0100 0x0002 0x0000 amdp2_instance=0x60D81170, registers=0x3D000000, ib=0x257C7E0 rx ring entries=64, tx ring entries=128 rxring=0x257C840, rxr shadow=0x60D81364, rx_head=32, rx_tail=0 txring=0x257CC80, txr shadow=0x60D81490, tx_head=54, tx_tail=54, tx_count=0 Software MAC address filter(hash:length/addr/mask/hits): 0x58: 0 0100.5e00.0006 0000.0000.0000 0 0x5B: 0 0100.5e00.0005 0000.0000.0000 0 0xC0: 0 0100.0ccc.cccc 0000.0000.0000 0 spurious_idon=0, filtered_pak=0, throttled=286, enabled=286, disabled=0 rx_framing_err=0, rx_overflow_err=1158, rx_buffer_err=0 rx_bpe_err=0, rx_soft_overflow_err=0, rx_no_enp=0, rx_discard=0 tx_one_col_err=0, tx_more_col_err=0, tx_no_enp=0, tx_deferred_err=0 tx_underrun_err=0, tx_late_collision_err=0, tx_loss_carrier_err=0 tx_exc_collision_err=0, tx_buff_err=0, fatal_tx_err=0 hsrp_conf=0, need_af_check=0 PHY registers: Register 0x00: 2100 784F 2000 5C01 01E1 0000 0000 0000 Register 0x08: 0000 0000 0000 0000 0000 0000 0000 0000 Register 0x10: 0000 0000 0000 FFFF 0000 0001 8062 Register 0x18: 8020 08A0 0000 1800 A3B9 Note the rx_overflow errors in line with the fe input errors. They seem to coincide with periods of unreachability but, we already replaced the card so.. Jason --- Jason Slagle - CCNA - CCDA Network Administrator - Toledo Internet Access - Toledo Ohio - raistlin(a)tacorp.net - jslagle(a)toledolink.com - WHOIS JS10172 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GE d-- s:+ a-- C++ UL+++ P--- L+++ E- W- N+ o-- K- w--- O M- V PS+ PE+++ Y+ PGP t+ 5 X+ R tv+ b+ DI+ D G e+ h! r++ y+ ------END GEEK CODE BLOCK------

3 2

attention net-grrls
by abha 13 Jun '00

13 Jun '00

Hi NANOG! Sorry for the spam, but this seemed like the best place to post this message.... :) Some of us have been talking about this for years.... And it has been a long time in the making, but it is finally here... A mailing list for Women in Networking... Whoohoo... :) I hope this list develops into a useful forum and resource for all of us... A place to discuss, network, complain, vent, coordinate... Whatever... :) Thanks to many gracious folks, this list is now possible (Thanks, Steve. Thanks, Paul. And to my co-conspirators... Hi Cathy! Hi Eve!) Send "subscribe net-grrls" to Majordomo(a)wibh.net Please send me any comments, complaints, etc.... //abha ;)

14 16

AS6082 route leakage
by Stromski, Michael 12 Jun '00

12 Jun '00

I would like to apologize for any problems or issues caused by our route leakage. We believe we have corrected the problem and are currently investigating the root cause to ensure that this does not happen again. Again, I apologize for any problems we have caused. mike stromski

1 0

Re: 7507 debug error
by Mufti Ahmed 12 Jun '00

12 Jun '00

Jesper how were you able to tell that it is a faulty card; from the traceback indicating it has to do with the "%CBUS" and "CCB handover timed out". Mufti Nayeem Ahmed Network Systems Engineer Market Data Delivery Reuters America Inc. 212-603-3595 HW problem, if you wasn't OIR'ing cards, I'd say you probably have a faulty card. On Mon, Jun 12, 2000 at 10:38:35PM +0200, Marc Teichtahl wrote: > > can anyone translate this for me ? > > Jun 12 21:41:07.679 CED: %RSP-3-RESTART: cbus complex > > Jun 12 21:41:55.996 CED: %DBUS-3-SW_NOTRDY: DBUS software not ready > after > > dbus_s > > lot_enable(), elapsed 12032, status 0x48 > > -Traceback= 602A5284 602A6418 602B808C 60287EAC 602879B0 60290B18 > 6023F2CC > > 6023F > > 2B8 > > Jun 12 21:42:06.504 CED: %CBUS-3-CCBPTIMEOUT: CCB handover timed out, > CCB > > 0x5800 > > FF20, slot 0 > > -Traceback= 602BA350 602B7B98 602B8178 60287EAC 602879B0 60290B18 > 6023F2CC > > 6023F > > 2B8 > > > -- > > > Marc Teichtahl Manager, Data Network Engineering > Versa(tel Telecom NASDAQ: VRSA AEX: VERSA > > US Cell: +1 650 248 7058 Dutch Cell: +31 6 21213104 > > /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

1 0

New GeekTools SuperWhois Windows Client available
by Rodney Joffe 12 Jun '00

12 Jun '00

Given the "requests" (flames) we got for not continuing development of the Windows version of the GT SuperWhois, we've just released V4. http://www.geektools.com/software.html GeekTools Whois Client v4.0/Win32 (PGP sig) Main changes: An "Update" feature that retrieves the latest list of known whois servers from whois-servers.net Additional parameters, including "abuse" which also returns the known abuse contact at a domain A help/man section Option to use ie to display results, allowing clickable links in results -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"(SM)

1 0

Real Internet Consortium
by Chris Cappuccio 12 Jun '00

12 Jun '00

Has anyone seen this? http://www.real-internet.org/whatisric.txt "It is widely recognized that, because of the speed limitation of electric circuit, Tbps or Pbps routers can be constructed only with massively parallel architecture with a lot of elementary routers combined by a high speed interconnection backbone. On the other hand, it is widely misunderstood that fine grain QoS assurance of individual flows is impossible, because, at the high speed backbone of the Internet, there are so many flows that signaling of the flows and routing (including policing and fair queuing) of packets of the flows do not scale. It is not widely understood that the backbone scalability problems of QoS assurance is solved by massively parallel nature of high speed routers. As a result, people in conventional standardization forum such as ISO, ITU and IETF are, in vain, trying to produce complex protocols to aggregate flows to reduce the complexity. However, it is easy to prove that such aggregation is impossible at least with multicast or QoS routed flows. Thus, in some IETF WG, QoS assurance is finally given up and CoS assurance, which is not useful for most applications, which is often obfuscated by the fallacy of calling CoS QoS, is pursued."

2 1

RE: AS6082
by Greene, Dylan 12 Jun '00

12 Jun '00

I used to work w/ Jim, and called him to let him know.. Let's see what happens.. ..Dylan | -----Original Message----- | From: Vincent J. Bono [mailto:vbono@vinny.org] | Sent: Monday, June 12, 2000 3:39 PM | To: joe.provo(a)rcn.com | Cc: nanog(a)merit.edu | Subject: Re: AS6082 | | | | Try e-mailing: | | Chris White <cwhite(a)harvardnet.com> | Jim D'Angelo <jdangelo(a)harvardnet.com> | Larry Jarvis <ljarvis(a)harvardnet.com> | | | In that order of potential usefuleness. We have called | their NOC several times now and have not gotten very far. | | -vb | | > That data is bogus; 6082 is now harvard.net, based in | charlestown MA. | > 800-772-6771 is the front door; all recognizable names in | my cell phone | > are in the "used to be there" category, no back-doors. | > | > -- | > Joe Provo Voice | 508.486.7471 | > Director, Internet Planning & Design Fax | 508.229.2375 | > Network Deployment & Management, RCN | <joe.provo(a)rcn.com> |

1 0

Re: AS6082
by Vincent J. Bono 12 Jun '00

12 Jun '00

Try e-mailing: Chris White <cwhite(a)harvardnet.com> Jim D'Angelo <jdangelo(a)harvardnet.com> Larry Jarvis <ljarvis(a)harvardnet.com> In that order of potential usefuleness. We have called their NOC several times now and have not gotten very far. -vb > That data is bogus; 6082 is now harvard.net, based in charlestown MA. > 800-772-6771 is the front door; all recognizable names in my cell phone > are in the "used to be there" category, no back-doors. > > -- > Joe Provo Voice 508.486.7471 > Director, Internet Planning & Design Fax 508.229.2375 > Network Deployment & Management, RCN <joe.provo(a)rcn.com>

1 0

RealMedia feed
by Bora Akyol 12 Jun '00

12 Jun '00

The real media feed from the conference is very spotty and the server seems to be loaded too. Is it possible to drop the rate to 32 Kbps or 64Kbps from 80Kbps and get at least good quality sound instead of nothing at all? Bora

2 1

Real Media feed down
by Bora Akyol 12 Jun '00

12 Jun '00

Hi all The real media feed is down. Bora

1 0