Flood affecting US east coast communication facilities?
Greetings all, Any reports on damage to communications facilities on US east coast? --Kauto -- Kauto Huopio - ka...@huopio.fi (dayjob @ CERT-FI )
Re: Flood affecting US east coast communication facilities?
On Tue, Oct 30, 2012 at 3:46 AM, Kauto Huopio wrote: > Any reports on damage to communications facilities on US east coast? Yes. The outages list is a better place to look for this information. https://puck.nether.net/pipermail/outages/2012-October/date.html -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts
Re: Flood affecting US east coast communication facilities?
I saw cogent is sending 50k less routes today dunno if that has anything to do with it. On Tue, Oct 30, 2012 at 1:55 AM, Jeff Wheeler wrote: > On Tue, Oct 30, 2012 at 3:46 AM, Kauto Huopio wrote: >> Any reports on damage to communications facilities on US east coast? > > Yes. The outages list is a better place to look for this information. > > https://puck.nether.net/pipermail/outages/2012-October/date.html > > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > -- Bryan Tong Nullivex LLC | eSited LLC (507) 298-1624
Re: Belpak / Beltelecom contact to address a BGP hijacking issue?
Hi, On Mon, Oct 29, 2012 at 7:03 PM, Anurag Bhatia wrote: > Seems like they are not advertising it anymore. AS6697 has transit from > Level3 and peering/transit from HE. Both of them show path to AS3215 for > that prefix now. Yes, seems that the annoucement stopped yesterday, after 5 days: Origin AS First Seen Last Seen AS3215 2012-10-28 17:32:51 UTC 2012-10-30 07:00:20 UTC AS6697 2012-10-24 09:28:20 UTC 2012-10-29 12:18:10 UTC AS5396 2012-10-24 09:17:58 UTC 2012-10-24 09:17:58 UTC Anyway, as we couldn't reach anyone from Belpak, not sure how the issue was solved. So I think we'll let the 2.2.2.0/24 a few days more (usually only the 2.2.0.0/16 is advertised by AS3215... but the 2.2.2.0/24 prefix is so often subject to hijacking that we might permanently add this /24 as well). -- sarah
Re: Flood affecting US east coast communication facilities?
I think XO circuits are also affected due to "Sandy" -Thanks, Viral On 30 October 2012 13:16, Kauto Huopio wrote: > Greetings all, > > Any reports on damage to communications facilities on US east coast? > > --Kauto > > -- > Kauto Huopio - ka...@huopio.fi > (dayjob @ CERT-FI ) > >
Re: IP tunnel MTU
>> Certainly fixing all the buggy host stacks, firewall and compliance devices >> to realize that ICMP isn't bad won't be hard. > > Wait till you get started on "fixing" the "security" consultants. Ack. I've yet to come across a *device* that doesn't deal properly with "packet too big". Lots (and lots and lots) of "security" people, one or two applications, but no devices. Regards, Tim.
Re: IP tunnel MTU
Hi, >>> Certainly fixing all the buggy host stacks, firewall and compliance devices >>> to realize that ICMP isn't bad won't be hard. >> >> Wait till you get started on "fixing" the "security" consultants. > > Ack. I've yet to come across a *device* that doesn't deal properly with > "packet too big". Lots (and lots and lots) of "security" people, one or two > applications, but no devices. I know of one: Juniper SSG and SRX boxes used to block IPv6 ICMP errors when the screening option 'big ICMP packets' was enabled because it blocked all (v4 and v6) ICMP packets bigger than 1024 bytes and IPv6 ICMP errors are often 1280 bytes. I don't know if that has been fixed yet. - Sander
Re: IP tunnel MTU
On 2012-10-30 11:19, Sander Steffann wrote: > Hi, > Certainly fixing all the buggy host stacks, firewall and compliance devices to realize that ICMP isn't bad won't be hard. >>> >>> Wait till you get started on "fixing" the "security" consultants. >> >> Ack. I've yet to come across a *device* that doesn't deal properly with >> "packet too big". Lots (and lots and lots) of "security" people, one or two >> applications, but no devices. > > > I know of one: Juniper SSG and SRX boxes used to block IPv6 ICMP errors when > the screening option 'big ICMP packets' was enabled because it blocked all > (v4 and v6) ICMP packets bigger than 1024 bytes and IPv6 ICMP errors are > often 1280 bytes. I don't know if that has been fixed yet. I do not see them "fixing" that either, if one misconfigures a host to filter big ICMP packets, you get exactly that, it will filter those packets. In the same way as folks misconfiguring hosts to drop ICMP in general etc. One cannot solve stupid people as they will do stupid things. Greets, Jeroen
RE: IP tunnel MTU
Hi Chris, > -Original Message- > From: Chris Woodfield [mailto:rek...@semihuman.com] > Sent: Monday, October 29, 2012 4:40 PM > To: Templin, Fred L > Cc: William Herrin; Ray Soucy; NANOG list > Subject: Re: IP tunnel MTU > > True, but it could be used as an alternative PMTUD algorithm - raise the > segment size and wait for the "I got this as fragments" option to show > up... Yes; it is a very attractive option on the surface. Steve Deering called it "Report Fragmentation (RF)" when he first proposed it back in 1988, but it didn't gain sufficient traction and what we got instead was RFC1191. As I mentioned, SEAL does this already but in a "best effort" fashion. SEAL will work over paths that don't conform well to the RF model, but will derive some useful benefit from paths that do. > Of course, this only works for IPv4. IPv6 users are SOL if something in > the middle is dropping ICMPv6. Sad, but true. Thanks - Fred fred.l.temp...@boeing.com > -C > > On Oct 29, 2012, at 4:02 PM, Templin, Fred L wrote: > > > Hi Bill, > > > >> Maybe something as simple as clearing the don't fragment flag and > >> adding a TCP option to report receipt of a fragmented packet along > >> with the fragment sizes back to the sender so he can adjust his mss to > >> avoid fragmentation. > > > > That is in fact what SEAL is doing, but there is no guarantee > > that the size of the largest fragment is going to be an accurate > > reflection of the true path MTU. RFC1812 made sure of that when > > it more or less gave IPv4 routers permission to fragment packets > > pretty much any way they want. > > > > Thanks - Fred > > fred.l.temp...@boeing.com > >
Re: IPv6 only streaming video
Hello, Due to popular demand ( :=)) ), we are currently offering the streaming of the LACNIC / LACNOG event over an IP6-only channel. Take a look at http://www2.lacnic.net/sp/eventos/lacnicxviii/stream6.html The webpage will load over IPv4 but the video is IPv6-only regards ~Carlos On 7/25/12 2:11 PM, Tina TSOU wrote: > http://video.v6.labs.lacnic.net/jw/ > Server can not be found since yesterday. Has the URL been changed? > > Tina > 408-859-4996 >
RE: Network scan tool/appliance horror stories
I can share with you several stories personnel (both IT or vendors), who have scanned Electric Utility environments with or without permission; and hence caused multiple failures - including electro-mechanical systems and related applications. Utilities typically utilize many industrial controllers - some of which many IT personnel have no knowledge, and some are not robust enough to weather the storm. 1. Know your environment. 2. Know your tools. 3. Communicate. -Original Message- From: Dan White [mailto:dwh...@olp.net] Sent: Monday, October 29, 2012 12:47 PM To: Pedersen, Sean Cc: nanog@nanog.org Subject: Re: Network scan tool/appliance horror stories On 10/29/12 12:10 -0700, Pedersen, Sean wrote: >We're evaluating several tools at the moment, and one vendor wants to >dynamically scan our network to pick up hosts - SNMP, port-scans, WMI, >the works. I was curious if anyone had any particularly gruesome horror >stories of scanning tools run amok. http://www.tulsaworld.com/news/article.aspx?subjectid=334&articleid=20121002_11_A1_CUTLIN325691 A > layer 7 failure. Make sure all members of your organization are aware of your plans. -- Dan White
Re: Network scan tool/appliance horror stories
We have had ncircle scans unexpectedly crash alcatel-lucent omni-switches. On Mon, Oct 29, 2012 at 3:10 PM, Pedersen, Sean wrote: > We're evaluating several tools at the moment, and one vendor wants to > dynamically scan our network to pick up hosts - SNMP, port-scans, WMI, the > works. I was curious if anyone had any particularly gruesome horror stories > of scanning tools run amok.
RE: Network scan tool/appliance horror stories
Network scan tools are a great way to verify what important protocols you left out of your control plane policing non-default policies. Had a scanner totally clog up our 6500 core router DHCP relay (ip helper) function once. Uggghhh, security people Chuck
RE: Network scan tool/appliance horror stories
Speaking of scan tools, does anyone have recommendations for tools to do baseline configurations on Windows systems? Looking for pre-change configuration baseline and post change configuration baseline - to identify differences implemented by the change? Thanks. -Original Message- From: Chuck Church [mailto:chuckchu...@gmail.com] Sent: Tuesday, October 30, 2012 10:23 AM To: nanog@nanog.org Subject: RE: Network scan tool/appliance horror stories Network scan tools are a great way to verify what important protocols you left out of your control plane policing non-default policies. Had a scanner totally clog up our 6500 core router DHCP relay (ip helper) function once. Uggghhh, security people Chuck
New York Crews?
Anyone know of lists, contacts, etc. for companies looking for I.T. Folks for help with cleanup and such on the eastern seaboard? I am guessing there will be a demand for anyone from cable pullers to Engineers. I have some free time on my hands and would gladly take a cut in pay to go out and work with the cleanup. I can terminate cables, climb towers, etc. I am sure I am not the only underemployed I.T. Guy who could spend a week or two helping a data center, or other entity. Just wondering if anyone knew of any resources, groups, contacts. Thanks, Justin -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog xISP News http://www.twitter.com/j2sw Follow me on Twitter
Twitter Issue
Hi All Was there is any global issue in Twitter.com here is saudi arabia we were not able to access twitter.com from 3:30 to 06:30 GMT any idea ? *Rashed Alwarrag *
Re: Twitter Issue
On Tue, Oct 30, 2012 at 7:18 PM, Rashed Alwarrag wrote: > Hi All > > Was there is any global issue in Twitter.com here is saudi arabia we were > not able to access twitter.com from 3:30 to 06:30 GMT any idea ? does the saudi telecom ministry (or like agency) limit access to things perhaps?
