Re: SNMP and BGP
Please ask your vendors to implement the bgp mib v2 draft.. or at least the received routes info. (draft-ietf-idr-bgp4-mibv2-02.txt) They already display it in their various CLIs. (juniper+cisco for example). They have the number available. it should be easy to reveal these in snmp for reliable accurate polling. - Jared On Fri, Mar 22, 2002 at 11:55:39AM +1100, Adam Spann wrote: > > Thanks to Everyone, > The answers were excellent :) > > I have gone through the mib definition file, and as Anne said in her > response, the information I was after is not stored in the mib, I was > looking to be able to get the total number of routes from a given Peer from > the Mib, in place of the 'show ip bgp sum' command, looks like I will be > stuck with that till a new object is added to the Mib. > > STill now that I have the information, I will be able to do some other > things using the mib which should be able to give me a lot more information. > > Thanks Everyone. > > Adam Spann. -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Network Outage
Well, I used to be a contractor for MCI/WCOM, so I know all the numbers to call and the names of people to ask for. They as a rule are very mysterious about anything outage related. The first rule to get better service, is always say OK to intrusive testing. I've had jacks go bad, and the bridge point isn't a wholesome indicator and the fault can be 2 inches away. Besides, I was hard down, all zeros, so it didn't matter. After some arm twisting at Bell Canada, they confirmed it wasn't on their side of the ditch, so I started calling people I know here. The usual characters at the WCOM NOC were calling and leaving useless messages on my answering machine, but I called Sardinia, and got them to check outbound, towards Canada, and they said the T3 looked wholesome, but he couldn't access it at T1 level. I did however, find my Ticket appended to some others, so I knew it had to be at a bigger pipe than my T1. I know where they can check at T1 level, at 3DE, (the old MFS site, where I used to work) so I called, and a girl I worked with told me they had a DS3 cross-connect cable failure earlier, and it was repaired. I called over to the transport desk, and they confirmed the circuit was outbound twords Canada. I put two and two together and when I called the NOC back (they hadn't called my pager as instructed when the cut was cleared) they said the problem had been cleared and the circuit restored. Turns out, the NYC stuff was independent of the Canada problem, (which was my top priority) and the NYC stuff cleared on its own about 15 mins after I talked to Sardinia. Never got a positive cause on that one, but its gone, so its ok by me. Theyre stretched so thin on manpower now, and rumors are flying theres to be another round of layoffs next week, groan. Anyway, all the circuits are back and wholesome, so Im happy...back up at 4:10pm At 19:59 3/21/02 -0500, you wrote: >What did you end up getting from them. I lost some ccts out of 60 Hudson >and they would not cough up to a problem, only hour later during a co-op >test did the problem "clear on its own". Any details you can provide would >be great. > > >- Original Message - >From: "blitz" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Thursday, March 21, 2002 3:00 PM >Subject: Network Outage > > > > > > Good day, > > There has been a MCI/Worldcom outage near the Sardinia, NY switching >site. > > I have been in contact with them since around 12:00 EST and they are > > presently trying to localize the problem. > > I've lost a couple international circuits to Canada, and some to NYC. I > > don't know if anyone else is experiencing similar problems. > > > > This is just a heads up for the list (and my first post..hello all) > > > > Marc Blitz > >
RE: Survey on IBGP persistent route oscillation problem
Hi Jac, I try to find a suitable bgp mib/oid for nearly one week, but failed. I have to say bgp v4 mib provide little help on this issue, neither cisco proprietary mib. So I have to turn to the "primitive" method. I use nc batch file ( netcat 1.1 for NT running in dos shell ) to read the "sh ip b s | inc table" output from each router, then a homemade perl script to analysis the router output and extract the table counter value, at last the perl script was called by mrtg as an external script. All the three parts are very small, and working well together for months. I've added some download link in the page (http://performance.cn.net:2003/), you can have them as your wish :-) regards, Yu Ning __ (Mr.) Yu Ning, Chief Engineer ChinaNET (AS4134) Senior Support Internet Dep. DCBU, China Telecom Beijing, P.R.China +86-10-62072357 Personal Page-> http://navidog.126.com __ |-Original Message- |From: Jac Kloots [mailto:[EMAIL PROTECTED]] |Sent: Thursday, March 21, 2002 10:08 PM |To: Yu Ning |Subject: RE: Survey on IBGP persistent route oscillation problem | | | | |Yu Ning, | |I took a look at your page and was wondering how you read the BGP table |version? do you use a snmpget command or do you have to login to |the router? | |If you use SNMP for this value, which OID is it you're using? | |Regards, | |Jac | |> Hi, |> |> We have a similar situation (RR + always-compare-MED off), and |the BGP table |> version keeps changing at 1K/min (http://performance.cn.net:2003/). I |> suspect some |> route meet the criteria of IDR-oscillation draft. But in real world, it's |> very hard to pick |> up the pattern depicted in the draft from a huge log of debug |bgp output. |> |> After several sample from the huge bgp log, I have the following |questions: |> |> 1. How many time do our operator really find and affected by the problem |> depicted |> in draft-ietf-idr-route-oscillation-01.txt £¿ |> |> 2. From my experience, most flapping seems to be oscillation route which |> escaped the |> eBGP damping protection. And for this, we need adjust damping |> parameters from |> RIPE 220 to make up. |> |> 3. Anyone see oscillation been magnified when injected into RR (cluster |> structure) ? |> |> |> 4. What's the typical bgp table change rate within your network ? From my |> observation at |>the major global looking glass, should be below 0.5K/min with some |> accidental surge. |> |> |> |> regards, |> |> Yu Ning |> __ |> |> (Mr.) Yu Ning, Chief Engineer |> ChinaNET (AS4134) Senior Support |> Internet Dep. DCBU, China Telecom |> Beijing, P.R.China +86-10-62072357 |> Personal Page-> http://navidog.126.com |> __ |> |> |-Original Message- |> |From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On |> |Behalf Of Susan Hares |> |Sent: Wednesday, March 20, 2002 8:23 PM |> |To: [EMAIL PROTECTED] |> |Subject: Survey on IBGP persistent route oscillation problem |> | |> | |> | |> | |> | |> |IBGP and Persistent Route Oscillation |> | |> |The Draft BGP Persistent Route Oscillation draft describes route |> |oscillation occurring in networks today. This draft can be |obtained at: |> | |> ||http://www.ietf.org/internet-drafts/draft-ietf-idr-route-oscillati |on-01.txt |> | |> |In order to evaluate how significant a problem the route |oscillation is, I |> |would like to get input from network operators. If you could |take a few |> |moments and fill out this survey, it would help in determining the |> |severity |> |of the problems. Any information solicited by this survey will remain |> |private. Summaries of this information will be sent to this |list and the |> |IDR working list. |> | |> | |> |Sue Hares |> |IDR co-chair |> | |> |> |> | |-- |Jac Kloots |Network Services |SURFnet bv | |
Re: Question re. SSH
On Wed, Mar 20, 2002 at 11:50:22AM -0500, Steve Sobol wrote: > > I have a customer who wants to get a static ip with his dialup. He uses SSH > extensively > and plans to do X11 forwarding, and if he gets disconnected and redials and > gets another > IP the previous sessions would be inaccessible. > > I can do static IP but I want to try to save the guy a couple bucks. :) > > Would a static IP be required to make sure he doesn't lose those X11 > sessions after a disconnect? > > Asking here because I figure my chances of getting an accurate answer are > better here than on > any of the other mailing lists I read. His best bet would be to use vnc - http://www.uk.research.att.com/vnc/ or one of its variants. Failing that, a pptp connection using RFC1918 addresses for the two endpoints could do the trick, but I'm not sure how X would deal with the icmp host unreachable messages that would be received when the pptp session goes down (would probably kill them). It should also be noted that vanilla vnc is not encrypted (but can be forwarded over an ssh connection or ssl'ized or ). -- Bob <[EMAIL PROTECTED]> | It's pretty good, if you don't think about it.
RE: SNMP and BGP
Thanks to Everyone, The answers were excellent :) I have gone through the mib definition file, and as Anne said in her response, the information I was after is not stored in the mib, I was looking to be able to get the total number of routes from a given Peer from the Mib, in place of the 'show ip bgp sum' command, looks like I will be stuck with that till a new object is added to the Mib. STill now that I have the information, I will be able to do some other things using the mib which should be able to give me a lot more information. Thanks Everyone. Adam Spann.
Re: SNMP and BGP
Yo Travis1
Or use the newer one from cisco: BGP4-MIB.my which claims to just
be from RFC1657. The OID can also be accessed by name as:
bgp := {mib-2 15}
RGDS
GARY
---
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676
On Thu, 21 Mar 2002, Travis Dawson wrote:
> I will send you the generic MIB file if you need it. Its on the cisco site
> listed as BGP4-MIB-V1SMI.my
Re: SNMP and BGP
The snmp root for BGP is .1.3.6.1.2.1.15 with the specific OID for which peer gave you the prefix at .1.3.6.1.2.1.15.6. There is also come stuff under enterprises.cisco but not much more info or at least I can't figure out where anything really useful is in the cisco bgp mib. (anyone else??) I will send you the generic MIB file if you need it. Its on the cisco site listed as BGP4-MIB-V1SMI.my I warn you to NOT do an snmpwalk on that table on a router with multiple full routing tables, it can take forever and will push the CPU on the router to the max (not a happy thing). Load a router with a partial table and poll that to test it out. Or if you just want what actually makes it into the routing table you might want to look at . 1.3.6.1.2.1.4.21.1 . Enjoy. At 03:11 PM 3/21/2002, Adam Spann wrote: >Hi Guys and Ladies, > >I was wondering if anyone had worked out how to SNMP poll a cisco router for >BGP information. >I know that Cisco has support for this but I can't work out the SNMP path to >actually reach the BGP Mib portion. > >I am looking to obtain the number of route prefixes recieved for a given BGP >Peer. I can currently do this using some perl. But I would like to move to >SNMP if possible. > >If anyone has any pointers, and ideally the actual MIB path to at least >reach the BGP Mib I would be greatful. > >Kind Regards, > > > >Adam Spann >Network Operations Engineer > >Email: [EMAIL PROTECTED] >Phone: 61 2 8304 9300 Fax: 61 2 9317 5856 >631-637 Gardners Road Mascot NSW 2020 >Web: www.au.psi.net -tdawson -Network Geek (Bit Pusher) -BlueMartini Software
SNMP and BGP
Hi Guys and Ladies, I was wondering if anyone had worked out how to SNMP poll a cisco router for BGP information. I know that Cisco has support for this but I can't work out the SNMP path to actually reach the BGP Mib portion. I am looking to obtain the number of route prefixes recieved for a given BGP Peer. I can currently do this using some perl. But I would like to move to SNMP if possible. If anyone has any pointers, and ideally the actual MIB path to at least reach the BGP Mib I would be greatful. Kind Regards, Adam Spann Network Operations Engineer Email: [EMAIL PROTECTED] Phone: 61 2 8304 9300 Fax: 61 2 9317 5856 631-637 Gardners Road Mascot NSW 2020 Web: www.au.psi.net
Re: Change management procedures
### On Thu, 21 Mar 2002 11:57:18 -0500 (EST), Greg Maxwell ### <[EMAIL PROTECTED]> casually decided to expound upon ### <[EMAIL PROTECTED]> the following thoughts about "Change management ### procedures": GM> More specifically, I'm interested in knowing how often blocking-type (i.e. GM> group consent before change) change management is used vs logging type GM> (i.e. recording the change during/after the fact so the change can be At my previous employ, we had two different tracks for CM. One handled domestic, and the other handled international. In both cases, blocking-type and logging-type procedures were used concurrently. CM meetings occured every other day with meeting agendas mailed out at least a day prior and covered events scheduled for at least a week out. GM> reverted, and for root cause analysis). Also, for blocking type change GM> management, I'd like to know how people deal with process latency, GM> emergency changes, approval group selection, etc (if indeed anyone uses GM> consent to manage top-tier staff, I haven't found anyone so far that does). Emergency and near-term events were also discussed in detail. As memory recalls, the CM process for normally scheduled events specified at least a week's notice for turnups and changes. In addition to the actual CM team, each group within engineering and operations (provisioning, network engineering, peering, first and second line ops, etc) had a representative. Each event and maintenance had a case number issued upon insertion of a change request into the system and a person (from the CM team) responsbile for tracking purposes. Process latencies were reported back through the representative of the issuer of the change and then handled on a case-by-case basis. Some changes required approval at different levels depending on whether or not any generic change-holds were in effect at the time. -- /*===[ Jake Khuon <[EMAIL PROTECTED]> ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Network Outage
Good day, There has been a MCI/Worldcom outage near the Sardinia, NY switching site. I have been in contact with them since around 12:00 EST and they are presently trying to localize the problem. I've lost a couple international circuits to Canada, and some to NYC. I don't know if anyone else is experiencing similar problems. This is just a heads up for the list (and my first post..hello all) Marc Blitz
Re: Survey on IBGP persistent route oscillation problem
> Beside, you have to run the command on a router that might hit the > problem it depends a lot on your peering locations and partners. > If you run Cisco commands on wrong router, you would not see any > problem and may get in wrong conclusion !! This is why you have to read the draft and understand where the problem _could occur. > Does not fix, but it would lower updates thus help to identify > update loops. I see these as entirely orthogonal -- but, OK. -danny
Re: Survey on IBGP persistent route oscillation problem
[EMAIL PROTECTED] disait : > > We have a similar situation (RR + always-compare-MED off), and the BGP table > > version keeps changing at 1K/min (http://performance.cn.net:2003/). I > > suspect some > > route meet the criteria of IDR-oscillation draft. But in real world, it's > > very hard to pick > > up the pattern depicted in the draft from a huge log of debug bgp output. > > It's actually quite trivial to identify. Have a look at: > > http://www.cisco.com/warp/public/770/fn12942.html As Yu said, it is not so easy. Most of the output in "show ip route bgp | include , 00:00" command match flapping updates that are getting "dampening candidates" !! Beside, you have to run the command on a router that might hit the problem it depends a lot on your peering locations and partners. If you run Cisco commands on wrong router, you would not see any problem and may get in wrong conclusion !! > > 2. From my experience, most flapping seems to be oscillation route > > which escaped the eBGP damping protection. And for this, we need > > adjust damping parameters from RIPE 220 to make up. > > Nope. Dampening doesn't resolve this because it occurs > intrA-domain. Does not fix, but it would lower updates thus help to identify update loops. Vincent.
Re: Survey on IBGP persistent route oscillation problem
> We have a similar situation (RR + always-compare-MED off), and the BGP table > version keeps changing at 1K/min (http://performance.cn.net:2003/). I > suspect some > route meet the criteria of IDR-oscillation draft. But in real world, it's > very hard to pick > up the pattern depicted in the draft from a huge log of debug bgp output. It's actually quite trivial to identify. Have a look at: http://www.cisco.com/warp/public/770/fn12942.html Juniper syntax would result in the same.. > 1. How many time do our operator really find and affected by the > problem depicted in draft-ietf-idr-route-oscillation-01.txt I know of more than a few, and would bet that if additional folks took the time to look, they'd realize it was occurring as well. > 2. From my experience, most flapping seems to be oscillation route > which escaped the eBGP damping protection. And for this, we need > adjust damping parameters from RIPE 220 to make up. Nope. Dampening doesn't resolve this because it occurs intrA-domain. > 3. Anyone see oscillation been magnified when injected > into RR (cluster structure) ? Not sure I understand what you mean by "magnified"? Have a look at the Cisco FN, it's useful in understanding and identifying the problem. -danny
Re: Internet Exchange Questions
> I know of 323 IXes today. > http://www.pch.net/documents/data/exchange-points/ep-in-addrs.xls Good to see AusBONE there, however it does seem that your recent public comments on AusBONE may need some clarification, specially when you have not bothered to seek any information from the people running it. There is no AusBONE Adelaide, it was/is SAIX, the South Australian Internet Exchange. Aside from that, you may wish to add an "under construction" for your Shanghai and Guangzhou (aka Canton) entries, and add a line for a possible in Wuhan. Most of the provincial capitals are planning some form of regional IXP, for hand off traffic on LCR/SPF. India, well, scrub the Enron entry. It's far more likely that the first real working IXP in India will be "east coast", possibly Chennai (aka Madras) or even Hyderabad. There is a private MPLA exchange in Colombo, Sri Lanka, I'll query the MD of the company there for a URL. I have not been able to get information on: Pakistan, Bangladash, Cambodia, Burma/Myanmar, Vietnam, Brunei, Nepal, Tibet and Bhutan. [Several of these countries have a state monopoly telco, which would explain the total lack of activity.] --- Terence C. Giufre-Sweetser +-+--+ | TereDonn Telecommunications Ltd | Phone +61-[0]7-32369366 | | 1/128 Bowen St, SPRING HILL |FAX +61-[0]7-32369930 | | PO BOX 1054, SPRING HILL 4004 | Mobile +61-[0]414-663053 | | Queensland Australia | http://www.tdce.com.au | +-+--+
Change management procedures
I'm interested in knowing if any service providers or commercial data-centers have any publicly available information on what change management systems and methodologies they use with their engineering staff on production systems. I've discussed this directly with a couple of operators and I'm now interested in getting a larger outlook. More specifically, I'm interested in knowing how often blocking-type (i.e. group consent before change) change management is used vs logging type (i.e. recording the change during/after the fact so the change can be reverted, and for root cause analysis). Also, for blocking type change management, I'd like to know how people deal with process latency, emergency changes, approval group selection, etc (if indeed anyone uses consent to manage top-tier staff, I haven't found anyone so far that does). Thanks for any information.
Re: csu /dsu
> what are the primary functions of a csu / dsu? keeping papers on your desk from blowing all over the place when someone opens a window
Re: csu /dsu
"c johnson" <[EMAIL PROTECTED]> writes: > what are the primary functions of a csu / dsu? http://www.tscnet.com/faq/internet/internetfaq006.html ---rob
RE: csu /dsu
http://www.commweb.com/article/COM20010807S0013/2 > -Original Message- > From: c johnson [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 21, 2002 7:46 AM > To: [EMAIL PROTECTED] > Subject: csu /dsu > > > > what are the primary functions of a csu / dsu? > > thanks. > > > > _ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com >
csu /dsu
what are the primary functions of a csu / dsu? thanks. _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
Re: ICMP filters again
On Wed, 20 Mar 2002, Donn Lasher wrote: > > At 05:16 AM 3/20/2002 -0700, Christopher E. Brown wrote: > >Is it just me, or are the Tripod member sited filtering type 3 ICMP > >again? (Think < 1500 octet MTU links and DF/FN) Donn, Use this tool: http://michael.toren.net/code/tcptraceroute/ tcptraceroute is a traceroute implementation using TCP packets. > > Would be nice if there was a "list" somewhere of sites that did this. Would > sure make troubleshooting customers complaining of "unreachable web sites" > a heck of a lot easier. (Think MLPS over 1514 byte pipes) > > > >
RE: Survey on IBGP persistent route oscillation problem
Hi, We have a similar situation (RR + always-compare-MED off), and the BGP table version keeps changing at 1K/min (http://performance.cn.net:2003/). I suspect some route meet the criteria of IDR-oscillation draft. But in real world, it's very hard to pick up the pattern depicted in the draft from a huge log of debug bgp output. After several sample from the huge bgp log, I have the following questions: 1. How many time do our operator really find and affected by the problem depicted in draft-ietf-idr-route-oscillation-01.txt £¿ 2. From my experience, most flapping seems to be oscillation route which escaped the eBGP damping protection. And for this, we need adjust damping parameters from RIPE 220 to make up. 3. Anyone see oscillation been magnified when injected into RR (cluster structure) ? 4. What's the typical bgp table change rate within your network ? From my observation at the major global looking glass, should be below 0.5K/min with some accidental surge. regards, Yu Ning __ (Mr.) Yu Ning, Chief Engineer ChinaNET (AS4134) Senior Support Internet Dep. DCBU, China Telecom Beijing, P.R.China +86-10-62072357 Personal Page-> http://navidog.126.com __ |-Original Message- |From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On |Behalf Of Susan Hares |Sent: Wednesday, March 20, 2002 8:23 PM |To: [EMAIL PROTECTED] |Subject: Survey on IBGP persistent route oscillation problem | | | | | |IBGP and Persistent Route Oscillation | |The Draft BGP Persistent Route Oscillation draft describes route |oscillation occurring in networks today. This draft can be obtained at: | |http://www.ietf.org/internet-drafts/draft-ietf-idr-route-oscillation-01.txt | |In order to evaluate how significant a problem the route oscillation is, I |would like to get input from network operators. If you could take a few |moments and fill out this survey, it would help in determining the |severity |of the problems. Any information solicited by this survey will remain |private. Summaries of this information will be sent to this list and the |IDR working list. | | |Sue Hares |IDR co-chair |
