- NANOG - lists.nanog.org

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

Re: Routing wars pending?
by salo＠msc.edu 17 Nov '95

17 Nov '95

> From: Tim Bass (@NANOG-LIST) <nanog(a)dune.silkroad.com> > Subject: Re: Routing wars pending? > To: big-internet(a)munnari.oz.au > Date: Thu, 16 Nov 1995 23:39:20 -0500 (EST) > Cc: nanog(a)merit.edu > [...] > Only three? There are about double that amount I would like > to see you do differently, Paul. I just don't have the time > to always count the number of signatures nor worry when > others hit the group reply key in elm like you seem to. > [...] Personally, I would much prefer that you waste the time of some other mail list with this sort of chatter... -tjs

1 0

Re: Routing wars pending?
by Robert Moskowitz 17 Nov '95

17 Nov '95

At 08:22 PM 11/15/95 -0500, Vadim Antonov wrote: > >>Consider process migration. > >Any commercial OS out there which does process migration? Most >OS people became quite convinced that process migration does not >pay for itself. Vadim, In many areas you and Noel know a lot more than me. You are the eagles, I am only a hawk. But over in corporate networks, we have had much of this for years. In VTAM. Yes sessions do not survive rollovers, but reconnects go immediately to the new system. We have WORKED VERY HARD trying to manage this in DNS. Notify has helped and Dynamic will help more. But that is for host, not process. So we have to have multiple A records for different names and that breaks in-addr.arpa! GRRRRR...... Talk to my at Dallas and I will give you living examples of BBBIIIGGG mobile processes VERY mission critical..... Enough. I got to head over to the AIAG office. Talk to me about that also at Dallas. Robert Moskowitz Chrysler Corporation (810) 758-8212

5 4

Re: Routing wars pending?
by jnc＠ginger.lcs.mit.edu 16 Nov '95

16 Nov '95

<CIDRD is the wrong list for this: CIDRD is for *deployment*, not architectural debate. Please follow-up on Big-Internet.> From: Tim Bass Then, in parallel, CIDR was hailed as the 'way to help save B space [depletion] problems'. ... very surprised to learn that our vision of "completely portable" CIDR address space have been overshadowed by the success of CIDR in another problem area that only those with keen insight at the time could predict, routing table explosion. You keep saying this, but it is *NOT TRUE*. You didn't need "keen insight" to know it was coming, you only needed to be able to *read*, viz (from "Supernetting: an Address Assignment and Aggregation Strategy" RFC-1338, June 1992): As the Internet has evolved and grown over in recent years, it has become painfully evident that it is soon to face several serious scaling problems. These include: ... 2. Growth of routing tables in Internet routers beyond the ability of current software (and people) to effectively manage. ... It has become clear that the first two of these problems are likely to become critical within the next one to three years. This memo attempts to deal with these problems by proposing a mechanism ... So, the routing table problem was well known to be coming at the time that CIDR was under discussion, and the effects of CIDR on address allocation were pointed out in *great* detail in a discussion on the *main* IETF list (look in the archives for the thread "Re: Vote NO on R-L-G IP Address Allocation proposal", and in particular my message of "Sat Oct 31 19:26:04 1992", the infamous "fnortz" message, which pointed out in some detail why renumbering was inevitable). So, if anyone who are around then missed it, they have only themselves to blame. I am damned tired of people rewriting history. Please cease and desist before I become extremely upset. after all, CIRD was only to be an *interim solution* for a few years for B space depletion. IPv6 would take care of that. ... aggregation was now the accepted practice for solving most I problems and was not an *interium* or temporary fix, but was to be a core Internet solution. There is a certain amount of truth to this. CIDR did assume that some "better" fix was coming as part of IPng (and let's not forget, the CIDR debate predated the IPv6 debate - SIP only started to be discussed late that summer). However, as is now I hope obvious to everyone, it's impossible to have a single namespace which is both i) used directly for routing, and ii) identifies hosts directly. To get rid of "renumbering", the Internet needed to split "addresses" as host-identifiers from "addresses" as routing-names, and map one into another. No matter how hard I and some others argued for doing this, though, people didn't want to take that "radical" step of two namespaces. Everyone's moaning now about the painful consequences? Tough. (I take great delight in the fact that one of the principal opponents of splitting off the host-identification function is also one of the people most upset at renumbering. I expect by now, with hindsight to help his understanding along, the irony will have dawned on him.) Technically, the aggregation advocates were correct. Socially and politically, aggregation on a global cooperative scale has problems. Which is why we need *two* namespaces: one for the routing to do what mathematics forces it to, and one for the humans to be able to dork with. there are future social and political implementations of global aggregation that are negative. There are some very painful routing consequences, even with two separate name-spaces (e.g. things like inbound traffic bias), but these are technical problems which will only admit of technical fixes. We have to investigate various possible technical solutions, and weigh the costs of them against the benefit of doing it the way we'd like, but that debate has to be a purely technical one, *not* a policy debate. Now, let's see, where are my winterized, flame proof, long johns? After this email, I'm sure to need numerous layers :-) ;-) Hah! When I get *really* grumpy, you better have something better than miserable protective clothing! Try a bunker reinforced to +125 PSI blast overpressure! :-) Noel

9 8

Re: A very late draft...
by Paul Ferguson 16 Nov '95

16 Nov '95

Not meaning to pick nits, but this should read 'no ip source-route'. - paul At 11:45 AM 11/16/95 -0800, bmanning(a)ISI.EDU wrote: > Use of traceroute (LSRR) is critical for network troubleshooting. > In current cisco IOS, coding the following statement will inhibit > cross-provider troubleshooting: > > no ip source route > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso(a)cisco.com c i s c o S y s t e m s

1 0

AS690 advisory update
by Steve Heimlich 16 Nov '95

16 Nov '95

Folks, As previously mentioned, ANS is moving to a new configuration system which will eliminate the need for registering AS690 advisories with RIPE-181 route objects. Our initial deployment described below has gone well, and as a result we will freeze our aut-num (currently still machine generated based on advisories) on Friday, 11/17, at midnight ET (Saturday, 11/18, 5am GMT). Tuesday morning's AS690 config run will use the frozen aut-num. After this time, AS690 advisories will be ignored. Policy toward routes registered in the IRR will be based solely on origin AS. The origin AS will be expanded to the set of route objects registered for that origin AS; the resulting list of prefixes will be used in generating router configurations, as today. Refinement of AS690 import policies will begin on a per AS basis next week, starting with large origin ASes. The human readable version of the 18,000 line AS690 aut-num is currently available at: ftp://ftp.ans.net/pub/info/routing-stats/aut-num-as-690 Steve -------- To: nanog(a)merit.edu Subject: AS690 policy configuration changes Date: Mon, 06 Nov 1995 18:43:22 -0500 From: Steve Heimlich <heimlich(a)kingbee.ans.net> All, Starting with Friday [11/10] morning's config run, AS690 will pick up any route listed in various routing registries, including both those routes with advisories and those routes without advisories. ANS customers will not be affected by this change. Routes without advisories will be examined for origin AS and will inherit the most popular policy currently used for that AS. For example, if a route for 147.225/16 (origin AS1660) were listed without an advisory, we would configure ourselves to listen for 147.225/16 in the same way that we listen to most other AS1660 routes (only from AS 1324 in this case). If a route is registered in an AS for which we don't have existing policy, it will not be routed. In the example above, if 147.225/16 were registered without an aggregate, and it were the only route registered with origin 1660, then we will not route it. We have a tool which flags such new ASes, and policy toward them will be created regularly. The rate of growth in number of ASes is not high, particularly relative to the rate of growth in number of routes. For now, we will continue to build our policy dynamically from the advisory attributes. Assuming that this hybrid deployment goes well, we intend to freeze our policy and convert to a system which ignores advisories altogether. With this system, the mechanics of shifting policy will be quite easy (essentially involving only ANS). I expect to announce that freeze and shift in the next week or so. At that point, those folks who want to strip AS690 advisories from any database may do so without a problem; as mentioned above, any advisories registered after that time will be ignored. Steve

4 5

A very late draft...
by bmanning＠ISI.EDU 16 Nov '95

16 Nov '95

Needs serious polish... Comments? -------------------------------------------- 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 This memo documents some experiences with the RFC 1797 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[x]. Internet Services offered over the RFC 1797 experiment were: FingerD HTTPD Telnet FTP server/client Gopher DNS F.Root-Servers.Net, a root name server had an interface as part of the RFC 1797 experiment. Here is a report 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.)" Inital predictions[x] seemed to indicate that the safest path is for an ISP is to have -all- of the ISP clients to be either: a) singly connected OR b) running a classless interior routing protocol Operations There were inital problems in at least one RIPE181 implementation. It is clear that operators need to register in the IRR all active or registered 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 may be applicable to RFC 1597 prefixes. Use of traceroute (LSRR) is critical for network troubleshooting. In current cisco IOS, coding the following statement will inhibit cross-provider troubleshooting: no ip source route In general, there are serious weaknesses in the Inter-Provider cooperation model and resultion of these problems are outside the scope of this document. Routing issues. If you have: ip route 39.1.28.0 255.255.255.0 router bgp 701 redistribute static then ciscos will, by default, promote any classfull subnet route to a full classfull route (supernet routes will be left alone). 1: ip route 39.1.28.0 255.255.255.0 router bgp 701 no auto-summary redistribute static 2: ip route 39.1.28.0 255.255.255.0 router bgp 701 network 39.1.28.0 mask 255.255.255.0 redistribute static route-map static-bgp route-map static-bgp match ip address 98 AGSs that have just partial routes (& a default) were problematic. Users of cisco gear currently need to code the following two statements: ip classless The implication of this directive is that it elmininates 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. ip subnet-zero Ascend default behaviour will create an aggregate announcement. The problem turned out to be that we were using a classfull IGP (rip) between our Ascends and our ciscos. The Ascend was told to announce 39.1.28/24, but since rip can't do this, the Ascend instead sent 39/8. This meet the predictions that were made early on. there are actually three ways to solve the subnet A problem, as described with current cisco's software. Which of them applies will depend on what software version you have, but a workaround can be implemented for ancient (e.g. 8.X) version software. o Preferred solution: turn on "ip classless" in your routers and use a default route inside your 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. 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 your default route would normally take. I think you can utilize the "recursive route lookups" so the "next-hop" may not actually need to be a directly connected neighbour -- you can e.g. point to a loopback interface on your 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 you have more than one possible exit point from your AS to choose from). Recommendations: The RFC 1797 experiment appears to have been a success. It is safe to start carving up "Class A" space, if the spaces are delegated according to normal IR conventions[x]. References: rfc1466bis rfc1797 draft-degroot draft-huston Security: Authors Info: -- --bill

1 0