RE: route-views.routeviews.org down?
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Randy Bush Envoyé : mardi 22 novembre 2005 09:35 À : Edward W. Ray Cc : [EMAIL PROTECTED] Objet : RE: route-views.routeviews.org down? 1555 ms55 ms55 ms www.routeviews.org [128.223.61.18] he did not mean the web server. try route views, route-views.oregon-ix.net 128.223.60.103 as i peer with rv2 and not rv, i can not tell you how bgp sessions are. could some noc which peers with rv please check and report. and i tried some relevant mobile phones. no go. I (AS6453) see: gin-ldn-core1sh ip b s | i 6447 128.223.60.102 4 6447 126140 15302644 13717324100 6w0d 0 128.223.60.103 4 6447 233238 16068732000 01:03:48 Active gin-ldn-core1 mh randy
RE: [Latest draft of Internet regulation bill]
On Mon, 14 Nov 2005, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Sean Donela n writes: On Mon, 14 Nov 2005, Blaine Christian wrote: We are talking about an infrastructure that does not lend itself very well to market forces. In many places FFTH and/or DSL from a single carrier are becoming the only options. I would not count a 500ms satellite hop as an option grin. The cable industry claims 97% of the households passed in the US. Why don't you consider it an option? Do they claim to pass 97% with two-way cable? The cable industry claims 91% of households passed with two-way cable. Maybe in North America, yes. Are you sure?.. mh
RE: Vonage complains about VoIP-blocking
Was that a device trying to phone home and get it's configs? Cisco, Nortel, etc. phone home and get configs via tftp. Vonage doesn't need to phone home for config. The device is programmed (router) and it registers with the call manager. If you analyze the transactions it's about 89% SIP and 11% SDP. Vonage devices initiate an outbound TFTP connection back to Vonage to snarf their configs on initial connection and also (presumably) on reboot. Many, many VoIP devices do this, including Cisco phones in all major flavors. If an ISP is blocking TFTP originated by its customers at the border, this will cause numerous problems with many VoIP devices as well as numerous other things where a customer needs to initiate a TFTP session over the Internet. Filtering customer-initiated TFTP will cause problems with many legitimate applications and devices. Consequently, should unlikely or most likely not :) be filtered by (I|N)SP, IMHO. Who's (still) using TFTP for fragile tasks...? Cheers, mh -- Jay Hennigan - CCIE #7880 - Network Administration - [EMAIL PROTECTED] WestNet: Connecting you to the planet. 805 884-6323 WB6RDV NetLojix Communications, Inc. - http://www.netlojix.com/
RE: Vonage complains about VoIP-blocking
ssh, or other schemes of enhanced security...? mh -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Daniel Golding Envoyé : mardi 15 février 2005 23:39 À : Jason L. Schwab; Martin Hannigan Cc : nanog@merit.edu Objet : Re: Vonage complains about VoIP-blocking Is there any move on the part of providers/manufacturers to use more secure protocols for this? - Dan On 2/15/05 5:22 PM, Jason L. Schwab [EMAIL PROTECTED] wrote: Hi; I unplugged and reset my vonage Motorola MTA device, and it did tftp to home to get its configs. -Jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hannigan, Martin Sent: Tuesday, February 15, 2005 3:14 PM To: 'Jay Hennigan' Cc: Eric Gauthier; nanog@merit.edu Subject: RE: Vonage complains about VoIP-blocking -Original Message- From: Jay Hennigan [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 15, 2005 5:10 PM To: Hannigan, Martin Cc: Eric Gauthier; nanog@merit.edu Subject: RE: Vonage complains about VoIP-blocking On Tue, 15 Feb 2005, Hannigan, Martin wrote: Something else to consider. We block TFTP at our border for security reasons and we've found that this prevents Vonage from working. Would this mean that LEC's can't block TFTP? Was that a device trying to phone home and get it's configs? Cisco, Nortel, etc. phone home and get configs via tftp. Vonage doesn't need to phone home for config. The device is programmed (router) and it registers with the call manager. If you analyze the transactions it's about 89% SIP and 11% SDP. Vonage devices initiate an outbound TFTP connection back to Vonage to snarf their configs on initial connection and also (presumably) on reboot. I tested the reboot. I didn't see it. I agree in general and think that providers shouldn't block tftp, IMHO. -- Daniel Golding Network and Telecommunications Strategies Burton Group
RE: Vonage complains about VoIP-blocking
On Tue, 15 Feb 2005, Hannigan, Martin wrote: On Tue, 15 Feb 2005, Hannigan, Martin wrote: Something else to consider. We block TFTP at our border for security reasons and we've found that this prevents Vonage from working. Vonage devices initiate an outbound TFTP connection back to Vonage to snarf their configs on initial connection and also (presumably) on reboot. I tested the reboot. I didn't see it. I agree in general and think that providers shouldn't block tftp, IMHO. Traditionally, tftp has been used by networks as a configuration/boot mechanism of their local equipment, with customers rarely using it (at least, thats been my experience). . Hence, most people writing the acls are concerned with protecting their own equipment, and getting the most out of their routers. Having acls that block all tftp except from your management IPs is a lot easier than acls that block all tftp to your tftpable devices except from your management IPs. . Introducing new devices that are intended to trust that big, bad, easily spoofable internet using non-secured protocols such as tftp in order to get their configuration from a non-local server shows a degree of trust not seen since the Famous Five, the BabySitters Club and pre '96 O'Reilly books on writing internet protocols. :) mh --==-- Bruce.
RE: Vonage complains about VoIP-blocking
ssh, or other schemes of enhanced security...? We have some that use https, but that is as about as secure as it gets. We also encrypt config files, so that helps. Likely (at least for the time being :) better than nothing (or of course use of naked protocols). My (inherited) point is that these kind of things belong to edge rather than network security enforcement/considerations. mh Nathan Stratton BroadVoice, Inc. nathan at robotics.net Talk IS Cheap http://www.robotics.net http://www.broadvoice.com
RE: Cisco moves even more to china.
On Sat, 25 Sep 2004 10:41:16 -0400 Ricardo \Rick\ Gonzalez [EMAIL PROTECTED] wrote: of people their. Probobly mostly the execs smiling about their payoff and there is the word you're looking for, not their Hey, Mr. Spelling Bee, it is *their*, not there. So, you can't make an argument that is valid and focus on the spelling? This thread has gotten a bit long in the tooth, so I'm waiting for Godwin's law to take effect. Yes, quite a bit OT for this list... Other lists and forums around... Thanks, mh -- Michael Hallgren, AS6453, mh2198-ripe -- Robin Lynn Frank Director of Operations Paradigm-Omega, LLC http://www.paradigm-omega.com == Sed quis custodiet ipsos custodes?
Test, please ignore
test
RE: Announcing a /19 from a /16
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Eric Pylko Envoyé : lundi 5 juillet 2004 22:02 À : [EMAIL PROTECTED] Objet : Announcing a /19 from a /16 Hi- I'm working on a project within a large corporation and asked their network folks about getting a /19 from one of their /16s. I wanted it to avoid NAT and any possible overlapping from using RFC1918 addresses. This project gets connected to the internet at different times throughout the year at different locations through different ISPs. I would announce the /19 for a short period of time, maybe a month or so. The response I got back was that this was impossible since ISPs require an announcement of the /16 the /19 would come from. Maybe one of the (fairly rare, from what I see) actors that ingress filter (or takes into account those small few that does) by allocation? (What prefixes are yopu talking about?) mh I have done work with ISPs before (and have read the NANOG list for many years) but haven't heard of such a requirement nor can I find any standards that indicate the same thing. Does anyone have requirements of a /19 announcement requires the /16 to be there as well? The company has plenty of /16s that it uses internally that are not being announced on the Internet at all. Thanks- -Eric
RE: Announcing a /19 from a /16
Hi- I'm working on a project within a large corporation and asked their network folks about getting a /19 from one of their /16s. I wanted it to avoid NAT and any possible overlapping from using RFC1918 addresses. This project gets connected to the internet at different times throughout the year at different locations through different ISPs. I would announce the /19 for a short period of time, maybe a month or so. The response I got back was that this was impossible since ISPs require an announcement of the /16 the /19 would come from. Maybe one of the (fairly rare, from what I see) actors that ingress filter (or takes into account those small few that does) by strict allocation border ? (What prefixes are yopu talking about?) mh ;) mh I have done work with ISPs before (and have read the NANOG list for many years) but haven't heard of such a requirement nor can I find any standards that indicate the same thing. Does anyone have requirements of a /19 announcement requires the /16 to be there as well? The company has plenty of /16s that it uses internally that are not being announced on the Internet at all. Thanks- -Eric
RE: Can a Customer take their IP's with them? (Court says yes!)
Hi, Hi James, i would agree except NAC seems to have done nothing unreasonable and are executing cancellation clauses in there contract which are pretty standard. The customer's had plenty of time to sort things and they have iether been unable to or unwilling to move out in the lengthy period given. This too isnt uncommon and the usual thing that occurs at this point is the customer negotiates with the supplier for an extension in service which they pay for. These guys seem to not want to admit they've failed to plan this move, dont want to pay for their errors and are now either panicking or trying to prove a point to NAC. I tend to agree. Reasonable time to migrate appears to be reasonable grace period. If unreasonable planning, hard (for me) to understand need for unreasonable grace period. 'reasonable' of course in need of a defintion, but from what I see most (but perhaps not all, these days... so I may be wrong) service providers allow sufficient grace period to make the technical needs fly. I'm far from sure non-technical issues should imply extended grace period. Hrm,... My few ören (or french or canadian cents, if preferred :) mh Steve On Tue, 29 Jun 2004, James wrote: quite frankly, looking at the TRO (thanks Richard for posting them here), UCI has requested permission to use Prior UCI Addresses being part of NAC, until September 1st, 2004. i am failing to see the problem with this TRO, given that customer is simply requesting relief guarantees that their move-out operation to new facility shall go unrestricted and not interfered by NAC. granted, the actual order fell from the court doesn't specifically state 9/1/04 as the deadline (which would be the policy issues w/ IP address portability), I think we need to take a look at both side's opinions and situations before blackholing NAC-UCI leased IP space(s) out of the blue as some here on this NAC-mailing list have stated they would do so. all i can see here is that UCI, being a customer is simply interested in doing what they can do to protect their business. moving entire business operational assets between colocation facilities is not an easy task, and can be quite risky for them. yes, i would take issues if UCI is simply requesting permanent portability of the IP space administrated by NAC, but so far looking at the documents, it appears UCI seems to be requesting enough period of time to help with their transition to the new facility, including enough time for renumbering of IP addresses in the process. Page 15, 45. of http://e-gerbil.net/ras/nac-case/restraining-order.pdf my 0.02 -J On Tue, Jun 29, 2004 at 12:24:44PM -0400, Richard A Steenbergen wrote: On Tue, Jun 29, 2004 at 09:11:08AM -0700, william(at)elan.net wrote: Actually, after reading most of the papers which Richard just made available at http://www.e-gerbil.net/ras/nac-case/ I don't see that court made an incorrect decision (it however should have been more clear enough on when TRO would end in regards to ip space). If you read through It is very likely that Pegasus made the correct decision to protect their business, regardless what a bunch of engineers on NANOG think about the IP space question. It also seems that the TRO is about far more than IP space (i.e. the continuation of full transit services, at existing contract rates). then they did other customers. Now, I do note that is probably just one side of the story, so likely there would be another side as this progresses through court (hopefully Richard will keep the webpage current with new documents), atlthough I have to tell you what I saw mentioned so far did not show NAC or its principals in the good light at all. I would like to post the NAC response to this so that we can hear all sides of the story, but unfortunately the case was moved from the US District Court back to the NJ Superior Court, where I no longer have easy access to the documents. I would be happy to take offline submissions of the legal filings from anyone willing to waste more on this than the $0.07/page that PACER charges. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: Open Source BGP Route Optimization?
Per Gregers Bilse [EMAIL PROTECTED] wrote: On May 28, 10:37am, Sam Stickland [EMAIL PROTECTED] wrote: Are there any BGP extensions that would cause a BGP speaker to foward all of it's paths, not just it best? I believe quagga had made some recent attempts It has been discussed and been on wish lists, but: in this direction. IIRC the problem isn't to do with the route annoucements, it's the route withdrawals. I believe BGP only specifies the prefix being withdrawn and not the path, so if it's advertised multiple paths to a prefix it's impossible to know which has been withdrawn. That is 100% correct, yes. Selective withdrawal is not supported. Another issue is that there isn't much point, as far as regular BGP and routing considerations go. Whichever is the best path for a border router is the best path; telling other routers about paths it will not use serves no (or at best very little) point in this context. Well something came up recently on a transit router. It takes multiple Tier-1 feeds, but management wanted to sell a just MFN to a customer. It's possible to policy route all of their traffic to the MFN interface and only advertise their prefixes to MFN, but not possible to only feed them the MFN routes without starting to use VRFs etc. Of course this is a great perversion of resources ;) Indeed. Makes me somehow wonder how come that customer did not think of buying transit directly from MFN? KISS, that is. Or am I missing something? mh Sam
RE: UUNet Offer New Protection Against DDoS
snip uRPF in the core seems like a bad plan, what with diverse routes and such. Loose-mode might help SOME, but really spoofing is such a low priority issue why make it a requirement? Customer triggered blackholing is a nice feature though. /snip Shared view, mh (Teleglobe, btw) --Chris (formerly [EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ###
RE: UUNet Offer New Protection Against DDoS
Global Crossing has this, already in production. Idem, Teleglobe, mh I was on the phone with Qwest yesterday this was one of this things I asked about. Qwest indicated they are going to deploy this shortly. (i.e., send routes tagged with a community which they will set to null) James Edwards Routing and Security [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965
RE: /24s run amuck
Deaggregation is at an all time high, I have raised this publically in some forums and IXP ops lists. Response is poor, action is non-existent. The only way I can see to do anything about this is for upstreams to educate their customers and others to pressure their peers. Two primary reasons are given, one is for traffic engineering purposes to either control the ingress of traffic or to allow a network to function with critical links down and the other is to allow blocks to be dropped to mitigate the effects of a DDoS, I dont believe either justify the deaggregation of large aggregates into Nx/24s Shared belief: some reasonably small subset potentially functionally justified/relevant, majority unlikely so. and that a large driver is to make your network look larger than it is... What audience?? mh Steve On Sat, 10 Jan 2004, Richard A Steenbergen wrote: Ok, I realized I haven't done one of these since 2001, so it's time for an updated list of /24 polluters. With /24s accounting for over 50% (more than 71k) of the announcements on the Internet, it seems reasonable to try and take a look at why there are so many. One of the patterns which quickly becomes evident is the announcing of almost all of a larger block, but with enough gaps that traditional scripts which look for CIDR aggregation can miss it. For example, someone who owns a /16 and announces it as 250 /24s might not show up in other CIDR aggregation scripts because of the missing 5 /24s, or if 1 of the /24s has a different AS Path. So, solely for the purpose of looking for this pattern, I have written a script which counts the number of /24s announced within a /16 (an admittedly arbitrary range, but one which happens to work) with a consistant AS Path, and sorts by the highest count. This of course doesn't mean for certain that the netblock listed doesn't have a good reason for their deaggregation, but odds are they don't or could otherwise take steps to limit announcement to the general internet (for example a cable modem provider with 250 individual routes /24s but only a single upstream provider, who could announce a /16 globally and use no-export on the more specifics). This is done from the point of view of a Global Crossing (AS3549) transit feed, so things may look slightly different fromy our corner of the Internet. You have been warned. A summary of the top 250 netblocks by count: http://www.e-gerbil.net/ras/projects/ipaddr/24summary Detailed list of the netblocks and AS Path by count: http://www.e-gerbil.net/ras/projects/ipaddr/24dump A sorted list of the origin ASs contributing the /24s in the above lists: http://www.e-gerbil.net/ras/projects/ipaddr/24asn If you are on the list or know someone who is, please encourage them to take steps to clean up their act. You may now return to your regularly scheduled complaining about Verisign.
RE: AOL rejecting mail from IP's w/o reverse DNS?
You mean like Level3? Well,... proxying (in any shape) should, hopefully, not happen prior to having a decent downstream trust relation onboard... (?)... mh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven M. Bellovin Sent: Wednesday, December 03, 2003 2:27 PM To: Matthew Crocker Cc: Christopher X. Candreva; [EMAIL PROTECTED] Subject: Re: AOL rejecting mail from IP's w/o reverse DNS ? In message [EMAIL PROTECTED], Matthew Crocker AOL says the PTR record needs to be assigned. It doesn't specify it has to match the @domain.com in the MAIL FROM: header. Wouldn't it be enough to make sure every IP address you announce has a PTR and matching A record? Hasn't this been a requirement for MANY services for MANY years? Right -- and then folks will start creating wildcard PTR records... --Steve Bellovin, http://www.research.att.com/~smb -- David Temkin
RE: edge interface bits
On Fri, Oct 10, 2003 at 04:55:44PM +0300, Petri Helenius wrote: Does anyone know, either on the east coast US, London, Stockholm, Copenhagen, Amsterdam or Helsinki transit providers which would allow edge/handoff interface control to different traffic classes using BGP communities? (for example to announce DDoS destinations Null communities suporting organizations: GBLX, UUNET, NLAYER, et al Others who can also do null routing over bgp community, please come forward. One of my customers may be interested in doing business w/ you ;-) Teleglobe mh snip/
Re: Fw: GLBX ICMP rate limiting (was RE: Tier-1 without their own backbone?)
Selon Christopher L. Morrow [EMAIL PROTECTED]:
On Thu, 28 Aug 2003, [EMAIL PROTECTED] wrote:
On Thu, 28 Aug 2003, Christopher L. Morrow wrote:
Rate-limiting ICMP is 'ok' if you, as the provider, think its worthwhile
and you, as the provider, want to deal with the headache phone calls...
Would it be fair to say that UUNET haven't been asked by Homeland Security
to do the rate limiting that GLBX claim they have been asked to do? Has
That is not fair at all :) DHS asked 'all ISPs' to filter 'all relevant
traffic' for this latest set of MS worm events. Some ISPs did the
filtering in part or in whole, others didn't...
I would think that any ISP should have made the decision to take action
not based on DHS's decree, but on the requirements of their network. So,
if the ISP's network was adversely impacted by this even, or any other,
they should take the action that is appropriate for their situation. That
action might be to filter some or all of the items in DHS's decree, it
might be to drop prefixes on the floor or turn down customers, or a whole
host of other options.
Doing things for the govt 'because they asked nicely' is not really the
best of plans, certianly they don't know the mechanics of your network,
mine, GBLX's, CW's or anyone elses... they should not dictate a solution.
They really should work with their industry reps to 'get the word out'
about a problem and 'make people aware' that there could be a crisis.
Dictating solutions to 'problems' that might not exist is hardly a way to
get people to help you out in your cause :) Oh, and why didn't they beat
on the original software vendor about this?? Ok, no more rant for me :)
anyone else been asked to rate limit by the U.S. Department of Homeland
Security?
Just about everyone with a large enough US office was asked by DHS, in a
public statement...
Rough agreement; with a fair amount of
innocence... : what about attemtpting to approach the (at least current)
ROOT CAUSE(S) albeit likely fairly (even more than patching the outcome)
cumbersome (but in the long run..)...
/innconcence ;)
ohh
-- if having bought a car I discover the brakes doesn't really do their job
(in spite of the car, considering other aspects, being (easy|nice) to
drive :), I'd rather (chat|complain) with the vendor, than asking the
highway provider to patch my way along.. building cotton walls.. ('cause
I wouldn't want my highway provider limit my driving experience in the
case I eventually run into a better performing car..). More subtle highway
speed versus security considerations... neglected, of course :)
/ohh
mh
--
Michael Hallgren, http://m.hallgren.free.fr/, mh2198-ripe
OT,..
.. but anyway: someone informed on planned role of policyanalysismarket.org ? Out of curiosity, mh
RE: National Do Not Call Registry has opened
Businesses that ask for email addresses know that a significant percentage of people can't type their own email address correctly. Each of those results in a bounce, or an undeliverable message sitting in an mqueue somewhere. It would not surprise me if they also reduced their Timeout.queuereturn to a few hours as well. Dealing with the bounces would be a nightmare, they've already got their handsful with the webservers and the outbound mail boxes. ;) mh Sameer
RE: IRR/RADB and BGP
On Fri, 20 Jun 2003, Deepak Jain wrote: I strongly approve of such requirement. I know that it is in the peering agreements of several carriers, but they often don't check or enforce this. Many register customer routes and ASes. If routes and policies were properly registered, securing the Internet would be a lot closer to being possible. Is it safe to assume (now) that all the routes one would care to listen to (under normal circumstances) are registered in an IRR now? I remember there used to be well-known issues with some networks, especially internationally. I dunno, there are plenty of smaller ASes who have yet to be forced to register their routes. Of some importance, yes, definitely, since at least some actors (including Teleglobe, my home) tend to recurse on AS-set when building filters... so unless registrered all the way down/up, filtered... which, by the way, is a good moment/reason to help those smaller ASes go register (rather than patching/proxying for them). Cheers, mh We haven't yet been forced, but I finally got motivated to submit them to altdb last night. Altdb definitely rocks. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
NOC Telephone List Update
Hi guys, What's the currently efficient/preferred way of updating (replacing, rather than adding) a record at http://puck.nether.net/netops/ :: NOC Telephone List ? Cheers, mh -- Michael Hallgren, http://m.hallgren.free.fr/, mh2198-ripe
RE: NOC Telephone List Update
On Thu, May 29, 2003 at 07:40:46PM +0200, Michael Hallgren wrote: Hi guys, What's the currently efficient/preferred way of updating (replacing, rather than adding) a record at http://puck.nether.net/netops/ :: NOC Telephone List ? Cheers, Jared, You need to really-really annoy me, but please don't for another week. Deal ;) There is a cgi where people can maintain their entries but it has required me to manually move entries under a maintainer id. If you have a maintainer id, you can edit your entry here: http://puck.nether.net/netops/engine.cgi?login I don't. But no problem, it's not that urgent :) I'll try and quickly go in and clear out entries but I think there's been about 1000 entries added over time which has made the dataset quite problematic to deal with. I really need to rebuild all the cgis with my latest cgi/html skills. Again, many thanks for your effort, mh - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: Who uses RADB? [was BGP to doom us all]
On Sat, 1 Mar 2003, Mark Radabaugh wrote: Who actually uses RADB to build filters other than Verio? While my experience with other providers is limited Verio is the only one (of the ones we have used) who used RADB entries for BGP peers. AFAIK, Level3 and CW. Teleglobe as well (mirror), unless late to me unknown changes. mh I have to keep RADB entries (actually altdb, and cw's own) up to date in order for each of them to accept our routes and our BGP customers' routes. Overall it wasn't the best solution IMHO for a couple of reasons: - there was nothing to keep us from making bogus entries in the RADB - filters were only updated once a day making changes slow OTOH, they don't have to pay someone to answer and respond to email sent to bgp-admin. They won't accept routes you accidentally leak to them. Is it secure? Not really. Is it cheap, reliable automation, I suspect so. This is not meant as a complaint toward Verio - I'm simply trying to decide why we should go to the added expense of entering our routes in a RADB. To date I have seen no operational difference between using RADB and not using www.altdb.net. No expense other than the time you spend keeping your objects up to date. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: UUnet routing problem
.ro -- try their London or Amsterdam guys. In an earlier life -- Teleglobe -- I found them quite responsive (at least EU daytime :). Cheers mh -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Sorin Constantinescu Envoye : jeudi 26 septembre 2002 20:21 A : dies Cc : [EMAIL PROTECTED]; [EMAIL PROTECTED] Objet : Re: UUnet routing problem Yes, we did. The e-mail was addressed to [EMAIL PROTECTED] and [EMAIL PROTECTED] We also called at 1-800-900-0241 option 2 3 1. All we got was some ticket numbers. Bye, On Thu, 26 Sep 2002, dies wrote: Date: Thu, 26 Sep 2002 14:06:50 -0400 (EDT) From: dies [EMAIL PROTECTED] To: Sorin CONSTANTINESCU [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: UUnet routing problem Have you contacted 701? On Thu, 26 Sep 2002, Sorin CONSTANTINESCU wrote: Hi, This morning we've discovered that one of our IP's was routed somewhere towards an ALTER.NET customer. All the experiments i'm going to show you are done from route-server.exodus.net. a show ip bgp 193.231.236.41 show that the originator of the IP Block from where 193.231.236.41 belongs is AS8708 (RDSNET ROMANIA). BGP routing table entry for 193.231.224.0/20, version 4439795 Paths: (8 available, best #1) Not advertised to any peer 3561 701 702 8708, (aggregated by 8708 193.231.191.33) 209.1.40.63 from 209.1.40.63 (209.1.40.63) Origin IGP, localpref 1000, valid, internal, atomic-aggregate, best 3561 701 702 8708, (aggregated by 8708 193.231.191.33) 209.1.40.129 from 209.1.40.129 (209.1.40.129) Origin IGP, localpref 1000, valid, internal, atomic-aggregate 3561 701 702 8708, (aggregated by 8708 193.231.191.33) 209.1.220.242 from 209.1.220.242 (209.1.220.242) Origin IGP, localpref 1000, valid, internal, atomic-aggregate 3561 701 702 8708, (aggregated by 8708 193.231.191.33) 209.1.220.134 from 209.1.220.134 (209.1.220.134) Origin IGP, localpref 1000, valid, internal, atomic-aggregate 3561 701 702 8708, (aggregated by 8708 193.231.191.33) 209.1.40.141 from 209.1.40.141 (209.1.40.141) Origin IGP, localpref 1000, valid, internal, atomic-aggregate 3561 701 702 8708, (aggregated by 8708 193.231.191.33) 209.1.220.7 from 209.1.220.7 (209.1.220.7) Origin IGP, localpref 1000, valid, internal, atomic-aggregate 3561 701 702 8708, (aggregated by 8708 193.231.191.33) 209.1.220.7 from 209.1.220.84 (209.1.220.7) But, somewhere on the way, route-server.exodus.nettr 193.231.236.41 Type escape sequence to abort. Tracing the route to FuckingLiveShow.home.ro (193.231.236.41) 1 dcr01-p0-1.sntc08.exodus.net (209.1.169.182) 0 msec 0 msec 0 msec 2 ibr01-g0-0.sntc08.exodus.net (66.35.194.197) 0 msec 0 msec 0 msec 3 dcr2-so-3-0-0.SantaClara.cw.net (208.172.156.197) [AS 3561] 0 msec 0 msec 4 msec 4 agr3-so-2-0-0.SantaClara.cw.net (208.172.156.138) [AS 3561] 4 msec agr4-so-6-0-0.SantaClara.cw.net (208.172.156.158) [AS 3561] 0 msec agr3-so-2-0-0.SantaClara.cw.net (208.172.156.138) [AS 3561] 4 msec 5 acr1-loopback.SanFrancisco.cw.net (206.24.210.61) [AS 3561] 4 msec 4 msec 4 msec 6 bpr2.SanJoseEquinix.cw.net (206.24.210.27) [AS 3561] 4 msec 4 msec 8 msec 7 cable-and-wireless-peering.SanJoseEquinix.cw.net (208.173.55.2) [AS 3561] 4 msec cable-and-wireless-peering.SanJoseEquinix.cw.net (208.173.55.46) [AS 3561] 224 msec cable-and-wireless-peering.SanJoseEquinix.cw.net (208.173.55.2) [AS 3561] 4 msec 8 POS2-0.XR2.SJC7.ALTER.NET (152.63.56.166) [AS 701] 8 msec 4 msec 4 msec 9 POS5-0.XR2.SJC1.ALTER.NET (152.63.52.141) [AS 701] 8 msec 4 msec 4 msec 10 0.so-0-0-0.XL2.SJC1.ALTER.NET (152.63.55.126) [AS 701] 8 msec 4 msec 4 msec 11 0.so-3-0-0.TL2.SAC1.ALTER.NET (152.63.54.10) [AS 701] 8 msec 8 msec 8 msec 12 0.so-4-0-0.TL2.DCA6.ALTER.NET (152.63.10.61) [AS 701] 84 msec 84 msec 84 msec 13 0.so-6-0-0.XL2.DCA6.ALTER.NET (152.63.38.74) [AS 701] 88 msec 88 msec 88 msec 14 0.so-7-0-0.XR2.DCA6.ALTER.NET (152.63.38.90) [AS 701] 88 msec 88 msec 88 msec 15 284.at-2-0-0.CL2.IAD5.ALTER.NET (152.63.35.58) [AS 701] 88 msec 88 msec 92 msec 16 501.ATM5-0.GW5.IAD5.ALTER.NET (152.63.43.141) [AS 701] 92 msec 92 msec 88 msec 17 xa-gw2.customer.alter.net (157.130.13.70) [AS 701] 120 msec 92 msec 92 msec 18 s1.home.ro (193.231.236.41) [AS 8708] 92 msec 92 msec 92 msec route-server.exodus.net Has anyone ever experienced this kind of problems? We've written to UUNET Europe, and they've answered to us that it's a problem at UUNET USA. It's been almost 8 hours since they replied to us, but the problem persists. PS: If there are any technicians from UUNET on this list, please give us a hand. Thank you, --- Sorin ConstantinescuTel: +402 13 010 850 Network Administrator
RE: Popular trouble ticket management system for IP NOC
Hi Yu, Hi nanog, Have any idea of the current popular trouble ticket system for the NOC ? The system used to accept, dispatch, close, store and search trouble ticket or customer case ? It's pretty much a NOC work flow system, but more focused on IP NOC. So what's the popular one ? How about HP help desk, or CA ? Any other ? Maybe URL: http://www.hotscripts.com/PHP/Scripts_and_Programs/Customer_Support/ would be of interest to you. mh thanks for any input. Yu Ning __ (Mr.) Yu Ning, Vice Director Networking Engineering Dep. North Telecom BU, China Telecom Beijing, P.R.China +86-10-66501239 Personal Page- http://navidog.126.com __
RE: Bad bad routing problems?
Hi, FYI, I'm currently sitting as customer to 5511, and I see your two mentioned addresses behind ATT (NY peering FT-ATT), NAC. mh -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Gerald Envoye : samedi 31 aout 2002 16:55 A : [EMAIL PROTECTED] Objet : Bad bad routing problems? We are seeing bad routing problems from outside our network. Can anyone corroborate this or help? We are on AS4276 and all traffic from us to our upstream seems good. Great way to spend holiday weekend. /me wonders if anyone is even awake on the NANOG list. :-) 2 addresses in our network I've tested with are: 216.223.200.14 and 216.223.192.68 Many many traces done, some interesting ones below: Here is a succesful traceroute: traceroute to 216.223.200.14 (216.223.200.14), 30 hops max, 40 byte 1 10 ms 10 ms 10 ms rt1.altair7.com [209.11.155.129] 2 10 ms15 ms16 ms 209.10.41.130 3 10 ms16 ms15 ms ge-6-1-0.core1.sjc1.globix.net [209.10.2.193] 4 10 ms16 ms16 ms so-4-2-0.core1.sjc4.globix.net [209.10.11.221] 563 ms46 ms47 ms so-1-0-0.core2.cgx2.globix.net [209.10.10.150] 662 ms63 ms47 ms so-0-0-0.core1.cgx2.globix.net [209.10.10.157] 778 ms94 ms94 ms so-1-0-0.core2.nyc8.globix.net [209.10.10.162] 878 ms94 ms94 ms pos15-0.core2.nyc1.globix.net [209.10.11.169] 978 ms94 ms94 ms s5-0-peer1.nyc3.globix.net [209.10.12.18] 1078 ms94 ms94 ms nyiix.peer.nac.net [198.32.160.20] 1178 ms94 ms93 ms internetchannel.customer.nac.net [209.123.10.34] 1278 ms94 ms94 ms auth-2.inch.com [216.223.200.14] These show failures before reaching our network: traceroute to 216.223.192.68 (216.223.192.68): 1-30 hops, 38 byte packets 1 paleagw4.hpl.external.hp.com (192.6.19.2) 1.95 ms 1.95 ms 5.86 ms 2 palgwb01-vbblpa.americas.hp.net (15.243.170.49) 0.976 ms 0.977 ms 0.976 ms 3 svl-edge-15.inet.qwest.net (65.115.64.25) 0.976 ms !H * 0.977 ms !H 4 * * * 5 * * * traceroute to 216.223.192.68 (216.223.192.68), 30 hops max, 40 byte packets 1 e3-13.foundry1.cs.wisc.edu (198.133.224.116) 2.195 ms 1.754 ms 1.663 ms 2 e15.extreme1.cs.wisc.edu (128.105.1.1) 0.856 ms 0.765 ms 0.737 ms 3 144.92.128.194 (144.92.128.194) 1.550 ms 1.171 ms 1.264 ms 4 * * * 5 * * * All global crossing traces seem to loop within their router: traceroute to 216.223.192.68 (216.223.192.68), 30 hops max, 40 byte 1 64.214.13.1 (64.214.13.1) 0.695 ms 0.889 ms 0.485 ms 0.453 ms 0.350 ms 2 64.214.13.1 (64.214.13.1) 4.535 ms !N ms * ms 0.574 ms !N ms 3 * (64.214.13.1) 64.214.13.1 ms 0.408 ms !N ms * ms 0.425 ms 4 64.214.13.1 (64.214.13.1) 0.741 ms !N ms * ms 0.542 ms !N ms traceroute to 216.223.200.14 (216.223.200.14), 30 hops max, 40 byte 1 ROUTER6.VINEYARD.NET (204.17.195.236) 0.401 ms 0.342 ms 0.325 ms 2 bos-edge-01.inet.qwest.net (65.115.97.141) 7.249 ms 7.089 ms 6.943 ms 3 * * * 4 * * bos-edge-01.inet.qwest.net (65.115.97.141) 9.885 ms !H 5 * * * 6 * * * 7 bos-edge-01.inet.qwest.net (65.115.97.141) 7.330 ms !H * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * bos-edge-01.inet.qwest.net (65.115.97.141) 7.021 ms !H * 16 * bos-edge-01.inet.qwest.net (65.115.97.141) 172.856 ms !H * 17 * * * 18 * * * 19 * * bos-edge-01.inet.qwest.net (65.115.97.141) 7.127 ms !H 20 * * bos-edge-01.inet.qwest.net (65.115.97.141) 6.787 ms !H 21 * * bos-edge-01.inet.qwest.net (65.115.97.141) 61.972 ms !H 22 * bos-edge-01.inet.qwest.net (65.115.97.141) 22.525 ms !H * 23 * bos-edge-01.inet.qwest.net (65.115.97.141) 6.944 ms !H * 24 bos-edge-01.inet.qwest.net (65.115.97.141) 15.922 ms !H * * 25 bos-edge-01.inet.qwest.net (65.115.97.141) 11.212 ms !H * 6.895 ms This one works: traceroute to 216.223.192.68 (216.223.192.68), 30 hops max, 40 byte 1 tin-V8.cac.washington.edu (140.142.3.1) 1 ms 0 ms 1 ms 2 uwbr2-GE1-1.cac.washington.edu (140.142.155.24) 1 ms 1 ms 0 ms 3 cnsp2-wes-GE0-1-0.pnw-gigapop.net (198.107.151.5) 1 ms 1 ms 1 ms 4 ge-7-2-0.r04.sttlwa01.us.bb.verio.net (129.250.10.77) 0 ms 0 ms 1 ms 5 p4-1-0-0.r03.sttlwa01.us.bb.verio.net (129.250.2.230) 0 ms 1 ms 0 ms 6 p16-0-1-0.r20.sttlwa01.us.bb.verio.net (129.250.2.14) 1 ms 0 ms 1 ms 7 p16-0-1-2.r21.plalca01.us.bb.verio.net (129.250.5.83) 23 ms 23 ms 23 ms 8 p64-0-0-0.r20.plalca01.us.bb.verio.net (129.250.3.76) 22 ms 23 ms 22 ms 9 p16-1-1-1.r20.dllstx01.us.bb.verio.net (129.250.4.104) 57 ms 57 ms 57 ms 10 p64-0-0-0.r21.dllstx01.us.bb.verio.net (129.250.3.41) 57 ms 57 ms 57 ms 11 p16-2-0-0.r00.stngva01.us.bb.verio.net (129.250.5.35) 87 ms 87 ms 88 ms 12 p16-0-0-0.r02.stngva01.us.bb.verio.net (129.250.5.15) 87 ms 88 ms 87 ms 13 p16-7-0-0.r02.mclnva02.us.bb.verio.net (129.250.5.47) 88 ms 88 ms 88 ms 14 p4-3-0.r00.mclnva02.us.bb.verio.net (129.250.5.249) 88 ms 88 ms 88 ms 15
RE: ATT NYC
On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote: Has anybody mentioned the benefits of ISIS as an IGP to them. Link-state protocols are evil, and when they break, they *really* break. I still do not see a compeling argument for not using BGP as your IGP. Slow convergence. As well there is the issues of running a full iBGP mesh. I've actually been doing it, and now that I'm about to add my 5th router, OSPF is looking a lot better than configuring 4 more BGP sessions. I've heard some people recommend a route-reflector, but that would mean if the route-reflector goes down you're screwed. What about a well choosen (wrt topo) pair of them... Planning on doing away with that pesky IBGP mesh and just redistributing BGP into OSPF are we Ralph? There is so much wrong with the above post that I can't do anything except hang my head in shame for people running networks everywhere around the world. mh -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
RE: ATT NYC
Um. Set up more than one reflector yes... and align your setup with your physical topology(so making it useful); use other proto for mapping your infra, etc, etc,.. mh On Thu, 29 Aug 2002, Ralph Doncaster wrote: On Thu, 29 Aug 2002, Peter van Dijk wrote: On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote: Has anybody mentioned the benefits of ISIS as an IGP to them. Link-state protocols are evil, and when they break, they *really* break. I still do not see a compeling argument for not using BGP as your IGP. Slow convergence. As well there is the issues of running a full iBGP mesh. I've actually been doing it, and now that I'm about o add my 5th router, OSPF is looking a lot better than configuring 4 more BGP sessions. I've heard some people recommend a route-reflector, but that would mean if the route-reflector goes down you're screwed. -Ralph
RE: ASN registry?
[...] the lower range controlled by ARIN. No idea why ARIN doesn't have a record for it...they only carry records for ASN 16779, which is Telstra-USA. Andy I noticed that as well. But a quick google shows that Telstra is most definitely AS1221. Maybe they forgot to renew one of their AS Numbers? aut-num AS1221, inverse as-name ASN-TELSTRA descrTelstra Pty Ltd descrLocked Bag No. 5744 descrGPO, Canberra, ACT, 2601 country AU admin-c GH105-AP, inverse tech-c DW187-AP, inverse remarks AS assigned by the former InterNIC mnt-by MAINT-AS1221, inverse changed [EMAIL PROTECTED] 2131 source APNIC mh Derek
RE: ASN registry?
That's a little odd, considering that's included in a range of AS' that RIPE shows as delegated to ARIN. Anyone have any ideas? aut-num AS1221, inverse [...] remarks AS assigned by the former InterNIC [...] source APNIC mh Derek -Original Message- From: Kris Foster [mailto:[EMAIL PROTECTED]] Sent: Monday, August 19, 2002 3:56 PM To: 'Derek Samford'; 'Andy Dills'; 'Ralph Doncaster' Cc: [EMAIL PROTECTED] Subject: RE: ASN registry? maybe you're forgetting Australia... think APNIC... -Original Message- From: Derek Samford [mailto:[EMAIL PROTECTED]] Sent: Monday, August 19, 2002 3:51 PM To: 'Andy Dills'; 'Ralph Doncaster' Cc: [EMAIL PROTECTED] Subject: RE: ASN registry? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Andy Dills Sent: Monday, August 19, 2002 3:42 PM To: Ralph Doncaster Cc: [EMAIL PROTECTED] Subject: Re: ASN registry? On Mon, 19 Aug 2002, Ralph Doncaster wrote: I've always used whois.arin.net to check ASN registrations, and until now it's always had information on those that I've checked. It doesn't have anything for 1221, which according to route-views.oregon-ix.net is Telstra. Is there a single complete database that has ASN assignment info? Well, when I can't find it quickly, I usually check RIPE, as the RIPE whois will tell you which region the ASN is delegated to, and which registrar to check with. And according to RIPE, 1221 is most definitely in the lower range controlled by ARIN. No idea why ARIN doesn't have a record for it...they only carry records for ASN 16779, which is Telstra-USA. Andy I noticed that as well. But a quick google shows that Telstra is most definitely AS1221. Maybe they forgot to renew one of their AS Numbers? Derek
RE: ASN registry?
aut-num AS1221, inverse as-name ASN-TELSTRA descrTelstra Pty Ltd descrLocked Bag No. 5744 descrGPO, Canberra, ACT, 2601 country AU admin-c GH105-AP, inverse tech-c DW187-AP, inverse remarks AS assigned by the former InterNIC mnt-by MAINT-AS1221, inverse changed [EMAIL PROTECTED] 2131 source APNIC Interesting. So then, how did that happen? Old network. as-block:AS1 - AS1876 descr: ARIN ASN block remarks: These AS numbers are further assigned by ARIN remarks: to ARIN members and end-users in the ARIN region admin-c: ARIN1-RIPE tech-c: ARIN1-RIPE mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-NONE-MNT changed: [EMAIL PROTECTED] 20010423 source: RIPE Is that just a general mess at the top where, in general, ARIN is in charge but not always? Or just a special situation? Andy mh Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
RE: Waiver of IP and AS Number Transfer Fees
Please correct me if I am wrong. This is not allowing the practice of selling IPs or ASes, I've never really come around to fully understand the notion (more and more common, it seems) of _selling_ such..? (Maybe I'm an idealist :) but it encourages those of us who have acquired other companies to consolidate all the registrations under a single NIC handle (for example) to reduce the total number of contacts floating out there? Is my understanding accurate? I would hope so, in a general perspective. mh Thanks, DJ
Re: KPNQwest
Quoting Rob Evans [EMAIL PROTECTED]: Considering the number of messages about companies going bust, this one seems vaguely operational for some... http://biz.yahoo.com/djus/020529/200205292257000882_2.html There are a number of quotes from people familiar with the matter, but as I understand it the background is sound. If KPNQ does have to switch off their network, it will affect a large number of businesses in Europe, as they offer both circuits (via their extensive Eurorings network) and IP connectivity (they acquired Ebone not too long ago). Rob. I fully agree: operational importance, in deed and afaik, for commercial as well as for RE. Let's hope for some 11th hour fix... mh Rob -- Michael Hallgren, http://m.hallgren.free.fr/, MH2198-RIPE
