October 1996 - Test - lists.nanog.org

Re: sprint and multihoming
by William Allen Simpson 17 Oct '96

17 Oct '96

> From: randy(a)psg.com (Randy Bush) > Some weeks back, I whined about SprintLink's policies and implementation in > respect to multi-homing. They did not leak the multi-homer's more specific > prefix outside of SprintLink. Nor did they accept the longer prefix from > outside, hence traffic from SL customers would die when the MHed site's SL > link was down. > Me, too.... > I just wanted to publicly thank SprintLink, and Hank Kilmer and his team in > particular, for fixing this. IMIHO, this makes SprintLink a reasonable > choice for a provider if you intend to multi-home. > Hmmm, well, as I reported here earlier, we already changed our ISP contract away from Sprint. But, for my clients, based on your representation that it is finally working, I suppose that I might be willing to at least allow Sprint in future multi-home bids, as long as the contract specifically requires Sprint to be on better behaviour. Thanks for the update, Randy! WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Are there plans to do MBONE broadcasts of the upcoming meeting?
by Curtis Generous 17 Oct '96

17 Oct '96

..for those of us who might not be able to make it to Michigan? There was a pretty good turnout on the last NANOG session in DC. --curtis -- Curtis Generous generous(a)uucom.com Phone: (703) 461-1350 UUcom Inc., Suite 250, 4875 Eisenhower Avenue, Alexandria, VA 22304-0797

1 0

sprint and multihoming
by randy＠psg.com 17 Oct '96

17 Oct '96

Some weeks back, I whined about SprintLink's policies and implementation in respect to multi-homing. They did not leak the multi-homer's more specific prefix outside of SprintLink. Nor did they accept the longer prefix from outside, hence traffic from SL customers would die when the MHed site's SL link was down. I just wanted to publicly thank SprintLink, and Hank Kilmer and his team in particular, for fixing this. IMIHO, this makes SprintLink a reasonable choice for a provider if you intend to multi-home. Thanks SL. Thanks Hank. randy

1 0

Re: hole punching reality check
by Eric Kozowski 17 Oct '96

17 Oct '96

>I would expect the world to see the following announcements. > >A - I announcing a shorter prefix, A >B - P announcing a more specific for the /24 allocated to C > >Is this not what we all expect? Sounds like the right thing to me. >Why I ask is we have provider P telling I that they should stop announcing A >and instead announce a bunch of prefixes around the /24. They're nuts. Eric -- Eric Kozowski Senior Network Engineer eric(a)structured.net Structured Network Systems, Inc. (503)656-3235 FAX Better, Cheaper, Faster -- pick any two. (800)881-0962 Voice http://www.structured.net/ "Providing High Quality, Reliable Internet Service" -- 56k to DS1

2 1

Re: Cisco as Big Brother (Was Re: Cisco's AIP vs HSSI)
by Paul Ferguson 16 Oct '96

16 Oct '96

At 06:30 AM 10/16/96 +0100, Peter Galbavy wrote: > >No. I think the phrase *actually* used at a meeting (I was elsewhere >that day) was "It is a priveledge to deal with a market leader like >Cisco." This was the Cisco sales rep, not us. sigh. > >Buy! Buy! Bye Bye. :-P > Well sorry to hear that you met up with such a twit. I personally carry a large baseball bat around for specifically that reason. I've even had to use it a few times. ;-) - paul

1 0

Re: Building Evacuation [Re: BBN outage]
by Kent W. England 16 Oct '96

16 Oct '96

At 10:39 AM 10/16/96 -0400, Curtis Villamizar wrote: > >We have a backup NOC 1,200 miles away. All the tools are set up and >kept running in two places and at least once a year Ann Arbor >intentionally hands off NOC duties to Elmsford. The people issue is >the main problem, with Elmsford not being as familiar with day to day >NOC operations. Both NOCs are connected to two POPs in different >states with alegedly diverse circuits. Neither NOC has generators but >the last time the UPS ran out we had NOC service cut over in time. >This is also why we have DNS servers in different states (and kerberos >slave servers and other critical services). > >I don't think a cell phone and a laptop would cut it. > >Curtis > > Curtis; Nobody does it better. --Kent

1 0

Re: Cisco as Big Brother (Was Re: Cisco's AIP vs HSSI)
by Paul J. Zawada 16 Oct '96

16 Oct '96

For the record, my Cisco saleperson and pre-sales engineer have always been supportive of my efforts to run a multi-vendor network and never has laid any of this "it's a priveledge to work with Cisco" crap on me. They don't do a hard sell to get my business, but that's OK since I prefer to talk to salespeople only when I need something from them... They don't hesitate to say they're better than everybody else, but they do continue to work for me instead of the other way around. (What salesperson doesn't claim to work for the company that's better than everyone else?) Having said that, there are certainly some salespeople with Cisco that are, to be polite, overzealous in their dealings with customers. These types of salespeople (whatever company they sell for) should be chased away immediately. It seems that most people that I've talked to that have had this experience with Cisco have been from Europe (not to say it doesn't happen in the US), so I wonder if for one reason or another the Cisco European salesforce tends to work that way. It's too bad for Cisco, because if they'd had used this tactic on me, I would have certainly shown them the door... --zawada At 06:30 AM 10/16/96 +0100, Peter Galbavy wrote: >> The salespeople in the UK are using that tactic too? If a sales rep >> EVER walked into my office and fed me a line like that, I would end the >> meeting right there. As it is, I refuse to do business with Cisco not >> because of their products, but because of their marketing department >> and their corporate attitude of "We're the best, nobody can touch us, >> and if you want to buy our product you better bend over backwards to do >> what we want you to do." That was their attitude three years ago when >> our company was just getting started, and I haven't noticed it change >> much today. > >No. I think the phrase *actually* used at a meeting (I was elsewhere >that day) was "It is a priveledge to deal with a market leader like >Cisco." This was the Cisco sales rep, not us. sigh. > >Buy! Buy! Bye Bye. :-P > >Regards, >-- >Peter Galbavy peter(a)wonderland.org >@ Home phone://44/973/499465 >in Wonderland http://www.wonderland.org/~peter/ > snail://UK/NW1_6LE/London/21_Harewood_Avenue/ > > Paul J. Zawada, RCDD | Senior Network Engineer zawada(a)ncsa.uiuc.edu | National Center for Supercomputing Applications +1 217 244 4728 | http://www.ncsa.uiuc.edu/People/zawada

1 0

Building Evacuation [Re: BBN outage]
by Kent W. England 16 Oct '96

16 Oct '96

At 09:06 PM 12-10-96 -0700, maillists wrote: > >In hindsight, solutions to tolerate a given failure are >very easy to come by but shouldn't be talked down. I did not >blame BBN--shit happens-- One thing constructive I would note that I haven't seen yet is that while one can imagine many awful scenarios where your lovely NOC is absolutely leveled (*) by a horrendous accident, it is much more likely that your NOC will be forced to evacuate for some "trivial" reason. Perhaps asbestos. Perhaps a gas main leak in the street. Perhaps the fire alarms just keep going off. Perhaps the power went off and the fire marshall won't let anyone stay in the building without elevator power. It might very well have been the case that had BBN had a backup generator they might still have been forced to evacuate the building, if the fire dept was paying attention. You have to remember that it's harder to keep people in a given building than it is to safeguard the equipment there. You always have to be ready to send your NOC operators packing with a cell phone and a laptop for up to 48 hours, in case the building has to be evacuated for one of a dozen reasons. You should have a backup call center with an ACD set up in some other city or a contract with someone for a backup service. --Kent (*) My nightmare scenario back when I ran the NOC at BBN at 10 Moulton Street was a gasoline tanker turning over in the street out front. The gasoline runs down the stairwell into the sunken parking lot under the building. Someone exits the building into the parking lot and lights a cigarette ... Next moment my NOC and 300 people are ashes and there's a 60 foot crater where the building used to be.

3 2

Windows/NT to break the Internet?
by Hank Nussbacher 16 Oct '96

16 Oct '96

How long can the Internet last if every customer needs to get a /24? That is what appears to be with Windows/NT 4.0. This server has lately become very popular with small customers that install an NT server and a few PCs and want a connection. ISPs up to know would assign a /26 or perhaps a /27 or even a /30 to SOHOs like this. Windows NT 4.0 when defining the address range as well as the DNS and inverse - only has space in the form for 3 octets. They assume you are a /24 or larger. I have had customers come back to me and say that they can't even enter the 255.255.255.224 mask I gave them on their system since the NT doesn't support it. Let alone the problems with inverse subnetting that there is a draft RFC out there that almost everyone follows. Seems to have slipped by the people in Oregon, though. I have been very careful up till now to make optimal use of IP address space but I fear with the plenthora of WinNT 4.0s out there we will see 2% utilization of IP address space in the future. Am I missing something here on WinNT installs? Or is Microsoft gonna cause the IP address space to expire sooner than we had planned? Hank Nussbacher IBM Israel

2 1

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