Re: ipv6 day DDoS threat?
I can confirm, it was indeed Verisign who emailed me with the same message. I am slightly disappointed by this course of action, needless to say I am not surprised, because this kind of behavior is expected from sales people. I had a bit more respect for them, however... -ck On Tue, Jun 7, 2011 at 12:04 PM, Nathan Eisenberg nat...@atlasnetworks.uswrote: We got the same call. I think they just trolled on through the IPv6Day participants list. They indicated that we were likely to be 'specifically targeted' as a result of 'putting ourselves out there'. I suspect it's merely a misprogrammed sales drone spewing fear-infused garbage. The caller claimed to represent Verisign (though we took no steps to verify that claim). If anyone from Verisign is on the list, you may want to look into this, especially if this is actually coming from one of your employees. Nathan -Original Message- From: Mark Pace [mailto:p...@jolokianetworks.com] Sent: Tuesday, June 07, 2011 11:43 AM To: nanog@nanog.org Subject: ipv6 day DDoS threat? I got an interesting contact from a large company that I will leave un-named for the moment. They said that they heard specific chatter about DDoS of IPv6 day participant sites and even more specifically about our website. Of course they have also offered to assist us in preventing this from affecting our site. I'm very skeptical about even calling said company at this point. I'm really feeling like this is a shakedown and was wondering if anyone else had been approached in a similar fashion? Mark Pace
Re: box.net network engineer
On Thu, Feb 10, 2011 at 12:01 PM, Andrew Matthews exstat...@gmail.comwrote:
Can someone with the box.net engineering group email me off list.
I have a peering issue with you guys at any2 in socal.
One would think, if you are interconnecting with another network you should
have some contact info for them. Or know where to find
the information necessary for situations like this.
https://www.peeringdb.com/private/participant_view.php?id=1904
$ whois -h whois.radb.net as33011
aut-num:AS33011
as-name:BOXNET
descr: Box.net, Inc.
import: from AS-ANY accept ANY
export: to AS-ANY announce AS33011 AND NOT {0.0.0.0/0}
admin-c:JQU26-ARIN
tech-c: GCG-ARIN
notify: n...@box.net
mnt-by: MNT-BOXNE-1
changed:gg...@box.net 20080513
source: ARIN
Thanks,
Drew
Re: Facebook issue
stop On Thu, Dec 16, 2010 at 1:34 PM, andrew.wallace andrew.wall...@rocketmail.com wrote: Anyone having issue with Facebook? Andrew
Re: ALT-DB Question
http://markmail.org/message/7vm3wk6kcnkqvonj On Wed, Dec 8, 2010 at 7:38 PM, Charles Gucker cguc...@onesc.net wrote: On Wed, Dec 8, 2010 at 1:25 PM, Chadwick Sorrell mirot...@gmail.com wrote: Hello, I'm sending a new MAINT-AS object to the db-ad...@altdb.net, but it doesn't appear to be in the database after a few weeks. Are there any requirements that I may be missing on my new request, or some sort of way I can help get it processed? I submitted one over a year ago. Still not sure who's running it these days. charles
Re: Trying to Make Sense of the Comcast/Level 3 Dispute
my guess is the info for that was pulled off comcast's route server, where only tata is seen BGP routing table entry for 98.137.128.0/19, version 681406320 Paths: (8 available, best #8, table Default-IP-Routing-Table) Not advertised to any peer 6453 10310 36752 36752, (received used) 68.86.1.43 (metric 72251) from 68.86.80.5 (68.86.1.5) Origin IGP, metric 0, localpref 250, valid, internal Community: 7922:43 7922:3050 7922:3120 Originator: 68.86.1.43, Cluster list: 68.86.1.5 6453 10310 36752 36752, (received used) 68.86.1.40 (metric 78885) from 68.86.80.15 (68.86.1.15) Origin IGP, metric 0, localpref 250, valid, internal Community: 7922:40 7922:3050 7922:3120 Originator: 68.86.1.40, Cluster list: 68.86.1.15 6453 10310 36752 36752, (received used) 68.86.1.41 (metric 85042) from 68.86.80.7 (68.86.1.7) Origin IGP, metric 0, localpref 250, valid, internal Community: 7922:41 7922:3050 7922:3120 Originator: 68.86.1.41, Cluster list: 68.86.1.7, 68.86.1.13 6453 10310 36752 36752, (received used) 68.86.1.44 (metric 101555) from 68.86.80.10 (68.86.1.10) Origin IGP, metric 0, localpref 250, valid, internal Community: 7922:44 7922:3050 7922:3120 Originator: 68.86.1.44, Cluster list: 68.86.1.10 6453 10310 36752 36752, (received used) 68.86.1.42 (metric 70822) from 68.86.80.0 (68.86.1.0) Origin IGP, metric 0, localpref 250, valid, internal Community: 7922:42 7922:3050 7922:3120 Originator: 68.86.1.42, Cluster list: 68.86.1.0 6453 10310 36752 36752, (received used) 68.86.1.41 (metric 85042) from 68.86.80.13 (68.86.1.13) Origin IGP, metric 0, localpref 250, valid, internal Community: 7922:41 7922:3050 7922:3120 Originator: 68.86.1.41, Cluster list: 68.86.1.13 6453 10310 36752 36752, (received used) 68.86.80.11 (metric 92374) from 68.86.80.11 (68.86.1.11) Origin IGP, metric 0, localpref 250, valid, internal Community: 7922:11 7922:3050 7922:3120 6453 10310 36752 36752, (received used) 68.86.1.46 (metric 65585) from 68.86.80.2 (68.86.1.2) Origin IGP, metric 0, localpref 250, valid, internal, best Community: 7922:46 7922:3050 7922:3120 Originator: 68.86.1.46, Cluster list: 68.86.1.2 On Fri, Dec 3, 2010 at 9:30 AM, Matthew Petach mpet...@netflight.comwrote: On Fri, Dec 3, 2010 at 6:49 AM, Leo Bicknell bickn...@ufp.org wrote: In a message written on Wed, Dec 01, 2010 at 09:40:01PM -0800, Paul Ferguson wrote: Interesting article: http://www.freedom-to-tinker.com/blog/sjs/trying-make-sense-comcast-level-3 - -dispute Here's an excellent summary, complete with some pictures: http://www.voxel.net/blog/2010/12/peering-disputes-comcast-level-3-and-you -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Unfortunately, they got at least part of the diagram wrong; Yahoo uses Global Crossing to reach Comcast, not TATA. Matt
Re: Weird Nexus AD
in x/y, x= preference, y= metric am= adjacency module, *= best unicast route a better place to have asked this would be c-nsp hth -ck On Fri, Oct 29, 2010 at 7:21 PM, Colby Glass colbycciest...@gmail.comwrote: We're seeing an AD of 2 on some routes on our Nexus 7k. I can't find anything (Google) to indicate where this value is coming from. Also unable to find out what am mean (adjacency module?). Does anyone have an explanation for this one? * via 192.168.21.49, Vlan13, [2/0], 00:44:52, am* Thanks -- Colby Glass Network Engineer http://blog.alwaysthenetwork.com
Re: Facebook down!! Alert!
+1 On Wed, Oct 6, 2010 at 12:57 AM, Zaid Ali z...@zaidali.com wrote: I think the Outages mailing list is more appropriate for this. On 10/5/10 9:46 PM, Mike Lyon mike.l...@gmail.com wrote: Same here in SF Bay Area On Tue, Oct 5, 2010 at 9:44 PM, James Smith ja...@smithwaysecurity.com wrote: At 1:20am here in Canada, NB our networks are showing that facebook is down. Please confirm in the USA. ~SmithwaySecurity Sent from my iPhone
Re: More ASN collissions
i believe john curran just posted the follow up to the list yesterday on this matter On Thu, Dec 10, 2009 at 10:51 AM, Dobbins, Roland rdobb...@arbor.netwrote: On Dec 11, 2009, at 1:35 AM, Jared Mauch wrote: As always, good research by renesys. What happens when an ASN is requested, and it's discovered that said ASN is already in use by an unauthorized network, and that some proportion of the Internet are accepting it due to a lack of appropriate routing policy? Is there a process to try and reclaim said ASN via persuasion, or some jurisdictionally-appropriate legal action, or peer pressure (pardon the pun), or . . . ? This is a different circumstance than either accidental or deliberate use of an already-assigned and -utilized ASN; has this situation occurred in the past, and if so, how was it resolved? If the situation isn't resolved in a timely manner, is the ASN in question considered 'poisoned' until a resolution is attained, and the next available ASN which isn't being utilized in a rogue fashion issued in its place? Apologies if this is a naive question; I've not run into this particular circumstance before, nor have I found any reference to it in any of the various list archives. I do believe that it may become a bit more common, given some of the confusion and drama regarding the operationalization of 4-byte ASNs. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: ALTDB Problems
On Tue, Oct 27, 2009 at 11:21 AM, Steve Rubin s...@tch.org wrote: ALTDB is free and you get what you pay for. However. Donations to http://www.nanog.org/scholarships/abha.php would probably get requests done a lot faster. -- Steve Rubin/ AE6CH / http://www.altdb.net/ Email: s...@tch.org / N6441C / http://www.tch.org/~ser/ so, each time someone wants to update they need to donate to make sure it gets processed in a timely matter? or do you track who donates and give priority to their updates? dont get me wrong - its a great cause, and people should donate if they can if the project is short of volunteers - i'm sure there are people in the community who would not mind helping out -ck
Re: Fiber cut in SF area
Monterey Highway I think On Thu, Apr 9, 2009 at 11:11 AM, Mike Lyon mike.l...@gmail.com wrote: Anyone know where the actual cut is? On 4/9/09, David W. Hankins david_hank...@isc.org wrote: On Thu, Apr 09, 2009 at 08:14:15AM -0700, Craig Holland wrote: Just dropping a note that there is a fiber cut in the SF area (I have a metro line down). AboveNet is reporting issues and I've heard unconfirmed reports that ATT and VZW are affected as well. Confirmed VZW ATT; http://cbs5.com/local/phone.internet.outage.2.980578.html Rather widespread general telco outage, the county has deployed extra patrol units in the south bay to compensate for not being able to call 911. Third video link in shows repairs underway. -- David W. Hankins If you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins -- Sent from my mobile device
Re: attacks on MPLS?
oh and heres the vid so you can see the demos http://www.shmoocon.org/2009/videos/AllYourPackets-Rey.m4v On Thu, Apr 9, 2009 at 11:28 AM, Christian Koch christ...@automatick.netwrote: They presented on the same topic at shmoocon, not sure if the info is any more updated for BH EUROPE, but here is the pres they did in Feb09 http://www.shmoocon.org/slides/rey_mende_all_your_packets_v05.pdf On Thu, Apr 9, 2009 at 10:15 AM, Hector Herrera hectorherr...@gmail.comwrote: On Thu, Apr 9, 2009 at 9:56 AM, Steven M. Bellovin s...@cs.columbia.edu wrote: http://www.darkreading.com/securityservices/services/data/showArticle.jhtml?articleID=216403220 --Steve Bellovin, http://www.cs.columbia.edu/~smbhttp://www.cs.columbia.edu/%7Esmb I'll wait to read their full presentation, but according to the article it appears to me that if they have gained access to a Network Management station or a Router, that the entire network has been compromised, not just MPLS. -- Hector Herrera President Pier Programming Services Ltd.
Re: Fiber cut in SF area
nice article on bitgravity blog regarding the cuts.. http://sandbox.bitgravity.com/blog/2009/04/09/destroy-the-internet-with-a-hacksaw/ On Thu, Apr 9, 2009 at 11:22 AM, Charles Wyble char...@thewybles.comwrote: Ravi Pina wrote: News coverage: http://cow.org/r/?5459 http://cow.org/r/?545a And not that I expect any useful updates: http://twitter.com/attnews Lots of folks covering the same thing... http://search.twitter.com/search?q=fiber+cut http://search.twitter.com/search?q=outage Also reports of power outages as well: http://search.twitter.com/search?q=power+outage Here is something interesting... http://twist.flaptor.com/trends?gram=outagetable=1tz=-7 http://twist.flaptor.com/trends?gram=fiber%20cuttable=1tz=-7
Re: AS path weirdness
a private asn in (parentheses) indicates a bgp confederation, i would tend to think that there is some sort of mis-config or software bug in one of the routers in that path thats leaking it On Sun, Mar 22, 2009 at 7:51 AM, Jason Lewis jle...@packetnexus.com wrote: I was under the impression that MRT only used brackets for sets. eg. [ASNUM] Thanks for taking a look. jas James Aldridge wrote: Jason Lewis wrote: I'm not entirely sure what I'm looking at. The reserved AS, 65490 appears in parentheses and I've never seen that in MRT formatted data and not sure why it's happening. That would be a single-element AS_SET, I guess.
Re: SNMP and syslog forwarders
you can easily configure syslog-ng for forwarding/relaying syslog msgs to another box On Wed, Mar 4, 2009 at 1:51 AM, Sam Stickland sam_mailingli...@spacething.org wrote: Hi, It's looking like running all of our traps and syslog through a couple of relay devices (and then onwards to the various NMS's) would be quite a win for us. These relay devices just need to be dumb forwarders (we don't require any filtering or storing, just reflection), but we need an HA pair (across two sites) without creating duplicates. I have the coding skills to make this myself, but as coding skills come and go in our network team, we are looking for a commerical product so it will continnue to work after I get: hit by a bus / amnesia / visions of grandeur. Any recommendations / experience? This needs to scale to ~1,500 devices. Thanks, Sam
Re: Anyone notice strange announcements for 174.128.31.0/24
snip ] part of the experiment is to measure the difference between the amount ] of nanog mail lorenzo drew in 2005 by pre-announcing with the amount we ] get in 2009 while not pre-announcing. :) This statement is an admission that he set out to annoy people, annoy them enough they would complain on a public mailing list. More over, I can't see how any researcher could use the amount of nanog mail as a valid indicator of anything. It has as much to do with how many engineers are bored on a given day as it does with the severity of the problem. So the goal of this research seemed to be to see how many people the researchers could panic, and then see how 10,000 people reacted to the panic. Sounds a lot like yelling fire in a crowded movie house just to research what the results might be, and then measuring success by the number of words in the article on the front page of the paper, or perhaps the number of people trampled to death, or both. maybe not so much annoy people, rather see how many people actually noticed the announcements and were aware that their AS was being used as an origin in the path
Re: [Nanog-futures] NANOG-L, Paging, and the AUP
On Sun, Oct 5, 2008 at 6:59 PM, Rich Kulawiec [EMAIL PROTECTED] wrote: I suppose what I'm saying here is that the presence of this traffic on the nanog list isn't the problem per se -- it's a symptom of the problem. ---Rsk This makes sense, and i totally agree that is more a symptom... Christian ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] NANOG-L, Paging, and the AUP
On Sun, Oct 5, 2008 at 8:09 PM, Gadi Evron [EMAIL PROTECTED] wrote: I agree with both you and Mr. Koch. It is currently specifically defined as not for NANOG, so there is no interpretation. However, I also agree that it is a symptom, and times chnage.. Operators who are not in specific closed groups have very little useful resources to find contacts and it sems to be very operational for them. I personally have no problem with folks asking for contacts--as long as they went through the process of trying to find it themselves (including two days on the phone as far as I am concerned). Honestly, i dont mind either, as long as it is for a well defined reason, ie; attack mitigation assistance (individual or org that does not participate in something like NSP-SEC) reaching an unhelpful noc, lack of contact information available on the net, etc.. But when I see emails come through which are very short and vague, quite frankly it gets annoying after a while, especially when I see the org in which they are looking for a contact for that i know myself is easy to get in touch with or at least has multiple avenues of reachability based on my own experience. It can be as simple as querying an IRR db and reaching out to one of the persons who last made changes, if the noc is unresponsive. As well as PeeringDB... In some scenarios, this might not work, but then at least explain in your email your efforts and why you are reaching out on the NANOG-L for assistance Christian ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] NANOG-L, Paging, and the AUP
On Sun, Oct 5, 2008 at 8:20 PM, Michael K. Smith [EMAIL PROTECTED] wrote: Hello Christian: I guess I disagree 'somewhat'. Not to long ago we had a long thread about someone trying to configure their modem that was deemed appropriate to the list. How can that be more appropriate that trying to get in touch with a clueful network engineer about some routing anomalies between you and them? I don't know why that would be acceptable content, nothing really operational about it besides the un-operational hardware :) Maybe what's acceptable is broadening? And if so, maybe its time to update the website with some fresh advice on posting to the list? As long as other methods were attempted, something like this I dont see a problem with. It seems in most cases people are too quick to hit the send button before exhausting first and foremost resources. Refer to my reply to Gadi so I dont have to re-type the rest :) I would rather see a defined way (a form perhaps?) for submitting a request for assistance to NANOG rather than saying it doesn't fit the charter. As others have said, perhaps a little more information could be required, rather than could someone somewhere ping me? As an example Request for Contact - AS11274 to ASXYZ Reason: Routing anomalies between Seattle and Ashburn Contact Attempts Made: - Called NOC, was advised not a direct customer so no assistance will be given. - Used Puck NOC POC and received no reply in 5 business days Or something like that which provides a little more depth and breadth. Regards, Mike In a perfect world, that would be an excellent procedure... And it would reduce a lot of noise, but how do you even get someone to follow it? Unless, they are warned by the MLC when they dont... ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] NANOG-L, Paging, and the AUP
[replying to self] A good example just hit NANOG. Mark, who is by no means unclued or lazy, asked for help contacting email admins. Now, obviously he has done all he can to contact them on his own (I assume this being obvious and true). There is no question this is operational for him, nor that he did his own part first. The only question is if his question should then, after al else fails, be sent to NANOG or somewhere else? Gadi. Ironically, that is what struck me to post this topic to futures to begin with. Without knowing him, a quick look at his signature, hints to me, that he probably exhausted other options.. So, not coming down on him specifically, it's just happened to be what led me to opening this discussion.. Christian ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: ARIN Routing Registry vs RADB vs X
Sounds ridiculous...radb mirrors arins db, I don't see why they are trying to force you to use radb. You can query whois.radb.net and you will be able to see your arin objects... Did they give you a reason on WHY you should have to use RADB? Christian On Thu, Sep 25, 2008 at 6:38 PM, Craig Holland [EMAIL PROTECTED] wrote: Hi, I recently ran across a situation where a large ISP only accepts IRR entries generated by RADB to build their path filters. I use the ARIN Routing Registry. Is this a common practice? Should I convert over to RADB? Thanks, Craig
Re: prefix hijack by ASN 8997
Ahah, so my first theory was on the right track :) Thanks for sharing the info... Christian On Tue, Sep 23, 2008 at 2:33 AM, Andree Toonk [EMAIL PROTECTED] wrote: Hi, .-- My secret spy satellite informs me that at Tue, 23 Sep 2008, Hank Nussbacher wrote: I too spotted this via PHAS for a large number of prefixes, but have not received alerts from IAR, Watchmy.Net nor does RIPE RIS show this hijack: http://www.ris.ripe.net/perl-risapp/risearch.html I would have expected with so many RRC boxes that RIPE RIS would have caught it. I had thought it was a false positive from PHAS but now that you and others have seen it - I guess it is for real. Not a false positive, It actually was detected by the RIS box in Moscow (rrc13). Strange that it's not visible in RIS search website, but it's definitely in the raw data files. Looking at that raw data from both routeviews and Ripe, it looks like they (AS8997) 'leaked' a full table, i.e. : * 217.208 unique prefixes detected by the RIS server in Moscow (ASpath: 2895 3267 8997) * 250495 seen by routeviews (ASpath: 2895 3267 8997). (results of quick query: where AS-path contained '3267 8997' update type = advertisement). I'm using another prefix monitoring tool and within a few minutes it notified me of this hijack for some of our prefixes: Prefix Hijack ( Code 11: Origin AS and Prefix changed (more specific) Or Origin AS changed) detected 1 updates for your prefix 128.189.0.0/16 AS271: Update details: 2008-09-22 09:33 (UTC) 128.189.0.0/16 Announced by: AS8997 (ASN-SPBNIT OJSC North-West Telecom Autonomous System), Transit AS: AS3267 (RUNNET RUNNet) ASpath: 2895 3267 8997 Prefix Hijack ( Code 11: Origin AS and Prefix changed (more specific) Or Origin AS changed) detected 1 updates for your prefix 142.231.0.0/16 AS271: Update details: 2008-09-22 09:34 (UTC) 142.231.0.0/16 Announced by: AS8997 (ASN-SPBNIT OJSC North-West Telecom Autonomous System), Transit AS: AS3267 (RUNNET RUNNet) ASpath: 2895 3267 8997 / Cheers, Andree
Re: prefix hijack by ASN 8997
I received a phas notification about this today as well... I couldn't find any relevant data confirming the announcement of one of my /19 blocks, until a few minutes ago when i checked the route views bgplay (ripe bgplay turns up nothing) and can now see 8997 announcing and quickly withdrawing my prefix On Mon, Sep 22, 2008 at 9:06 PM, Scott Weeks [EMAIL PROTECTED] wrote: I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and another of our prefixes) by ASN 8997 (OJSC North-West Telecom in Russia) in using ASN 3267 (Russian Federal University Network) to advertise our space to ASN 3277 (Regional University and Scientific Network (RUSNet) of North-Western and Saint-Petersburg Area of Russia). Is that what I'm seeing when I go to bgplay.routeviews.org/bgplay, put in prefix 72.234.0.0/15 and select the dates: 22/9/2008 9:00:00 and 22/9/2008 15:00:00 If so, am I understanding it correctly if I say ASN 3267 saw a shorter path from ASN 8997, so refused the proper announcement from ASN 36149 (me) it normally hears from ASN 174 (Cogent). If the above two are correct, would it be correct to say only the downstream customers of ASN 3267 were affected? scott
Re: prefix hijack by ASN 8997
about 09:30 UTC per rviews On Mon, Sep 22, 2008 at 9:31 PM, Scott Weeks [EMAIL PROTECTED] wrote: --Scott Weeks [EMAIL PROTECTED] wrote: --- I am hoping to confirm a short-duration prefix hijack snip - --- [EMAIL PROTECTED] wrote: --- From: Christian Koch [EMAIL PROTECTED] I couldn't find any relevant data confirming the announcement of one of my /19 blocks, until a few minutes ago when i checked the route views bgplay (ripe bgplay turns up nothing) and can now see 8997 announcing and quickly withdrawing my prefix - At what time did you see it? scott
Re: prefix hijack by ASN 8997
At first glance this morning not seeing any data between the gain and lost alerts from phas and inability to find a route in any of the many collectors and route servers out there I had thought it was a possibly a fat finger mistake by 8997 or a false positive. After locating the data in bgplay/rviews, and noticing how many more people this occured to I'm leaning towards 2 possible scenarios: 1 - bgp misconfigurations leading to leaks (Depends on the overall scale of how many other prefixes were possibly announced) 2 - 8997 began announcing prefixes as an experiment to test the waters for potential real hijacks in future... 'geography' hints towards #2 Or both theories could be way off :) I'd be interested to know if Renesys collected any data that might give some better insight to this... Christian On 9/23/08, Justin Shore [EMAIL PROTECTED] wrote: Looking up some of my prefixes in PHAS and BGPPlay, I too see my prefixes being advertised by 8997 for a short time. It looks like it happened around 1222091563 according to PHAS. Was this a mistake or something else? Justin Christian Koch wrote: I received a phas notification about this today as well... I couldn't find any relevant data confirming the announcement of one of my /19 blocks, until a few minutes ago when i checked the route views bgplay (ripe bgplay turns up nothing) and can now see 8997 announcing and quickly withdrawing my prefix On Mon, Sep 22, 2008 at 9:06 PM, Scott Weeks [EMAIL PROTECTED] wrote: I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and another of our prefixes) by ASN 8997 (OJSC North-West Telecom in Russia) in using ASN 3267 (Russian Federal University Network) to advertise our space to ASN 3277 (Regional University and Scientific Network (RUSNet) of North-Western and Saint-Petersburg Area of Russia). Is that what I'm seeing when I go to bgplay.routeviews.org/bgplay, put in prefix 72.234.0.0/15 and select the dates: 22/9/2008 9:00:00 and 22/9/2008 15:00:00 If so, am I understanding it correctly if I say ASN 3267 saw a shorter path from ASN 8997, so refused the proper announcement from ASN 36149 (me) it normally hears from ASN 174 (Cogent). If the above two are correct, would it be correct to say only the downstream customers of ASN 3267 were affected? scott -- Sent from my mobile device
Re: prefix hijack by ASN 8997
Bgplay on routeviews, not the ripe one :) Christian On 9/23/08, Hank Nussbacher [EMAIL PROTECTED] wrote: On Mon, 22 Sep 2008, Christian Koch wrote: Strange that RIPE RIS search doesn't show it: http://www.ris.ripe.net/perl-risapp/risearch.html but yet you say BGPlay does show it. -Hank I received a phas notification about this today as well... I couldn't find any relevant data confirming the announcement of one of my /19 blocks, until a few minutes ago when i checked the route views bgplay (ripe bgplay turns up nothing) and can now see 8997 announcing and quickly withdrawing my prefix On Mon, Sep 22, 2008 at 9:06 PM, Scott Weeks [EMAIL PROTECTED] wrote: I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and another of our prefixes) by ASN 8997 (OJSC North-West Telecom in Russia) in using ASN 3267 (Russian Federal University Network) to advertise our space to ASN 3277 (Regional University and Scientific Network (RUSNet) of North-Western and Saint-Petersburg Area of Russia). Is that what I'm seeing when I go to bgplay.routeviews.org/bgplay, put in prefix 72.234.0.0/15 and select the dates: 22/9/2008 9:00:00 and 22/9/2008 15:00:00 If so, am I understanding it correctly if I say ASN 3267 saw a shorter path from ASN 8997, so refused the proper announcement from ASN 36149 (me) it normally hears from ASN 174 (Cogent). If the above two are correct, would it be correct to say only the downstream customers of ASN 3267 were affected? scott -- Sent from my mobile device
Re: Atrivo/Intercage: Now Only 1 Upstream
On Wed, Sep 17, 2008 at 1:07 PM, Christopher Morrow [EMAIL PROTECTED] wrote: On Wed, Sep 17, 2008 at 1:01 PM, Gadi Evron [EMAIL PROTECTED] wrote: On Wed, 17 Sep 2008, Skywing wrote: Putting things in the automated bogon feeds (e.g. Team Cymru) that are not strictly bogons (unallocated addresses) is likely to very quickly erode trust in those services, if that is what you are suggesting. We all want a really really bad stuff BGP feed for anyone who wants it, but the Internet is not ready for that. hrm, so actually there's a lot of supporting infrastructure that is necessary (or could be necessary) to implement something of that sort in any decent sized network. Provided you wanted to sinkhole the trafffic off somewhere to 'do the right thing' not just null0 the traffic, of course. right on. There's the additional issue of allowing a third party to manage/traffic-engineer inside your network which might upset some operations folks. If you can build a list on your own in a reasonable fashion with supporting information and high confidence level that's one story, if this list comes from someone else whom you don't even have a billing-relationship with... it's hard to sell that when something bad happens. and this is the exact reason i will not implement any of these auto-bgp feeds or drop lists in my network. now not only do i have internal operation folks fat fingers to worry about,but what if one of these third parties, as you pointed out, with no money changing hands or formal agreements,has fat fingers one day, and now adds a legitimate allocation to the feed/list? then what? Certainly not everyone feels this way (see 'popularity' of the existing RBL/xbl lists) but in a larger network, or one that makes money ... How about providing some open-source intelligence in a centralized and machine-parsable fashion (perhaps with community input of intel even) which would allow better decsions to be made? -Chris Christian
Re: LoA (Letter of Authorization) for Prefix Filter Modification?
I dont mind, i think it is another good step towards 'good filtering' but...i think the PITA part is downstream 'clueless' customers, who may need an explanation on prefix hijacking and the state of the internet today, and that these are all just combined efforts to minimize the risk of accepting allocations that don't belong to you. Christian On Tue, Sep 16, 2008 at 9:56 AM, Jon Lewis [EMAIL PROTECTED] wrote: On Tue, 16 Sep 2008, Rodriguez, Mauricio wrote: Recently, one of our Transit providers has started requiring a Letter of Authorization for addition of any of our own Transit customers' prefixes to their filters. The verbiage of the LoA basically states that the owner of the assignment or allocation (not necessarily our customer) allows us to advertise their prefixes through our service. Is this a common practice? Our past experience indicates that a simple request to a NOC or update of a routing registry usually is sufficient. It's not unheard of. Most providers don't require it, but I have run into a few who do. It's a minor PITA compared to the web interfaces some providers make you use to request filter updates. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: LoA (Letter of Authorization) for Prefix Filter Modification?
good point... :) On Tue, Sep 16, 2008 at 10:24 AM, Jon Lewis [EMAIL PROTECTED] wrote: On Tue, 16 Sep 2008, Christian Koch wrote: I dont mind, i think it is another good step towards 'good filtering' but...i think the PITA part is downstream 'clueless' customers, who may need an explanation on prefix hijacking and the state of the internet today, and that these are all just combined efforts to minimize the risk of accepting allocations that don't belong to you. IMO, it's just an illusion of added security and is really just CYA for the provider. When I fax TWTelecom an LOA that a customer faxed to me, how does TWTelecom verify the authenticity of that LOA? I doubt they try. I suspect it's just filed, and will only be pulled out if the advertisement is challenged by some 3rd party. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: community real-time BGP hijack notification service
I've been using IAR and PHAS, but I've noticed IAR seems to work a bit better and much faster. Recently we changed our ASN, and seconds after we started announcing prefixes under thew new ASN I received the email alerts from IAR. I did not receive anything from PHAS. Although I have in the past, PHAS seems to be unreliable at times. As for alerting on AS_PATH changes, I think that more false alarms would be generated given certain 'techniques' used to 're-route' traffic to use the best available path. (Internap/FCP). Maybe a better idea would be if you were able to input your origin asn and define your upstreams and/or peers, to be alerted on as well. (ie: Do not alert me on any paths containing 123_000, 456_000, 789_000). Christian On Fri, Sep 12, 2008 at 8:49 AM, Nathan Ward [EMAIL PROTECTED] wrote: On 12/09/2008, at 10:42 PM, Gadi Evron wrote: Hi, WatchMy.Net is a new community service to alert you when your prefix has been hijacked, in real-time. Hi Gadi, I just had a quick play with this, as I've been considering hacking together something similar. It is trivially easy for an attacker to falsify the origin AS. If 'they' are not doing it already, then I'm quite surprised. This isn't really a good thing to alarm on, in my opinion. Or, maybe it is, but there should be big bold text explaining that it's not reliable as it's trivially easy to falsify. To be honest, I can't think of anything better, all the attributes you can monitor can easily be falsified. My best idea is looking at the AS_PATH for changes, and alerting whenever that happens. You'd obviously get a different path whenever there is churn in the network though. I'm sure there's a way to do this, and I suspect having BGP feeds from many many places is the most reliable way for it to happen, I just haven't figured out why yet. This seems like a service that Renesys etc. could/should (or maybe do?) offer, they seem well placed with all their BGP feeds.. -- Nathan Ward
Re: New Intercage upstream
looks to me as if they are just using output of 'top' and displaying it there as it were for network stats. output of top from one of my boxes.. top - 11:39:48 up 3 days, 20:56, 3 users, load average: 0.07, 0.21, 0.16 On Fri, Sep 12, 2008 at 11:13 AM, Bill Woodcock [EMAIL PROTECTED] wrote: On Fri, 12 Sep 2008, William Hamilton wrote: What's amusing about having one user on that particular host? That's the _front page of their corporate web site_. It doesn't say host it says that's their _network_. -Bill
Re: only WV FIBER now peering with Atrivo / Intercage
On Sat, Sep 6, 2008 at 8:30 PM, Anton Kapela [EMAIL PROTECTED] wrote: On Sat, Sep 6, 2008 at 6:33 PM, Patrick W. Gilmore [EMAIL PROTECTED] wrote: Anton's post that GX is still providing them transit is a bit curious, since I was under the impression GX had severed all ties with Atrivo. But the table does not lie, a path of 174 3549 27595 is clearly transit. GX, care to comment? After poking for a bit, it's unclear what, if anything, GX is or isn't doing here. I tossed a static /24 towards the upstream sending the AS path with GX in it, and traced towards a host in the that /24 - the traceroute output disagrees with the as path, oddly enough. bgp routes, again: r 58.65.238.0/24 71.13.116.101 100 0 20115 19151 27595 i r 204.11.128.105 100 0 33125 174 3549 27595 i actual path is cogent, (3), wv, intercage, not cogent, gx, intercage: Tracing the route to 58-65-238-1.myrdns.com (58.65.238.1) 1 204.11.128.105 [AS 33125] 0 msec 0 msec 0 msec 2 gi2-15.ccr02.ord03.atlas.cogentco.com (38.104.102.29) [AS 174] 4 msec 4 msec 8 msec 3 te-9-1.car4.Chicago1.Level3.net (4.68.127.129) [AS 3356] 4 msec 8 msec 4 msec 4 ae-32-56.ebr2.Chicago1.Level3.net (4.68.101.190) [AS 3356] 8 msec 20 msec 16 msec 5 ae-5.ebr2.Chicago2.Level3.net (4.69.140.194) [AS 3356] 8 msec 4 msec 8 msec 6 ae-2.ebr2.Washington1.Level3.net (4.69.132.70) [AS 3356] 40 msec 36 msec 36 msec 7 ae-72-72.csw2.Washington1.Level3.net (4.69.134.150) [AS 3356] 36 msec ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) [AS 3356] 40 msec ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) [AS 3356] 40 msec 8 ae-14-69.car4.Washington1.Level3.net (4.68.17.6) [AS 3356] 28 msec ae-24-79.car4.Washington1.Level3.net (4.68.17.70) [AS 3356] 32 msec ae-34-89.car4.Washington1.Level3.net (4.68.17.134) [AS 3356] 32 msec 9 CWIE-LLC.car4.Washington1.Level3.net (4.79.170.146) [AS 3356] 32 msec 32 msec 28 msec 10 * * * 11 atl-ten3-1-ash-ten3-1.wvfiber.net (66.216.1.157) [AS 19151] [MPLS: Label 120 Exp 0] 216 msec 208 msec 188 msec 12 nsh-ten4-1-atl-ten3-2.wvfiber.net (64.127.130.58) [AS 19151] [MPLS: Label 73 Exp 0] 32 msec 32 msec 32 msec 13 la-ten1-1-nsh-ten4-2.wvfiber.net (66.186.197.109) [AS 19151] [MPLS: Label 113 Exp 0] 80 msec 80 msec 80 msec 14 sjc-ten1-1-la-ten1-2.wvfiber.net (66.186.197.106) [AS 19151] 80 msec 84 msec 80 msec 15 58-65-238-1.myrdns.com (58.65.238.1) 84 msec 132 msec 104 msec question I have for the list is...who's faking the funk? second that... from ripe bgplay view, gx is never seen as an adjacency to 27595, just wv and bandcon, with liteup being brought up later on in the 2 day interval http://www.ris.ripe.net/cgi-bin/bgplay.cgi?prefix=58.65.238.0/24start=2008-09-05+01:15end=2008-09-07+01:15 -Tk -christian
Re: HurricaneElectric
you might want to check the obvious first :) http://www.tunnelbroker.net/forums/ [EMAIL PROTECTED] On Fri, Aug 29, 2008 at 5:34 AM, Colin Alston [EMAIL PROTECTED] wrote: Is anyone from Hurricane Electric/TunnelBroker.net here?
Re: Revealed: The Internet's well known BGP behavior
what do mpls, ipsec tunnels, ssl have anything to do with someone announcing your address space and hijacking youre prefixes?? i think we all know this is not new.. and these guys didnt claim it to be.. they're not presenting this to a 'xNOG' crowd, defcon has a different type of audience..im not saying they dont know about this kind of insecurity, but it is nice to see this material being presented, and exposing it to different 'groups' especially with a live demo... christian On Wed, Aug 27, 2008 at 11:07 PM, John Lee [EMAIL PROTECTED] wrote: 1. The technique is not new it is well known BGP behavior and not stealthy to people who route for a living. 2. When your networks use VPNs, MPLS, IPsec, SSL et al you can control what packets are going where. 3. When you are running some number of trace routes per hour to see how and where your packets are going you spot the additional hops. 4. If you do cold potatoe routing and know where you peering points are and what the acls and peering policies are it is more difficult to hijack. And finally you use high speed optical paths or broad band ISDN (ATM) why route when you can deterministically switch. John (ISDN) Lee :) From: Frank [EMAIL PROTECTED] Sent: Wednesday, August 27, 2008 8:47 PM To: NANOG list Subject: Revealed: The Internet's Biggest Security Hole http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html Two security researchers have demonstrated a new technique to stealthily intercept internet traffic on a scale previously presumed to be unavailable to anyone outside of intelligence agencies like the National Security Agency. The tactic exploits the internet routing protocol BGP (Border Gateway Protocol) to let an attacker surreptitiously monitor unencrypted internet traffic anywhere in the world, and even modify it before it reaches its destination. The demonstration is only the latest attack to highlight fundamental security weaknesses in some of the internet's core protocols. Those protocols were largely developed in the 1970s with the assumption that every node on the then-nascent network would be trustworthy. The world was reminded of the quaintness of that assumption in July, when researcher Dan Kaminsky disclosedhttp://blog.wired.com/27bstroke6/2008/07/details-of-dns.htmla serious vulnerability in the DNS system. Experts say the new demonstration targets a potentially larger weakness. It's a huge issue. It's at least as big an issue as the DNS issue, if not bigger, said Peiter Mudge Zatko, noted computer security expert and former member of the L0pht hacking group, who testified to Congress in 1998 that he could bring down the internet in 30 minutes using a similar BGP attack, and disclosed privately to government agents how BGP could also be exploited to eavesdrop. I went around screaming my head about this about ten or twelve years ago We described this to intelligence agencies and to the National Security Council, in detail. The man-in-the-middle attack exploits BGP to fool routers into re-directing data to an eavesdropper's network. Anyone with a BGP router (ISPs, large corporations or anyone with space at a carrier hotelhttp://www.fubra.com/blog/2007/10/mac-mini-bgp-routers-part-2.html) could intercept data headed to a target IP address or group of addresses. The attack intercepts only traffic headed *to* target addresses, not from them, and it can't always vacuum in traffic within a network -- say, from one ATT customer to another. The method conceivably could be used for corporate espionage, nation-state spying or even by intelligence agencies looking to mine internet data without needing the cooperation of ISPs. BGP eavesdropping has long been a theoretical weakness, but no one is known to have publicly demonstrated it until Anton Tony Kapela, data center and network director at 5Nines Data http://www.5ninesdata.com/, and Alex Pilosov, CEO of Pilosoft http://www.pilosoft.com/, showed their technique at the recent DefCon hacker conference. The pair successfully intercepted traffic bound for the conference network and redirected it to a system they controlled in New York before routing it back to DefCon in Las Vegas. The technique, devised by Pilosov, doesn't exploit a bug or flaw in BGP. It simply exploits the natural way BGP works. We're not doing anything out of the ordinary, Kapela told Wired.com. There's no vulnerabilities, no protocol errors, there are no software problems. The problem arises (from) the level of interconnectivity that's needed to maintain this mess, to keep it all working. The issue exists because BGP's architecture is based on trust. To make it easy, say, for e-mail from Sprint customers in California to reach Telefonica customers in Spain, networks for these companies and others communicate through BGP routers to indicate when they're the quickest, most
Re: Smallest netblock that providers will accept?
a lot of providers have their bgp/routing policy published somewhere online/in their community guide for instance, you can find L3's policy in their irr objects ( whois -h whois.radb.net as3356) there are also plenty of community guides available here - http://www.onesc.net/communities/ Christian On Mon, Aug 18, 2008 at 9:32 PM, Mike Lyon [EMAIL PROTECTED] wrote: Hello All, I am curious as to the routing polices of the bigger providers such as ATT, L3, Internap, Qwest, Etc Etc... Is there a standard size netblock that these providers will accept? For instance, if customer A gets a /22 from ARIN and his upstream provider is ATT and L3, what would the smallest block be that those providers would accept from customer A? Would they accept something as small as a /24? Thanks, Mike
Re: Arbitrary de-peering
http://www.renesys.com/blog/2008/03/you_cant_get_there_from_here_1.shtml http://www.renesys.com/blog/2008/03/he_said_she_said_cogent_vs_tel.shtml http://www.renesys.com/blog/2008/03/telia_and_cogent_kiss_and_make_1.shtml On Mon, Jul 28, 2008 at 11:24 AM, William Waites [EMAIL PROTECTED] wrote: Le 08-07-28 à 17:12, [EMAIL PROTECTED] a écrit : Example: A York University professor was sitting at his desk at work in March 2008 trying to reach an internet website located somewhere in Europe. [...] York's bandwidth supplier is Cogent which had severed a peering relationship with a bandwidth provider in Europe called Telia [...] which was the bandwidth network provider for the website that the Professor was trying to reach. [...] Cogent did not proactively inform the University of the issue and the loss of connectivity. Unreachability due to arbitrariness in network peering is unacceptable. There must be more to this story. If Cogent de-peered from Telia the traffic would normally just have taken another path. Either there was a configuration error of some sort or else some sort of proactive black-holing on one side or the other. As the latter would be surprising and very heavy handed, I would tend to suspect the former. Peering relationships are made and severed all the time with no particular ill-effects, unless you can point to examples of outright malice (i.e. of the black-holing kind) I don't think there is much basis for any public policy decisions in this example. Unreachability due to configuation error is of course relatively common; perhaps I am wrong, but I don't think the CRTC would really have much to say about that. Cheers, -w
Re: SANS: DNS Bug Now Public?
matasano blogged about it cache of the original post here.. http://beezari.livejournal.com/ matasano apologizes here http://www.matasano.com/log/1105/regarding-the-post-on-chargen-earlier-today/ dan posts (13 - 0) 13 days left to blackhat opposed to the 0 days since the details were discussed http://www.doxpara.com/?p=1176 halvar flake speculation http://addxorrol.blogspot.com/2008/07/on-dans-request-for-no-speculation.html post on daily dave http://seclists.org/dailydave/2008/q3/0070.html On Tue, Jul 22, 2008 at 8:40 AM, Jon Kibler [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 SANS is reporting that Kaminsky's DNS bug may be now being exploited in the wild. See: http://isc.sans.org/diary.html?nstoryid=4765 Jon Kibler - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiF1T8ACgkQUVxQRc85QlMN1ACfTR8oJRy2V27+c5PjERcUjgIU evAAn1sDR9xMc1bEmTeygXl7QkF9er2T =eqbc -END PGP SIGNATURE- == Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.
Re: AS 54271
interestingly, before july 7th these prefixes were originating from another private as - 65501, until sometime that day routes were withdrawn from 65501 and began being announced from 54271... On Sun, Jul 13, 2008 at 4:10 PM, Joel Jaeggli [EMAIL PROTECTED] wrote: Scott Morris wrote: Wouldn't it be better to ask the folks in Hungary (AS20922) who are peering with this site? These are or appear to be all 20922's prefixes... 54271 is a stub from my vantage points that only appears from behind 20992. One side, I'd buy the typo. Both sides, mutual typos are a little more difficult. looks more like a lack of clue. off-hand I'd hazard that only one party is involved. Not that conspiracy theories are all that much fun, but I'm finding the one-sided mistake hard to believe. Either that or the folks at AS20922 haven't figured out that an open bgp peer isn't a great idea! :) Scott -Original Message- From: Joel Jaeggli [mailto:[EMAIL PROTECTED] Sent: Sunday, July 13, 2008 1:36 PM To: Marshall Eubanks Cc: NANOG list Subject: Re: AS 54271 those prefixes all have ripe route object with origin AS 20922 all the routes I see for a given prefix look like the following: 2914 1299 12301 8696 20922 54271 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:1299 2497 3257 12301 8696 20922 54271 202.232.0.2 from 202.232.0.2 (202.232.0.2) Origin IGP, localpref 100, valid, external 7660 2516 3257 12301 8696 20922 54271 203.181.248.168 from 203.181.248.168 (203.181.248.168) Origin IGP, localpref 100, valid, external Community: 2516:1030 etc... Marshall Eubanks wrote: As of this morning, I am seeing BGP from AS 54271 * 62.77.196.0/22 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 62.77.254.0/23 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 81.17.184.0/22 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 81.17.190.0/23 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 82.131.196.0/23 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 82.131.198.0/24 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 82.131.248.0/21 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 89.148.64.0/22 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 89.148.70.0/23 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 89.148.72.0/23 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 89.148.78.0/23 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 89.148.82.0/23 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 89.148.96.0/23 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 89.148.99.0/24 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i This ASN has not been assigned to any RIR. Is this a bogon, or does anyone know of a legitimate reason for this ? Regards Marshall -- ^christian$
Re: Multiple DNS implementations vulnerable to cache poisoning
surely the tool is not focused at a dns operator/admin audience.. On Tue, Jul 8, 2008 at 8:20 PM, Owen DeLong [EMAIL PROTECTED] wrote: The tool, unfortunately, only goes after the server it thinks you are using to recurse from the client where you're running your browser. This makes it hard to test servers being used in production environments without GUIs. The tool is not Lynx compatible. Owen On Jul 8, 2008, at 5:12 PM, Lynda wrote: This is also being covered over on the Defcon Forums. Jeff Moss has said that he'll post the link to the interview that Kaminsky is doing right now, after it's over. Here's the link to the Forum discussion: https://forum.defcon.org/showthread.php?t=9547 The forum link also has a link to Dan's tool, where you can see if your DNS server is vulnerable. -- In April 1951, Galaxy published C.M. Kornbluth's The Marching Morons. The intervening years have proven Kornbluth right. --Valdis Kletnieks -- ^christian$
Re: Replacement for Avaya CNA/RouteScience
agreed. i see the most benefit from these boxes geared towards networks with critical apps that are latency intensive and more than a handful of transit providers than i do for a smaller provider.. depending on how many upstreams you're juggling, its not that hard to create some traffic engineering policies that can easily be modified, (whether by hand or you use a script with a front end that can push the changes for you) in order to re-route traffic in the event of issues with an SP network in your end to end path.. personally i think manual traffic engineering and re-routing is one of the more fun parts of engineering.. -christian On Thu, Jul 3, 2008 at 12:50 PM, Robert E. Seastrom [EMAIL PROTECTED] wrote: Eric Van Tol [EMAIL PROTECTED] writes: I'd like to hire that engineer, please. Can you send me his resume? Here's the job description: - Required to works 24x7x365. - Must monitor all network egress points to examine latency, retransmissions, packet loss, link utilization, and link cost. - Required to tweak localpref on an average of 5000 prefixes per day, based upon a combination of the above criteria. - Required to write up a daily, weekly, and monthly report to be sent to all managers on said schedule. - Must not require health or dental care. These devices are not a replacement for an actual engineer. They are a supplement to the network to assist the engineer in doing what he should be doing - engineering and planning as opposed to resolving some other network's packet loss/blackhole/peering dispute/latency problem. You can certainly get close to the requirements stated above by offering a decent salary and hiring a reasonably clued engineer with an SP background. You may have to settle for IRC, WoW, or SecondLife as daily recreational activity that doesn't buy you much (expressed in your requirements list as tweaking localpref). My general experience with such boxes is that they're awfully good at impressing the PHBs, but not something you can really defend from a cost/benefit perspective. I really do need to go into the custom painted boxes with LCD screens on the front business. I could make melons, like Tom Vu. ---Rob -- ^christian$
Re: Replacement for Avaya CNA/RouteScience
imo, no more than 3-4 transit providers and maybe a presence at 1 or 2 ixp's with x amount of peer's would be small im not saying customers won't/don't care about latency, its just not difficult to route around the problematic nodes (unless SP A/B/C gets to it first and band aid the issue until resolution), maybe i just don't see enough issues to even recognize the problem? agreed, human error is a big cause of a lot of issues. well there are plenty of ways to manipulate traffic other than local_pref, that is why i find it interesting, you have options. i don't understand what the difficulty is in monitoring your bandwidth and understanding your traffic patterns, if this is done properly, you can plan capacity and execute your routing policies for optimal performance, and not have to re-route/re-engineer traffic so often. does your traffic fluctuate that much that you cant get a good grasp on what you're pushing, from who, and when? i definitely see value in appliances like the fcp and route science box, i just think for a smaller provider it may not be necessary - or maybe i have it backwards,and it is a better solution for a smaller provider so they don't have to waste money on highly skilled engineers? maybe i am just thinking inside the box at the moment, from an engineers view..if so my apologies for steering off course -christian On Thu, Jul 3, 2008 at 4:51 PM, Eric Van Tol [EMAIL PROTECTED] wrote: From: Christian Koch [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 2:39 PM To: Robert E. Seastrom Cc: Eric Van Tol; nanog@nanog.org Subject: Re: Replacement for Avaya CNA/RouteScience agreed. i see the most benefit from these boxes geared towards networks with critical apps that are latency intensive and more than a handful of transit providers than i do for a smaller provider.. Two questions: First, what would you characterize as a smaller provider? One that has only one or two transits? If that's the case, then yes, I would definitely agree with you. However, once you go beyond just a few transits and peers, choosing which one to use for an unhealthy destination becomes tedious if you're trying to do it all manually. That said, I believe there is a stopping point at which the size of the network outgrows the need for such a device. Second, can you provide an example of a network where users don't care about latency? I can't say that I've worked on tons of networks, but if the internet is slow, and even though our customers may not be using the latest in realtime streaming media protocols and apps, they notice. depending on how many upstreams you're juggling, its not that hard to create some traffic engineering policies that can easily be modified, (whether by hand or you use a script with a front end that can push the changes for you) in order to re-route traffic in the event of issues with an SP network in your end to end path.. It *is* relatively simple to make routing changes manually, but wouldn't you agree that human error is the cause of most outages? Even the most skilled engineers/techs have days where their fingers are larger than normal. These devices, at least the one we use, makes no changes to router configurations. personally i think manual traffic engineering and re-routing is one of the more fun parts of engineering.. -christian Yes, as long as the problem is interesting. Manually changing localpref on a route because of packet loss in someone else's network, several times per week, is not interesting to me or my staff. Nor is checking every transit link several times a day to make sure that we're not going over a commit when other transits have plenty of bandwidth to spare. In my opinion, most of the value of these types of appliances is to help identify problem areas outside of your network, before end users notice them. I know firsthand that our route optimization appliance frees up my staff to work on other issues such as capacity planning, new service deployments, or discussing the latest MGS4 strategies. Well, hopefully not that last one. -evt -- ^christian$
Elanti Inteligent Routing..
anyone with firsthand operational experience with this? pro's, con's? feedback? ck
