- Test - lists.nanog.org

a.gtld-servers.net
by Newell, Tom 22 Jun '00

22 Jun '00

The Network Solutions Registry identified a problem with one of its generic Top Level Domain servers (a.gTLD) that caused negative responses to some DNS lookups for the com zone only between 00:30 and 9:30 EDT on Thursday, 6/22/2000. Although the problem has been resolved, DNS name servers with MAX-NCACHE-TTL parameter set to anything other than the default value may need to have named restarted to correct any possible negative responses to valid domain names. Mark Rippe VP, Operations Tom Newell VP, Registry DNS Programs

1 0

Re: exchange point media (was: Re: MAE-EAST Moving? ...)
by Jeff Haas 22 Jun '00

22 Jun '00

I was heard to say a few days ago: > Please be aware that any traffic passing through FDDI XP's using > DEC gigaswitches is biased. These switches break path mtu discovery. This was in the context of measuring packet size in the Internet. After receiving a couple notes asking for clarification, I figured it was worthwhile to pass the same info back on to NANOG. Should one install a (fast|gig)ethernet card into one's Gigaswitch and said switch have FDDI interfaces, the switch will go from having a 4500+ byte MTU to a 1500 byte MTU. This is even between FDDI card to FDDI card on the same switch. The switch will happily fragment the packet if you leave DF off. However, if you turn it on, the switch will drop the packet silently. The switch is unable to generate ICMP and route it back to the sender. Given all of this, PMTU-D breaks in these circumstances. This is important because at least two XP's that I run route server service experienced problems due to this - Mae-West and PAIX. PAIX solved the problem by heavily encouraging customers to get off the Gigaswitch - I don't know if its still in service. Mae-West (SJ) still has this issue to the best of my knowledge. Mae-West (NASA) has been migrating to a SSR fast ether network to get off the Gigaswitches. Collectively, Mae-West still has this issue when transiting across the bridge. So, to make a long story short, try some PMTU probes on your switched fabric before trusting statistics about packet sizes. IM(probably undereducated)O, larger MTUs are not going to do you a lot of good across public exchange point fabric for a long time to come. Large MTU's across private interconnects, or specially targeted interconnects between "Service Providers" will probably be of greater benefit. -- Jeffrey Haas - Merit RSng project - jeffhaas(a)merit.edu

3 2

Re: using IRR tools for BGP route filtering
by Jessica Yu 22 Jun '00

22 Jun '00

If every ISP does prefix based filtering on its downstream customers, the integrity of the Internet routing system will be improved a lot. The document below proposes such a model: http://www.iops.org/Documents/routing.html --Jessica --- Danny McPherson <danny(a)tcb.net> wrote: > > > > i emphatically DO NOT think that large providers > should filter other > > peers. i think the large providers should filter > their own announcements, > > by carefully verifying what a downstream wishes to > announce before > > accepting it, filtering the customer > announcements, and aggregating their > > announcements to peers. > > I believe Randy's point is that it'd be really nice > to filter prefixes > learned from peers, but even if the routing > databases were up to date, > reliable and useful, the routers can't perform the > policy matches against > filters fast enough. > > And I agree completely. The fact that pretty much > any network with an > AS number could take any Internet subnet completely > offline in a matter > of -- what, ~8 minutes(?), intentionally or > unintentionally, well, > I think it's pretty amazing. The only way a service > provider can protect > their customers from this is by applying > prefix-based filtering to all > their peers. > > > Of course, this requires valid, accessible, up to > date IP registration > information. It also routers that can store > hundreds of thousands of > lines of policies. Then, the routers have to be > able to perform matches > on the policies when processing updates. All this > is at the "control > plane". > > Then, ideally, the routers would be able to utilize > the same set of > policies to perform packet filtering functions in > the "data plane", > which is even more interesting. > > These two components alone would make the overall > Internet > infrastructure far more reliable and secure than it > is today, > no doubt. > > > i think its silly to try and regulate the world > from ones own corner. > > regulate your corner, and encourage others to do > the same. i don't care if > > said encouragement is by tacit agreememnt, or > bound up in legealese in > > peering agreements. > > I don't think it's silly at all to regulate the > policies one employs in > in their network in order to increase overall > destination availability > to ones customers. Policies of this nature only > require support of the > network that implements them. Other than requiring > peers to keep registry > information up to date, they impact the peer > networks no way whatsoever. > > -danny > > > __________________________________________________ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/

1 0

Re: using IRR tools for BGP route filtering
by Sean Donelan 22 Jun '00

22 Jun '00

I believe every major backbone has suffered a multi-hour service disruption due to another provider announcing blackhole routes. The most recent one was Sprint a couple of weeks ago when another major provider re-announced part of their network in Chicago. Its not just a risk from "small" providers like 7007. Most of the widely distributed bogus announcements pass through large providers like Spring and UUNET. Most bogus announcements only affect a single network customer, like the FCC web site, so some people just assume its usual Internet flakiness when they can't reach a network. Its strange to see carriers whose management wouldn't think of ignoring the LERG, believe its ok to risk extended service disruptions by announcing and listening to unfiltered, unauthenticated routing information. Are engineers keeping their managers' in the dark. Does management not know there is a potential solution to the problem. Or does their management really think its Ok their customers are at risk of losing service at any time due to unfiltered routes. When you speak with your Cisco sales rep, do you tell them one of the requirements is being able to filter the entire route table with multiple peers.

9 12

Re: using IRR tools for BGP route filtering
by Danny McPherson 22 Jun '00

22 Jun '00

> AS Path filtering would be much smaller than prefix based filtering. > Perhaps small enough to work on existing routers. These filters could also > be built using registry data, from the ASes that make up providers' as-macros. > Not a silver bullet, but probably significantly better than doing > nothing. Though it's certainly better than nothing, it does little more than ensure AS_PATH sequence and integrity .. it provides no protection against invalid announcements. -danny

1 0

Re: [apops] Re: RIPE NCC CIDR blocks - smallest allocations
by Mark Prior 22 Jun '00

22 Jun '00

http://www.apnic.net/db/RIRs.html . Interesting but it doesn't contain the data in Joao's posting nor does it contain the equivalent data from the other registries. Mark.

1 0

(fwd) FW: Duff root nameserver
by Simon Lockhart 22 Jun '00

22 Jun '00

This looks like it could be fun :) > microsoft.com. Server: a.GTLD-SERVERS.NET Address: 198.41.3.38 *** a.GTLD-SERVERS.NET can't find microsoft.com.: Non-existent host/domain - ---------- Forwarded message ---------- Date: Thu, 22 Jun 2000 12:36:32 +0100 (BST) From: ULCC Postmaster <Postmaster(a)ulcc.ac.uk> To: uk-mail-managers(a)ncl.ac.uk Cc: Postmaster <Postmaster(a)ulcc.ac.uk> Subject: Duff root nameserver For your enjoyment, it appears to us that one of the root nameservers has no information about the .com domains. UKERNA IT Support queried a problem with domain lookups and our investigation revealed that a.GTLD-SERVERS.NET is returning NXDOMAIN responses to .com lookups. Eg: dig microsoft.com @a.GTLD-SERVERS.NET. ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; microsoft.com, type = A, class = IN Bob Pockney ------- End of Forwarded Message -- Simon Lockhart | Tel: +44 (0)1737 839676 Internet Engineering Manager | Fax: +44 (0)1737 839516 BBC Internet Services | Email: Simon.Lockhart(a)bbc.co.uk Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/

1 0

Re: using IRR tools for BGP route filtering
by Danny McPherson 22 Jun '00

22 Jun '00

> i emphatically DO NOT think that large providers should filter other > peers. i think the large providers should filter their own announcements, > by carefully verifying what a downstream wishes to announce before > accepting it, filtering the customer announcements, and aggregating their > announcements to peers. I believe Randy's point is that it'd be really nice to filter prefixes learned from peers, but even if the routing databases were up to date, reliable and useful, the routers can't perform the policy matches against filters fast enough. And I agree completely. The fact that pretty much any network with an AS number could take any Internet subnet completely offline in a matter of -- what, ~8 minutes(?), intentionally or unintentionally, well, I think it's pretty amazing. The only way a service provider can protect their customers from this is by applying prefix-based filtering to all their peers. Of course, this requires valid, accessible, up to date IP registration information. It also routers that can store hundreds of thousands of lines of policies. Then, the routers have to be able to perform matches on the policies when processing updates. All this is at the "control plane". Then, ideally, the routers would be able to utilize the same set of policies to perform packet filtering functions in the "data plane", which is even more interesting. These two components alone would make the overall Internet infrastructure far more reliable and secure than it is today, no doubt. > i think its silly to try and regulate the world from ones own corner. > regulate your corner, and encourage others to do the same. i don't care if > said encouragement is by tacit agreememnt, or bound up in legealese in > peering agreements. I don't think it's silly at all to regulate the policies one employs in in their network in order to increase overall destination availability to ones customers. Policies of this nature only require support of the network that implements them. Other than requiring peers to keep registry information up to date, they impact the peer networks no way whatsoever. -danny

1 0

Re: maximum active vlans in a cisco 6509
by Julian Eccli 22 Jun '00

22 Jun '00

>okay, now let's change venue: >the hotel has copper pairs to all of the rooms that are terminated on a >dslam. this dslam has only ethernet out and on the segment can provision >each cable pair/customer to a vlan. these vlans are then aggregated into >10/100 switches in the basement uplinked to the corporate office via gige. >then all those customer vlans end up being bridged 1483 to atm pvcs into an >ssg. > I think you have been playing with Nortel far too long. This was there old model and a great way to get rid of their first generation DSLAM's which are the Star Hubs that hang off a DMS switch. Basically a DMS and Star Hub, the Star Hub connects to a Xylan O/S which does 1483B/R to a Shasta SSG-5000 which connect to a router and then the destination network...The DMS has a leased pipe to the star hub to provide the voice portion. xDSL only soultion up to 1.3 Meg and a seven foot rack can only support 500 subs and costs about $300,000 or something like that, a tad pricey and very little sub to space ratio and proprietary management software as well. Nortel's new Prometory DSLAM's should fare much better and are true ATM switches through and through instead of badly hacked DSL to Ethernet to ATM. Prometory's are nice boxes and they even do PNNI and allow for up to 128 VCC's per DSL port which can offer a ton of nice services to a destination node. We just got some in and ordered about 30+ more of these units, easy to set up and configure. >what box could possible aggregate all this gige, sar to atm, all the while >supporting thousands of vlans > >many thanks from hotel owners everywhere 8> > Well, unless your average hotel customer or possibly the Maid's are major bandwidth hogs (All those lonely people in those plush and warm hotels. Well, now we know why they are typing with only one hand!) and accessing FTP/Napster sites exclusively I don't think you would have to worry much about the BW utilization at this time. The thousands of VLAN's could be done with thousands of PVC's, just get rid of the VLAN's in this scenario for DSL. Each box that maybe has 500 DSL access ports will aggregate to either one or just a few PVC's for back haul to either be routed or aggregated again so I seriously doubt you will have thousands of anything in a single box, at least in the near future. Else some of the other comments about building out a building and using switch ports as VLAN'ed router sub interfaces works just great up to about 40-60 VLAN's per 100 Meg port on a VIP module (My experience from doing this) and with CAR you can even setup a poor man's Packeteer BW management for free! Have never gone over 150 VLAN's in a box, so I do not know the upper limit, although it is 250 to my understanding. Regards, Julian

1 0

Re: maximum active vlans in a cisco 6509
by Bob Biver 21 Jun '00

21 Jun '00

okay, now let's change venue: the hotel has copper pairs to all of the rooms that are terminated on a dslam. this dslam has only ethernet out and on the segment can provision each cable pair/customer to a vlan. these vlans are then aggregated into 10/100 switches in the basement uplinked to the corporate office via gige. then all those customer vlans end up being bridged 1483 to atm pvcs into an ssg. what box could possible aggregate all this gige, sar to atm, all the while supporting thousands of vlans many thanks from hotel owners everywhere 8> bob- > >If you put all of the users on separate switch ports, then would they be >able to snoop each other's traffic? At least the switches that I have seen >prevent this behavior unless you put a particular switch port in "monitor" >mode. > >As long as all rooms in this hotel are on separate switch ports, you would >basically be OK even without using VLANs. > >Yes, multicast sessions, ARP requests etc can still be snooped. > >Bora > > 2000-06-20-23:01:45 Roeland Meyer (E-mail): > > > > Bob Biver: Tuesday, June 20, 2000 7:28 PM > > > > the docs say max 250, is this informational or a limit of > > > > spanning tree? > > > > > > If I recall correctly, that's also real close to the maximum > > > number of physical connections to the chasis, with all modules > > > installed. Personally, I've never run anywhere near that number. > > > I don't think it is useful to have less than 2 members in a vlan. > > > You would also be surpassing the bandwidth limitations of that > > > chasis, even if all the connections were 100baseTX. > > > > For many uses, I think you certainly have a clear and reasonable > > point. But while I don't know what the original poster had in mind, > > I can fantasize a use for thousands of vlans, even on a switch that > > doesn't have thousands of distinct ports. And without necessarily > > exceeding available bandwidth. > > > > Lessee, suppose I were designing something like an > > internet-access-for-hotel-rooms, or thereabouts. Or suppose > > otherwise I had thousands of users who didn't trust each other, at > > all, who I didn't want to have sniffing each other's traffic, who > > were just wanting to share access to an internet connection, itself > > less than 100BaseT, maybe even much less. > > > > One way I could fantasize doing it would be to assign a separate > > VLAN to each port of as many different switches, interconnected with > > 802.1Q or ISL, as it took to provide ports to every room. Run one > > 802.1Q line into the one router in this picture, say a Linux box > > using iproute2 for traffic shaping. > > > > Ok, so maybe 6509s would be way overkill for this application, no > > way you need that kind of backplane bandwidth. But as circumstances > > emerge where you want to have a fully-routed network (next step up > > the protocol ladder from a fully-switched network --- each host gets > > its own dedicated router port) I can anticipate settings where VLANs > > might get abused in a most remarkable way. > > > > - -Bennett > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.0.0 (GNU/Linux) > > Comment: For info see http://www.gnupg.org > > > > iD8DBQE5UDpTL6KAps40sTYRAkSXAJ9zRIAdsIp1xjdS2Vl56WjTeNdmdgCghySl > > Z+zy1YE6u1OW3RopArzAkDg= > > =gFAm > > -----END PGP SIGNATURE----- > > > ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

3 2