Re: Ukraine request yikes

[virendra rode]

I concur, this is an extremely dangerous slippery slope that ICANN should 
refrain. There’s the possibility for misfires, misattribution and 
miscalculation that could backfire which is extremely concerning.

—
regards,
/vrode 

> On Mar 1, 2022, at 00:56, Matthew Petach  wrote:
> 
> 
> 
> 
>> On Tue, Mar 1, 2022 at 12:19 AM George Herbert  
>> wrote:
>> Posted by Bill Woodcock on Twitter… 
>> https://twitter.com/woodyatpch/status/1498472865301098500?s=21
>> 
>> https://pastebin.com/DLbmYahS
>> 
>> Ukraine (I think I read as) want ICANN to turn root nameservers off, revoke 
>> address delegations, and turn off TLDs for Russia.
>> 
>> Seems… instability creating…
>> 
>> -george
> 
> 
> Information sharing should increase during wartime, not decrease.
> 
> Restricting information is more often the playbook of authoritarian regimes, 
> and not something we should generally support.  
> 
> Besides, GhostWriter is based out of Belarus, not Russia proper.  ^_^;
> https://www.wired.com/story/ghostwriter-hackers-belarus-russia-misinformationo/
> 
> Matt
> 
> 
> 

Re: loc.gov

[virendra rode]

Hi,

No, that's for changes and updates related to the list. I would stick with w/ 
outages@ and outages-discussion@ as mentioned below.

outa...@outages.org - Warnings of (un)planned outages and reports of observed 
current outages
outages-discuss...@outages.org - Discussion about post outages 
(troubleshooting, analysis, post-mortem, venting, etc).
outages-annou...@outages.org - Change management and future updates related to 
the lists. 

---
regards,
/vrode 

> On Jul 9, 2017, at 8:59 PM, Joly MacFie  wrote:
> 
> I also noticed an outages-announce - is that for people who don't sub to
> the other two, or should one do all 3 to be fully notified?
> 
> j
> 
> 
> 
> On Sun, Jul 9, 2017 at 10:28 PM, Damian Menscher via NANOG 
> wrote:
> 
>> There are two lists, depending on whether you're reporting an ongoing
>> outage, or just talking about one:
>> 
>> https://puck.nether.net/mailman/listinfo/outages
>> https://puck.nether.net/mailman/listinfo/outages-discussion
>> 
>> Damian
>> 
>> On Sat, Jul 8, 2017 at 6:41 PM, Nicholas Oas 
>> wrote:
>> 
>>> I'd be interested to know the answer to this one as well, as I've gone
>>> looking for the outages list in the past and found the same result.
>>> 
>>> Have isitdownorjustme sites simply superceded the need for such lists?
>>> 
 On Jul 8, 2017 6:59 PM, "Joly MacFie"  wrote:
 
 Actually, now I go to https://www.nanog.org/list/faq/other
 
 I don't see any such thing, just http://www.outages.org/ where the
>>> latest
 report is 2013.
 
 Also "See *http://www.isp-lists.com/*  for
>>> many
 other topic-specific lists." takes one somewhere else entirely!
 
 j
 
 
 
 On Sat, Jul 8, 2017 at 6:47 PM, Doug Barton 
>> wrote:
 
> Isn't that a problem that suggests its own solution?
> 
> 
> 
>> On 7/8/2017 1:43 PM, Joly MacFie wrote:
>> 
>> (sorry I'm not on the outage list)
>> 
>> --
>> ---
>> Joly MacFie  218 565 9365 Skype:punkcast
>> --
>> -
>> 
> 
 
>>> 
>> 
> 
> 
> 
> -- 
> ---
> Joly MacFie  218 565 9365 Skype:punkcast
> --
> -

Re: Another puck.nether.net Outage?

[virendra rode]

Thank you for reaching out.

Will update outages wiki so people can reach admins directly for future 
reference.

Sorry for any inconvenience this may have caused. 

regards,
outages team 

> On Nov 13, 2015, at 7:25 AM, Hugo Slabbert  wrote:
> 
> The problem seems to have been with mailman. I pinged Jared OOB and he 
> responded this that it's fixed. I'd sent something to outages-request prior 
> to test, and that came through this morning.
> --
> Hugo
> h...@slabnet.com: email, xmpp/jabber
> also on Signal
> 
>  From: Christopher Morrow  -- Sent: 2015-11-13 - 
> 06:46 
> 
>> Received: from puck.nether.net (localhost [IPv6:::1])
>> by puck.nether.net (Postfix) with ESMTP id 25969540762;
>> Fri, 13 Nov 2015 07:05:01 -0500 (EST)
>> 
>> puck seems to be processing mail...
>> 
>> $ w
>> 09:45:28 up 2 days, 11:30,  2 users,
>> 
>> $ mailq | grep cisco-nsp | wc -l
>> 174
>> 
>> $ mailq | grep pumpk | wc -l
>> 0
>> 
>>> On Fri, Nov 13, 2015 at 12:33 AM, Crist Clark  wrote:
>>> There hasn't been a any traffic on the puck.nether.net list to which I am
>>> subscribed since the 10th. I sent something to cisco-nsp yesterday and
>>> retried today, and nothing has come through.
>>> 
>>> Is it me or puck?
>>> 
>>> I apologize for using NANOG for this, but jared's email is puck.nether.net
>>> too; something OOB is needed. I know there are many, many people here who
>>> also follow puck.nether.net lists and some may have another way to reach
>>> him.
> 
> 

Re: New York Crews?

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 10/30/2012 02:00 PM, Justin Wilson wrote:
> 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
- ---
If people interested in such effort feel free to drop me a note w/
your location, contact and what are you willing to help w/. I can put
a list and plot it on tracker so people reach you if need be.


regards,
/virendra
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iF4EAREIAAYFAlCRay0ACgkQ3HuimOHfh+G3jQD+NacDHePtULlPQBw4UBRwkl0e
DG9igmrlbLR7/6X/kRoA/RNWKwyBDrSJ8BtaB2UcF6MF247wgNCKZZLB9rLTdwAc
=IShy
-END PGP SIGNATURE-

Re: 75th Broad up/down?

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/31/2012 09:19 AM, Jeff Shultz wrote:
> An online magazine I work with is, we believe, hosted at 75 Broad
> or 111 8th. It dropped out Monday night, right after they announced
> that the diesel pumps had fried due to flooding at 75 Broad, came
> back up early Tuesday morning, and then died again this morning.
> 
> IP address is in 74.63.44.0/24 block (which may be part of a larger
> block).
> 
> Pinging 74.63.44.255 gets me replies from 208.122.44.210 only.
> 
> Anyone know the current status of these facilities? I've got an
> e-mail in to noc@internap but haven't heard back - and if they have
> a facility down they're probably too busy to reply to a single web
> hosting customer.
> 
> I have seen the report from earlier this morning indicating that
> 111 8th had an issue that's been fixed - but the Internap NOC line 
> (877.843.4662) still indicates that NYM008 is having a power
> outage.
> 
> Thanks!
> 
- --
http://tracker.outages.org/reports/view/68

and more update on the list.


regards,
/virendra
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iF4EAREIAAYFAlCRZPgACgkQ3HuimOHfh+HKKgEAhF3Iwx8/LOqAM49MmOsI6uwZ
fdHcLpOFMBHFzYyFRoUBAIH91cZKrmzooK/Akhl4IixNEw4fu6P/Yq4D5W0nrcvv
=1QUU
-END PGP SIGNATURE-

Re: Multiple Sprint Outages?

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/08/2012 12:06 PM, Eric Rosenberry wrote:
> Looks like Sprint is having a very bad day today in the NW?
> 
> Anybody able to elaborate on exactly where these fiber cuts are and exactly
> what is impacted?  I see mention of several different places that things
> may be cut right now...
> 
> We saw sporadic readability issues this AM until we downed our connection
> to Sprint.
> 
> http://www.datacenterknowledge.com/archives/2012/10/08/cable-cut-in-midwest-hobbles-alaska-airlines/
> 
> http://techcrunch.com/2012/10/08/sprint-voice-data-down-in-minnesota-washington-oregon-alaska-airlines-flights-delayed/
> 
> -Eric
> 
- 
http://tracker.outages.org/reports/view/48


regards,
/virendra
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iF4EAREIAAYFAlBzJv4ACgkQ3HuimOHfh+EvrQD/T9hRplTeA0Cqfs9Wt3BUNsc4
iAt2qELtbWZmF6AM+ZYA/3dIX0YRhA/J8rycF8isVvOq26zu2gt92jDxpLE0zfuy
=+gyU
-END PGP SIGNATURE-

Re: Strange Reachability Issue

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 09/04/2012 07:20 AM, Bryn Sadler wrote:
> Many thanks to Jared for jumping on this so quickly off-list, it's
> much appreciated and hopefully we're getting towards a solution
> now.
> 
> Bryn
- --
yup you are in good hands, sounds more like filtering related among
peers. Use can use communities to test this theory.


regards,
/virendra
> 
> 
> 
> 
> On 04/09/2012 15:12, "Jared Mauch"  wrote:
> 
>> I know a few folks from NTT have looked into this.  If someone 
>> from KPN would get in touch with Bryn I'm sure the issue could
>> be quickly resolved.
>> 
>> - Jared
>> 
>> On Sep 4, 2012, at 9:18 AM, Brandt, Ralph wrote:
>> 
>>> I will bet that will bet that within 48 hours of you checking
>>> and posting this the problem will mysteriously go away.
>>> 
>>> 
>>> 
>>> Ralph Brandt Mechanicsburg PA 17055
>>> 
>>> -Original Message- From: Bryn Sadler
>>> [mailto:bryn.sad...@essensys.co.uk] Sent: Tuesday, September
>>> 04, 2012 9:02 AM To: nanog@nanog.org Subject: Strange
>>> Reachability Issue
>>> 
>>> Hello all,
>>> 
>>> I was wondering if anyone might be able to share their thoughts
>>> on a strange issue we're experiencing with NTT at the moment.
>>> We're AS48273 and are advertising a prefix 94.198.184.0/21
>>> through AS 8190 (single upstream provider at the moment). We've
>>> been doing this for some years now, and all has been fine. The
>>> last few days we seem to have disappeared from NTT's worldwide
>>> routing tables, with the exception of Europe. If we use their
>>> looking glass to query any NTT european router we can see the
>>> prefix, being learned via AS 286 then AS 8190, as expected. If
>>> we look at any other router outside of europe, there is simply
>>> no entry for that prefix. Elsewhere in the world we seem to be 
>>> fine, we're in every other network I've looked at and general 
>>> reachability is fine.
>>> 
>>> First step was to contact the NTT NOC, and they've confirmed
>>> that there's no Internal routing/config issue on their network,
>>> but that they cannot discuss their peering arrangements due to
>>> NDAs. We've also picked it up with KPN (AS 286), who have
>>> verified that the prefix is visible throughout their network
>>> (true), and that they are advertising it to NTT. One thing of
>>> note is that Global Crossing are learning our prefix from KPN
>>> as well, and the prefix is showing fine in their global
>>> tables.
>>> 
>>> We seem to be caught in the classic finger pointing scenario,
>>> but I can't get my head around why the prefix is visible in NTT
>>> Europe, but not anywhere else, unless they have a config error
>>> somewhere on their network. We've checked a few of the routes
>>> from AS 8190 and they are in the NTT global tables just fine,
>>> and at least in Europe they seem to have the same community
>>> values etc. We're still following on with NTT, but can anyone
>>> offer some wisdom for new avenues to pursue?
>>> 
>>> Thanks for your help,
>>> 
>>> Bryn Sadler
>>> 
>>> 
>>> This message has been scanned for viruses by essensys
>>> mailcontrol
>>> 
>> 
> 
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iF4EAREIAAYFAlBGGlMACgkQ3HuimOHfh+GpNgD+PMX5zFgMcCc7pzLr9e/yskNs
RESv+rEeZKC2t1UfpCYA/0vPN8JlgiRLoRi+S/kkJwOEXMlzYMnHS7eGkOn0YU4j
=PJwR
-END PGP SIGNATURE-

Re: Redundant Routes, BGP with MPLS provider

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/31/2012 09:21 AM, bill.ing...@t-systems.com wrote:
> I think having a GRE tunnel for the internal routing protocol is 
> unnecessary.  Can you explain the reasoning behind this?  I
> understand the technical issue whereby GRE will allow multicast for
> EIGRP, OSPF, etc, but why not just redistribute into BGP?
> 
> I work on a lot of MPLS CE routers, and in general you can
> accomplish anything you need by redistributing your internal
> routing protocol into BGP, and adjusting LP, MED and AS Prepend as
> needed.
> 
> Thanks,
> 
> Bill
- ---
Using bgp communities (MED attribute "inbound") helped influence our
path(s) between our mpls providers.


regards,
/virendra
> 
> -Original Message- From: Lee [mailto:ler...@gmail.com] 
> Sent: Friday, August 31, 2012 11:15 AM To: Tribble, Wesley Cc:
> nanog@nanog.org Subject: Re: Redundant Routes, BGP with MPLS
> provider
> 
> On 8/30/12, Tribble, Wesley  wrote:
>> Hello all,
>> 
>> I am an Network Operator working in an Enterprise environment
>> with offices all over the country(mostly connected via MPLS).  We
>> are currently working towards building a Disaster Recovery Site
>> that will host some of our vendor routers and provide the
>> capability to access these vendors from both our primary and
>> backup data center locations.
> 
>> The routes(as advertised by the vendor's routers) will be the
>> same at both locations.  I would like to advertise the routes
>> from multiple locations at the same time, rather than suppress
>> the routes and
> advertise conditionally.
> 
> At work, we have our internal routing protocol running on GRE over
> IPSec tunnels & keep the BGP sessions with the MPLS provider
> limited to just the MPLS network.  And have an ACL on the MPLS
> network interface that allows only what's expected in...   some
> providers are better than others at not having anything hit the
> 'deny any any log' line
> 
> Regards, Lee
> 
> 
>> 
>> What is the best method to Instruct the provider's network to
>> prefer the Primary Data Center routes over the DR site?  Keep in
>> mind that I am only peering with the provider over BGP and I have
>> no visibility to
> 
>> the underlying MPLS architecture or configuration.  Although if
>> you have specific questions  about their architecture, I can work
>> to get
> answers.
>> 
>> Discussing in house, we have gone over a few different options:
>> 
>> -Advertise specific routes from primary site and summary routes
>> from the DR site.  Most specific will always be chosen. -Prepend
>> the routes from the DR site so that they will have a longer 
>> AS-path than the Primary location -Use Community Strings to
>> influence local preference.(Still working to find out if Provider
>> will pass our community strings)
>> 
>> Just looking for some ideas and best practices.  Any thoughts or
>>  insight would be much welcomed and appreciated.  This is my
>> first message on NANOG, so please be gentle.  I apologize in
>> advance if I have done something incorrectly.
>> 
>> 
>> Wes
>> 
>> 
>>  
>> **
>>
>> 
 Sterne Agee Group, Inc. and its
>> subsidiaries request that you do not transmit orders and
>> instructions regarding your Sterne Agee account by e-mail.
>> Transactional details do
> 
>> not supersede normal trade confirmations or statements. The 
>> information contained in this transmission is privileged and 
>> confidential. It is intended for the use of the individual or
>> entity named above. The information contained herein is based on
>> sources we believe reliable but is not considered all-inclusive.
>> Opinions are our
> 
>> current opinions only and are subject to change without notice. 
>> Offerings are subject to prior sale and/or change in price.
>> Prices, quotes, rates and yields are subject to change without
>> notice. Sterne Agee & Leach, Inc. member FINRA and SIPC, is a
>> registered broker-dealer subsidiary of Sterne Agee Group, Inc.
>> Generally, investments are NOT FDIC INSURED, NOT BANK GUARANTEED,
>> and MAY LOSE VALUE. Please contact your Financial Advisor with
>> information regarding specific investments. Sterne Agee reserves
>> the right to monitor all electronic correspondence.
>> 
> 
>
> 
**
>> 
> 
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iF4EAREIAAYFAlBBA1kACgkQ3HuimOHfh+HhsgD7BGtBuiX9tw0leW5e2Jv3jT5E
OvAlvkc6bJgE6oSPwdYA/2AkjAWawOOJAIvkmIh6+jXQJo5IRJhl5u6IqtbwFKsy
=zUYy
-END PGP SIGNATURE-

Re: XO outage in NJ/NY?

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/30/2012 01:10 PM, chris wrote:
> Anyone heard anything about an XO fiber cut in northeast? We have
> had a bunch of issues with some DID's in NJ today and one of our
> carriers forwarded a a vague statement from XO:
> 
> *XO Communications is currently experiencing a fiber-cut which is
> causing a service interruption for some markets in the east coast
> region. Users may experience DID failures for numbers in NY, NJ and
> other surrounding areas. They are working on fixing the issue but
> unfortunately have not provided an ETA at this time*
> 
> Just curious how widespread the effect is and if anyone knows
> anything more about it
> 
> thanks chris
- 
http://tracker.outages.org/reports/view/29

regards,
/virendra

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAlA/0kEACgkQ3HuimOHfh+FNNgD+K2UBkKIr14f5moV/8W5J47f/
yuESX7szffFFb6pqa6AA/30kMggu1MEvxkOsfW7ebbf5SzmCItZqUx+I9AZpd1ME
=WF+9
-END PGP SIGNATURE-

Re: Sprint Outage - Chicago

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 08/27/2012 10:54 AM, Patrick W. Gilmore wrote:
> On Aug 27, 2012, at 12:58, virendra rode 
> wrote:
>> On 08/25/2012 11:36 AM, Jason Baugher wrote:
>>> On 8/24/2012 11:39 PM, Randy Bush wrote:
>>>>> You mean outages@...
>>>> chris, this is not productive.  outages are a very apt
>>>> subject for nanog.
> 
> I'm actually not certain posting outages to NANOG-l is a good idea.
> There are a LOT of outages, and I worry the list will be drowned.
> 
> But I don't run the list.  Plus this discussion is probably better
> suited for NANOG-futures@.
> 
> The stuff below, however, may belong on NANOG.
> 
> 
>>> Did anyone ever give any details of the issue? We're a Chicago 
>>> Sprint customer, and never saw a problem. No mention of any
>>> issues in Compass either.
>>> 
>>> Jason
>> -  I hear there was a memory leak issue to their
>> core IP backbone router. Don't have specifics as to what
>> region(s) within chicago that was impacted.
> 
> I wonder if the Sprint & Telia outages were for the same reason /
> bug.  Anyone from those networks want to comment?  Or at least
> compare notes?
> 
> 
>> If you and /or anyone else have any specifics, please post in
>> the comments section of,
>> http://tracker.outages.org/reports/view/25
> 
> Interesting!
> 
> Is there a way to say "this may be related to ticket $FOO?"
- -
Do you mean when reporting an outage? If so, yes, once verified it
will be updated and /or plotted.



regards,
/virendra
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAlA7zDQACgkQ3HuimOHfh+H4zAD+L3mE1s7gW+60h1ccrVR5o+5x
eHLQ+PdDTxGd5cgG4wMA/2Fd+4DHEBg0eN8ZeON52HkEIJDXI4N9dNgT7FxUQQrj
=wVcX
-END PGP SIGNATURE-

Re: Sprint Outage - Chicago

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/25/2012 11:36 AM, Jason Baugher wrote:
> On 8/24/2012 11:39 PM, Randy Bush wrote:
>>> You mean outages@...
>> chris, this is not productive.  outages are a very apt subject
>> for nanog.
>> 
> Did anyone ever give any details of the issue? We're a Chicago
> Sprint customer, and never saw a problem. No mention of any issues
> in Compass either.
> 
> Jason
- 
I hear there was a memory leak issue to their core IP backbone router.
Don't have specifics as to what region(s) within chicago that was
impacted.

If you and /or anyone else have any specifics, please post in the
comments section of, http://tracker.outages.org/reports/view/25


regards,
/virendra

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAlA7pzQACgkQ3HuimOHfh+FxfwD+NMcQB1PiQDHo9OrfJWr4XJ3b
bEq/SWioKZ84z9+q4NEA/RmLo4Nhps0beitZ/0PysSI8e7xu8C55c0N/KLa/93JI
=oR8v
-END PGP SIGNATURE-

Re: Att funkyness

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

What baffles me is that we have external sources reporting the status
as opposed to the provider. In all fairness there's a list of others
right behind.

Their their status page has been static as a sticky bit & sealed
harder than woodpecker lips.


regards,
/virendra


On 08/16/2012 09:18 AM, Tom Taylor wrote:
> http://www.networkworld.com/news/2012/081512-atampt-suffers-dns-261673.html?hpg1=bn
>
>
> 
> 
> Continuing DDOS attack knocked out some DNS servers.
> 
> On 15/08/2012 10:46 PM, Phil Dyer wrote:
>> On Wed, Aug 15, 2012 at 3:41 PM, Mark Foster 
>>  wrote:
>>> Yep. 'no servers could be reached' for at least one domain 
>>> that's hosted with them that i've come across.
>>> 
>>> Appears to have been the case for >6 hours as of about 30 
>>> minutes ago, but just retested, fault appears to have cleared.
>> 
>> 
>> I followed up with this on the outages@ list. Started clearing
>> up for us about 3:30PM EDT. However, I don't see any update from 
>> AT&T. Message has been basically the same all day.
>> 
>> http://www.attens.com/customers/outages.shtml
>> 
>> phil
>> 
>> 
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAlAtSmwACgkQ3HuimOHfh+HXfwD+KPpzxz+rHez58vr+5dYNUGBY
kim6QbLhN7c2pHxA1LEBAIxNtvF/nXZcywr2JrTkd7hZm16hRRwTMyeaQ2BONAml
=hhjA
-END PGP SIGNATURE-

Re: St Louis Internet Exchange

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 07/16/2012 07:36 PM, Bill Woodcock wrote:
> 
> On Jul 16, 2012, at 3:23 PM, Jay Hanke wrote:
> 
>> After a bit of googling, I found some references to an Internet 
>> Exchange in St. Louis, MO called the St. Louis Regional
>> Exchange. Is this project still active?
> 
> It appears to be dead.  The web site redirects to a commercial
> colo, and the last few ISPs appear to have departed at the end of
> 2008, after about two years of activity.
> 
> https://prefix.pch.net/applications/ixpdir/detail.php?exchange_point_id=350
>
>  If anyone has any better information, please let us know.
> 
> -Bill
- 
IXP DBs are coming out empty. I understand these DBs are best effort
but what I like about PCH that it tends to never drop an exchange from
the list and instead marks it as "defunct" or "down" by performing
some sort of validation which Bill could confirm.

In addition to IXP DBs, IRR, LGs & bgp tables (route view & ripe ris)
shows no sign either.


regards,
/virendra
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAlAE5gUACgkQ3HuimOHfh+FRbwD+NLNDFPc+ru2x3fIYJ0gDKuZU
K77j6h8jxrJXwtOSduIA/i09nBAalPPK1fCii+z0swTE6Upj4dWqRA9osFTjwNN5
=iW4R
-END PGP SIGNATURE-

Re: Collecting flows at an IXP

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 06/25/2012 10:45 PM, Graham Beneke wrote:
> Hi All
> 
> I'm busy doing some digging to find a solution for collecting
> layer-2 flows data on a medium sized IXP. All we have at the moment
> is some MRTG graphs and we're trying to get a better view into IPv4
> vs IPv6, src and dst MACs, packet sizes and also perhaps port &
> protocol trends.
> 
> I found Richard A. Steenbergen's NANOG 39 presentation and not
> much since then.
> 
> Is it still correct that Cisco does not support sFlow?
> 
> Are you able to get the same kind of useful data using Netflow v9?
> 
> Which FOSS flow collectors do an decent/adequate job at crunching
> about 10Gbps worth of flows and presenting it in a useful way?
> 
> Thanks
- ---
Another option to consider would be nfsen/nfdump..running nicely as a
plugin under cacti so we get a central view.


regards,
/virendra
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk/qHC0ACgkQ3HuimOHfh+FioQD/Qs7/fje8hziGEym2Wh0sIDWI
16p7ZC+6cJnUUGHzPJsA/jzn0/iCwDCFO8UKSjkXuEpwysRo8U/WeZpTKcbzvhHN
=k2E2
-END PGP SIGNATURE-

Re: Concern about gTLD servers in India

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/11/2012 03:57 AM, Peter Losher wrote:
> On Mar 9, 2012, at 10:19 PM, Anurag Bhatia wrote:
> 
>> I can see India has 3 root servers hosting root zone - i, j & k in India
>> which is good. So we can resolve the root zone i.e dot within India.
> 
> 
> One correction to that; F has been operating in India from NIXI Chennai's PoP 
> since 2005.  The reason you may not see it from your location in India is 
> that it's a local node, so we advertise F's prefixes with the NO_EXPORT 
> community string to limit it's reach to networks directly connected to the 
> local IX/routeserver @NIXI Chennai.
- ---
I see 192.5.5.0/24 less widely seen by the peers as opposed to
192.5.4.0/23 maybe as you mentioned the longer prefix (/24) should be
visible to clients using local instance of f-root.

Why? It would be bad to attract traffic from half way around the world
to a local node as they are there to serve the local community.

Just wondering how do the other root keepers manage that because reminds
me of an outage (k-root related) sometime september or october time
frame of 2010 that a /24 may have leak more widely than intended from a
one of the local instances.

I know off-topic here but what caught my interest is in "no_export" set
for root server as the outage mentioned above came near the K-root local
instance in India.


regards,
/virendra

> 
> And even with that restriction as noted at APNIC 33 in Dehli, the node is one 
> of our (F's) busiest in Asia...
> 
> -Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk9dM6QACgkQ3HuimOHfh+H61gD/VGHBJdphTPA1yOYUGr7nmouG
UJwR3yL4WAPcgfpDh6oA/AvwWW7kqU00ghOVE+Xioejv2gKPBQDB18hHGrmEcxtY
=RDVK
-END PGP SIGNATURE-

Re: BBC reports Kenya fiber break

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/27/2012 08:11 AM, Marshall Eubanks wrote:
> Is anyone seeing this ?
> 
> http://www.bbc.co.uk/news/world-africa-17179544
> 
> "East Africa's high-speed internet access has been severely disrupted
> after a ship dropped its anchor onto fibre-optic cables off Kenya's
> coast."
> 
> Regards
> Marshall
> 
- --
I don't have a direct feedback into this disruption but from what I
gather they were able to (manually) re-route traffic (alternative
submarine cable and /or satellite systems) whether its slow that's a
different story but having performance degradation, as opposed to
complete service outage is still workable, IMO. Hopefully diversity will
help minimize localized damages as the global economy (communications,
education, business, entertainment, banking & commerce) continues to be
dependent on undersea cables.

Typically the GPS navigation suite has undersea cables well documented.
I for one am interested to know how this was overlooked or maybe human
error?


regards,
/virendra


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk9LyVkACgkQ3HuimOHfh+FZggD/a+LIEBXANdItl2NGbaTCRQsh
+5/l0RvFRL3EMws8IsAA/jlV2gFGzCB1SM8pFAmKnK6sgS38tnxDFDj/4KqIUFky
=40jD
-END PGP SIGNATURE-

Re: do not filter your customers

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Speaking of leaking the world, I remember one of our transit peer during
their nightly maintenance decided they needed people to talk to, so they
decided to share some love by passing ~ 350k routes causing a meltdown.

As lesson learned, we included a combination of prefix-list &
maximum-prefix filters as part of our config script.

When the hard limit hits a certain percentage, we get alerted that the
neighbor is approaching the limit.


regards,
/virendra

On 02/22/2012 09:41 PM, Randy Bush wrote:
> don't filter your customers.  when they leak the world to you, it will
> get you a lot of free press and your marketing department will love you.
> 
> just ask telstra.
> 
> randy
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk9GpfUACgkQ3HuimOHfh+HwZgD/dlgPaTsxCs0cyRFVBsDI2J5i
/dLwyQrUADOySuKlgn0A/iuF+gojyqIbLwstPin0Je06KDytE8AYsNuwLXCmAWI5
=qrOK
-END PGP SIGNATURE-

Re: IX in France

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/23/2012 10:00 AM, Jared Mauch wrote:
> 
> On Feb 23, 2012, at 12:39 PM, virendra rode wrote:
> 
>> I understand this is not true peering relationship, however its an
>> interesting way to obtain exchange point routes and I understand this is
>> nothing new.
> 
> 
- --
> 
> I've found people who use the term 'peering' to mean something different than 
> what I personally interpret it to mean.
> 
> eg: "We have peering with 4 carriers at our colocation facility where you can 
> place gear"
> 
> Translation: We have blended IP transit from 4 carriers, or you can directly 
> connect to them as needed.
> 
> I understand why they call it this, because "I configured peering with 
> Level3/Cogent" on my router, etc.  The difference is in the policy.  What 
> you're speaking of is someone selling transit, which is perfectly fine over 
> various IXes, you generally are prohibited from 'selling next-hop', i.e.: you 
> have to bear the cost on the IX port of the forwarding.
> 
> 
- ---
Correct, I meant to say private peering as opposed to settlement-free.


> 
> Buying transit isn't as dirty as people think it is, sometimes its the right 
> business decision.  If you connect to an IX for $4000/mo at gig-e, you might 
> as well buy transit at $4/meg on that same port IMHO.  You're unlikely to be 
> using the port at 100% anyways at the IX, so your cost-per-meg there needs to 
> properly reflect your 95% or whatnot.
> 
> - Jared
- --
I understand, I'm trying to factor in cost of peering (transport,
equipment, cross-connect, colocation, equipment cost) of buying transit
vs private peering.


regards,
/virendra

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk9GhVsACgkQ3HuimOHfh+HqFgD+L2WYr2Tt1ZRY+Z2AAVDpX00N
bwNSXKLbnzjy8Ol5b2QA/AiL3NbesEoZy901tBW7TAdAzPOUK8W9a4rnhRakDk8B
=acfM
-END PGP SIGNATURE-

Re: IX in France

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Brings up another question to mind, how many of you have peered using
partial route transit versus having direct peering relationship at the
exchange?

I've personally ran into companies during peering meetings wanting to
sell you their peering relationship (access to their routes that they've
earned through their relationship) as opposed to you wanting to
establish direct peering relationship.

This way you don't bare port fees, no colocation cost, cost of IX
membership, etc.

I understand this is not true peering relationship, however its an
interesting way to obtain exchange point routes and I understand this is
nothing new.

Just interested in learning about your experiences.


regards,
/virendra

On 02/21/2012 08:46 AM, Ido Szargel wrote:
> Hi All,
> 
>  
> 
> We are currently looking to connect to one of the IX's available in Paris,
> 
> It seems that there are 2 "major" players - FranceIX and Equinix FR, can
> anyone share their opinions about those?
> 
>  
> 
> Thanks,
> 
> Ido
> 
>  
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk9GeccACgkQ3HuimOHfh+GcBAD8CBJ6Of8ciFMr4ufim8+u7Hpg
cWLXuuqNkgIeQa+jr1gA/27Bqck+d/LEXeoPNJQExUjXMoQC7sNXoPOIHlfrrKF0
=7jTr
-END PGP SIGNATURE-

Re: DNS Attacks

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi -

We've been victims of these attacks many a times and more recently
towards our customer dns servers which was rated at ~ 4gbps for a
duration of 30mins.

Tracking the source of an attack is simplified when the source is more
likely to be "valid".

The nature of these attacks for us was a combination of amplification
and spoofed, however implementing anti-spoofing (uRFP) specially bcp38
is a good idea not saying its a fix but certainly the attack methodology
will significantly lessen.

As Matt Katz put it rightly so, "Distributed denial of service can only
be solved with distributed delivery of service".


regards,
/virendra

On 01/17/2012 09:04 PM, toor wrote:
> Hi list,
> 
> I am wondering if anyone else has seen a large amount of DNS queries
> coming from various IP ranges in China. I have been trying to find a
> pattern in the attacks but so far I have come up blank. I am completly
> guessing these are possibly DNS amplification attacks but I am not
> sure. Usually what I see is this:
> 
> - Attacks most commonly between the hours of 4AM-4PM UTC
> - DNS queries appear to be for real domains that the DNS servers in
> question are authoritive for (I can't really see any pattern there,
> there are about 150,000 zones on the servers in question)
> - From a range of IP's there will be an attack for approximately 5-10
> minutes before stopping and then a break of 30 minutes or so before
> another attack from a different IP range
> - Every IP range has been from China
> 
> I have limited the number of queries that can be done to mitigate this
> but its messing up my pretty netflow graphs due to the spikes in
> flows/packets being sent.
> 
> Does anyone have any ideas what the reasoning behind this could be? I
> would also be interested to hear from anyone else experiencing this
> too.
> 
> I can provide IP ranges from where I am seeing the issue but it does
> vary a lot between the attacks with the only pattern every time being
> the source address is located in China. I read a thread earlier,
> http://seclists.org/nanog/2011/Nov/920, which sounds like the exact
> thing I am seeing.
> 
> Thanks
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk8Wz9YACgkQ3HuimOHfh+EupAD+MkS8Z0+j1D53txQTqMOVDRWe
vve+Ov/im9y87mEqxhsA/0IJKkntI8w11QTMZGgbw55A4V4VQvj7WchKnMNKaT2L
=HsEg
-END PGP SIGNATURE-

Re: Internet Blip in San Diego at 1pm?

[virendra rode]

On 07/31/2011 01:55 PM, Khurram Khan wrote:

Also impacted our POP's out of Houston and San Antonio, TX. We peer
with L3 at both of those locations.


Level3's had a core router failure in their Dallas region that lost 
adjacency towards LA region.



regards,
/virendra



On Sun, Jul 31, 2011 at 2:43 PM, Michael J McCafferty
  wrote:


I am one of your customers that noticed it. To add some data points;
This affected Cogent, Level3 and several networks we peer with at the
Any2 Exchange at One Wilshire.

On Sun, 2011-07-31 at 13:35 -0700, Joe Renwick wrote:

Several of my customers in San Diego noticed large drops in traffic at 1pm
today.  Note it was not a total loss in connectivity.  Anyone else notice
this?



--

Michael J. McCafferty
Principal
M5 Hosting
http://www.m5hosting.com

You can have your own custom Dedicated Server up and running today !
RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more

Re: Internet Blip in San Diego at 1pm?

[virendra rode]

On 07/31/2011 01:35 PM, Joe Renwick wrote:

Several of my customers in San Diego noticed large drops in traffic at 1pm
today.  Note it was not a total loss in connectivity.  Anyone else notice
this?


---
Several of our east coat/overseas customers called in about reachability 
issues towards our SD pop. I believe this was LEVEL3 peering (?) related.


Hopefully transparency will follow.

regards,
/virendra

Re: Securing Border Routers

[virendra rode]

Hi -

On 01/19/2011 04:35 PM, Brandon Kim wrote:


Gents:

What measures do you take to protect your border routers? Our routers are 
running BGP so I'm interested
if there is any way to secure them without interfering with BGP? Is it normal 
to put a firewall in front of the
border routers?

I'm concerned about DDOS attacks mainlyalthough we haven't had any, I don't 
welcome them.

Brandon


-
BCP 38 is worth implementing :-)


regards,
/virendra

Re: Chase.com outage

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/16/2010 09:13 AM, N. Yaakov Ziskind wrote:
> Does anyone have any information (beyond the wimpy statement that
> "technical issues" were to blame) on the Chase outage?
- 
- From my understanding their back-end database suffered from some sort of
corruption that caused login to fail.


regards,
/virendra

> 
> It seems that when a multibillion dollar company's major web site is
> down for more than a day, there must be juicy "technical issues" that 
> beg to be told. So, can anyone dish? :-)
> 
> --  
> _
> Nachman Yaakov Ziskind, FSPA, LLM   aw...@ziskind.us
> Attorney and Counselor-at-Law   http://ziskind.us
> Economic Group Pension Services http://egps.com
> Actuaries and Employee Benefit Consultants
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkySSe8ACgkQpbZvCIJx1beISgCdHerBst0K7Ktv8LzYvNtXmPY2
WHgAnA01VHy75DvnRcyG1JF5WyCAafQB
=KQ6Y
-END PGP SIGNATURE-

Re: SMW4 Routing Implications

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,


shake righa wrote:
> What have been the routing implications in regards to internet traffic
> with SMW4
> cable beign down?
- ---
Latency and slowness then again things are starting to change (mid-2010)
in terms of traffic balance as fibers are being lit across diverse paths.


regards,
/virendra

> 
> 
> 
> Regards,
> Shake Righa
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFL2eHbpbZvCIJx1bcRAjLfAKDl8ouIT9zH2pzjs/1uIafx8E281gCgvRXn
NdDyrX58kLpasNXDEcVgMCo=
=/YYx
-END PGP SIGNATURE-

Re: Network Naming Conventions

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul,

If my memory serves me correct, Richard presented traceroute presto at
nanog47 that covered location identifiers.

HTH,


regards,
/virendra


Paul Stewart wrote:
> Hi Folks...
> 
>  
> 
> With many changes going on this year in our network, I figured it's a
> good time to revisit our naming conventions used in our networks.
> 
>  
> 
> Today, we use the following example:
> 
>  
> 
> Core1-rtr-to-ge1-1-1-vl20.nexicom.net
> 
>  
> 
> Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc
> etc
> 
>  
> 
> Going forward, I'd like to examine a better method to identify the
> devices does anyone have published standards on what they use or
> that of other networks and maybe even why they chose those methods?  The
> core of the network is fairly easy for us to look at different changes
> where you have interfaces, subinterfaces, locations etc. to deal with.
> 
>  
> 
> But what do folks do for "aggregation devices" such as dial-up shelves,
> BAS devices etc?
> 
>  
> 
> Finally, we have a fair amount of gear (that we own) at customer
> premises that act as either a managed device or a demarcation point 
> how to you name those today?
> 
>  
> 
> Open ended questions obviously - looking for many ideas. 
> 
>  
> 
> ;)
> 
>  
> 
> Paul
> 
>  
> 
> 
> 
> 
>  
> 
> 
> 
> "The information transmitted is intended only for the person or entity to 
> which it is addressed and contains confidential and/or privileged material. 
> If you received this in error, please contact the sender immediately and then 
> destroy this transmission, including all attachments, without copying, 
> distributing or disclosing same. Thank you."
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFLm7t7pbZvCIJx1bcRAin3AJ4r69FiLr+qC6KpVn3pfPnuEWRQCgCeMeRU
BbhE1ExSlGBTGU/rWk+3pj4=
=TeNX
-END PGP SIGNATURE-

Re: qwest outage no notice

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,



Martin Hannigan wrote:
> On Sat, Jan 9, 2010 at 9:37 AM, Paul Wall  wrote:
> 
>> On Thu, Jan 7, 2010 at 5:04 AM, Mike 
>> wrote:
>>> We just had a qwest outage of about 2 mins at 1:41am pst. When I called
>> to
>>> report it I was told it was a 200+ emergency software upgrade due to a
>>> security concern, and that we will get a notice later after the fact.
>> That's not a maintenance, that's an outage.
>>
>> I hope everybody impacted on this list is claiming SLA.
>>
>> Drive Slow, much like the M40,
>> Paul Wall
>>
> 
> 
> 
> SLA for what? < 2m of outage time related to an emergency maintenance event?
> I don't think so. Most agreement language covers this kind of event.
- -
I think it comes down to disclosure policy. I cannot imagine qwest was
the only provider who was hit by this emergency patch upgrade.

I don't think general public is really keen in knowing the exact details
of the vulnerabilities as much as getting some sort of heads up about
emergency maintenance window which IMHO should have been issued.

Given that I'm a staunch believer in openness when it comes down to
outages related to critical infrastructure :-)


regards,
/virendra

> 
> You'll be lucky if you can badger your account team into a free dinner
> and/or some free beer for it.
> 
> 
> -M<
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFLSVTkpbZvCIJx1bcRAvX2AJsEmwKOBOs9Ynl8VaHTnS0SLP+SlACgykj3
nEmbjBDWmFj6XUI3k7Kv7fw=
=yGz+
-END PGP SIGNATURE-

Re: Question. Cisco PIX/ASA

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joe -

Maybe the middlebox along the path doesn't like tcp window scale
parameter being changed in the midway due to dropped tcp connections or
something. Could be specific to microsoft server. What does your pix
logs show?

Have you tried turning off 'tcp window scale' option on your windows
server? I believe this is enabled by default[0]. See if you can test this.

I've ran into similar problems using pix/nokia fw.

Hopefully this helps and you might want to bounce (do not crosspost :))
this thread off cisco-nsp.


regards,
/virendra

[0] http://support.microsoft.com/kb/934430


Jo¢ wrote:
> Greetings all
> 
> 
> I have a customer running with a Cisco 5500 series firewall. What were
> seeing (as a problem) is that there is a bit being flipped by the firewall
> in the packet header. The bit in question is the Congession Window Reduced
> or CWR bit. Under heavy load the target server is getting this bit as high
> and since (I am guessing) its that way dropping the session yet its not near
> capacity. It?s a Microsoft server as well. Not that I am knocking that but.
> Under the same situation a Linux/Apache server doesn't seem to care, and
> goes about its business. Anyone heard of this? I did searches regarding this
> but found (as per usual) tons of usless info.  I'm not sure why the packets
> are being changed by the ASA. I know there not hitting the firewall this way
> (Packet capture) but they are getting changed. Config mishap? Is the ASA
> throttling down stuff, and if so why not at the requesting party? 
> 
> Dunno. Completely baffled. Thanks In Advance!
> 
> -Joe
> 
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ+e6DpbZvCIJx1bcRAiYcAKDsGJd2H4QNSB7Leqqc5LwX8Bu78ACgo43T
j6t3fKOELjTbgkP0qhBzzwg=
=krtL
-END PGP SIGNATURE-

Re: Remote hands site or list?

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Owen Roth wrote:
> Hello nanog mailing list,
> 
> I was curious how one would go about looking for certain types of remote
> hands by geography (ie coaxial runs in Phoenix, AZ). Is there another
> mailing list or a web site that recommends itself?
> 
- 
http://nanog.cluepon.net/index.php/Hands


regards,
/virendra
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJynDCpbZvCIJx1bcRAqF3AJ9+BYHGqeYJAmVg+4+rApsW/5uPLQCffq8E
ByrjxjtWQLrsI+hFnPhF6jc=
=76EB
-END PGP SIGNATURE-

Re: Level 3 issues

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

IMHO, this is exactly what service providers love to hear in order for
them not to be forth coming.


regards,
/virendra


Matthew Petach wrote:
> On 12/28/08, Blake Pfankuch  wrote:
>> Any word on the actual cause of the issue?
> 
> Given the lurking presence of wannabe press vultures here, I
> doubt you'll see anything forthcoming from the technical folks
> about what actually happened.  This is not to say that people
> haven't been informed of the issue, it's simply that NANOG is
> no longer a friendly hapy techie-only place where such information
> can be shared without it being seized on and quoted without
> permission by the press.
> 
> Bitter?  Just a bit, yes.  After having what I mentioned here get
> quoted by the press without permission, it's very clear that there
> will be no more technical commentary/feedback/information flow
> through this channel from me or any of the other people at the
> company for which I work, more's the pity.  If you can find a
> forum where engineers can share information freely without
> having to worry about being quoted by the press, you might
> try enquiring there.  ^_^;
> 
> Matt
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJV+UUpbZvCIJx1bcRAoxfAKCFn9inJ1Pq2Z0W9uuu1YeMGjf0LACeJVca
GkejywYfBp2yUjTFJwrOLFU=
=d1BQ
-END PGP SIGNATURE-

Re: Cap'n Bubba the marine backhoe driver - SEA-ME-WE 3 and 4, FLAG cut

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Martin Hannigan wrote:
> On Fri, Dec 19, 2008 at 12:17 PM, Suresh Ramasubramanian
>  wrote:
>> On Dave Farber's IP list.
>>
>>> From: France Telecom / Press 
>>> To: France Telecom / Press 
>>> Subject: Three undersea cables cut: traffic greatly disturbed between
>>> Europe and Asia/Near East zone
>>> Date: Fri, 19 Dec 2008 17:09:03 +0100 (CET)
>>> X-Concentric-MX-Info: s=0AKNHR84D300:1 ts=0 td=53 dt=0 tro=1 tra=2
>>> trb=1 sro=1 sra=2 ic=0
>>> X-Concentric-DKIM: SigStatus="No signature", PolSusp="No",
>>> PolTest="No", Policy="none", Handling="none"
>>> X-Virus-Status: No
>>>
>>> If you can't read this email, please go to : 
>>> http://www.orange.com/en_EN/press/press_releases/cp081219en.html
>>> Paris, December 19, 2008
>>> Three undersea cables cut: traffic greatly disturbed between Europe and
>>> Asia/Near East zone
>>>
>>> 3 cables cut this morning (Sea Me We3 partly + Sea Me We4 + FLAG)
>>> France Telecom Marine cable ship about to depart
>>>
>>> France Telecom observed today that 3 major underwater cables were cut:
>>> ?Sea Me We 4? at 7:28am, ?Sea Me We3? at 7:33am and FLAG at 8:06am.
>>> The causes of the cut, which is located in the Mediterranean between
>>> Sicily and Tunisia, on sections linking Sicily to Egypt, remain
>>> unclear.
>>>
>>> Most of the B to B traffic between Europe and Asia is rerouted through
>>> the USA.
>>> Traffic from Europe to Algeria and Tunisia is not affected, but traffic
>>> from Europe to the Near East and Asia is interrupted to a greater or
>>> lesser extent (see country list below).
>>> Part of the internet traffic towards R?union is affected as well as 50%
>>> towards Jordan.
>>> A first appraisal at 7:44 am UTC gave an estimate of the following
>>> impact on the voice traffic (in percentage of out of service capacity):
>>> -Saudi Arabia: 55% out of service
>>> -Djibouti: 71% out of service
>>> -Egypt: 52% out of service
>>> -United Arab Emirates: 68% out of service
>>> -India: 82% out of service
>>> -Lebanon: 16% out of service
>>> -Malaysia: 42% out of service
>>> -Maldives: 100% out of service
>>> -Pakistan: 51% out of service
>>> -Qatar: 73% out of service
>>> -Syria: 36% out of service
>>> -Taiwan: 39% out of service
>>> -Yemen: 38% out of service
>>> -Zambia: 62% out of service
>>>
> 
> 
> And it looks like they are going back to square one on SMW4.
> 
> AMMAN - Internet users in the Kingdom and elsewhere in the region are
> expected to continue experiencing slower services as repair teams
> continue their attempts to fix cut cables in the Mediterranean.
> 
> Raslan Diranieh, chief financial officer of the Jordan Telecom Group
> (JTG), said that a few hours after SMW-4 Internet cable which links
> the Kingdom to the International Internet Network was fixed, it
> experienced another cut on Saturday.
- 
I wonder how many km apart smw4 & smw3 are of eachother as my
understanding is they follow same path.

My understanding is repairing is extremely tedious process by which
robot has to scour the seabed and dig out the broken cable and solder
individual fiber and check for connectivity not that this is an excuse
for another cut.


regards,
/virendra


> 
> 
> http://www.jordantimes.com/?news=13079
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJVupFpbZvCIJx1bcRApz7AJ9r5ZzXOUZ7fa30R+hDqrMfzS9hPQCeMYwN
DZglqvleGT3gkaDc1v6DDsw=
=L8xJ
-END PGP SIGNATURE-

Outages BOF - NANOG 44 (los angeles).

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Just wondering if there's any interest in meeting up during nanog 44
(los angeles) and sharing your thoughts, challenges or your outages
experience in general or would like to simply vent and empty your head.


Topics of interest:

* Service provider(s) participation in outages notification?

* What monitoring  tools do you use to monitor your environment? How do
they work for your environment? Does it scale for your environment? What
would you like to see out of such a tool (open-source or commercial).

Collaboration/participation is one of the key things that I'm aiming to
achieve w/o the need for an overarching organizational body and have a
broad base of representation. So come and speak your mind.


Please respond to me directly and not the list so I can arrange for a
meeting room.


grateful thanks,


regards,
/virendra
moderator, outages.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI5SB9pbZvCIJx1bcRApU5AJ916/9T3+k0swPIyFMQfEJBWLNAmQCgoyDo
KD7qhBFmjfcrmSJTXhDmJtk=
=641j
-END PGP SIGNATURE-

puck outage this am.

[virendra rode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

You may or may not have noticed puck.nether.net (hosting outages.org
mailing list)  suffered an outage this am. This was caused due to a file
system issue (possible inconsistence state) on a fairly large (1tb)
filesystem
which caused services on puck to be unresponsive.

Many thanks to Jared Mauch in addressing this issue.

Like always, appreciate your feedback and your constructive criticism.


regards,
/virendra

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI2wsgpbZvCIJx1bcRArpUAJsECd19nRQs06wkgvnfS3Xhk2TvOQCghhTC
OyRIHk8YHPR72l+WRmh15qU=
=fy4U
-END PGP SIGNATURE-

nanog@nanog.org

[virendra rode //]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert E. Seastrom wrote:
> Is anyone else seeing issues with multiple copies and delayed
> originals for SMSes on the AT&T network?  I've been seeing this
> behavior for about the past 24-36 hours.
- ---
Some reported sbc outage on outages mailing list. Not sure if this has
anything to do with the latency what you and others have and are
experiencing.


regards,
/virendra

> 
> This is phone-to-phone, not email-gateway stuff.  Includes both new
> iPhones and people on T-Mobile as well as $random_att_handset.  Given
> that our (royal we here) network monitoring is gatewayed directly via
> a phone...  this is of some annoyance, to get interface transition and
> other alarms hours after the fact.
> 
> I'm an old AT&T Blue customer if that makes a difference.
> 
> Anyone?  Bueller?
> 
> -r
> 
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIpFF4pbZvCIJx1bcRAl5sAJ92F4C4Dqy5XV5wzduAF/9thI9dUwCg6D6f
qj0L7dcl11KOj/reuzCHXEE=
=e78H
-END PGP SIGNATURE-

Re: Network meltdowns anywhere in US?

[virendra rode //]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tuc at T-B-O-H wrote:
>> On Wed, May 28, 2008 at 4:05 PM, Tuc at T-B-O-H.NET <[EMAIL PROTECTED]> 
>> wrote:
>>
>>> Hi,
>>>
>>>Sorry, would have posted this elsewhere, but I can't get
>>> to alot of places...
>>>
>>>I originally started chasing not being able to get to
>>> 71.74.56.243 (RR Mail server). I then found out neither L3 nor
>>> my other connection saw it in the table. I checked a few other
>>> router servers, some had it, some didn't.
>>>
>>>Now, though, I'm trying to get a few other places and
>>> most of them oddly seem to hang off L3 (Like the outages
>>> list. :) )
>>>
>>>Any ideas of there is some meltdown happening
>>> in L3 or elsewhere?
>>>
>>>Thanks, Tuc
>>>
>>> 
>> >From a cursory glance seems to be ok from where I'm currently looking from
>> (at&t), then again I haven't done my technical diligence. Will need to look
>> further and I'm sure someone will pipe up.
>>
>> Do you have any traceroutes, route stats, etc to give us as to what you are
>> experiencing?
>>
> 
>   A bit more "clue"... :)
> 
>   1) If its been discussed before, I was out that day... But it seems
> that CERF NET route-server isn't quite authoritative:
> 
> route-server>sho ip bgp 204.107.90.128
> % Network not in table
> 
> route-server>sho ip bgp
> 
> route-server>
- -
you could also try,

route-views.oregon-ix.net>sho ip bgp 204.107.90.128
BGP routing table entry for 204.107.90.0/24, version 201333
Paths: (35 available, best #32, table Default-IP-Routing-Table)
  Not advertised to any peer
  3303 3356 1784 35954
164.128.32.11 from 164.128.32.11 (164.128.32.11)
  Origin IGP, localpref 100, valid, external
  Community: 3303:5004
  3277 3267 9002 1784 35954
194.85.4.55 from 194.85.4.55 (194.85.4.16)
  Origin IGP, localpref 100, valid, external
  Community: 3277:3267 3277:65100 3277:65320 3277:65326
  812 6461 3356 7911 35954
64.71.255.61 from 64.71.255.61 (64.71.255.61)
  Origin IGP, localpref 100, valid, external
  293 3356 7911 35954
134.55.200.1 from 134.55.200.1 (134.55.200.1)
  Origin IGP, localpref 100, valid, external
  Community: 293:14 293:41
  2905 701 3356 1784 35954
196.7.106.245 from 196.7.106.245 (196.7.106.245)
  Origin IGP, metric 0, localpref 100, valid, external
  4513 13789 22212 1784 35954
209.10.12.125 from 209.10.12.125 (209.10.12.125)
  Origin IGP, metric 4103, localpref 100, valid, external
  4513 12182 3356 7911 35954
209.10.12.156 from 209.10.12.156 (209.10.12.156)
  Origin IGP, metric 7002, localpref 100, valid, external
  2497 1784 35954
202.232.0.2 from 202.232.0.2 (202.232.0.2)
  Origin IGP, localpref 100, valid, external
  5511 3356 1784 35954
193.251.245.6 from 193.251.245.6 (193.251.245.6)
  Origin IGP, localpref 100, valid, external
  3257 3356 7911 35954
89.149.178.10 from 89.149.178.10 (213.200.87.40)
  Origin IGP, metric 10, localpref 100, valid, external
  Community: 3257:3150 3257:3152 3257:5010
  6079 1784 35954
207.172.6.162 from 207.172.6.162 (207.172.6.162)
  Origin IGP, metric 6, localpref 100, valid, external
  6539 1784 35954
66.59.190.221 from 66.59.190.221 (66.59.190.221)
  Origin IGP, localpref 100, valid, external
  6453 3356 1784 35954
195.219.96.239 from 195.219.96.239 (195.219.96.239)
  Origin IGP, localpref 100, valid, external
  1221 4637 3356 7911 35954
203.62.252.186 from 203.62.252.186 (203.62.252.186)
  Origin IGP, localpref 100, valid, external
  7500 2516 1784 35954
202.249.2.86 from 202.249.2.86 (203.178.133.115)
  Origin IGP, localpref 100, valid, external
  7660 2516 1784 35954
203.181.248.168 from 203.181.248.168 (203.181.248.168)
  Origin IGP, localpref 100, valid, external
  Community: 2516:1030
  2914 3356 7911 35954
129.250.0.171 from 129.250.0.171 (129.250.0.12)
  Origin IGP, metric 1, localpref 100, valid, external
  Community: 2914:420 2914:2000 2914:3000 65504:3356
  6079 1784 35954
207.172.6.20 from 207.172.6.20 (207.172.6.20)
  Origin IGP, metric 0, localpref 100, valid, external
  701 3356 7911 35954
157.130.10.233 from 157.130.10.233 (137.39.3.60)
  Origin IGP, localpref 100, valid, external
  1668 3356 7911 35954
66.185.128.48 from 66.185.128.48 (66.185.128.48)
  Origin IGP, metric 504, localpref 100, valid, external
  3549 3356 7911 35954
208.51.134.254 from 208.51.134.254 (67.17.81.162)
  Origin IGP, metric 53, localpref 100, valid, external
  Community: 3549:2142 3549:30840
  852 1239 3356 7911 35954
154.11.11.113 from 154.11.11.113 (154.11.11.113)
  Origin IGP, metric 0, localpref 100, valid, external
  Community: 852:180
   3356 1784 35954
193.0.0.56 from 193.0.0.56 (193.0.0.56)
  Origin IGP, localpref 100, valid, external
  3356 7911 35954
4.68.1.1

Re: Network meltdowns anywhere in US?

[virendra rode]

On Wed, May 28, 2008 at 4:05 PM, Tuc at T-B-O-H.NET <[EMAIL PROTECTED]> wrote:

> Hi,
>
>Sorry, would have posted this elsewhere, but I can't get
> to alot of places...
>
>I originally started chasing not being able to get to
> 71.74.56.243 (RR Mail server). I then found out neither L3 nor
> my other connection saw it in the table. I checked a few other
> router servers, some had it, some didn't.
>
>Now, though, I'm trying to get a few other places and
> most of them oddly seem to hang off L3 (Like the outages
> list. :) )
>
>Any ideas of there is some meltdown happening
> in L3 or elsewhere?
>
>Thanks, Tuc
>
> 
>From a cursory glance seems to be ok from where I'm currently looking from
(at&t), then again I haven't done my technical diligence. Will need to look
further and I'm sure someone will pipe up.

Do you have any traceroutes, route stats, etc to give us as to what you are
experiencing?



regards,
/virendra

Re: Hurricane season starts June 1: Carriers harden networks

[virendra rode //]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jared Mauch wrote:
> 
> On May 27, 2008, at 6:47 PM, Jerry Dixon wrote:
> 
>> Jared nailed it on the head.  It is absolutely critical to get to know
>> who
>> your State JFO POC is, State EOC POC, and have the National Communication
>> Systems Hotline on speed dial or at least in your cell.  They can help
>> facilitate needs such as getting human resources from your company or
>> mutual
>> aide in to help with a crisis (credentialing issues), fuel trucks, and
>> other
>> supplies as needed.
>>
>> Also you might want to check to see if your company has a govt. affairs
>> person within your organization who might all ready have a lot of this
>> info
>> and the contacts to assist.
> 
> I think there's something else to make note of.
> 
> NCS wants to make sure that a number of the ISPs and critical
> infrastructure operators have WPS/GETS available to the people who
> rightly need them.  If you're not sure, give them a ring and chat with
> them about what resources you should have at your disposal.  If there is
> a major communication disruption, this may help your operations team
> communicate.
- 
What you briefly outlined here applies to outages effecting certain size
of customers. If so I wonder what's that magic number is? How do you
measure the impact of an outage that would require companies to issue
outages?

It would be nice for these companies to report network outages to a
central public forum (w/o bureaucracy) so end users irrespective of the
size can lookup such reports and know why their services (e-mail,
phones, etc) went down eliminating the need to open tons of trouble
tickets during a major event. This way everyone could benefit from it.

Due to such lack of information sharing outages mailing was started
for the purpose of on having outages available to the public when and where
it is most needed irrespective how big or small the company is.

Then there are others who believe that there are companies who are
protected from public disclosure like to use this protection to their
advantage as they no longer have to air their dirty laundry.

IMO, network outages needs to get to the public rather than keeping it a
secret.

Before software bugs were routinely published, network/software
companies denied their existence and wouldn't bother fixing them,
believing in the security of secrecy. If we return to a practice of
keeping these bugs secret, we'll have vulnerabilities known to a few in
the security community. Public reporting forces companies to improve
their service.


regards,
/virendra

> 
> You can fill out the forms online at gets.ncs.gov
> 
> - Jared
> 
> 
> 


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIPXQVpbZvCIJx1bcRAjHrAJkB9lNtGYdib5Kezhmz2EBtpoXMowCeKgqR
tR1+3To4MsBnTNMEgGJ/6Kw=
=GrRH
-END PGP SIGNATURE-

outages mailing list is back online!

[virendra rode //]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[ Apologies to those of you who receive this note in multiple forums. ]

Hello all,

I wanted to drop a quick note to everyone and explain how/why things
took so long and I deeply apologize for the service interruption.

Apparently the machine hosting outages mailing list went belly
up during the package upgrade (postfix/mailman/apache) in order to bring
the system up to date. This was suppose to be a planned upgrade which
unfortunately turned out to be sysadmin's nightmare. During the headless
chicken syndrome it led into further issues and from there on murphy
took over that led to a prolonged outage.

We are working towards a cluster setup (active-active cluster) where we
will be able to pull the host out of operation without affecting the
service in the future. Something we are also looking into is a separate
instance in availability zones (multi-site) in order to protect
applications/ host availability from failure of a single location.

We deeply regret the delay this caused the mailing list to be off the air.

Many thanks to Gadi Evron / Randy Vanghn / James Eastman / Larry Vaden /
Joe St Sauver and other members of the team who work effortlessly to
resurrect this list. Without there help and direction outages list
wouldn't exist today. I'm indebted to them.


Suggestions, comments are welcome.


If interested, you can subscribe to the list at,
http://isotf.org/mailman/listinfo/outages



respectfully,
/virendra































-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFINzKXpbZvCIJx1bcRAv0lAJ46sBa9/uZ/lbl54ehE7tgNZiySZgCghKsq
AjuiEP7kwKGXSsJqDBBe08w=
=1OV7
-END PGP SIGNATURE-

Re: [NANOG] Fiber Cut at 60 Hudson

[virendra rode //]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Robert Blayzor wrote:
> Does anyone know of any NY fiber cuts going on near/around 60 Hudson  
> Street?  I have a Level3 DIA Gig-E that's been out for almost 36 hours  
> and each time I call them I get a different answer on what the problem  
> is and exactly how much longer this is going to take to be resolved.   
> We noticed this go down around 7pm EDT on Sunday and the following  
> morning the dark fiber we have going through 60 Hudson took a hit for  
> about an hour on one side of our DWDM ring...
> 
> Anyone know whats up?
> 
- ---
Possible bad module / fiber. Techs are in route back to Albany site. ETA
1 hr.

On a different note, outages mailing list ([EMAIL PROTECTED]) should be
up / running by this week at the latest. We are finishing up on the last
 pieces (hw/software).


regards,
/virendra
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIMuvypbZvCIJx1bcRAoiSAJwK7wptXgTAxtokgKosCPC3L6fHTwCgjt6u
HKREsGqHELOS0XAmzOMjjuA=
=6kAb
-END PGP SIGNATURE-

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

[NANOG] [Fwd: Re: [EMAIL PROTECTED]

[virendra rode //]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

We are on the final stages of getting the host operational that has
taken longer than we expected. This was a combination of application /
hardware related issue that caused a prolonged outage.

We deeply regret the delay and we should have outages mailing
operational soon. The goal is to pull the host out of operation without
affecting the service in the future.

Thanks all for your patience during this prolonged delay.


regards,
/virendra



-  Original Message 
Subject: Re: [NANOG] [EMAIL PROTECTED]
Date: Sun, 4 May 2008 00:50:11 -0500 (CDT)
From: Gadi Evron <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: nanog@nanog.org
References: <[EMAIL PROTECTED]>

That list oaught to be working again in a matter of days.


On Sat, 3 May 2008, Justin Sharp wrote:

> Hello,
>
> Forgive me if this has been covered previously.
>
> I have recently discovered this list and have found it a gold mine of
> information. I've now traded 3 hours of my life reading through archives
> and have even found reference to specific recent outages that my company
> suffered to which we never really did get a RFO from the ISP.
>
> In the archives, I have read of another list which I am interested in at
> [EMAIL PROTECTED] I've tried visiting the site, and subscribing at
> http://www.isotf.org/mailman/listinfo/outages (as mentioned in several
> archived messages) but it doesn't seem to exist there anymore. Also
> tried to search this list for information as to whether it had moved or
> been discontinued, etc (google site searches, etc). Has this list been
> discontinued? If not, is it still open to the public, and what is its
> new location, that I might subscribe?
>
> Regards,
>
> --Justin
>
> ___
> NANOG mailing list
> NANOG@nanog.org
> http://mailman.nanog.org/mailman/listinfo/nanog
>

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIHgTgpbZvCIJx1bcRAmzBAJoCtjUyQ4sFAwRlKv9q+HF5wtmGbACfXXCl
JP9n+9Hb5gb9G43MQrjzkC0=
=9kiY
-END PGP SIGNATURE-

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

[NANOG] [Fwd: isotf outtages]

[virendra rode //]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

FYI -/



-  Original Message 
Subject: isotf outtages
Date: Thu, 24 Apr 2008 13:41:42 -0500
From: RVaughn <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: virendra rode // <[EMAIL PROTECTED]>,  Gadi Evron
<[EMAIL PROTECTED]>

Hi Matthew,

As you noted in your NANOG post, the outtages list has
been unavailable.  We are in the process of moving the
list to a new server home and anticipate having the list
back on line soon.  the critical question being how soon.
Initially, I expected to have the list on line this week.
There were a few glitches on some of the new installation so
my estimate is now for the beginning of the next week -
barring unforeseen operator induced errors which we have
had more than our fair share of the past couple of weeks.

Best,
R

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIENhWpbZvCIJx1bcRAqq5AJ9zQ6jJWS7aI4s5h8tm/BFWwIHUlgCgoSkV
9rp6S2Kivh+r6+g+6bL8TLI=
=oOqL
-END PGP SIGNATURE-

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: 6bone space used still in the free (www.ietf.org over IPv6 broken) (Was: why same names, was Re: NANOG 40 agenda posted)

[virendra rode //]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

James Jun wrote:
>>> I think what's going on is that packets from www.ietf.org don't make it
>>> back to my ISP. A ping6 or traceroute6 doesn't show any ICMP errors and
>>> TCP sessions don't connect so it's not a PMTUD problem. So it's an
>>> actual timeout.
>> I also just started noticing this, that is, that it does not work. And
>> there is a very simple explanation for this: 6bone space.
> 
> We (OCCAID) had recently turned up peering with a few networks (including HE
> and others) and as a result our outbound path to HEAnet and other networks
> had changed.
> 
> Some of the abrupt route changes are being corrected today evening and
> hopefully should resolve pMTU problems in reaching www.ietf.org.  If you
> continue to experience trouble in reaching thru OCCAID via IPv6, please
> don't hesitate to drop me a line in private.
> 
> Regards,
> James
- ---
that was quick, although I tunneling via freenet6.

[EMAIL PROTECTED]:/etc/ppp/peers$ traceroute6 www.ietf.org
traceroute to www.ietf.org (2610:a0:c779:b::d1ad:35b4) from
2001:5c0:8fff:::a5, 30 hops max, 16 byte packets
 1  2001:5c0:8fff:::a4 (2001:5c0:8fff:::a4)  91.114 ms  90.643
ms  92.29 ms
 2  freenet6.hexago.com (2001:5c0:0:5::114)  95.166 ms  102.207 ms
95.866 ms
 3  if-5-0-1.6bb1.mtt-montreal.ipv6.teleglobe.net (2001:5a0:300::5)
89.454 ms  120.386 ms  92.113 ms
 4  if-1-0.mcore3.mtt-montreal.ipv6.teleglobe.net (2001:5a0:300:100::1)
 90.882 ms  92.495 ms  91.239 ms
 5  if-13-0.mcore4.nqt-newyork.ipv6.teleglobe.net (2001:5a0:300:100::2)
 96.672 ms  97.731 ms  97.782 ms
 6  2001:5a0:400:200::1 (2001:5a0:400:200::1)  107.734 ms  96.951 ms
97.486 ms
 7  2001:5a0:600:200::1 (2001:5a0:600:200::1)  107.223 ms  105.586 ms
103.39 ms
 8  2001:5a0:600:200::5 (2001:5a0:600:200::5)  104.942 ms  106.728 ms
102.465 ms
 9  2001:5a0:600::5 (2001:5a0:600::5)  107.945 ms  104.898 ms  103.782 ms
10  equinix6-was.ip.tiscali.net (2001:504:0:2::3257:1)  107.448 ms
109.082 ms  107.891 ms
11  equi6ix-ash.ipv6.us.occaid.net (2001:504:0:2:0:3:71:1)  223.532 ms
217.531 ms  218.709 ms
12  unassigned.in6.twdx.net (2001:4830:e6:d::2)  219.648 ms  221.496 ms
 223.614 ms
13  stsc350a-eth3c0.va.neustar.com (2610:a0:c779::fe)  228.079 ms
227.053 ms  226.536 ms
14  www.ietf.ORG (2610:a0:c779:b::d1ad:35b4)  226.191 ms  227.959 ms
219.163 ms


regards,
/virendra

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGXdovpbZvCIJx1bcRAu0lAJ4ldNWYXCvBf4Vtvkdih8WknZc5XwCfdKKy
UsquQuxR+AytwKrfuOF0MlM=
=oJoI
-END PGP SIGNATURE-