RE: Interesting new spam technique - getting a lot more popular.
Since this technique requires a IPinIP or GRE tunnel, wouldn't blocking these two protocols to/from the hosts be sufficient? Assuming of course the customer's host isn't using that normally. Chuck Netco Government Services has recently acquired Multimax and is changing its name to Multimax Inc. Visit http://www.multimax.com for more information.
RE: Open Letter to D-Link about their NTP vandalism
"Service Area: Networks BGP-announced on the DIX" Since the intended (and announced) use of this server is just for DIX networks, blocking NTP from any other networks should be trivial. That IP address will still be hit by D-Link devices looking for a suitable server, but with no response, they'll move onto another device, and probably never try the DIX address again, at least until they're rebooted. That alone should kill off 95% of the unwanted traffic hitting the box, and probably 80% of the traffic even being sent to DIX in the first place. Chuck
RE: The Backhoe: A Real Cyberthreat?
It seems a terrorist would benefit from obtaining fiber map information from the source, rather than googling for outages, and trying to find needles in haystacks. How well are the internal databases with fiber path details protected? How hard would it be for Al-Qaeda to social-engineer it's way into obtaining this stuff? Though personally, I don't think terrorists would target telecom infrastructure. A hundred simultaneous intentional fiber cuts could be fixed in a day. That's something that is forgotten within a year. Bombings are not. Fiber cuts resulting in phone and internet connectivity loss aren't going to have the whole world turning to CNN. Just us... Just my .02 though, Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Hannigan Sent: Saturday, January 21, 2006 8:28 AM To: Wallace Keith Cc: nanog@merit.edu Subject: Re: The Backhoe: A Real Cyberthreat? > > > I for one have spoken in the past in favor of making the FCC Outage Reports public again. If you want to deliberatley destroy fiber infrastructure, you can gain more knowledge quicker by stepping outside your door and gazing upon clearly marked routes, than by reading outage reports. Want to find a bldg where multiple carriers are housed? Read the carrier hotel advertisements on the internet and in print or read NANOG. Any idiot terrorist can walk up to a CO or colo and find the entrance facilities (facility in more cases) and walk down the block looking for manhole covers with company names or logo's. It doesn't matter if you cut it 10 miles or at the CO, it still takes the same amount of time to resplice it all. If it were at the CO it would probably be done half-assed i.e. they throw a cable out the window and splice that as a temporary fix not understanding just that, that it does not matter where it's cut in most cases. There are methods and methods and techniques to use to make the mitigation harder which I won't get into here, but anybody can knock out comm links with not a lot of thought. FCC outages reports should be public because it keeps carriers competing. We want that. I don't know where this whole nonsense about not being able to find metro loop fiber routes came from, but if a carrier refuses to at least show you the redundancy on a map then they probably don't have it. It's pretty simple. Ask to see the DLR, the metro loop map, and ask where your cross connects are going to be made, if any. If you're going to a carrier hotel, you are likely aggregating closer than you think and you want to know. If you are single homed, don't bother asking those questions. -M<
RE: WMF Microsoft Patch is out
So rather than finish the testing they wanted to do, they rushed it out? Hmmm. Sounds a little scary to me Chuck From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jerry Dixon Sent: Thursday, January 05, 2006 3:37 PM To: [EMAIL PROTECTED] Subject: WMF Microsoft Patch is out FYI all, the Microsoft Official patch is out for WMF and available via Windows Update. Cheers, Jerry
RE: Clueless anti-virus products/vendors (was Re: Sober)
What about all the viruses out there that don't forge addresses? Sending a warning message makes sense for these. Unless someone has done the research to determine the majority of viruses forge addresses, you really can't complain about the fact that the default is to warn. Calling vendors 'clueless' because a default doesn't match your needs is a little extreme, don't you think? The ideal solution would be for the scanning software to send a warning only if the virus detected is known to use real addresses, otherwise it won't warn. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Todd Vierling Sent: Sunday, December 04, 2005 4:53 PM To: W.D.McKinney Cc: nanog@merit.edu Subject: RE: Clueless anti-virus products/vendors (was Re: Sober) On Sun, 4 Dec 2005, W.D.McKinney wrote: > > (Virus "warnings" to forged addresses are UBE, plain and simple.) > > Since when? I disagree. UBE = "unsolicited bulk e-mail". Which of those three words do[es] not apply to virus "warning" backscatter to forged envelope/From: addresses? Think carefully before answering. -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
RE: QoS for ADSL customers
But be careful about the CPU usage and platform support for NBAR. I don't think the sup720 will do NBAR, at least that's what I heard. Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design & Implementation Team 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 864-266-3978 [EMAIL PROTECTED] PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Burkholder Sent: Thursday, December 01, 2005 8:52 AM To: Ejay Hire Cc: 'Kim Onnel'; 'NANGO' Subject: RE: QoS for ADSL customers There are a bunch of p2p and torrent custom classifier pdlm's at http://www.cisco.com/cgi-bin/tablebuild.pl/pdlm Quoting Ejay Hire <[EMAIL PROTECTED]>: > > I got an off-list reply about using Nbar, but I've never > seen a class map that would match torrent. > > -e > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On > > Behalf Of Kim Onnel > > Sent: Thursday, December 01, 2005 7:12 AM > > To: Ejay Hire > > Cc: NANGO > > Subject: Re: QoS for ADSL customers > > > > Our ADSL customers traffic is 3 OC3 worth of traffic, I > dont > > think our management would buy the idea. > > > > thanks > > > > > > On 12/1/05, Ejay Hire <[EMAIL PROTECTED]> wrote: > > > > Hello. > > > > Going back to your original question, how to keep > from > > saturating the network with residential users using > > bittorrent/edonkey et al, while suffocating business > > customers. Here goes. > > > > Netfilter/IpTables (and a slew of commercial > products I'm > > sure) has a Layer 7 traffic classifier, meaning it > can > > identify specific file transfer applications and set > a > > DiffServ bit. This means it can tell between a real > http > > request and a edonkey transfer, even if they are > both using > > http. It also has rate-limiting capability. So... > If you > > pass all of the traffic destined for your DSL > customers > > through an iptables box (single point of failure) > then you > > can classify and rate-limit the downstream rate on a > > > per-application basis. > > > > Fwiw, if you are using diffserv bits, you could push > the > > rate-limits down to the router with a qos policy in > it > > instead of doing it all in the iptables box. > > > > References on this.. The netfilter website (for > > classification info) and the Linux advanced router > tools > > (LART) (qos info/rate limiting) > > > > -e > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > > On > > > Behalf Of Kim Onnel > > > Sent: Thursday, December 01, 2005 3:26 AM > > > To: NANGO > > > Subject: Re: QoS for ADSL customers > > > > > > Can any one please suggest to me any commercial or > none > > > solution to cap the download stream traffic, our > upstream > > > will not recieve marked traffic from us, so what > can be > > done ? > > > > > > > > > On 11/29/05, Kim Onnel <[EMAIL PROTECTED]> > wrote: > > > > > > Hello everyone, > > > > > > We have Juniper ERX as BRAS for ADSL, its > GigE > > > interface is on an old Cisco 3508 switch with an > old IOS, > > its > > > gateway to the internet is a 7609, our transit > internet > > links > > > terminate on GigaE, Flexwan on the 7600 > > > > > > The links are now almost always fully > utilized, we > > want > > > to do some QoS to cap our ADSL downstream, to give > room > > for > > > the Corp. customers traffic to flow without pain. > > > > > > I'm here to collect ideas, comments, advises > and > > > experiences for such situations. > > > > > > Our humble approach was to collect some p2p > ports > > and > > > police traffic to these ports, but the traffic > wasnt much, > > > > > one other thing is rate-limiting per ADSL > customers IPs, > > but > > > that wasnt supported by management, so we thought > of > > matching > > > ADSL www traffic and doing exceed action is > transmit, and > > > police other IP traffic. > > > > > > Doing so on the ERX wasnt a nice experience, > so > > we're > > > trying to do it on the cisco. > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > -- > Scanned for viruses and dangerous content at > http://www.oneunified.net and is believed to be clean. > > -- Ray Burkholder http://www.oneunified.net [EMAIL PROTECTED] 441 505 7293 - Sent from http://www.oneunified.net via IMP: http://horde.org/imp/ -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be cl
RE: a record?
Isn't it just good security practice to limit telnet/SSH access to only a few choice hosts/subnets? I know I'd never allow the 0/0 net access to a signon screen, even if it is SSH. If you're on vacation and need to access something, call your NOC, and have them temporarily allow your dynamic address for SSH. When a hacker finds an open SSH host, they think two things - This host is important to someone, and that they need more doughnuts... Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Louwers Sent: Tuesday, November 15, 2005 3:03 AM To: [EMAIL PROTECTED] Subject: Re: a record? On Tue, Nov 15, 2005 at 12:01:00AM +0100, Peter Dambier wrote: > > Moving sshd from port 22 to port 137, 138 or 139. Nasty eh? don't do that! Lots of (access) isps around the world (esp here in Europe) block those ports (in and out), so if you ever need emergency access to your system from a network you don't know, you'll find yourself blocked. Kind Regards, Frank Louwers -- Openminds bvbawww.openminds.be Tweebruggenstraat 16 - 9000 Gent - Belgium
RE: And Now for Something Completely Different (was Re: IPv6 news)
Nanog, I've been thinking a bunch about this IPv6 multihoming issue. It seems that the method of hierarchical summarization will keep the global tables small for all single-homed end user blocks. But the multihomed ones will be the problem. The possible solution I've been thinking about is 'adjacency blocks', for lack of a better term. In theory, the first customer to home to two different ISPs causes a new large address block to be advertised upstream by these two ISPs. Further customers homing to these two ISPs get an allocation out of this same block. The two ISPs will only announce the large block. Of course there are issues involving failure and scalability... Failure would involve an ISP losing contact with end customer, but still announcing the aggregate upstream. This can be solved by requiring that two ISPs must have a direct peering agreement, before they can accept dual-homed customers. Or a possible method (maybe using communities?) where ISP B will announce the customer's actual block (the small one) to it's upstreams, if notified by ISP A that it's not reachable by them. When ISP A resumes contact with end customer, ISP B retracts the smaller prefix. Scalability is an obvious issue, as the possible number of these 'adjacency blocks' would be N * (N-1), where N is the number of ISPs in the world. Obviously pretty large. But I feel the number of ISPs that people would actually dual home to (due to reputation, regional existence, etc) is a few orders of magnitude smaller. ~100,000 prefixes (each can be an ASN, I suppose) should cover all needs, doing some simple math. The downside is that end customers are going to lose the ability to prefer traffic from one ISP versus another for inbound traffic. That alone might be a show-stopper, not sure how important it is. Since IPv6 is a whole new ballgame, maybe it's ok to change the rules... Looking for any thoughts about it. I'm sure there's things I haven't considered, but the people I've bounced it off of haven't seen any obvious problems. Flame-retardant clothes on, just in case though. Chuck >Every multi-homer will be needing their own ASN, so that's what clutters >up your routing tables. It's economy there. Btw, a lot of ASNs advertise >one network only. People surely think multihoming is important to them >(and I cannot blame them for that). >Hierarchical routing is one possible solution, with a lot of drawbacks >and problems. Forget about geographic hierarchies; there's always people >who do not peer. Visibility radius limitation is another (I cannot believe >the idea is new, I only don't know what it's called).
RE: IPv6 news
> If that is devising some sort of NAT for the large percentage of >customers that don't care, then that may be the direction we need to take. Doesn't NAT-PT do just this? If I'm an ISP with a million customers, if I can use NAT-PT along with a IPV4 block of say /13, that seems like a win. V4-mapped and V4-Compatible V6 addresses were created for this purpose, weren't they? Chuck
RE: Very funny: While Bush fiddles, New Orleans dies
Even if the sending server is in a different domain that the users's reply-to address? s48.tribuneinteractive.com != netzero.net (Keep in mind I'm not a mail admin, nor do I play one on TV...) Chuck -Original Message- From: Joe Abley [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 07, 2005 10:23 AM To: Church, Chuck Cc: nanog@merit.edu Subject: Re: Very funny: While Bush fiddles, New Orleans dies On 7-Sep-2005, at 17:09, Church, Chuck wrote: > So how did this newspaper server end up with NANOG posting rights > anyway??? Servers don't get posting rights. From: headers get posting rights.
RE: Very funny: While Bush fiddles, New Orleans dies
So how did this newspaper server end up with NANOG posting rights anyway??? Chuck Church -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew - Supernews Sent: Wednesday, September 07, 2005 9:51 AM To: nanog@merit.edu Subject: Re: Very funny: While Bush fiddles, New Orleans dies > "Patrick" == Patrick W Gilmore <[EMAIL PROTECTED]> writes: Patrick> Perhaps someone "in authority" can track and kill, er, ban Patrick> this luser? Which luser? The one who first thought it would be a good idea for newspaper sites to have a "mail this article to someone" feature that forges the sender address with no attempt to verify that the person making the request has the right to use that address? -- Andrew, Supernews http://www.supernews.com
RE: zotob - blocking tcp/445
On Mon, 15 Aug 2005, Church, Chuck wrote: > > > >'enterprise security folks' are probably not the issue... The fact > remains > >that lots of folks DO do this :( There are quite a few folks between > >'consumer' and 'enterprise' that do all manner of dumb things on the > >Internet (where 'dumb' is equivalent to running smb shares across the > >public network minus encryption/ipsec). It's their choice to do that, > and > >their network providers are expected/demanded to pass those packets for > >them. > > >-Chris > > Surely the ratio of 'useful' traffic compared to 'junk' for a particular > protocol must be considered. What percentage of netbios entering a on your piece of the network you can consider the ratio of pigs to birds, or good to bad traffic or phases of the moon, it's your network do what you will. I can say that if you have a vocal enough customer the blocks won't last very long, or the customer will find another network to connect to... *** Rules are going to be different for residential vs. business customers. Business customers who aren't on crack probably know better to block netbios in and out. But residential customers, I think you'll win more customers than lose by taking some proactive blocking measures. > service provider's edge is intentional? 1%? 0.1%? I'm guessing much > less than that. If 5 or 6 nines worth of a particular protocol entering > or leaving an ISP's network is unintentional, and highly susceptible to > viral activity, isn't it in our best interest to block it? With proper your best interest might be to do that sure... 'your network, your call'. > notification to subscribers and instructions on setting up host-to-host > PPTP/whatever, blocking netbios can solve a large bunch of issues > please send my instructions for host-to-host pptp that my grandmother can follow without help of techsupport. *** Well, if you grandmother is already familiar with mapping drives and modifying her lmhosts file :)
RE: zotob - blocking tcp/445
>'enterprise security folks' are probably not the issue... The fact remains >that lots of folks DO do this :( There are quite a few folks between >'consumer' and 'enterprise' that do all manner of dumb things on the >Internet (where 'dumb' is equivalent to running smb shares across the >public network minus encryption/ipsec). It's their choice to do that, and >their network providers are expected/demanded to pass those packets for >them. >-Chris Surely the ratio of 'useful' traffic compared to 'junk' for a particular protocol must be considered. What percentage of netbios entering a service provider's edge is intentional? 1%? 0.1%? I'm guessing much less than that. If 5 or 6 nines worth of a particular protocol entering or leaving an ISP's network is unintentional, and highly susceptible to viral activity, isn't it in our best interest to block it? With proper notification to subscribers and instructions on setting up host-to-host PPTP/whatever, blocking netbios can solve a large bunch of issues Just my .02 though, Chuck
RE: OT: Cisco.com password reset.
I eventually got an email stating it couldn't associate my email address with an active CCO ID. I'm guessing their system is getting backed up because it's affecting lots of people. Next step: "Please email [EMAIL PROTECTED] to have your correct email address associated with your User ID. To ensure you receive prompt attention, please provide all of the following details: 1 Maintenance contract or Account number you used in your registration 2 The user ID your believe you have 3 Full name 4 Company name " Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design & Implementation 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 [EMAIL PROTECTED] PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Tancsa Sent: Wednesday, August 03, 2005 9:52 AM To: Dan Armstrong Cc: nanog@merit.edu Subject: Re: OT: Cisco.com password reset. Same here. I didnt get a notice that it was reset, but I cannot login ---Mike At 09:30 AM 03/08/2005, Dan Armstrong wrote: >My PW to CCO did not work this morning either. I am on hold with the TAC >right now > > > >Joe Blanchard wrote: > >>FYI >>I got an email that my CCO account's password was reset >>last night. Not sure how widespread this issue was, but >>I called my account contact and verified that this is >>a valid email, and that my password needed to be reset. >> >>Just a heads up. >> >>-Joe Blanchard >> >> >>
More info on the Exploit from Black Hat conference
http://www.tomsnetworking.com/Sections-article131.php Chuck ChurchLead Design EngineerCCIE #8776, MCNE, MCSENetco Government Services - Design & Implementation Team1210 N. Parker Rd.Greenville, SC 29609Home office: 864-335-9473Cell: 864-266-3978[EMAIL PROTECTED]PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D
RE: Vonage Selects TCS For VoIP E911 Service
I think this can work. Put a battery backup in the ATA, to power the GPS and real time clock. The ATA will maintain the internet-routable address it's using (not necessarily it's own IP address) indefinitely. If the ATA determines it's routable address (or /23 or whatever subnet) has changed since being disconnected, it prompts (via voice menu on connected phones) that it needs to be taken outside and re-GPS'ed. Flashing light on the box confirms when GPS has synced it's location. Take it back inside, plug it in, and all is ok again. Or something along those lines Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design & Implementation Team 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 [EMAIL PROTECTED] PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, July 20, 2005 5:32 AM To: nanog@merit.edu Subject: Re: Vonage Selects TCS For VoIP E911 Service > >I see no other way of doing this reliably than to put some kind of > >GPS device into the VoIP unit. > > While I agree that GPS is the likely answer, I wasn't expecting the > ability to work inside computer rooms and basements. It doesn't need to work in basements, etc. It only needs to keep a record of the last location it was at when the signal faded away. The emergency service vehicles probably can't get any closer than that anyway. --Michael Dillon
FW: DNS .US outage
Guess I wasn't going crazy. Forwarded to me by a read-only lister. Might be worth trying if prob still exists for anyone. Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design & Implementation 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 [EMAIL PROTECTED] PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D -Original Message- From: Mark Moseley [mailto:[EMAIL PROTECTED] Sent: Friday, July 08, 2005 7:17 PM To: Church, Chuck Subject: Re: DNS .US outage Hi. I don't have 'write' access to the nanog group so I'm writing you directly. I saw the exact same behaviour. After some banging-head-against-wall at 3am, I noticed that if I turned *off* "query-source * port 53" in Bind (i.e. it was using port 53 as the source port for queries to make firewalling easier), it magically started working again. Don't know if you're using Bind or Windows DNS, but all I could tell is that when Bind was configured to query *from* port 53, I couldn't get the .us TLDs to answer me, but when using a random ephemeral port (of named's choice), it worked just fine. I don't know if they are (or were, haven't check since then) blocking queries with a source port of 53, but whatever the case it worked for some reason. If this works for you, please feel free to re-post to nanog (unless of course, the outage has gone away and they've fixed their stuff over at the .us TLD servers). One thing to note is that when you use dig or nslookup or whatever, it'll also be using some ephemeral port, so it'll work, even when the lookups from source port 53 wouldn't. Again, I haven't checked since that night to see if that's gone away, so it might be a moot point now. On 7/6/05, Church, Chuck <[EMAIL PROTECTED]> wrote: > > Anyone else having issues with .US right now (~12AM EST)? NSlookup, etc > show various .us destinations as unknown domains... > > > Chuck Church > Lead Design Engineer > CCIE #8776, MCNE, MCSE > Netco Government Services - Design & Implementation Team > 1210 N. Parker Rd. > Greenville, SC 29609 > Home office: 864-335-9473 > Cell: 703-819-3495 > [EMAIL PROTECTED] > PGP key: > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D >
RE: DNS .US outage
Thanks for your help, guys. Didn't know dig existed for windows. Several ISPs (charter.net, alter.net) are choking on .us queries right now, but AT&T's name server is working ok for me. Here's one failing on .us, but .com works fine: C:\temp\dnstools>dig @24.197.96.16 com NS ; <<>> DiG 9.3.1 <<>> @24.197.96.16 com NS ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1940 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;com. IN NS ;; ANSWER SECTION: com.172800 IN NS d.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.172800 IN NS a.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. ;; Query time: 4046 msec ;; SERVER: 24.197.96.16#53(24.197.96.16) ;; WHEN: Thu Jul 07 08:20:35 2005 ;; MSG SIZE rcvd: 245 C:\temp\dnstools>dig @24.197.96.16 us NS ; <<>> DiG 9.3.1 <<>> @24.197.96.16 us NS ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1682 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;us.IN NS ;; Query time: 31 msec ;; SERVER: 24.197.96.16#53(24.197.96.16) ;; WHEN: Thu Jul 07 08:20:50 2005 ;; MSG SIZE rcvd: 20 Is it possible that one of the authoritative servers for .us is unreachable/down at the moment, at least from name server 24.197.96.16's point of view? 198.6.1.2 gives similar results. Thanks again, Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design & Implementation 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 [EMAIL PROTECTED] PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D -Original Message- From: Jeroen Massar [mailto:[EMAIL PROTECTED] Sent: Thursday, July 07, 2005 4:10 AM To: Randy Bush Cc: Church, Chuck; nanog@merit.edu Subject: RE: DNS .US outage On Wed, 2005-07-06 at 19:19 -1000, Randy Bush wrote: > > Thanks. Didn't have any *NIX boxes laying around to 'dig' any deeper. > > i believe even windoze has dig at the command line, though i don't > know in what directory it lies. The web directory: http://www.isc.org/index.pl?/sw/bind/bind9.php or the ftp directory: ftp://ftp.isc.org/isc/bind/contrib/ntbind-9.3.1/BIND9.3.1.zip What is also very useful are the following two websites, so people can click around a bit and get nice pictures making everything crystalclear for them: DNSDoctor (which even supports IPv6 :) http://demo.dnsdoctor.org/ And of course DNS report: http://www.dnsreport.com/ Greets, Jeroen
RE: DNS .US outage
Thanks. Didn't have any *NIX boxes laying around to 'dig' any deeper. When I checked networksolutions' whois for neosystems.us and state.ny.us , both returned: " We are unable to process your request at this time. Please try again later." Figured something was up. But when I tried nslookup with a server on yet a 4th ISP just now, it worked ok. Thanks again. Chuck -Original Message- From: Suresh Ramasubramanian [mailto:[EMAIL PROTECTED] Sent: Thursday, July 07, 2005 12:34 AM To: Church, Chuck Cc: nanog@merit.edu Subject: Re: DNS .US outage On 07/07/05, Church, Chuck <[EMAIL PROTECTED]> wrote: > > Anyone else having issues with .US right now (~12AM EST)? NSlookup, etc > show various .us destinations as unknown domains... > nslookup is not the best tool to troubleshoot dns issues works for me though - [EMAIL PROTECTED] 10:02:22 [~]$ dig us NS ; <<>> DiG 8.3 <<>> us NS ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; us, type = NS, class = IN ;; ANSWER SECTION: us. 1d23h59m46s IN NS A.GTLD.BIZ. us. 1d23h59m46s IN NS B.GTLD.BIZ. us. 1d23h59m46s IN NS C.GTLD.BIZ. ;; Total query time: 3 msec ;; FROM: frodo.hserus.net to SERVER: default -- 127.0.0.1 ;; WHEN: Thu Jul 7 10:02:25 2005 ;; MSG SIZE sent: 20 rcvd: 76 and a random .us domain - [EMAIL PROTECTED] 10:02:25 [~]$ dig help.us ; <<>> DiG 8.3 <<>> help.us ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; help.us, type = A, class = IN ;; ANSWER SECTION: help.us.58m46s IN A 66.98.178.79 ;; Total query time: 2 msec ;; FROM: frodo.hserus.net to SERVER: default -- 127.0.0.1 ;; WHEN: Thu Jul 7 10:03:30 2005 ;; MSG SIZE sent: 25 rcvd: 41 -- Suresh Ramasubramanian ([EMAIL PROTECTED])
DNS .US outage
Anyone else having issues with .US right now (~12AM EST)? NSlookup, etc show various .us destinations as unknown domains... Chuck ChurchLead Design EngineerCCIE #8776, MCNE, MCSENetco Government Services - Design & Implementation Team1210 N. Parker Rd.Greenville, SC 29609Home office: 864-335-9473Cell: 703-819-3495[EMAIL PROTECTED]PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D
RE: Document Action: 'BGP Wedgies' to Informational RFC
Will sharply 'pulling up' the MED on a rear-facing peer clear the wedgie, or make it worse??? Sorry, couldn't resist... Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fergie (Paul Ferguson) Sent: Wednesday, June 15, 2005 1:29 PM To: nanog@merit.edu Subject: FWD: Document Action: 'BGP Wedgies' to Informational RFC Direct operational relevence, methinks. FYI. - ferg -- The IESG <[EMAIL PROTECTED]> wrote: The IESG has approved the following document: - 'BGP Wedgies ' as an Informational RFC This document is the product of the Global Routing Operations Working Group. The IESG contact persons are David Kessens and Bert Wijnen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-grow-bgp-wedgies-03.txt Technical Summary It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable, and that the stable state where BGP converges may be selected by BGP in a non-deterministic manner. These stable, but unintended, BGP states are termed here "BGP Wedgies". Working Group Summary The Grow Working Group came to consensus on this document. Protocol Quality This document was reviewed for the IESG by David Kessens. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
RE: Cisco to merge with Nabisco
Yes. According to the Keebler elves, who now are 3rd level TAC engineers... Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design & Implementation Team 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 [EMAIL PROTECTED] PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D -Original Message- From: Bill Nash [mailto:[EMAIL PROTECTED] Sent: Friday, April 01, 2005 1:09 PM To: Church, Chuck Cc: nanog@merit.edu Subject: RE: Cisco to merge with Nabisco On Fri, 1 Apr 2005, Church, Chuck wrote: > > Incorrectly chosen switching path can now result in lost packets AND > indigestion. > Is this mitigated by activating Nabisco Express Forwarding?
RE: Cisco to merge with Nabisco
Incorrectly chosen switching path can now result in lost packets AND indigestion. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Hilton Sent: Friday, April 01, 2005 12:44 PM To: nanog@merit.edu Subject: RE: Cisco to merge with Nabisco Runts are hereinafter referred to as crumbs. Hilton
Vonage Hits ISP Resistance
For what it's worth - I monitored my Vonage call today, which lasted 54 minutes: Ethernet0/1 Input Output Protocol Packet Count Packet Count Byte Count Byte Count 5 minute bit rate (bps) 5 minute bit rate (bps) rtp 109086 108959 18971788 18958866 00 Or about 20 mbytes/hour, 33 packets per second. That's on Vonage's middle phone quality setting, (50kbit), with the Motorola ATA... Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design & Implementation 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 [EMAIL PROTECTED] PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D
RE: More on Vonage service disruptions...
Yeah, I forgot about the regulation thing. I suppose I'd give the ISP a call first, but I'd expect it to be working within a few hours. But now that cable modem providers themselves are providing VoIP/dialtone, wouldn't those be regulated by the FCC? I know that my cable modem ISP (Charter) has been much more reliable the last few months, as they're doing a bunch of upgrades regarding redundancy. I believe this is to support their new VoIP service. But it still seems to me that blocking someone from making a 911 call would be a lawsuit waiting to happen. Chuck -Original Message- Even if the ISP in question is a LEC, normally the ISP side of the house is unregulated. The LEC providesthe circuit, and the ISP provides the bandwidth / services on that circuit. If you ISP decided to block VOIP, your cell phone call should be to their competition to order service from them, and vote with your dollars. Or at least to your ISP to call up and complain. Just my opinion, IANAL (I don't even play one on TV), etc... -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C (A)bort, (R)etry, (P)retend this never happened?
RE: More on Vonage service disruptions...
Those are good points. Someone last week mentioned what I thought was a great list of priorities for an ISP: 1. Keep the network running 2. Remove those violating policies 3. Route packets (or something along those lines) A 30/50/90 kbps unicast stream isn't going to affect #1. I don't think any policies involved in #2 would cover a VoIP service either. That should leave #3 as the default for this traffic. I can picture a DDOS where infected Windows machines could send bogus SIP traffic to Vonage servers; in this case temporary blocking might be needed/justified. But until that happens, blocking SIP is just wrong. Another thing for an ISP considering blocking VoIP is the fact that you're cutting off people's access to 911. That alone has got to have some tough legal ramifications. I can tell you that if my ISP started blocking my Vonage, my next cell phone call would be my attorney... Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design & Implementation Team 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 [EMAIL PROTECTED] PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fergie (Paul Ferguson) Sent: Wednesday, March 02, 2005 9:46 AM To: nanog@merit.edu Subject: More on Vonage service disruptions... advancedIPpipeline is running another article this morning in their series of articles covering the Vonage service disruptions that [allegedly] invlove an ISP "port blocking" SIP connectitity between Vonage's client equipment and Vonage's servers. While there is a bit more decriptive detail in this article involving the nature of the service interruptions, Vonage's CEO, Jeffrey Citron, is trying to make a [in my opinion] weak argument that this type of traffic blocking is akin to censorship. http://www.advancedippipeline.com/news/60404589 The silliness of the "censorship" argument aside, an interesting snippet within this article started me thinking abut the "slippery slope" which might ensue if any type of legislation is enacted which would attempt to prohibit an ISP from blocking traffic in an effort to keep it [unwanted traffic] from traversing their network: "'It'd be unfortunate to have to pass a law [against port blocking and other types of interference], but we may have to,' Citron said. Though he said he has previously testified against the need for port-blocking regulation, Citron may now change that tune, especially if more network operators start using port-blocking or other techniques to selectively control Internet traffic." It looks to me like this is going to open up a huge can of worms. On one hand, you have ISP's who own their own infrastructure and have every right to prohibit traffic from traversing their network which does not conform to their AUP, business practices, technical standards, etc., or provide revenue. By the same token, and specifically when it comes to things like VoIP, we have these issues involving PUC's, FCC regulations, "equal access" rights, etc. IANAL (or a policy wonk), and I hope I'm wrong, but it certainly looks like things could get pretty ugly. - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
RE: $50,000 reward for Verizon cable cutter
Maybe a current Verizon employee looking for extra OT... Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design & Implementation Team 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 [EMAIL PROTECTED] PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua Brady Sent: Friday, January 14, 2005 10:32 PM To: Hannigan, Martin Cc: [EMAIL PROTECTED]; nanog@merit.edu Subject: Re: $50,000 reward for Verizon cable cutter Your not giving customers enough credit, your a customer yourself arn't you? Do you know how to cut those cables? Would anyone else on the list who isn't a disgruntled verizon employee? On Fri, 14 Jan 2005 22:26:04 -0500, Hannigan, Martin <[EMAIL PROTECTED]> wrote: > > > Disgruntled customers don't know how to cut X hundred pair cables. > > --- > Martin Hannigan > [EMAIL PROTECTED] > Verisign, Inc. > > > -Original Message- > From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > To: nanog@merit.edu > Sent: Fri Jan 14 19:10:35 2005 > Subject: Re: $50,000 reward for Verizon cable cutter > > Sean Donelan wrote: > > >Verizon is offering a $50,000 reward for information about several > >acts of cut cables in the last couple of months. At least three lines > >were cut in the last week. > > > >http://www.boston.com/news/local/massachusetts/articles/2005/01/13/veri zon_ > seeking_information_about_cable_cutter/ > > > > > > > With a power saw? Goodness, that sounds noisy in the middle of the > night. I'd have thought a low tech ax would do the job. :-) > > Probably a disgruntled customer, with cable bundles that repair says > were supposed to be replaced 12 years ago, but engineering says isn't > in the budget (like my SBC/Ameritech neighborhood in Ann Arbor). > > Sigh, not enough criminal instinct here. > > -- > William Allen Simpson > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 > -- Joshua Brady
RE: Bogon filtering (don't ban me)
Rob, Just thinking out loud, but is there any reason that this route-server methodology couldn't be applied to other 'undesirable' destinations, such as the world's top spammers, phishing web sites, etc? Maybe break them up into different communities, so subscribers can pick which ones they want to filter. Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design & Implementation Team 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 [EMAIL PROTECTED] PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Thomas Sent: Saturday, December 04, 2004 7:22 PM To: NANOG Subject: RE: Bogon filtering (don't ban me) Hi, Hank. ] I do as well, but does this scale? Can Team CYMRU handle 2,000 BGP ] sessions? 20K? 200K? -Hank We can handle quite a lot of sessions, and already do, thanks to the distributed nature of the Bogon route-server project. We have several routers deployed, and are prepared to deploy more if necessary. By the way we recommend that folks peer with at least two of the Bogon route-servers. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
RE: [Insight?] OutPut Drops Cisco 7206VXR
Isn't weighted fair queueing generally a bad idea on a LAN interface? Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design & Implementation Team 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 [EMAIL PROTECTED] PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gyorfy, Shawn Sent: Tuesday, October 26, 2004 10:49 AM To: '[EMAIL PROTECTED]' Cc: [EMAIL PROTECTED] Subject: RE: [Insight?] OutPut Drops Cisco 7206VXR Yeah - we have traffic shaping: policy-map Outbound-Transmission-To-Core (We have 10) class Expedited-Forwarding-To-Core priority percent 50 class Hanover_13364_14025_37272-TS-To-Core shape average 1536000 192000 15000 class Queller_3266_3268_30989-TS-To-Core shape average 70 87500 15000 . . . (10) FastEthernet0/0 is up, line protocol is up Hardware is DEC21140A, address is 0001.636e.1c00 (bia 0001.636e.1c00) Description: Connected to Extreme Summit48 Internet address is MTU 1500 bytes, BW 10 Kbit, DLY 100 usec, reliability 255/255, txload 12/255, rxload 3/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:21, output 00:00:00, output hang never Last clearing of "show interface" counters 00:37:12 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 5397 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/82/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 25000 kilobits/sec 5 minute input rate 1505000 bits/sec, 979 packets/sec 5 minute output rate 5084000 bits/sec, 1590 packets/sec 2028319 packets input, 434456929 bytes Received 3 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog 0 input packets with dribble condition detected 3453733 packets output, 1359654191 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out Serial2/0 is up, line protocol is up Hardware is M1T-T3+ pa Description: ny-0200 V#51HFGL605916 (DS3 to 39 Broadway POP) Internet address is MTU 4470 bytes, BW 44210 Kbit, DLY 200 usec, reliability 255/255, txload 8/255, rxload 29/255 Encapsulation PPP, LCP Open Open: CDPCP, IPCP, crc 16, loopback not set Keepalive set (10 sec) Restart-Delay is 0 secs Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 00:37:49 Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/10/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 11052 kilobits/sec 5 minute input rate 5029000 bits/sec, 1584 packets/sec 5 minute output rate 1437000 bits/sec, 966 packets/sec 3460149 packets input, 1351120603 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 parity 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 2005303 packets output, 418156501 bytes, 0 underruns 0 output errors, 0 applique, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions rxLOS inactive, rxLOF inactive, rxAIS inactive txAIS inactive, rxRAI inactive, txRAI inactive -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 10:55 AM To: Gyorfy, Shawn Subject: Re: [Insight?] OutPut Drops Cisco 7206VXR Do you have any rate limiting on the Ethernet interface? The bus error.. I would say let cisco just replace your gear... that dosen't sound good. How is the bandwidth usage soo different? That dosen't sound right -Justin On Tue, 26 Oct 2004, Gyorfy, Shawn wrote: > > What's up all, > > I have a question, maybe some have experienced this before- let me paint the > picture for you first - We are running VoIP- customer's are experiencing > static. > > I have a DS3 going for a Cisco 10k router to a Cisco 7206VXR M2T-T3+ pa > Interface. As of right now, the current usage is about 5.5Mbps with an > input rate of about 1425pps and output rate of 756. > > The Fast Ethernet is connected to an Extreme Switch. The FastE's usage > right now is about 20Mbps with an input rate of 868pps and an output of > 1541pps. > > On the FastE - we are seeing Output drops. They were at a constant > interval, when we were running IOS c7200-p-mz.123-9a. As per cisc
RE: OT: Looking for Ethernt/Optical Device
You need to check the switches to make sure they support the xWDM GBICs though. The older Cisco switches don't support them. Last time I checked, 3500XLs didn't support them, but 3550s did... Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Wam!Net Government Services - Design & Implementation Team 13665 Dulles Technology Dr. Ste 250 Herndon, VA 20171 Office: 703-480-2569 Cell: 703-819-3495 [EMAIL PROTECTED] PGP key: http://pgp.mit.edu:11371/pks/lookup?op=index&search=cchurch%40wamnetgov. com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erik Haagsman Sent: Tuesday, June 01, 2004 11:49 AM To: Michael Smith Cc: [EMAIL PROTECTED] Subject: Re: OT: Looking for Ethernt/Optical Device What you could try is use the Cisco CWDM-MUX-4 and it's pluggable optics that can be fit into any GBIC 802.3z compliant slot. It's just an OADM with 4 or 8 wavelengths that delivers GigE to any box with pluggable GBICs provided you use the right optics and it's quite a bit cheaper than using ONS stuff. That said, CWDM doesn't get you much further than 80 kilometres, above that DWDM is your only option, and a hell of a lot more expensive. Cheers, -- --- Erik Haagsman Network Architect We Dare BV tel: +31(0)10 7507008 fax:+31(0)10 7507005 http://www.we-dare.nl On Tue, 2004-06-01 at 17:30, Michael Smith wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello All: > > I'm wondering if anyone has seen a good and cheap(er) solution for > providing multiple Gigabit Ethernet circuits over single pair of > fiber. I'm looking for a way to do CWDM or DWDM that's cheaper than > putting in a Cisco 15454 or 15327. I'm only going to be doing 2 GigE > circuits between two switches, so I don't need to plan for future > growth. > > If anyone knows of a magic box that will do the above I would love to > hear about it. > > Thanks, > > Mike > > - -- > Michael K. SmithNoaNet > 206.219.7116 (work) 866.662.6380 (NOC) > [EMAIL PROTECTED] http://www.noanet.net > > -BEGIN PGP SIGNATURE- > Version: PGP 8.0.3 > > iQA/AwUBQLyiVJzgx7Y34AxGEQIDewCfR8JQG2jqbxsBopUE6u3FUnfiX3UAoODx > 41QL7T1eyK1EQ4ZMnVJU+l2p > =hDVT > -END PGP SIGNATURE-
