- Test - lists.nanog.org

Re: FW: Re: Loss of BGP peering monitoring via SNMP
by k-ueda＠mms.mt.nec.co.jp 11 Jun '97

11 Jun '97

I could not find out " .iso.org.dod.internet.mgmt.mib.15" group in MIB1(RFC1156),MIB2(RFC1213). Could you tell me RFC-No. of MIB which have this group. > >I have written a simple perl script that uses SNMP polling to check the >status of some of our BGP peerings from Cisco routers. Unfortunately, the >script is closely tied to our configuration information so it's not >appropriate to post as is. As I'm in Tampa, I don't have all my >documentation on the MIB variables I used. > >To get you started, here are the hybrid text/numeric OIDs used by the >script to poll the applicable data out of the tables: > > .iso.org.dod.internet.mgmt.mib.15.3.1.7 BGP Peer Remote Address > .iso.org.dod.internet.mgmt.mib.15.3.1.2 BGP Peer FSM State > .iso.org.dod.internet.mgmt.mib.15.3.1.15 BGP Peer FSM Transitions > >The premise of the script is to poll periodically for the state of each >peer. If the state is different than the last poll or the count of >transitions was incremented (indicating a peering went down and was >reestablished between polls) a warning message is sent to a list of >recipients. The Peer Remote Address table is used to dynamically discover >new peerings. > >Other replies have mentioned the use of BGP traps. Traps are probably the >better way to go -- we, unfortunatly, have some issues with our current >trap collection that didn't allow us to easily add the BGP processing. > >- Doug > > / Douglas A. Junkins | Network Engineering \ >/ Sr. Network Engineer | NorthWestNet \ >\ junkins(a)nwnet.net | Bellevue, Washington, USA / > \ +1-425-649-7419 | / > > >On Thu, 5 Jun 1997, Curtis Generous wrote: > >> We have been caught several times lately with some of our border routers >> loss of BGP peering going undetected for sometime. Is there a way >> to enable BGP peering loss monitoring via SNMP from a CISCO router? >> I've looked at both the public and private MIBS but haven't found anything. >> >> I am aware of the 'nocol' package but really was hoping for an SNMP based >> approach to tie into our net-mgmt packages (sunnet and hpov). >> >> TIA >> >> --curtis >> -- >> Curtis Generous generous(a)uucom.com Phone: (703) 461-1350 >> UUcom Inc., Suite 250, 4875 Eisenhower Avenue, Alexandria, VA 22304-0797 >> > > > >------- End of Forwarded Message > > ________________________________________________ NECマルチメディアサービス構築運営本部植田晃市 e-mail : k-ueda(a)mms.mt.nec.co.jp tel : 03-3798-6085 fax : 03-5440-7297

1 0

Re: NSP ... New Information
by Eric Germann 11 Jun '97

11 Jun '97

At 01:36 PM 6/4/97 -0400, you wrote: >Well, that was interesting. > >Thanks to everyone who has responded thus far. I've gotten a lot of >"sale" types of email, but also a lot of really good information. > >It appears as if I was right in my assumption that I needed to get my own >IP block of PI space from the InterNIC. > Isn't the biggest problem with PI space having a big enough network so Sprint and everyone else doesn't filter you? Specifically a /19 or larger (~ 8000 addresses)? Can you justify to them 32 Class C's so you can be seen everywhere? I know of another startup provider who had this problem. Its a chicken and egg scenario. They needed to sell connectivity, but couldn't reach portions of the net, specifically Sprint. Kind of kills your marketing when you can't get to the entire 'Net. How do others deal with this scenario in a startup environment, or even an established environment where you can't justify 8000 addresses yet? Eric

24 37

64/2 allocations?
by Stephen Sprunk 11 Jun '97

11 Jun '97

This message is rather dated (LA IETF), but I haven't seen anything lately on the same topic, nor do there seem to be any relevant RFCs; could anyone perhaps point me to more recent discussions and/or plans to implement the below scheme? Does anyone have projections on when 192/3 will actually be exhausted at the current allocation rate? Does anyone believe the opening of 64/2 (or more likely, a segment thereof) will cause a change in allocation policies or routing filters? Is anyone aware of any problems with current equipment in the major providers that would preclude the deployment of 64/2 CIDR blocks? Has anyone considered the possible effects of IP space being marked "atomic"; that is, not allowed to be sub-allocated to another AS (and therefore hopefully precluding route explosion). Non-atomic allocations could still be made from the 204/6 swamp to support multi-homing for ASes not worthy of a /19 (or whatever the policy is today). Stephen >To: Michael Dillon <michael(a)memra.com> > Subject: Re: Allocation of IP Addresses > From: Paul Ferguson <pferguso(a)cisco.com> > Date: Wed, 13 Mar 1996 19:15:44 -0500 > Cc: Jim Browning <jfbb(a)atmnet.net>, "'com-priv list'" <com-priv(a)psi.com>, "'NANOG > List'" <nanog(a)merit.edu>, "'NIC Registry list'" <nic-registry(a)internic.net> > Sender: owner-nanog(a)merit.edu [snip] >Well, I knew this topic would come up sooner or later, since it was >discussed briefly in LA/IETF at the CIDRD WG meeting(s). > >A snippet from the LA/IETF CIDRD minutes: > >[snip] > >Yakov >Class A Allocation Guidelines >============================= >Motivation >Observation 1: 192/3 is 1/8 of the total IPv4 unicast space >Observation 2: 64/2 is 1/4 of total IPv4 unicast addrses space >Hypothesis1: at some point we will exhaust 192/3 >Hypothesis2: at some point we will need to allocate out of 64/2 >Observation3: It appears safe to allocate out of 64/2 based >on experience documented in RFC???? on Class A Experiment > >Recommendation >allocation of /17 or larger should be done out of 64/2 >allocation of /18 or smaller should be done out of 192/3 > >Comments? >Randy: Do you mean start this now? >YR: No, only when we decide it necessary. > >Eliot Lear: Can big ISPs get bigger blocks? >YR: Yes, it should allow them to. >EL: Do we need to advise Registries? >EL: Should 192/3 be declared unroutable? >YR: Perhaps part of it. >BManning: I would like to attach a rider on this. >I think before anyone gets anything out of 64/2 that they >should agree to give back their old blocks. >TonyLi: Is there some reason not to start alloc 64/2 immediately? >YR: We don't have to yet, so perhaps we should not. >TonyLi: Pressure from international carriers to get large blocks. >ELear: We should wait as long as possible to age legacy systems. >Tony: There weren't any big problems in the RFC. >BManning: Some things were not tested. Only routing protocols were tested. >We couldn't figure out a reliable way to test interior routing. >We should hold off a little longer before we jump into this. >NoelChiappa: We can't get rid of all the legacy systems. Is the >cost of hurting the legacy equipment less than the benefit of 64/2. > >[general discussion of when we should implement this. Now or >wait a little longer for legacy systems to expire.] >[discussion of route-able v unroute-able prefixes. Will certain >prefix ranges be declared unroute-able in future?] >MKosters: @home has a /14 out of net 24, so we have already >allocated out of Class A. > >BrianC: Suppose IANA decides to do this, and some joe-ISP >asks for a /14. We haven't given the Registries any guidance >on how to allocate. >RConrad: Policy most likely to remain the "power of 2" increase. >The size of the ISP is irrelevant with this scheme. >Cathy of @home complained that Sean won't take 24/14 only 24/8. >Sean Doran raised the issue of charging for prefixes. > >Tony advised we leave this for further discussion on the mailing list. > >[snip]

3 2

Re: NSP ... New Information
by Eric Kozowski 11 Jun '97

11 Jun '97

>Suppose that IP space were not a problem. When IPv6 comes up all around, >it certainly won't be then. You can have and waste all the IP space you >could imagine, since we'll be numbering every atom in the known universe. > >And suppose we have ASNs a plenty. > >Would Sprint, Digex, and AGIS still be trying to cut out so many routes? It has nothing to do with available IP address space. It is purely the number of routes in the "global" BGP routing table. Doing rout filtering a la Sprint is one way to enforce better aggregation and cut down on route table size. Also, in general, the longer the prefix, the more a route tends to flap. Route filtering is one way to help cust down on the number of BGP updates. > >Are any other ISPs doing this filtering? Yes. -- Eric Kozowski VP Internet Services eric(a)structured.net Structured Network Systems, Inc. (800)390-5945 Support A Verio Affiliate (800)881-0962 Sales/Info http://www.structured.net/ PGP Key fingerprint = 0A E4 91 B8 BD CB 3E 95 42 12 04 4E 14 DF 86 76 'They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.' -- Benjamin Franklin 1759

2 1

unreachable
by Bill Becker 11 Jun '97

11 Jun '97

Can't seem to reach any of cyberpromo's nameservers. Anybody know why? Bill

5 5

Livingston & BGP & multicast USENET (was blah blah blah)
by smd＠clock.org 11 Jun '97

11 Jun '97

bmanning(a)ISI.EDU writes: > Livingston has serious problems with its BGP code and > has since it was first available (going on six > months now) I don't suppose you'd care to elucidate? I'd be curious about how many updates/second this box can handle while forwarding across all interfaces at line rate, and how quickly from the receipt of an update switching to another path the forwarding engine begins sending traffic along that path, and how many christmas-tree packets flowing at line rates to a series of changing destinations are lost or mis-forwarded. Of course I tend to be interested in environments where traffic is already enormously aggregated, where all or nearly all the available bandwidth is being used, where dozens of BGP updates/second is commonplace, and where occasionally there will be "flutter" that causes large numbers of prefixes to attract data down oscillating paths. These are difficult conditions for any router, and unfortunately nobody seems to have a public benchmark which tests for them, other than the "it works/it doesn't" in the middle of large pieces of the Internet. I would be interested in actual "it works/it doesn't" commentary (and possible explanation of "it doesn't", if that's the case) involving this particular router from some sizeable ISP or other. Learning from vendor mistakes is of use to many of us. > > Will IP multicast help with the usenet stuff? > > Tangental question. Kurt Lidl and company's excellent MUSE paper, presented at USENIX in Winter 1994 details early attempts to distribute news via the MBONE. Unfortunately the MBONE is not IP multicast in any serviceable or saleable sense, and that and the work involved in making it difficult to forge multicast USENET news tends to make the distribution of news slower and less reliable than the parallel interactive unicast scheme. On the other hand, as there has been a great deal of work on eliminating multiple MBONE tunnels across providers, this both could be less true and less important for people who are concerned about the number of copies of articles moving across their networks. On yet another hand, it might make sense for "proper" multicast facilities to be deployed as supportable products before jumping into doing MUSE or something like it in a serious way. On yet another hand, satellite dissemination of news, both with pagesat-style distribution and sniffing at satellite point-to-point transmissions using amusing tcpdump scripts or programs directly using the berkeley packet filter, have been happening for some time. On the final hand, NNTP distribution is much less broken than Web distribution, and the latter distribution problem probably deserves to be attacked first. Oh yah, out of curiosity, what native multicast support is in the Livingston box, and what does it use for routing? PIM? DVMRP? CBT? Sean.

2 1

Multicast USENET News paper citation
by rja＠corp.home.net 10 Jun '97

10 Jun '97

(My apologies for following up on myself.) Someone suggested in private email that I should provide a full reference for the prior art on USENET/IP-Multicast back to the NANOG list. Here it is. However, this thread probably should migrate to some other (more appropriate) place like the mboned list and off of NANOG... Ran rja(a)home.net ---------------------------------------------------------------------- Author: Kurt J. Lidl Author: Josh Osborne Author: Joe Malcolm Title: Drinking from the Firehose: Multicast USENET News Pages: 33-45 Publisher: USENIX Proceedings: USENIX Conference Proceedings Date: Winter 1994 Location: San Francisco, CA Institution: UUNET Technologies, Inc. Abstract: News transport and spooling systems of the last several years have concentrated on decreasing the resource load on news servers. One beneficial side effect has been the average decrease in time that a news system spends on a given article. This paper describes a novel USENET news transport protocol, which we call Muse. The two major motivations behind Muse are to reduce the average propagation delays of articles on USENET and to further reduce the resource load on a centralized news server. Muse runs on top of the experimental Internet multicast backbone, commonly referred to as the Mbone. Major design and implementation issues are discussed. Security concerns of multicast news are discussed and our solution is examined. The problems of scaling news distribution to thousands of hosts are also addressed. ----------------------------------------------------------------------

1 0

Re: multicast USENET
by rja＠corp.home.net 10 Jun '97

10 Jun '97

On Jun 10 12:21, Aleph One wrote: % If anyone is really interested in writing a good reliable multicast % new protocol I suggest you read this internet draft: % % Title : The Multicast Dissemination Protocol (MDP) Framework % Author(s) : J. Macker, W. Dang % Filename : draft-macker-mdp-framework-02.txt % Pages : 14 % Date : 06/06/1997 Joe Macker happens to have freely distributable source code. Folks interested in MDP and IMM (not INN) might want to goto this URL: http://tonnant.itd.nrl.navy.mil/ipresearch/rm.html Folks seriously working on reliable multicast protocol design should look into the IRTF Reliable Multicast Research Group... All IMHO, Ran rja(a)home.net

1 0

Re: NSP ... New Information
by Eric Germann 10 Jun '97

10 Jun '97

The really annoying part of the whole "/19 or you are screwed" policy with respect to routability is the hoops the little guy has to go through to get address space. As has been quoted here earlier in this thread, Internic claims you need 100% utilization off the bat. However, none of the big guys seem to play by the rules for rational allocations. I have a client connected to MCI. They have five divisions on one campus. They have been allocated 5 class C's by MCI. They need exactly four addresses, one for the mailgate, one for the proxy, one for the Web server and one for the the router for each division. So their utilization is 4/256 or 1.5625%. Responsible allocation? I have a colleague who wanted dial on demand LAN routing. PSI offers it. He has a 2 node + router LAN. One for the router and one for each PC. Guess what he gets? A Class C. 3/256 or 1.17% utilization. Their reasoning, and I quote: "Its just easier for us to set up that way." Why doesn't Internic go back and pick on the big guys and start yanking their addresses. <underline>I'm all for conservation, universally applied.</underline> Ironic that the big guys waste the space and then filter the routes of the little guys who give their first three children to Internic to get PIA, isn't it. At 11:19 AM 6/10/97 -0400, Paul Ferguson wrote: >At 09:22 AM 06/10/97 -0500, Phil Howard wrote: > >> >>Right. But people see it as such a problem because the routing policies >>are IP space derived. When people are told they need a /19 to be routable, >>then they begin to go backwards on solving the IP space problem and resume >>wasting it (but hiding the waste to look like its used). >> > >But this is somewhat of a misnomer. It is not an issue of being >'routable' v. 'non-routable', but rather, one of whether you can >be aggregated into a larger prefix. This practice encourages >aggregation -- it is commonly agreed that Aggregation is Good (tm). > >The routability issue comes into play when: > > o You are specifically referring to routes being propagated by > a service provider who uses prefix-length filters, AND > > o You cannot be aggregated into a large enough advertised CIDR > block to conform to these types of filters. > > >>When the need to justify space usage occurred, along with it came some ideas >>on actually how to do that. And I see that working. We were projected to >>run totally out of space by now, and since we have not, I assume it did work >>pretty well. >> > >BGP4, CIDR, or Die. > >>But the real problem is routing policies that are encouraging people to go >>back to wasting space. By using the network size as the criteria for doing >>route filtering, the smaller guys get screwed and they see their solution >>as inflating their network. This practice needs to be stopped or a better >>solution needs to come out of it. >> > >One might suggest that some of the prefix length filter could be >replaced by more aggressive dampening policies. > >- paul > > >

1 0

Re: Livingston & BGP & multicast USENET (was blah blah blah)
by Eric Germann 10 Jun '97

10 Jun '97

At 11:21 PM 6/9/97 -0400, Sean M. Doran wrote: [snip] >> > Will IP multicast help with the usenet stuff? >> >> Tangental question. > >Kurt Lidl and company's excellent MUSE paper, presented at >USENIX in Winter 1994 details early attempts to distribute >news via the MBONE. > > [snip] >On the final hand, NNTP distribution is much less broken >than Web distribution, and the latter distribution problem >probably deserves to be attacked first. > Just released yesterday: A Protocol for the Transmission of Net News Articles over IP multicast. ftp://ds.internic.net/internet-drafts/draft-rfced-exp-rupp-01.txt Eric

2 1