- Test - lists.nanog.org

Re: Cisco's AIP vs HSSI
by sthaug＠nethelp.no 16 Oct '96

16 Oct '96

> But I like PPP because cisco still doesn't document their HDLC line > protocol. :-) (Go ahead, try to find it online or ask someone on > one of the tech support lists to find it for you. :-) No problem. Here's a message from Bill Westfield which explains the Cisco HDLC framing. It doesn't mention the FCS, but as far as I know it has a standard two-byte FCS at the end. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no ---------------------------------------------------------------------- From: BILLW(a)MATHOM.CISCO.COM (William "Chops" Westfield) Subject: Re: Wanted: IP directly over HDLC Date: 7 Nov 90 07:57:33 GMT We have an opportunity here to productize a capability of doing IP over serial lines. The way I've prototyped this is to encapsulate IP datagrams directly into HDLC framing (ISO 3309), without any of the "upper-layer" (ISO 4335 or LAPB) retransmission or windowing stuff. Indeed, this is what almost all of the major router vendors do. PPP is also like this except that there is a potential of doing millions of lines of code to support all the random option negotiation. We were wondering if there are any implementations out there that are also able to do this. Both Wellfleet and cisco boxes come to mind, but are there any other implementations that can do this in a non-proprietary manner? As far as I know, wellfleet and cisco "hdlc" encapsulations are only "proprietary" in that no one else does them - they aren't big secrets. (Ill enclose a description of cisco's spec later in this message...) Note: I am aware of PPP and am not interested in implementing it as a solution at this time. Why not? I would think that this would be a good idea, especially if you leave out the negotiation of the millions of options. A "minimal subset" (refuse all options) of PPP is not difficult, and even a format equivilent to PPP with not option negotiation supported at all (eg only the PPP wire format) probably has a better interoperability future than anything else... Bill Westfield cisco Systems. cisco Serial Line Encapsulation ------------------------------- cisco's default encapsulation on synchronous serial lines uses HDLC framing, with packet contents defined as follows: The first ("address") octet is set to 0x0F for unicast packets and 0x8F for broadcast packets. Broadcast just means that the higher-level protocol thought this was a broadcast packet; cisco doesn't support multidrop HDLC at this time. The second ("control") octet is always 0. The next two octets are a 16-bit protocol code, sent most-significant-first. These codes are usually Ethernet type codes. cisco has added some codes to support packet types that don't appear on Ethernets. The current list of codes is as follows: TYPE_PUP 0x0200 PUP TYPE_XNS 0x0600 XNS TYPE_IP10MB 0x0800 IP TYPE_CHAOS 0x0804 Chaos TYPE_IEEE_SPANNING 0x4242 DSAP/SSAP for IEEE bridge spanning prot. TYPE_DECNET 0x6003 DECnet phase IV TYPE_BRIDGE 0x6558 Bridged Ethernet/802.3 packet TYPE_APOLLO 0x8019 Apollo domain TYPE_REVERSE_ARP 0x8035 cisco SLARP (not real reverse ARP!) TYPE_DEC_SPANNING 0x8038 DEC bridge spanning tree protocol TYPE_ETHERTALK 0x809b Apple EtherTalk TYPE_AARP 0x80f3 Appletalk ARP TYPE_NOVELL1 0x8137 Novell IPX TYPE_CLNS 0xFEFE ISO CLNP/ISO ES-IS DSAP/SSAP This list is shared between serial and Ethernet encapsulations. Not all these codes will necessarily appear on serial lines. This list will probably be extended as cisco adds support for more protocols. Bytes after this are higher-level protocol data. These normally look the same as they'd look on Ethernet. Bridging packets include Ethernet/802.3 MAC headers; no other packets do. Packets with type 8035 (reverse ARP) don't contain reverse ARP data as they would on an Ethernet. Instead, they carry a protocol cisco refers to as SLARP. SLARP has two functions: dynamic IP address determination and serial line keepalive. The serial line model supported by SLARP assumes that each serial line is a separate IP subnet, and that one end of the line is host number 1, while the other end is host number 2. The SLARP address resolution protocol allows system A to request that system B tell system A system B's IP address, along with the IP netmask to be used on the network. It does this by sending a SLARP address resolution request packet, to which system B responds with a SLARP address resolution reply packet. System A then attempts to determine its own IP address based on the address of system B. If the host portion of system B's address is 1, system A will use 2 for the host portion of its own IP address. Conversely, if system B's IP host number is 2, system A will use IP host number 1. If system B replies with any IP host number other than 1 or 2, system A assumes that system B is unable to provide it with an address via SLARP. For the SLARP keepalive protocol, each system sends the other a keepalive packet at a user-configurable interval. The default interval is 10 seconds. Both systems must use the same interval to ensure reliable operation. Each system assigns sequence numbers to the keepalive packets it sends, starting with zero, independent of the other system. These sequence numbers are included in the keepalive packets sent to the other system. Also included in each keepalive packet is the sequence number of the last keepalive packet _received_ from the other system, as assigned by the other system. This number is called the returned sequence number. Each system keeps track of the last returned sequence number it has received. Immediately before sending a keepalive packet, it compares the sequence number of the packet it is about to send with the returned sequence number in the last keepalive packet it has received. If the two differ by 3 or more, it considers the line to have failed, and will route no further higher-level data across it until an acceptable keepalive response is received. There is interaction between the SLARP address resolution protocol and the SLARP keepalive protocol. When one end of a serial line receives a SLARP address resolution request packet, it assumes that the other end has restarted its serial interface and reset its keepalive sequence numbers. In addition to responding to the address resolution request, it will act as if the other end had sent it a keepalive packet with a sequence number of zero, and a returned sequence number the same as the returned sequence number of the last real keepalive packet it received from the other end. The following is a C definition for the SLARP packet. The "long" and "ulong" types are 32-bit numbers, high octet sent first. The "ushort" type is a 16-bit number, high octet sent first. struct slarp { long code; /* SLARP packet type code */ union sl { /* followed by one of: */ struct { /* Address resolution functions */ ulong address; /* Address of system sending this pkt */ ulong mask; /* IP subnet mask for this line */ ushort unused; /* Unused: contents undefined */ } add; /* -- or -- */ struct { /* Keepalive probing functions */ ulong mysequence; /* Outgoing sequence number */ ulong yoursequence; /* Returned sequence number */ ushort reliability; /* Reserved: set to FFFF */ } chk; } t; }; Note that the data storage for t.add is overlayed on the data storage for t.chk. The whole SLARP packet consists of a 32-bit type code, followed by two 32-bit quantities and one 16-bit quantity. The overall length of the SLARP packet is 14 octets. The "code" field is used to identify the packet's SLARP type. Legal values for the "code" field are as follows: SLARP_REQUEST 0 Address resolution request SLARP_REPLY 1 Address resolution reply SLARP_LINECHECK 2 Line keepalive For address resolution request packets, the "address" and "mask" fields are set to zero, and the contents of the "unused" field field are undefined. For address resolution reply packets, the "address" field contains the IP address of the _replying_ system, and the "mask" field contains the IP subnet mask to be used. The contents of the "unused" field are undefined. For keepalive packets, the "mysequence" field contains the sequence number of the packet and the "yoursequence" field contains the returned sequence number, which is the sequence number of the last keepalive packet the sending system has gotten from the receiving system. The "reliability" field is reserved for future use, and _must_ be set to FFFF hexadecimal.

1 0

Re: Cisco's AIP vs HSSI
by Vadim Antonov 16 Oct '96

16 Oct '96

Kent W. England <kwe(a)6SigmaNets.com> wrote: >But I like PPP because cisco still doesn't document their HDLC line >protocol. :-) (Go ahead, try to find it online or ask someone on >one of the tech support lists to find it for you. :-) Look in BSD/386 source code (/sys/net/if_c_hdlc*). I reverse-engineered their protocol quite a time ago, took a day of looking at bytes going back and forth :) --vadim

1 0

Re: BBN outage [Press Release]
by cdc＠GroupZ.net 16 Oct '96

16 Oct '96

FYI forwarded from the NANOG group - cdc Hi, Here's the formal Press Release on the outage...complete with down times for those of you who were asking for specifics. Note - I work the gov't services side of things, so don't let the BBN mailing address fool anyone. I'm usually not privy to real time happenings on the commercial side, but I can follow up on high visibility issues when requested...like "The CIDR List" and this outage, etc. --------------Forwarded Message: Date: Fri, 11 Oct 1996 15:31:30 -0500 To: BBN-Staff(a)BBN.COM From: "Joan L. Irons" <jirons(a)BBN.COM> Subject: Power Outage Release FOR IMMEDIATE RELEASE For Information Contact: Peter Thonis BBN Corporation 617-873-3512 pthonis(a)bbn.com STANFORD POWER OUTAGE AFFECTS SOME BBN INTERNET CUSTOMERS CAMBRIDGE, Mass., October 11, 1996 - An electrical power outage at the Stanford University complex has caused BBN Corporation's Internet access in Palo Alto, California to be temporarily unavailable, affecting approximately 400 of BBN's business and organizational customers. The electrical outage, which began at 7 p.m. PDT on Thursday, has cut off power to BBN's Point of Presence (PoP) located at Stanford University Data Center. The PoP is one of the connection points to the Internet for BBN's customers in California. BBN has more than 60 PoPs in the U.S. A battery backup power system kept the BBN Palo Alto PoP operational for two hours, but power was lost at 9:00 p.m. PDT. Stanford's power was restored at 12:30 a.m. on Friday and then went out again at 6:00 a.m. PDT. Stanford has a redundant power system, tying in Stanford's co-generation facility and PG&E Power, but the equipment that switches between these power sources failed. This is the first power failure at the Stanford facility in more than 10 years. Backup generators are being deployed to the Stanford site. BBN expects Internet access through the PoP to resume later today, once electrical power is restored. BBN Chairman and CEO George H. Conrades, who is at the Palo Alto site working with customers on the problem, said, "We apologize for the fact Internet access is unavailable while Stanford University works to repair its electrical power. We understand how important full-time access to the Internet is to our customers, and we are doing everything we can to help Stanford restore electrical power to BBN's facilities. Up to this point, the facility has had an excellent history of uninterrupted power service, including through brownouts and earthquakes. Obviously, we are committed to providing our customers with the highest standard of reliable service." # # # ------------------------------------------------------------ Joan L. Irons Corporate Communications (617) 873-3514 Voice BBN Corporation (617) 873-6899 Fax 150 CambridgePark Drive jirons(a)bbn.com Internet Cambridge, MA 02140 http://www.bbn.com ---------------End Forwarded Message

1 0

Re: BBN outage [Press Release]
by Patty Martinez 16 Oct '96

16 Oct '96

Hi, Here's the formal Press Release on the outage...complete with down times for those of you who were asking for specifics. Note - I work the gov't services side of things, so don't let the BBN mailing address fool anyone. I'm usually not privy to real time happenings on the commercial side, but I can follow up on high visibility issues when requested...like "The CIDR List" and this outage, etc. --------------Forwarded Message: Date: Fri, 11 Oct 1996 15:31:30 -0500 To: BBN-Staff(a)BBN.COM From: "Joan L. Irons" <jirons(a)BBN.COM> Subject: Power Outage Release FOR IMMEDIATE RELEASE For Information Contact: Peter Thonis BBN Corporation 617-873-3512 pthonis(a)bbn.com STANFORD POWER OUTAGE AFFECTS SOME BBN INTERNET CUSTOMERS CAMBRIDGE, Mass., October 11, 1996 - An electrical power outage at the Stanford University complex has caused BBN Corporation's Internet access in Palo Alto, California to be temporarily unavailable, affecting approximately 400 of BBN's business and organizational customers. The electrical outage, which began at 7 p.m. PDT on Thursday, has cut off power to BBN's Point of Presence (PoP) located at Stanford University Data Center. The PoP is one of the connection points to the Internet for BBN's customers in California. BBN has more than 60 PoPs in the U.S. A battery backup power system kept the BBN Palo Alto PoP operational for two hours, but power was lost at 9:00 p.m. PDT. Stanford's power was restored at 12:30 a.m. on Friday and then went out again at 6:00 a.m. PDT. Stanford has a redundant power system, tying in Stanford's co-generation facility and PG&E Power, but the equipment that switches between these power sources failed. This is the first power failure at the Stanford facility in more than 10 years. Backup generators are being deployed to the Stanford site. BBN expects Internet access through the PoP to resume later today, once electrical power is restored. BBN Chairman and CEO George H. Conrades, who is at the Palo Alto site working with customers on the problem, said, "We apologize for the fact Internet access is unavailable while Stanford University works to repair its electrical power. We understand how important full-time access to the Internet is to our customers, and we are doing everything we can to help Stanford restore electrical power to BBN's facilities. Up to this point, the facility has had an excellent history of uninterrupted power service, including through brownouts and earthquakes. Obviously, we are committed to providing our customers with the highest standard of reliable service." # # # ------------------------------------------------------------ Joan L. Irons Corporate Communications (617) 873-3514 Voice BBN Corporation (617) 873-6899 Fax 150 CambridgePark Drive jirons(a)bbn.com Internet Cambridge, MA 02140 http://www.bbn.com ---------------End Forwarded Message

1 0

Re: Cisco's AIP vs HSSI
by Kent W. England 16 Oct '96

16 Oct '96

At 02:15 PM 15-10-96 -0400, Avi Freedman wrote: >> ..., IMHO, you really need PPP. > >We run PPP on all non-frame-or-smds and less-than-DS3 links so that >the customer (or ourselves, if it came to it) could switch to non- >Cisco gear instantly. > >But we usually leave most cisco-cisco high-speed links at HDLC. >My impression is that HDLC was the same efficiency - or moderately >more so - than PPP. There are about three flavors of HDLC encapsulation, one of which is cisco and because of that the others don't matter. There is precious little difference between all the flavors of HDLC and PPP, they all carry the old OUI/Ethertype/etc overhead. And the efficiencies of all are the same compared to SMDS or ATM. > >For what do feel that one *really* needs PPP? > Well, that's it -- I don't assume that the whole world is cisco, but I'm a bit naive. Of course there are other hooks in PPP that are useful, since PPP, like BGP, is a Swiss Army knife protocol, but again since the whole world is cisco, let BGP figure everything out and run HDLC. You don't really need PPP in an all cisco backbone. But I like PPP because cisco still doesn't document their HDLC line protocol. :-) (Go ahead, try to find it online or ask someone on one of the tech support lists to find it for you. :-) --Kent I'm kidding. Of course I love everything about cisco, since as Dave O'Leary has told me for a long time "Sooner or later everyone ends up working for cisco" and he seems to be right.

1 0

RAToolSet 3.4.1 is available for anonymous ftp
by Cengiz Alaettinoglu 15 Oct '96

15 Oct '96

RAToolSet 3.4.1 (contains RtConfig and Route Object Editor in addition to other tools) is now available at http://www.isi.edu/ra/RAToolSet ftp://ftp.isi.edu/ra/RAToolSet The ftp directory also contains binaries for selected architectures. We can make binaries for other systems available upon request. RAToolSet 3.4.1 compiles out of the box for the following systems: SunOS, Solaris, OSF/1, BSDI, FreeBSD, linux, and probably on other systems as well. There is also a mailing list, ratoolset(a)isi.edu. To join, please send a message to majordomo(a)isi.edu with body containing subscribe ratoolset In the upcoming Nanog, there will be demos of these tool. Bug reports, fixes and suggestions for improvements are welcome and appreciated. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/~cengiz

1 0

Parking info for NANOG Meeting
by Pam Ciesla 15 Oct '96

15 Oct '96

There is LIMITED PARKING in the Thompson Parking Structure (ONLY) located on Thompson St. about 1 block from the MI Union. Please park your car on the 2nd level and up (do not use the 1st level). You will need to come into the meeting site to get a parking pass and return to your car to put it in your car. Please NOTE that if you get a ticket while doing this bring it to me and I will take care of it. PARK IN STAFF PARKING. NOTE: THIS IS A FIRST COME FIRST SERVE POLICY. HOTEL SHUTTLES ARE HIGHLY RECOMMENDED. Pam Ciesla ps There are no meters available in the Thompson Parking Structure, please use Staff Parking spaces. Sorry for any confusion.

1 0

NANOG Registration
by Pam Ciesla 15 Oct '96

15 Oct '96

The list of attendees for the NANOG Meeting has been updated. If you are not on the list and should be please contact me. NOTE: THIS IS LAST CALL FOR REGISTRATION FOR THE OCTOBER NANOG MEETING Hotels that were blocked are no longer available. Please check other hotels list on the WEB page also check the Crowne Plaza 313-761-7800. If you need any info please contact me. Thanks Pam Ciesla

1 0

Re: Cisco's AIP vs HSSI
by salo＠msc.edu 15 Oct '96

15 Oct '96

> From: bmanning(a)ISI.EDU (Bill Manning) > Subject: Re: Cisco's AIP vs HSSI > To: freedman(a)netaxs.com (Avi Freedman) > Date: Tue, 15 Oct 1996 07:55:50 -0700 (PDT) > Cc: bmanning(a)ISI.EDU, salo(a)msc.edu, kri(a)bellcore.com, nanog(a)merit.edu > [...] > The orginal question can be paraphrased as; "which > board is better" (see the subject line). > Tim S. couched his replies in the form of an ATM only > solution. I feel that the HSSI board was not designed > as such. Your comments seem to back up my assertions. The HSSI card was not designed as an ATM solution. The HSSI ATM solution involved, in some sense, making the ATM network look like a frame relay network to the HSSI card. > I would claim that for raw throughput, and assuming > the DS3 daughtercard for the AIP, that the HSSI board > delivers more useful bits at the expense of an outboard > CSU. This is based on my feeling that HDLC is more efficent > than ATM signaling/framing. If the context of the question is the most appropriate interface for a point-to-point connection between two routers, I would worry more about throughput than, for example, issues of ATM versus HDLC functionality and overhead. The AIP card can obviously clock out data a lot faster than can a HSSI board, (assuming you don't intentionally put a slow interface on the AIP card). However, I think it is also important to understand the throughput of the two boards and how well they are integrated into the Cisco (or, in general, your favorite vendor's) router. I was under an impression that the HSSI card was a lower-performing board, but someone with some more detailed understanding should provide some insight. I suppose my answer could be refined as: o If you need an ATM solution, use the AIP card. o If you merely want a DS-3 or slower point-to-point link between two routers, test both solutions, (or talk to someone who has), to determine which solution has better performance; or o If you want a point-to-point connection between two routers at speeds faster than HSSI can support (a bit more than 45 Mbps, I think) use the AIP card. Again, you should also consult your router vendor. They should be giving you all this information and more. For example, you might discuss a OC-3c IP over SONET solution for point-to-point connections. -tjs

1 0

Re: cable modems [Re: Intra/Inter - was Inet-II]
by Kent W. England 15 Oct '96

15 Oct '96

At 09:01 AM 15-10-96 -0700, Milo Medin wrote: >Really Ken, just because you consult to PacBell, you shouldn't be so >obvious in your posturing. :-) Well, Milow, it's hardly posturing. More a gesture. :-) Everyone who's been to NANOG knows that I work for PacBell on the NAP. I believe that you yourself were once a consultant for a long stint at Ames, working for Sterling Software before you stepped over and became a government employee? I don't think you can so easily discredit me for being a low-life self-prostituting money-grubbing consultant. But nice try. I'm sure you've read the Upside article and the issue it raises regarding TCI's investment in the necessary cable plant upgrades to support @Home? > >Cable modems by themselves don't don't the performance problem, in fact, >that's what @Home has been talking about for sometime now, and why we >believe you have to build an intelligent network architecture, not just >dumb pipes. That is certainly true and no one better to architect a data network that works for the web than you. An xDSL network needs the same kind of caching and replication as you are designing into the @Home network for the same reasons. Fortunately, it isn't rocket science (to take your old NASA phrase) and doesn't require proprietary extensions, although some might like to lock in a subscriber to proprietary features of an intelligent web architecture. > >Some folks do believe that just fixing the loop will fix system >performance, and they are clearly in the wrong. However, I will venture >to say that unless you do something like what we're doing, it doesn't >matter if the loop is ADSL or Cable or laser, it's not going to end up >running very fast. This is not just a loop problem. > Right again, just fixing the loop problem isn't enough, but since we are tangentially back on that topic, what exactly has TCI and the other cable partners committed to regarding the investment in cable plants outside the Bay Area? For while you absolutely must have an intelligent data architecture, you also absolutely must have a solution to the local loop problem. You go fix the local loops at TCI and I'll get PacBell to roll out an intelligent data architecture along with the xDSL service. --Kent

1 0