- Test - lists.nanog.org

Re: Links on the blink - what will/should mci & sprint do?
by Sean Doran 19 Nov '95

19 Nov '95

icm-dc-3.icp.net is a 7505, as is one of its counterparts on the other side of the Atlantic. All routers in Kansas City, Seattle, Cheyenne and Atlanta are 7513s, although they are not yet up and operational. There are a largeish number of 7513s deployed in another parallel network that is engineered out of our group. No points for guessing what that's for. :) Sean.

1 0

Links on the blink - reprise
by Gordon Cook 19 Nov '95

19 Nov '95

People are starting to tell me that the way out of smashing into the brick wall at 60 miles and hour that the Links on the Blink discussion was worrying about a week ago, is to take cascade or other frame relay switches for the national service providers backbone topology and push routers out to spoke and wheel hubs at the perimiters of the back bone where traffic sent on the backbone at the data link layer (2) can pop out and into the appropriate router for layer 3 routing to the final destination. PSI and UUNET have apparently been following this strategy with their backbones for some time. Netcom has also come on board. Its advocates say that this combination can scale and avoid the 60 mile per hour brick wall crash. Are they right? And if so why aren't sprint and MCI running in this direction and away from purely router based networks as fast as they can? If they are why are they wrong? Where does this architecture fail? If it fails. ******************************************************************** Gordon Cook, Editor & Publisher Subscript.: Individ-ascii $85 The COOK Report on Internet Non Profit. $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook(a)cookreport.com Corporate. Site Lic $650 Newly expanded COOK Report Web Pages http://pobox.com/cook/ ********************************************************************

7 7

Re: Links on the blink - reprise
by Paul Ferguson 19 Nov '95

19 Nov '95

At 05:47 PM 11/17/95 -0500, Sean Doran wrote: > >There are substantial disadvantages, too. > >In order to take advantage of the greater >port-density(-per-dollar) on FR switches right now, the >end user has to use FR, which is not always practical >or desirable. > One of the reasons why end users find frame-relay undesireable is that they cannot be assured that their provider is not grossly oversubscribed on PVC-per-port density. When you buy a T1 private line, you can be assured that you're not sharing it with 120 other end-users. :-) - paul

7 7

Re: Links on the blink - reprise
by Paul Ferguson 19 Nov '95

19 Nov '95

At 06:56 PM 11/18/95 -0600, Alan Hannan wrote: > >] Yes, that is true but most ISP's in my area are overselling 100 X or >] more. Sure I mux 4 T1 FR to 1 T1 port and oversell my bandwidth, but all >] of my links have at least 20% free on them during our peek. > > What is your sample interval? Cisco's 5 minute average? > > 80% utilization at 5 minute samples means it is very likely the > lines are choked a good portion of that time. > >-alan > > Peek. A Freudian slip. :-) - paul

1 0

Re: Links on the blink - what will/should mci & sprint do?
by Sean Doran 19 Nov '95

19 Nov '95

| COOK: does this mean that there is some way to get the cisco to behave | like the cascade switch I asked about?? If not what in general does it mean? No, this means that we should be able to squeeze every last drop of bandwidth out of the 7500, such that 4x+ or so worth of OC3s can work in the same chassis without difficulty. | Finally you said if the 7500 doesn't perform well then you might have to | do the redesign I asked about.... meaning going to an atm switched | backbone with routers at the periphery of the backbone?? Over my dead body. The nicer bits of Curtis's last message very clearly and correctly indicated the drawbacks in using ATM or any other L2 protocol. Perhaps he or someone else can put it into slightly less technical terms. No, what a disaster would mean is replacing backbone 7500s with 7000s and doing lots of thinking about really ugly kludges to deal with scale beyond the bandwidth limits of the 7000 series backplane and lots of screaming at Cisco to make the 7500 work at least as well as the 7000+SSP. (We have the latter committment from them already, btw.) Many possibilities exist that don't entail going with ATM, or even necessarily with some non-Cisco switching engine, or some L2 protocol sandwiched between the physical lines and IP, all of which would work in principle. As I think I have said earlier, the value of Cisco is much more in its software than in its hardware; I like Cisco because I know that IOS can be made to work the way I need it to, which is more than I can say for any vendor of any other platform. Cisco does weird things with respect to hardware that sometimes gets annoying or frustrating, but as Melinda Shore's .signature (after Hippocrates) reminds the world: "software longa, hardware brevis". Sean. P.S.: Actually, the quote from Hippocrates's _Aphorisms_ is pretty apt to this discussion: "[Of medicine] The life so short, the art so long to learn, opportunity fleeting, experience treacherous, judgement difficult." Maybe Dave Mills should consider storing this with his jaguar.txt file. :-)

1 0

Re: Links on the blink - reprise
by Hank Nussbacher 18 Nov '95

18 Nov '95

Look up the Nov 6th issue of Communciations Week International. Article entitled "Internet providers move to frame relay" by Richard Karpinski and Kenneth Hart. Discusses how PSI, UUnet and Netcom have moved to B-STDX 9000 frame relay switches by Cascade. Hank

2 1

Re: Links on the blink - reprise
by Paul Ferguson 18 Nov '95

18 Nov '95

At 07:30 AM 11/18/95 -0500, Mike O'Dell wrote: > >don't confuse the link encoding with back-haul design > Don't confuse backhaul design with excessively high concentrations of PVCs, grossly oversubscribed in ratio of aggragate ingress bandwidth. If you don't drop the bits on ingress, you at least stand a fighting chance of getting them (the bits) onto the backbone in the first place. :-) >if the network is deeply over-subscribed, you will drop packets. >the only question is "where?" > Where indeed. >whether the link uses F/R-1490 framing or cisco HDLC doesn't change >that. > This has nothing at all to do with it. Regardless of the frame-relay encapsulation, the fact that one can oversubscribe at ingress exists and lends itself to what Vadim calls 'too may points of indirection'. A private line only has two end-points (let's not discuss imuxes). The possibility of sloppy or careless engineering is just a tad higher when building frame-relay networks. This does not mean that sloppiness can't be avaoided; it certainly can. Just a thought, - paul

1 0

Re: Links on the blink - reprise
by Paul Ferguson 18 Nov '95

18 Nov '95

At 05:45 PM 11/17/95 -0700, Dave Siegel wrote: >> One of the reasons why end users find frame-relay undesireable is >> that they cannot be assured that their provider is not grossly >> oversubscribed on PVC-per-port density. When you buy a T1 private >> line, you can be assured that you're not sharing it with 120 other >> end-users. :-) > >Nor can you know that with a Dedicated line, that the other side doesn't feed >into a 2501 into a collision-ridden Boca 10baseT hub, into a Welfleet bridging >over Frame-Relay-over-ATM at 1.5Mbps simplex speeds into an over-committed >4Mbps port speed on the other side. > >i.e., the fact that your buying a leased line to connect and running HDLC >over it doesn't count for anything. When it comes right down to it, customers >can't really be reassured of anything. > Quite true. Appearances can be deceiving. :-) I was just reiterating (what I thought to be) the obvious. >But then, nobody expects the customer to realize this, right? > >Dave > Um, I won't touch this one. - paul

1 0

Re: Links on the blink - reprise
by Paul Ferguson 18 Nov '95

18 Nov '95

At 05:28 PM 11/17/95 -0700, Ehud Gavron wrote: >>When you buy a T1 private line, you can be assured that you're not >>sharing it with 120 other end-users. :-) > > A T-1 private line to what? Do you think Sprint has sold > more than 30 T-1s, filling up their DS-3 backbone? > > Do you think MCI has sold more than 30 T-1s, filling up > their DS-3 backbone? > > You _are_ sharing bandwidth, unless 100% of your traffic > is to your provider. > I think you missed my point. This is not exactly an issue of how your traffic, once routed through your providers router, traverses their backbone. Rather, its an issue of the ability (or inability, as it were) to sloppily engineer capacity due to the nature of defining excessively high ratios of virtual circuits-to-aggregate ingress bandwidth. - paul

1 0

Like dogs, returning to thier own
by bmanning＠ISI.EDU 17 Nov '95

17 Nov '95

Here is round two... Last Chance B&G. It's off to the drafts directory in the early morn. (~14:00 UTC) TTFN..!! ---------------------------------------------- Network Working Group net39-testgroup Request for Comments: 19xx bill manning - editor Category: Experimental November 1995 Class A Subnet Experiment Results and Recommendations Status of this Memo This documents the experience the Internet community with the Experimental Protocol defined in RFC 1797. This does not specify an Internet standard of any kind. Continued discussion is requested. Distribution of this memo is unlimited. Discussion/Purpose This memo documents some experiences with the RFC 1797[1] subnet A experiment and provides a number of recommendations on future direction for both the Internet Registries and the Operations community. Not all proposed experiments in RFC 1797 were done. Only the "case one" type delegations were made. Additional experimentation was done within the DNS service, by supporting a root nameserver and the primary for the domain from within the subnetted address space. In addition, testing was done on classless delegation[2]. Internet Services offered over the RFC 1797 experiment were: Finger HTTP Telnet FTP server/client Gopher DNS F.Root-Servers.Net, a root name server had an interface defined as part of the RFC 1797 experiment. Attached is a report fragment on it's performance: "My root server has processed 400,000,000 queries in the last 38 days, and well over half of them were to the temporary 39.13.229.241 address (note that I retained the old 192.5.5.241 address since I knew a lot of folks would not update their root.cache files and I didn't want to create a black hole.)" - Paul Vixie Initial predictions[3] seemed to indicate that the safest path for an ISP that participates in such a routing system is to have -all- of the ISP clients be either: a) singly connected to one upstream ISP OR b) running a classless interior routing protocol Problems & Solutions Operations There were initial problems in at least one RIPE181[4] implementation. It is clear that operators need to register in the Internet Routing Registry (IRR) all active aggregates and delegations for any given prefix. Additionally, there need to be methods for determining who is authoritative for announcing any given prefix. It is expected that problems identified within the confines of this experiment are applicable to some RFC 1597 prefixes or any "natural" class "A" space. Use of traceroute (LSRR) was critical for network troubleshooting during this experiment. In current cisco IOS, coding the following statement will disable LSRR and therefore inhibit cross-provider troubleshooting: no ip source-route We recommend that this statement -NOT- be placed in active ISP cisco configurations. In general, there are serious weaknesses in the Inter-Provider cooperation model and resolution of these problems is outside the scope of this document. Perhaps the IEPG or any/all of the national or continental operations bodies[5] will take this as an action item for the continued health and viability of the Internet. Routing A classic cisco configuration that has the following statements ip route 39.1.28.0 255.255.255.0 router bgp 64000 redistribute static will, by default, promote any classful subnet route to a full classful route (supernet routes will be left alone). This behaviour can be changed in at least the following two ways: 1: ip route 39.1.28.0 255.255.255.0 router bgp 64000 no auto-summary redistribute static 2: ip route 39.1.28.0 255.255.255.0 router bgp 64000 network 39.1.28.0 mask 255.255.255.0 redistribute static route-map static-bgp .... route-map static-bgp match ip address 98 Users of cisco gear currently need to code the following two statements: ip classless ip subnet-zero The implication of the first directive is that it eliminates the idea that if you know how to talk to a subnet of a network, you know how to talk to ALL of the network. The second is needed since it is no longer clear where the all-ones or all-zeros networks are[6]. Other infrastructure gear exhibited similar or worse behaviour. Equipment that depends on use of a classful routing protocol, such a RIPv1 are prone to misconfiguration. Tested examples are current Ascend and Livingston gear, which continue to use RIPv1 as the default/only routing protocol. RIPv1 use will create an aggregate announcement. This pernicious use of this classful IGP was shown to impact otherwise capable systems. When attempting to communicate between an Ascend and a cisco the promotion problem identified above, was manifest. The problem turned out to be that a classful IGP (RIPv1) was being used between the Ascends and ciscos. The Ascend was told to announce 39.1.28/24, but since RIPv1 can't do this, the Ascend instead sent 39/8. We note that RIPv1, as with all classful IGPs should be considered historic. This validates the predictions discussed in [3]. Cisco Specific Examples There are actually three ways to solve the unintended aggregation problem, as described with current cisco IOS. Which of them applies will depend on what software version is in the router. Workarounds can be implemented for ancient (e.g. 8.X) version software. o Preferred solution: turn on "ip classless" in the routers and use a default route inside the AS. The "ip classless" command prevents the existence of a single "subnet" route from blocking access via the default route to other subnets of the same old-style network. Default only works with single-homed ISPs. o Workaround for 9.1 or later software where the "ip classless" command is not available: install a "default network route" like this: "ip route 39.0.0.0 255.0.0.0 next-hop" along the axis the default route would normally take. It appears an ISP can utilize the "recursive route lookups" so the "next-hop" may not actually need to be a directly connected neighbour -- the internal router can e.g. point to a loopback interface on the border router. o Workaround for 9.0 or older software: create a "default subnet route": "ip route 39.x.y.0 next-hop" combined with "ip default-network 39.x.y.0", otherwise as the 9.1 fix. Both of the latter solutions rely on static routes, and in the long run these will be impossible to maintain. In some topologies the use of static routes can be a problem (e.g. if there is more than one possible exit point from the AS to choose from). Recommendations: The RFC 1797 experiment appears to have been a success. We believe it safe to start carving up "Class A" space, if the spaces are delegated according to normal IR conventions[7] and recommend the IANA consider this for future address delegations. Credits: Thanks to all the RFC 1797 participants. Particular thanks to Paul Vixie, Geert Jan de Groot, and the Staff of the IETF33 Terminal room. Other thanks to ACES, MCI, Alternet, IIJ, UUNET-Canada, Nothwestnet, BBN-Planet, cisco systems, RIPE, ESnet, Xlink, SURFnet, STUPI, Connect-AU, INBEnet, SUNET, EUnet, InterPath, VIX.COM, MindSpring. Especial thanks to Suzanne for cleanup. References: [1] IANA, "Class A Subnet Experiment", RFC 1797, ISI, April 1995 [2] H. Eidnes, G. J. de Groot, "Classless in-addr.arpa delegation", Work in Progress, SINTEF RUNIT, RIPE NCC, May 1995 [3] G. Huston, "Observations on the use of Components of the Class A Address Space within the Internet", Work in Progress, AARnet, May 1995 [4] T. Bates, et.al, "Representation of IP Routing Policies in a Routing Registry", RFC 1786, MCI, March 1995 [5] http://info.ra.net/div7/ra/Ops.html, November 1995 [6] F. Baker, Editor, "Requirements for IP Version 4 Routers", RFC 1812, cisco systems, June 1995 [7] K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, "INTERNET REGISTRY GUIDELINES", Work in Progress, InterNIC, APNIC, RIPE, November 1995 Security Considerations: Security was not considered in this experiment. Editor Address: Bill Manning Information Sciences Institute University of Southern California 4676 Admiralty Way Marina del Rey, CA 90292-6695 USA Phone: +1 310-822-1511 x387 Fax: +1 310-823-6714 EMail: bmanning(a)isi.edu -- --bill

3 2