August 2005 - Test - lists.nanog.org

RE: Rip again!
by Chris Ranch 23 Aug '05

23 Aug '05

In case no one else has suggested it: the source MAC address will identify the source. Chris > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Scott Morris > Sent: Sunday, August 21, 2005 9:21 AM > To: 'Tom Sanders'; nanog(a)nanog.org > Subject: RE: Rip again! > > > How about the source IP? > > RIP v1 is sent to 255.255.255.255 broadcast. RIPv2 is sent > to 224.0.0.9 multicast. Both are local-link only, so won't > go THROUGH a router. The sending source IP will tell you > where they came from. > > If you're using VLANs (trunks), there won't be any issues. > If you're using > secondary addresses, this will depend on whose devices you > use. In the > Cisco world, packets will always be sourced from the primary > IP address on an interface. And if the receiving router > doesn't have a subnet matching the sender, packets/updates > are ignored. (Again, Cisco world you can use "no > validate-update-source" to override this check) > > But that gives you a tracking method on packets. > > Scott > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Tom Sanders > Sent: Sunday, August 21, 2005 12:13 PM > To: nanog(a)nanog.org > Subject: Rip again! > > > Hi, > > There isnt IMO a way in RIP to identify the source of the RIP > packet (the way we have Router ID in OSPF, system ID in ISIS, etc.) > > Now assume we have 2 vlans defined on an ethernet. Thus we > would have two IP interfaces, 1.1.1.1/24 and 2.2.2.2/24 and > both using the same physical interface. RIP is running on > both these interfaces. > > My doubt is that how will another router, which is configured > in the same way (2 vlans) be able to differentiate between > the RIP responses originated by 1.1.1.1 and 2.2.2.2? > > Thanks, > Toms > >

2 1

Re: 4-Byte AS Number soon to come?
by Yakov Rekhter 23 Aug '05

23 Aug '05

Hi, > On 23-aug-2005, at 11:53, Paul Jakma wrote: > > >The IDR draft is awaiting implementation report. > > If this is true, it's very distressing. The IDR draft awaits an implementation report in order to advance the draft to Proposed Standard. What is so distressing about this ? > Drafts are deleted after > about six months. That means that any implementations will be based > on a no longer existing specification. That's wrong in so many ways. Drafts are deleted after about six months *unless* the drafts are renewed (republished). The draft we are talking about is an *existing* specification (draft-ietf-idr-as4bytes-10.txt). Yakov.

2 1

4-Byte AS Number soon to come?
by Elvis DePaula 23 Aug '05

23 Aug '05

Anyone in the list has a good update on the IETF:draftietf- idr-as4bytes-10.txt ? Is the projection os AS Number exhaustion of 2011-2013 exaggerated or do we really have a potential big problem with a slow solution ahead of us? -Elvis.

7 10

BGP AS Sets in the wild
by Abhishek Verma 23 Aug '05

23 Aug '05

Hi, I was looking at route-views.routeviews.org for the BGP routes and i dont see any AS-Sets whatsoever. Are BGP routes with AS-SETs not generally leaked into the wild? Is this the case? I am under the impression that AS_SETs are generated whenever there are some routes that are aggregated. Is there any other way also to generate AS_SETs in BGP? Any clues. Thanks, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India

3 2

Question about propagation and queuing delays
by David Hagel 23 Aug '05

23 Aug '05

I was wondering what are the typical coast-to-coast propagation and queuing delays observed by today's backbone networks in North America. Is there any data/study which provides a breakdown of different components of such end-to-end delays in today's backbone networks? Thanks, David

11 17

RE: KVM over IP suggestions?
by nick.nauwelaerts＠thomson.com 23 Aug '05

23 Aug '05

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Kevin > Sent: Monday, August 22, 2005 10:27 PM > To: nanog(a)merit.edu > Subject: Re: KVM over IP suggestions? > > > We have a non-IP switch from Raritan and saw presentations on their > > IP KVM products. Seemed pretty impressive. One problem you may want > > to focus on is screen resolution since the video output must be > > converted to IP packets with a lower refresh rate. We're planning > > to buy a few of these switches for remote monitoring. > > The "IP Reach" video compression is bearable for installation and > recovery. Video quality is degraded, but unless you really cannot > stand moire patterns, it'll take an hour or so staring at the display > before your headache becomes unbearable. > > I have experience with Raritan's "Paragon IP Reach" products, and they > do work, but are expensive for such a low port density. Also it has > been very difficult to work with tech support to make the Paragon > product with a RADIUS server for OTP access control. > > The newer "Dominion" line may be better; I've heard some complaints > about their serial console products, nothing either way about KVM. We've tested Raritan's integrated KVM over IP + serial products for a while, but were less than impressed with their interface tools. Both the standalone client and the ActiveX client were prone to crashing, sometimes taking the raritan device with it. We've since junked the servers for which we needed the KVM over IP for in favor of HPs with advanced ilo or IBMs with remote supervisor cards, if which I'd recommend HPs offering any day. // nick

1 0

KVM over IP suggestions?
by Drew Weaver 23 Aug '05

23 Aug '05

Howdy, I'm looking for a way to give our remote users access to their servers, perhaps a KVM-IP solution. What we need is support for multiple users (more than 2), with access control that limits what users can connect to what ports on the KVM switch, and would allow you BIOS level access and os-installation type control over the server, would also be nice if it worked with windows and linux/unix based systems. Any suggestions would be helpful. Thanks, -Drew

10 11

Qwest PSTN problems / status page?
by Mike Lewinski 22 Aug '05

22 Aug '05

Is anyone aware of a network status page for Qwest PSTN. We have been told they are currently experiencing a major outage and "All calls are failing out-going" (which isn't true as I've made some calls, but am seeing intermittent congestion returned on our PRIs) I have also heard that it... "Seems to be on the public switching network.Seattle can call out, Minneapolis & Ohio can't." (We first noticed it WRT LD calls, and my first test was to OH and that succeeded, so whatever it is clearly is intermittent). Mike

3 3

RE: Qwest PSTN problems / status page?
by Nick Thompson 22 Aug '05

22 Aug '05

We are currently having outbound long distance issues via Qwest right now. A PSTN status page would be rather convenient at this moment. Nick Thompson ISP Administrator Multiband 2000 44th Street SW Fargo, ND 58103 -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mike Lewinski Sent: Monday, August 22, 2005 4:16 PM To: nanog(a)merit.edu Subject: Qwest PSTN problems / status page? Is anyone aware of a network status page for Qwest PSTN. We have been told they are currently experiencing a major outage and "All calls are failing out-going" (which isn't true as I've made some calls, but am seeing intermittent congestion returned on our PRIs) I have also heard that it... "Seems to be on the public switching network.Seattle can call out, Minneapolis & Ohio can't." (We first noticed it WRT LD calls, and my first test was to OH and that succeeded, so whatever it is clearly is intermittent). Mike

2 1

Re: Question about propagation and queuing delays
by Robert E.Seastrom 22 Aug '05

22 Aug '05

"Howard, W. Lee" <Lee.Howard(a)stanleyassociates.com> writes: > Do carrier ISPs classify their voice traffic as Really > Important, and everybody else's data as Best Effort? This > isn't just selfishness, since We All Know voice is less > tolerant of latency and jitter than TCP. We do? Try to keep a single-TCP-stream session over 500 mbit/sec of goodput halfway across the country sometime. Most of us who have VoIP boxes have 20ms or better jitter playout buffers. Ever (successfully) talk to someone over a GSM handset when their coverage was a little marginal? The human ear is a marvelous tool compared to a TCP timer. Apologies if "We All Know" was supposed to be a cue to sarcasm or irony... ---Rob

1 0