April 2005 - Test - lists.nanog.org

AW: Getting a BGP table in to a lab
by John van Oppen 21 Apr '05

21 Apr '05

I agree... I have around 75 peers on a box that actually does the routing running quagga, and there appears to be no problem. My only issues have been with version upgrades having bugs in them, but those problems are due to my inadequate testing. I also utilize supervise scripts (daemontools)to keep all the The best feature is being able to use the same route maps I use on my cisco boxes. John :) -----Ursprüngliche Nachricht----- Von: Arnold Nipper [mailto:arnold@nipper.de] Gesendet: Thursday, April 21, 2005 2:09 PM An: Reeves, Rob Cc: nanog(a)merit.edu Betreff: Re: Getting a BGP table in to a lab On 21.04.2005 17:17 Reeves, Rob wrote > > Quagga is great for smaller implementations, but it doesn't scale very > well. It eats up a lot of CPU, so once you hit a certain number of > BGP peers, it may start intermittently flapping BGP sessions, or even > just crash the bgpd process entirely. For what numbers? I've two quaggas, ~150 peers each, doing as-path and *full* prefix filtering for each peer (Config is around 9MB). CPU is idle 99.x% mostly ... Arnold -- Arnold Nipper, AN45

1 0

RE: Getting a BGP table in to a lab
by Frotzler, Florian 21 Apr '05

21 Apr '05

Hi, Zebra is outdated, the successor is called quagga (at least on debian) and is capable of providing most of the vendor C BGP features, though MD5 autentication is still experimental I think. We used to push a handful of BGP full feeds on our quagga router and it didn't stumble a bit. OSPF also works quite well, btw. Florian > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Scott Morris > Sent: Donnerstag, 21. April 2005 02:50 > To: swm(a)emanon.com; 'Nathan Ward'; nanog(a)merit.edu > Subject: RE: Getting a BGP table in to a lab > > > Forget part of my reply here... I thought someone was > posting from the CCIE forum stuff I do. > > So disregard the lack-of-caffeine-induced, retarded command > about no router being able to support a full feed. :) > > My apologies.... > > Zebra is still a good idea though! > > Scott > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Scott Morris > Sent: Wednesday, April 20, 2005 8:42 PM > To: 'Nathan Ward'; nanog(a)merit.edu > Subject: RE: Getting a BGP table in to a lab > > > None of the routers that are tested in the lab are capable of > supporting a full BGP feed.... > > If you just want to play with BGP stuff, you can use Zebra > (unix) or go to www.nantech.com and get their BGP4WIN program. > > That may help you a bit more. > > Scott > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Nathan Ward > Sent: Wednesday, April 20, 2005 8:35 PM > To: nanog(a)merit.edu > Subject: Getting a BGP table in to a lab > > > I'm trying to come up with a way to get a full BGP routing > table in to my lab. > I'm not really fussed about keeping it up to date, so a > snapshot is fine. > At the moment, I'm thinking about spending a few hours > hacking together a BGP daemon in perl to peer with and record > a table from a production router, disconnect, and then start > peering with lab routers. > > Am I reinventing a wheel here? > > -- > Nathan Ward > > > >

1 0

RE: Getting a BGP table in to a lab
by Fergie (Paul Ferguson) 20 Apr '05

20 Apr '05

...or if you just want to look at BGP route/path stuff, try one of the route servers. Here's a good link: http://www.inetdaemon.com/tools/route_servers.html - ferg -- "Scott Morris" <swm(a)emanon.com> wrote: None of the routers that are tested in the lab are capable of supporting a full BGP feed.... If you just want to play with BGP stuff, you can use Zebra (unix) or go to www.nantech.com and get their BGP4WIN program. That may help you a bit more. Scott -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Yahoo mail ops contact
by just me 20 Apr '05

20 Apr '05

Please contact me offlist, did you decide to stop accepting mail from berkeley.edu? thanks, matt ghali --matt(a)snark.net------------------------------------------<darwin>< The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke

1 0

Re: Slashdot: Providers Ignoring DNS TTL? (fwd)
by Dean Anderson 20 Apr '05

20 Apr '05

BTW, while it looks like you've shown it to be traditional load balancing, I ought to explain that this is also not a very good idea. The loadbalancer is a single point of failure, usually. Loadbalancers are a good idea for stateful, high-work-request servers such as web servers running web-apps. This allows you to apply many servers to what then appears to be a single service. This is well worth the expense of a single point-of-failure, since what you really wanted was a single, bigger and exponentially more expensive server. The multiple small cheap servers with the load balancer give you that view. When the load balancer detects failure and drops that failed server, the loadbalancer isn't really offering "higher availability" than a single server, but is rather compensating for the fact that multiple small cheap servers will collectively crash more frequently. However, DNS service is comparatively low-work-request, and low latency. Generally, people are seeking high availability and load distribution for DNS caches. But the work of the traditional load balancer is probably comparable to the work of the DNS server. So the benefits of multiple DNS servers behind a single load balancer are probably negligible. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ---------- Forwarded message ---------- Date: Wed, 20 Apr 2005 14:13:33 -0400 (EDT) From: Dean Anderson <dean(a)av8.com> To: Crist Clark <crist.clark(a)globalstar.com> Cc: nanog(a)merit.edu Subject: Re: Slashdot: Providers Ignoring DNS TTL? On Wed, 20 Apr 2005, Crist Clark wrote: > Dean Anderson wrote: > > I'd rather expect this sort of behavior with anycasted servers... > > I would not expect this kind of behavior from an anycasted address. > You'd need a LOT of routing churn to see different caches every few > seconds. It's much more likely some kind of load balancer in front > of a DNS server farm. No, you are thinking of the (wrong) claims originally made by ISC about how anycast would affect TCP to an anycast authoritative server. ISC wrongly asserted that since BGP routes don't churn very fast compared with DNS TCP connection lifetimes, that there should be no problem with anycast and TCP. This view has been shown to be wrong in the face of Per Packet Load Balancing (PPLB) which has been demonstrated to work on BGP links by haesu(a)towardex.com. Further, I showed that if you have PPLB on interior (eg OSPF) links leading to different BGP peers, the problem also happens. Packets are sent on a per packet basis to different places. But caching servers are usually setup to load balance. Usually, the servers with the same IP address share an ethernet along with multiple routers. So the packets are switched on essentially a per-packet basis. Or possibly a per-arp basis that alters the MAC-based-forwarding behavior of a switch. This is fairly fine grained load balancing. > > With a cache, the behavior is confusing, but also harms DNS TCP support, > > just like that described for authoritative servers. > > I verified it wasn't anycast by trying to exploit this very issue. I > did a query that fell back to TCP while doing multiple small queries. > I ran a network capture to pick out the short quries that occurred while > the TCP query was going on. Short quries during the TCP connection > came back with verying TTLs indicating that I was talking to different > caches, i.e. different servers. Yet the TCP query continued without > any hiccups. This indicates there is some type of per-session load > balancing going on, not anycast routing. This additional information would seem to indicate they are behind a more traditional stateful load balancer, rather than anycast. Without your TCP connection, I don't think you could distinguish a traditional load balancer from an anycast cache setup. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000

2 1

Re: Slashdot: Providers Ignoring DNS TTL?
by sthaug＠nethelp.no 20 Apr '05

20 Apr '05

> While that setup may have worked well, it's not an anycast implementation > I would suggest that others follow. Having the same set of servers > announcing multiple IP addresses (assuming those addresses are both in the > same set of addresses given out to those doing dns lookups) leaves you > open to a failure mode where a single server stops responding to queries > but doesn't withdraw its routing announcement. If a user sees that server > as the closest instance of both DNS server IP addresses, they will see > that as a failure of "both" of their DNS servers. Agreed, that's a possibility. In practice it hasn't really turned out to be a problem for us. > A more reliable way of doing this is to have multiple anycast clouds with > their own servers, each serving a single service address. That way, an > incomplete failure (on query response but no route withdrawl) of a local > server for one service address won't have any effect on access to the > second service address. Yes, we have been doing some of this also. Part of the problem is the desire to spread the load among the servers: Some of this comes naturally from the different server locations in our network - but with 2 addresses per server we can also balance the load somewhat by announcing either one or two addresses per server. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Re: Slashdot: Providers Ignoring DNS TTL?
by sthaug＠nethelp.no 20 Apr '05

20 Apr '05

> > But caching servers are usually setup to load balance. Usually, the > > servers with the same IP address share an ethernet along with multiple > > routers. So the packets are switched on essentially a per-packet > > basis. > > Or possibly a per-arp basis that alters the MAC-based-forwarding > > behavior > > of a switch. This is fairly fine grained load balancing. > > This is complete news to me. Of course, I do not run most of the > caching name servers on the Internet, so what do I know. Do you? > > Would anyone who runs an anycast recursive name server care to supply > data points to support or refute Mr. Anderson's assertion? Our recursive name service, using anycast servers, is setup with 3 name servers at 3 different physical locations, with each server connected to a router at the same physical location. Each server handles two different anycast addresses. There is no per-packet load balancing involved. I can't speak for the rest of the net, of course - but our recursive anycast service has worked well for several years. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

This fall in LA
by Susan Harris 20 Apr '05

20 Apr '05

NANOG and ARIN are very pleased to announce our fourth joint meeting, to be held this fall in Los Angeles. Many thanks to Equinix, our host-- we'll look forward to seeing you Oct. 23-25 (NANOG) and Oct. 26-28 (ARIN.) I'm at ARIN's spring meeting now, and continue to be amazed at the importance the organization places on input from the community. Attending an ARIN meeting gives you a chance to help form IP addressing policy for Canada, the US, and several islands in the Caribbean and North Atlantic. At www.arin.net you'll find subscription info for email lists you can join to start getting involved in the policy development process.

1 0

RIPE NCC to begin allocating from 87/8
by leo vegoda 20 Apr '05

20 Apr '05

Dear Colleagues, This announcement is being sent to multiple lists. I apologise for duplicates. The RIPE NCC received the IPv4 address range 85.0.0.0 - 88.255.255.255 (85/8, 86/7 and 88/8) from the IANA in April 2004. We began making allocation from 85/8 in August 2004 and from 86/8 in March, this year. We expect to start making allocations from 87/8 in the next few weeks. We have been announcing two prefixes from 87/8: 87.192.0.0/16 and 87.255.248.0/21, which originated in AS12654. These announcements have now been withdrawn as we will start to allocate from this /8. We are currently announcing two prefixes from 88/8, from which we will allocate in a few months. Those announcements are: 88.192.0.0/16 and 88.255.248.0/21, originating in AS12654. Details of the BGP announcements, reachability tools and other information are available on our web site at: http://www.ris.ripe.net/debogon/debogon.html You may want to update any filters you have in place. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

Promosis? Who are these guys?
by Suresh Ramasubramanian 20 Apr '05

20 Apr '05

seen on a local linux mailing list - > It looks like some one broke into VSNL's name server and done some > harm to open source websites I'm now using Airtel's (mantraonline) > name server and able to browser the sites mentioned above any one have > any idea whats happening ??? while nslookup to the VSNL's name server > I'm getting 66.151.179.147 for all those sites. the list includes, > gnomefiles.org > gnome-look.org > gforge.org > mantisbt.org suresh@frodo 12:23:32 [~]$ whois 66.151.179.147 Internap Network Services PNAP-06-2001 (NET-66-150-0-0-1) 66.150.0.0 - 66.151.255.255 Promosis Inc. PNAP-BSN-PROMO-RM-01 (NET-66-151-179-128-1) 66.151.179.128 - 66.151.179.191 The promosis.com site, however, is an all flash site that says they've developed promo campaigns for Bose, Oracle, art.com, Forbes etc. Looks legit .. Any idea? Something that works when NS is changed couldnt be spyware on the guy's PC though he is a newbie to linux, and is surfing the net using firefox on a windows PC -- Suresh Ramasubramanian (ops.lists(a)gmail.com)

3 2