- Test - lists.nanog.org

RE: Router Servers in a lab
by Yosi Yarchi 12 Apr '01

12 Apr '01

Hi I'm using mrtd for this purpose exactly. To begin with, I wrote small PERL script (route_stoa.pl) which takes "show ip bgp" output of cisco router (default free, found in the internet) and convert it to mrtd ASCII format. Then I patched the route_atob (route_atob.c) of mrtd package to read this file. I used sbgp to inject the full table into my router. Assuming that the "show ip bgp" dump file is ASproc.pl (this is actually the name I found it), the command should be (after trimming ASproc so only pure table exist): gunzip --stdout ASproc.pl | route_stoa.pl -i stdin -o stdout | route_atob -i stdin -o stdout | sbgp -i stdin .... Good luck Best Regards, Yosi Yarchi KereniX Data-Aware Optical NetworksTM ---------------------------------------------------------------------------- ------ Yosi Yarchi http://www.kerenix.com Phone: +972-3-9050783 Mobile: 972-58-512783 Fax: +972-3-9347720 mailto:yosi_yarchi@kerenix.com > 70 Pinsker St., Petach-Tikva 49221 ISRAEL ---------------------------------------------------------------------------- ------ > -----Original Message----- > From: mike harrison [mailto:meuon@highertech.net] > Sent: Wed, April 11, 2001 6:27 AM > To: Barrie Jones > Cc: Perry Jannette; Nanog1 > Subject: Re: Router Servers in a lab > > > > > i like mrtd better anyway, since it has the bgpsim tool. > it allows you > > to withdraw and announce routes to simulate flapping. has > frequency, > > jitter, all that fun stuff. > > (see www.mrtd.net) > > Downloading.... :) --Thanks > >

1 0

RE: gigabit router (was Re: Getting a "portable" /19 or /20)
by Kavi, Prabhu 12 Apr '01

12 Apr '01

Vendors have known how to solve this problem for many years. Failure to do so is a poor implementation and has nothing to do with centralized forwarding being better/worse than distributed forwarding. Prabhu ---------------------------------------------------------------------- Prabhu Kavi Phone: 1-978-264-4900 x125 Director, Adv. Prod. Planning Fax: 1-978-264-0671 Tenor Networks Email: prabhu_kavi(a)tenornetworks.com 100 Nagog Park WWW: www.tenornetworks.com Acton, MA 01720 > -----Original Message----- > From: Matt Zimmerman [mailto:mdz@csh.rit.edu] > Sent: Wednesday, April 11, 2001 4:47 PM > To: nanog(a)merit.edu > Subject: Re: gigabit router (was Re: Getting a "portable" /19 or /20) > > > > On Wed, Apr 11, 2001 at 12:26:54AM -0700, David Schwartz wrote: > > > > > Why do you think central fowarding is superior > to distributed > > > > forwarding? > > > > > > Because you will have consistency problem. You are nearly > 100% guaranteed > > > to have them. > > > > > > Alex > > > > Ahh, so that's what you're thinking. > > > > If you have forwarding table F(X) at time X and > forwarding table F(X+1) > > at time X+1, a packet that arrives between times X and X+2 can > > reasonably be forwarded by any of the tables. There is > no special > > sequencing present or required between the packets that > involve routing > > protocols and the data packets. > > I think Alex was referring to internal consistency within the > router (between > linecards), not external consistency. For example, if > linecard X believes that > a packet should be forwarded to linecard Y, but linecard Y's > forwarding table > is older than X's, Y could misforward the packet, causing a > forwarding loop or > a dropped packet. Thus, it can be the case that neither the > old path nor the > new path is taken. > > Yes, there are ways to approach this problem, but it is a problem that > central-forwarding systems will not have. > > > We misroute packets between routers because routing > table updates don't > > happen fast enough. It's not a problem -- IP is > designed to tolerate > > packet losses and has never guaranteed sequencing. > > It is true that IP does not make guarantees about delivery, > but packet loss has > a detrimental effect on performance nonetheless. > > > The added occasional misroutes due to inconsistency will be > > proportional to the ratio of the average network > transport time for a > > routing protocol packet to the average delay in > propogating forwarding > > table changes to a linecard. You do the math. > > I think a more useful model is this: > > S(X) = (% of time that a router X spends in a consistent state) * > (packets/sec through router X) > > For the percentage of packets which will be successfully > routed. The total > end-to-end loss is 1 - S(X)^N for N identical routers. N >= > 20 is not uncommon > these days, and packets/sec gets higher all the time. > > -- > - mdz > >

4 4

RE: gigabit router (was Re: Getting a "portable" /19 or /20)
by Kavi, Prabhu 12 Apr '01

12 Apr '01

Craig did a great job describing the problem and one valid approach to solving it. There are other valid approaches as well. Creating modern packet forwarding devices is based upon learning what did not work well in previous incarnations (such as how to synchronize these forwarding tables) and elmininating the problems (Too little bandwidth in the control plane? Add bandwidth) in the next version. Many vendors learned about the synchronized forwarding table problem years ago, either with experience on their own routers, or by getting talent from places (like BBN) that previously dealt with this. And any recent system architecture created by competent engineers should not have this problem. Prabhu > -----Original Message----- > From: Craig Partridge [mailto:craig@aland.bbn.com] > Sent: Thursday, April 12, 2001 10:16 AM > To: Matt Zimmerman > Cc: nanog(a)merit.edu > Subject: Re: gigabit router (was Re: Getting a "portable" /19 or /20) > > > > > In message <20010412100249.B15380(a)alcor.net>, Matt Zimmerman writes: > > >It _does_ show that distributed forwarding will be > significantly more complex > >and more difficult to implement. I am not arguing that > distributed forwarding > >is a bad thing; on the contrary, it has a logical and > demonstrated performance > >benefit. However, it comes with a cost in overall system complexity. > > Having implemented distributed forwarding once, and consulted on it a > couple of times, the answer is that it adds complexity but not where > you'd think. > > You usually only have to generate one forwarding table (the outbound > interface through which you send the packet doesn't change > depending on > whether you make the decision centrally or at the inbound interfaces). > You can try to reduce the size of the forwarding table by > excising stuff > (e.g., info on VPNs that don't run through that interface) > but forwarding > tables are pretty small so you don't have to do that if you > don't want to. > > Provided you don't do something stupid and have the outbound interface > re-evaluate the inbound interface's routing decision, then > all you need > is a way to copy the forwarding table to each interface (and if the > interfaces receive the table at slightly staggered times that's OK, > because they don't have to be perfectly consistent). > > Now I just said "all you need" -- that's a lie :-). The > major complexity is > actually getting the forwarding tables out to the inbound interfaces. > There are at least two issues: (a) bandwidth [a small > forwarding table, > times 32 or 64 ports rapidly becomes big, especially for the control > data path which is typically short on bandwidth] and (b) > finding a way to > update the forwarding table in a way that is not too > disruptive to forwarding > [incremental updates are often mindbreakingly hard to do, esp. if the > update changes the table size, or invalidates some entries -- you can > have the forwarding table doing housecleaning instead of forwarding]. > We used a bank swap -- we had an active forwarding table and > an inactive > one. Updates were sent to the inactive bank and when you had a fully > updated bank, you send a message to the forwarding processor saying > "swap banks." And, of course, the software to track which forwarding > engine had which bank live and the current state of each > bank's updates > got a little exciting. > > In short, generating the tables is easy, consistency isn't an issue, > but getting the tables to the right place, in a timely > manner, and without > getting confused and trashing a table, is a challenge. > > Thanks! > > Craig > >

1 0

Synthetic BGP routes in a lab
by Perry Jannette 12 Apr '01

12 Apr '01

Yesterday I sent out a message inquiring about a method to inject BGP routes into a lab network. Here is a follow-up message on what I learned. Thanks to everyone that replied. There are several methods to inject synthetic routes into a lab network. 1. MRT (Multi-Threaded Routing Toolkit) is a sweet of tools that allow you to perform several different functions with BGP. a. MRTd - an IPv4/IPv6 routing daemon b. SBGP - a BGP speaker and listener, no policy routing, etc... c. BGPsim - a BGP simulator used to inject instability into the BGP network d. route_atob - converts ASCII messages to MRT format e. route_btoa - converts binary MRT messages to ASCII format Check it out at www.mrtd.net. You can get a BGP table (sh ip bgp) from a route server and format it for use with MRT. Then inject these routes with SBGP. 2. Smartbits using SmartFlow I have not attempted either of these methods yet, but MRT seems like a fairly easy solution. Perry

2 1

RE: OT-ish: netsol facist contact info?
by Cerqua, Toby 12 Apr '01

12 Apr '01

*slap forehead* not nanog. netsol. right. -----Original Message----- From: John Fraizer [mailto:nanog@Overkill.EnterZone.Net] Sent: Thursday, April 12, 2001 9:37 AM To: Cerqua, Toby Cc: 'nanog(a)merit.edu' Subject: Re: OT-ish: netsol facist contact info? On Thu, 12 Apr 2001, Cerqua, Toby wrote: > > i've been trying to get through to nanog for months now to do a simple > address change. of course i used their form correctly -- several times, in > fact -- and i've exchanged emails with some lackey on the problem. once i > made the problem clear, communications dropped off sharply. anyone know a > contact with a clue? i'd rather get this done *before* the time runs out and > i lose the name. > > thanks much. of course, please respond off-list. > > -t > Um, are you sure you're trying to get through to NANOG? I think you've been trying to get through to NETSOL. If you're having problems with them and are worried about losing a domain because you can't update information, etc, might I suggest you do what large quantities of others are doing and simply transfer your domain AWAY from the low life %^&#ards? You can move your domains to a different registrar fairly simply. http://www.lowcostdomains.com/ --- John Fraizer EnterZone, Inc

1 0

CLEC Compensation appeal
by Henry R. Linneweh 12 Apr '01

12 Apr '01

US Supreme Court to Review State Telecom Case http://www.clec-planet.com/legal/cappuccio4-9.html -- Thank you; |---------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | | working group | | Resilient Packet Transport | | http://www.luminousnetworks.com | |---------------------------------| Henry R. Linneweh

1 0

Re: OT:Optical Splitters
by Martin Hannigan 12 Apr '01

12 Apr '01

As far as I know they aren't power, but they inject loss as a termination device. It should be a "wiring" issue. Feel free to ping me offline if you need more detail. The primary/protect is an equipment characteristic, not a splitter characteristic. You do have to "watch out" for providers that "forget" to drop in the protect or neglect to mention it, or charge more. It also depends where your gear is slung off the network i.e. a spur or a lateral to the network. -M At 11:09 PM 4/11/2001 -0400, Martin, Christian wrote: >Folks, > >Sorry for the slightly off-topic post. Is anyone familiar with optical >splitters that can run in a primary-backup mode in a passive way? The >intent is to provide GigE redundancy between a host and a pair of switches. >It needs to be able to switch over on a loss-of-link condition, and >preferably switch back once the primary comes online. Does such a thing >exist that runs without power? If not, is there a manageable, rackmount >solution with telco-grade reliability? > >TIA, >chris Regards, -- Martin Hannigan hannigan(a)fugawi.net Fugawi Networks Founder/Director of Implementation Boston, MA http://www.fugawi.net Ph: 617.742.2693 Fax: 617.742.2300

1 0

Re: solar flares effecting anyone else?
by Sean Donelan 12 Apr '01

12 Apr '01

On Wed, 11 April 2001, John Todd wrote: > From a terrestrial perspective, the recent solar flare activity would > have a much more noticeable effect on circuits that have long, > inductive (copper) loops that collect those pesky electron charges. > In North America, I imagine that this is mostly local loop issues, > since the majority (everything?) that is of any appreciable distance > is fiber. It is perhaps the case that the Canadians and Alaskans may > see more of an issue even on their short local loops, since the more > polar segments of the Earth bear the brunt of the storms (if I recall > my astronomy courses correctly.) April 2, 2001 Sol Solar flare April 3, 2001 Phoenix, AZ Under Investigation (Qwest) April 3, 2001 Elkton, MD Fiber Cut (ATT) April 3, 2001 Columbus, GA Under Investigation (Bellsouth) April 4, 2001 Northeastern US Power supply (Sprint) April 5, 2001 Dullas, VA Power supply (AOL/TW) April 6, 2001 Joilet, IL Power supply (Ameritech/SBC) April 6, 2001 Alamagorda, NM Fiber cut (Qwest) April 6, 2001 Jacksonville, FL Under investigation (Bell South) April 8, 2001 Loredo, TX Power supply (Southwestern Bell) Its probably not statistically significant, but the hit on power supplies after the recent solar flare did catch my eye. I don't recall a similar rise occuring in the past. But I can't compare the number of power supply problems to the same period last year because ATIS Network Reliability Steering Committee has removed all of its public reports from its free portion of the web site, and I don't really want to spend $50 to buy a copy.

1 0

solar flares effecting anyone else?
by Jim Mercer 12 Apr '01

12 Apr '01

i've got an E1 circuit that goes: Toronto -> Amsterdam (fiber) Amsterdam -> Islamabad (satelite) Islamabad -> Karachi (fiber) for the last couple days, my router has been seeing an abnormally high number of "carrier transitions". a parse of the log shows 400+ UPDOWN syslog messages from the cisco for today (4:pm Eastern), and some 400 for yesterday. prior to that maybe 0-10 a day. i've openned a ticket with the circuit provider, but by asking the list, i was hoping to be prepared for a "must be solar flares" excuse. -- [ Jim Mercer jim(a)pneumonoultramicroscopicsilicovolcanoconiosis.ca ] [ Reptilian Research -- Longer Life through Colder Blood ] [ aka jim(a)reptiles.org +1 416 410-5633 ]

4 6

RE: gigabit router (was Re: Getting a "portable" /19 or /20)
by alex＠yuriev.com 12 Apr '01

12 Apr '01

> CEF is not the only mechanism to implement distributed forwarding > (within or without Cisco for that matter), and to say that distributed > forwarding is faulty because of software complexities of one > manufacturer, whose code base is built upon on a monolithic core (to use > operating system would lower what it means to actually be a operating > system) is to generalize all failures to a distributed architecture > where the fault does not _always_ lie. CEF and dCEF periodically break on Cisco. They break in the most interesting ways - the debugging indicates that the packets are going one way when they in reality are going the other way. Without CEF or dCEF Cisco's are useless for the amount of traffic that I am interested in. Juniper is very interesting. The only problem is a gazillion strange things that it tries doing. Juniper's BGP has very intereting bugs in confederations which I have discovered on the day #1 of putting one of them into production. That bug is still not fixed. Since confederations are very widely used, and no one else found this bug, and yet we have hit it nearly immediately, there is some sort of logical problem here. If something as simple as AS_PATH prepending in confederations does not work, I have some big reservations about things that are much more complex than that. Nortel has some exellent hardware that they have inherited from Bay Networks. Unfortunately, they still have not written the software to take any advantage of it, nor they developed it to the level where it can actually complete with the new offerings from the other vendors. Thanks, Alex > While a central architecture is simple, it has been shown within and > beyond the industry that it does not scale. > > David > > > -----Original Message----- > From: alex(a)yuriev.com [mailto:alex@yuriev.com] > Sent: Wednesday, April 11, 2001 1:41 PM > To: nanog(a)merit.edu > Subject: RE: gigabit router (was Re: Getting a "portable" /19 or /20) > > > > > > > Vendors have known how to solve this problem for many years. > > Failure to do so is a poor implementation and has nothing to do > > with centralized forwarding being better/worse than distributed > > forwarding. > > Yet another person who does not understand the KISS principle. I am > sure in theory it all works great, though I am seeing way too many > comments > similiar to: > > "The connectivity issues have been resolved. This appears to be the > same > CEF related issues we experienced Monday evening, and we have a case > open > with Cisco. As we get more information from Cisco, we will be passing > it > along." > > Alex > > >

2 3