- NANOG - lists.nanog.org

Errors from a 7513..
by Adrian Chadd 11 Dec '97

11 Dec '97

%SYS-2-GETBUF: Bad getbuffer, bytes= 40470 -Process= "<interrupt level>", ipl= 1 -Traceback= 60159874 601C5FEC 601C8E18 601CB450 60196D00 %SYS-5-CONFIG_I: Configured from console by vty1 (203.55.84.2) %SYS-2-GETBUF: Bad getbuffer, bytes= 38198 -Process= "<interrupt level>", ipl= 1 -Traceback= 60159874 601C5FEC 601C8E18 601CB450 60196D00 %SYS-2-GETBUF: Bad getbuffer, bytes= 62691 -Process= "<interrupt level>", ipl= 1 -Traceback= 60159874 601C5FEC 601C8E18 601CB450 60196D00 %SYS-2-GETBUF: Bad getbuffer, bytes= 38118 -Process= "<interrupt level>", ipl= 1 -Traceback= 60159874 601C5FEC 601C8E18 601CB450 60196D00 %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial12/6, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial12/6, changed state to up %SYS-2-GETBUF: Bad getbuffer, bytes= 60021 -Process= "<interrupt level>", ipl= 1 -Traceback= 60159874 601C5FEC 601C8E18 601CB450 60196D00 %SYS-2-GETBUF: Bad getbuffer, bytes= 56788 -Process= "<interrupt level>", ipl= 1 -Traceback= 60159874 601C5FEC 601C8E18 601CB450 60196D00 I have been getting pages of these lately. Its a 7513 w/ dual RSP2 modules and 64mb RAM. Its running IOS 11.2(8) P w/ 1 SSIP controller (8 Serial). 1 VIP2 controller (1 FastEthernet)(4 Serial). 1 FastEthernet/IEEE 802.3 interface(s) 12 Serial network interface(s) Has anyone on the list come across this before? Adrian

4 3

RE: Cisco Vip Cards.
by Steve Martin 11 Dec '97

11 Dec '97

Correct. :) -----Original Message----- From: Tom Eastgard [SMTP:eastgard@nwnet.net] Sent: Wednesday, December 10, 1997 2:12 PM To: Randy Bush Cc: Steve Martin; north american nominated origin of gossip Subject: RE: Cisco Vip Cards. what they won't support, I believe, is anything in the second adapter slot after the first PA-(the 0c-3 atm thingie) is installed....limitation has to do with the PA- (oc-3 atm), only. TE On Wed, 10 Dec 1997, Randy Bush wrote: > > Cisco will not support multiple PA's within a VIP2-40. > > I do not believe this statement to be true. > > randy >

1 0

Re: PPP Question
by Chris MacFarlane 10 Dec '97

10 Dec '97

More to the point is that the frame size is negotiated while handshaking. Once two devices agree on the size it is fixed for the duration of the session. Chris MacFarlane Manager, Data Operations ACC Telenterprises Canada 4162132023 cmacfarlane(a)acc.ca cjm(a)ican.net -----Original Message----- From: George Janosik <gjanosik(a)torrentnet.com> To: nanog(a)merit.edu <nanog(a)merit.edu> Date: Wednesday, December 10, 1997 4:09 PM Subject: PPP Question >A quick protocol question. > >Is a PPP frame size static or elastic? RFC 1661 states: > > Information Field > > The Information field is zero or more octets. The Information > field contains the datagram for the protocol specified in the > Protocol field. > > The maximum length for the Information field, including Padding, > but not including the Protocol field, is termed the Maximum > Receive Unit (MRU), which defaults to 1500 octets. By > negotiation, consenting PPP implementations may use other values > for the MRU. > > Padding > > On transmission, the Information field MAY be padded with an > arbitrary number of octets up to the MRU. It is the > responsibility of each protocol to distinguish padding octets from > real information. > >This is somewhat ambiguous. If I read it straight it sounds like PPP frames >are >static and that padding is used to maintain the MRU between endpoints. > >But, it also says the the Information field "MAY" be padded up to the MRU. > >I have hard time believing that a PPP frame would be static. >Very truly yours, > >George J Janosik >Senior Systems Engineer >Torrent Networking Technologies >gjanosik(a)torrentnet.com > >412-851-1103 > >

1 0

RE: Cisco Vip Cards.
by Steve Martin 10 Dec '97

10 Dec '97

Hi Randy, We have seen situations under heavy load where a VIP2-40 with an OC3 running at 80% and a Fast Ethernet PA running at 50% have resulted in severe packet loss and latency. After addressing this with our Cisco reps (including the Product Manager and Product Engineer for the 7513/VIP family) they acknowledged the problem and stated: "We do not recommend putting any other PA into a VIP2-40 if an OC3-PA is already installed. We have seen adverse performance, in the way of latency and packet loss, resulting from such a configuration. Customer's choosing to do so, do so at their own risk". Whether this is a company wide, advertised position at Cisco is unknown. During a recent, major launch, our Fast-E PA providing uplink connectivity to our download servers was located on the same VIP as one of our major NAP OC3 PA's. At 80% utilization on the Fast E and 50% on the OC3 we started seeing packet loss and increased latency. When the OC3 gets real busy, the SARing work consumes most of the VIP's resources. Additional taxation from other media interfaces pushes the VIP over the edge and it starts dropping packets and delaying throughput. It was such a problem for us that Cisco offered special pricing bundle's for us until the VIP2-50 could come out and handle the aggreagate loads better. Regards, Steve -----Original Message----- From: Randy Bush [SMTP:randy@psg.com] Sent: Wednesday, December 10, 1997 12:37 PM To: Steve Martin Cc: north american nominated origin of gossip Subject: RE: Cisco Vip Cards. > Cisco will not support multiple PA's within a VIP2-40. I do not believe this statement to be true. randy

2 1

Re: New MAE-EAST
by Richard Irving 10 Dec '97

10 Dec '97

Noemi Berry wrote: > > > Our nets *Scream*. > > > > Another question, in response to another email you'd sent to NANOG > and I subsequently deleted: :( > > You mentioned that your ATM switch at MAE-EAST supports CBR, VBR-RT, > VBR-NRT and UBR. What ATM-connection type do you use to connect peers? > Well at MAE-E , FDDI ;) (We have a pending deal to move some exchange neighbors to direct ATM OC-3/DS3, to route around the MAE) However, passing back into the our national fabric, we tend to run VBR-NRT, with a few UBR's, and a few RT-VBR tunnels. > Actually, I'm probably misunderstanding what you use your ATM switch > for. What is its function at the NAP, anyway? It becomes an Exchange Fabric in and of itself. See Ameritech VNAP, and OneCall's IndyX offerings. > > very curious, > noemi > -- > Noemi Berry > Network Operations > Covad Communications

1 0

Re: New MAE-EAST
by Richard Irving 10 Dec '97

10 Dec '97

Noemi Berry wrote: > > > > > I'd certainly be interested in seeing anything > >> > anyone has on fragmentation related delays going from a large MTU > switched > >> > environment to a small MTU switched environment though. Overall, I've > >> > been less-than-pleased with latency when I've been transited that way. > >> > > > > > Uh... Doctor , it hurts when I do this. > >Doctor: So don't do that! > > > > Hint, it is *pretty* foolish to run mixed MTU's on switched fabric. > > *Most* people on ATM exchanges run with common MTU's. > > Getting to my NANOG mail kinda late here.... I will say. *grin* > > But WHAT are you guys talking about WRT to MTUs through an ATM switch? > The MTUs almost always refer to the layer 3 and up MTUs, which the ATM > switches themselves have no visibility to. We are discussing Router ATM cards. (Layer 2/3).... > It's righter to say that > most people on *any* exchange run with common MTUs. Don't I wish. > > If you're going from a "large MTU switched environment" to a "small MTU > switched environment", then you must be passing through a router or some > other device that understands and sets its own MTU. The ATM layer has > nothing to do with that. MTU issues are independent of what layer 2 > technology is used to connect the peers. The point ? You would have a hard time setting an MTU of 4470 on ethernet... The object of the game ? If you must fragment, do it *after* transmission. (If possible) (Less WAN bandwidth than otherwise) > > I know a thing or two about ATM, but not NAPs, so please correct me if my > terminology is screwy and I missed something. > Try reading RFC-1626. We are talking about MTU for the IP PLCP card into the ATM fabric. FDDI to ATM to Ethernet, try it , you won't like it. PS Don't forget ATM is not the only switched fabric in town.... You will find there is a whole PDU and SDU maxsize declaration for SAR to use on AAL5 based framing. However, these are *not* the limits you want to be using..... I know non-mixed MTU's seem obvious, but some don't get it. On the other hand, I have neighbors who have the CHI-NAP fabric declared as /24, and *cannot* be made to understand why this is bad. ;) (One Quote: Its the internet, I can do as I want! ) Sigh........ Cheers ! > thanks, > noemi > -- > Noemi Berry > Network Operations > Covad Communications > > p.s. (all that said, it's not *entirely* true that the ATM layer has no > visibility to the higher-layer MTUs: early- and partial- packet discard peeks > into the ATM cells to see the start and end of AAL5 frames that encapsulate > layer 3 packets, but it does no fragmentation nor otherwise manipulate the > layer 3 packet).

1 0

PPP Question
by George Janosik 10 Dec '97

10 Dec '97

A quick protocol question. Is a PPP frame size static or elastic? RFC 1661 states: Information Field The Information field is zero or more octets. The Information field contains the datagram for the protocol specified in the Protocol field. The maximum length for the Information field, including Padding, but not including the Protocol field, is termed the Maximum Receive Unit (MRU), which defaults to 1500 octets. By negotiation, consenting PPP implementations may use other values for the MRU. Padding On transmission, the Information field MAY be padded with an arbitrary number of octets up to the MRU. It is the responsibility of each protocol to distinguish padding octets from real information. This is somewhat ambiguous. If I read it straight it sounds like PPP frames are static and that padding is used to maintain the MRU between endpoints. But, it also says the the Information field "MAY" be padded up to the MRU. I have hard time believing that a PPP frame would be static. Very truly yours, George J Janosik Senior Systems Engineer Torrent Networking Technologies gjanosik(a)torrentnet.com 412-851-1103

1 0

PPP Question
by George Janosik 10 Dec '97

10 Dec '97

A quick protocol question. Is a PPP frame size static or elastic? RFC 1661 states: Information Field The Information field is zero or more octets. The Information field contains the datagram for the protocol specified in the Protocol field. The maximum length for the Information field, including Padding, but not including the Protocol field, is termed the Maximum Receive Unit (MRU), which defaults to 1500 octets. By negotiation, consenting PPP implementations may use other values for the MRU. Padding On transmission, the Information field MAY be padded with an arbitrary number of octets up to the MRU. It is the responsibility of each protocol to distinguish padding octets from real information. This is somewhat ambiguous. If I read it straight it sounds like PPP frames are static and that padding is used to maintain the MRU between endpoints. But, it also says the the Information field "MAY" be padded up to the MRU. I have hard time believing that a PPP frame would be static. Very truly yours, George J Janosik Senior Systems Engineer Torrent Networking Technologies gjanosik(a)torrentnet.com 412-851-1103

1 0

UUNET POP Down
by Dan Hubbard 10 Dec '97

10 Dec '97

NOC says the problems are still there but we can route through there LA POP now so it must be a routing issue on there end. >UUNET has a "router hardware" problem in there LA POP. Has been down since around 10:35AM PST. They currently are working on it from the NOC --> ticket # UU570970. > > > --------------- Dan Hubbard The Palace Inc.

1 0

ARIN will begin operations 12/22/97
by Kim Hubbard 10 Dec '97

10 Dec '97

The American Registry for Internet Numbers (ARIN) will initiate operations December 22, 1997, to provide Internet Protocol (IP) number administration and registration services for North America, South America, the Caribbean and sub-Saharan Africa. On this date, the Internet Assigned Numbers Authority (IANA) will transfer the authority for IP number administration from Network Solutions, Inc., administrator of the InterNIC, to ARIN. All IP requests received by the InterNIC, that are not processed prior to the close of business on Friday, December 19, will be forwarded from the InterNIC to ARIN. The InterNIC will make every attempt to complete all requests received by this date. As prepayment is a requirement for ARIN registration services, we encourage ISPs that have previously received address space directly from the InterNIC to pre-establish a customer account with ARIN. The account establishment process will open on December 10, 1997, and is limited to those ISPs that have previously received IP addresses directly from the InterNIC. This prerequisite is due to the fact that ARIN registration fees are based on the previous year's total allocation. All other organizations should establish customer accounts after they have been approved for address space from ARIN. To establish a customer account, use the Customer Account Procedures and Form or for more information about ARIN, please visit the ARIN website located at www.arin.net.

1 0