RE: [HMS-SPAM] regions.com down??
Confirmed down from my site in Los Angeles via nLayer. Chrome says "Error 101 (net::ERR_CONNECTION_RESET): The connection was reset". C:\Users\jake>tracert regions.com Tracing route to regions.com [205.255.243.11] over a maximum of 30 hops: 124 ms14 ms 5 ms v403.er01.lax.ubiquity.io [72.37.224.129] 2 1 ms 1 ms 4 ms xe-1-0-3.ar1.lax2.us.nlayer.net [69.31.127.45] 3<1 ms<1 ms<1 ms ae1-80g.cr1.lax1.us.nlayer.net [69.31.127.129] 4 9 ms 1 ms 1 ms ae2-50g.ar1.lax1.us.nlayer.net [69.31.127.142] 5<1 ms<1 ms<1 ms as3549.xe-9-0-0.ar1.lax1.us.nlayer.net [69.31.127.190] 6<1 ms 1 ms<1 ms ae1.scr3.LAX1.gblx.net [67.16.162.173] 7 131 ms 146 ms 131 ms xe2-2-0-10G.scr3.LON3.gblx.net [67.16.165.66] 8 132 ms 141 ms 132 ms lag1.ar9.LON3.gblx.net [67.17.72.21] 9 141 ms 160 ms 142 ms HIGHWINDS-NETWORK-GROUP.TenGigabitEthernet9-1.ar4.LON3.gblx.net [64.210.29.54] 10 *** Request timed out. 11 *** Request timed out. 12 --Jake -Original Message- From: Positively Optimistic [mailto:positivelyoptimis...@gmail.com] Sent: Wednesday, December 26, 2012 2:44 PM To: nanog list Subject: [HMS-SPAM] regions.com down?? Is http://www.regions.com down globally?
Re: rDNS delegation process question
Someone needs to update the delegation at ARIN since they are the authoritative root for 69/8. http://whois.arin.net/rest/rdns/223.26.69.in-addr.arpa shows that the current nameservers are OAK.FOREST.NET and WILLOW.FOREST.NET. If I recall correctly, the ARIN Online interface allows the registered administrative and technical POC to make these adjustments directly from the interface. As it stands right now, it would appear that whomever has access to net...@alfordmedia.com,. n...@airband.com, or an associated POC would need to use the appropriate ARIN template or interface to make the change. -- Regards, Jake Mertel Nobis Technology Group, LLC *Web: *http://www.nobistech.net *Phone: *1-480-212-1710 *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 On Tue, Aug 18, 2015 at 12:50 PM, Dave Pooser wrote: > At $DAYJOB we have a /24 of PA space that we were allocated by Airband, > and when the account was set up they delegated authoritative reverse DNS > to our DNS hosting provider. This is 69.26.223.0/24, in ARIN address > space. > > Now, almost a decade later Airband has been acquired by somebody or other > who was in turn acquired by GTT.net; we're trying to move our rDNS to > Route53 and nobody at GTT.net seems to know how they would go about > changing that rDNS delegation. My involvement with the process back in the > day was limited to "provide Airband with the name servers we would like to > be authoritative for the reverse DNS and wait about 12 hours for them to > handle the ticket." Now I'm trying to help my GTT contact get pointed in > the right direction, and any assistance would be appreciated. > -- > Dave Pooser > Cat-Herder-in-Chief, Pooserville.com > > >
Re: Synful Knock questions...
Reading through the article @ https://www.fireeye.com/blog/threat-research/2015/09/synful_knock_-_acis.html, I'm lead to believe that the process(s) they overwrite are selected to cause no impact to the device. Relevant excerpt: ### Malware Executable Code Placement To prevent the size of the image from changing, the malware overwrites several legitimate IOS functions with its own executable code. The attackers will examine the current functionality of the router and determine functions that can be overwritten without causing issues on the router. Thus, the overwritten functions will vary upon deployment. ### So, if the device in question isn't using OSPF, then the malware may overwrite the code for the OSPF process, allowing them to A) infect the device; B) cause no disruption to the operational state of the device (since, presumably, OSPF isn't going to be turned on); and C) keep the image firmware file size the same, preventing easy detection of the compromise. -- Regards, Jake Mertel Ubiquity Hosting *Web: *https://www.ubiquityhosting.com *Phone (direct): *1-480-478-1510 *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 On Tue, Sep 15, 2015 at 11:15 AM, wrote: > I'm sure most have already seen the CVE from Cisco, and I was just reading > through the documentation from FireEye: > > https://www.fireeye.com/blog/threat-research/2015/09/synful_knock_-_acis.htm > l > > Question is that it looks to me like they are over-writing the ospf > response > for "show ip ospf timers lsa-group"? > And if that's the case I'm guessing the router would need to have ospf > enabled to be able to see the response? > > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > F: 610-429-3222 > > > > >
Re: Synful Knock questions...
Indeed -- While there are methods that can be used to "pack" a file so that it collides with a desirable checksum, that would be nearly impossible to do in this scenario. I suspect that you're right in all regards -- that taking the image file and checking it on another host would show obvious indications of change, that local verification would be impossible since the malware could presumably change the verification output, and that the primary motivation for keeping the file size the same was to prevent simple differential checks like those done by rancid from picking up the change. -- Regards, Jake Mertel Ubiquity Hosting *Web: *https://www.ubiquityhosting.com *Phone (direct): *1-480-478-1510 *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 On Tue, Sep 15, 2015 at 11:50 AM, Michael Douglas wrote: > Wouldn't the calculated MD5/SHA sum for the IOS file change once it's > modified (irrespective of staying the same size)? I'd be interested to see > if one of these backdoors would pass the IOS verify command or not. Even > if the backdoor changed the verify output; copying the IOS file off the > router and MD5/SHA summing it on another host should show a difference. I > guess maintaining the file size is to prevent something like RANCID firing > off a diff on the flash dir output. >
Re: Synful Knock questions...
My apologies, Valdis is indeed correct, I did not mean to suggest that it would be possible to make modifications in such a way that would result in an identical checksum. Sorry for the confusion and extra noise. -- Regards, Jake Mertel Ubiquity Hosting *Web: *https://www.ubiquityhosting.com *Phone (direct): *1-480-478-1510 *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 On Tue, Sep 15, 2015 at 1:01 PM, wrote: > On Tue, 15 Sep 2015 11:54:30 -0700, Jake Mertel said: > > Indeed -- While there are methods that can be used to "pack" a file so > that > > it collides with a desirable checksum, that would be nearly impossible to > > do in this scenario. > > Small clarification here. > > There are known methods to easily produce two files that have the same MD5 > hash, but you have no control over the checksum. > > There are not (to my knowledge) ways to tweak a file to produce a specified > MD5 hash. MD5 is broken, but not *that* broken (yet). Feel free to point > me at papers if it's been done. > > There are ways to easily produce a file with a specified > non-crypto-strength > hash like a CRC-32. > > So it really matters to be clear on what algorithm is used for the > checksum/hash. >
Re: IP's with jitter/packet loss and very far away
Expanding on this a little further, you could use this tool + some virtual machines and static routes to simulate just about any conditions you wanted. -- Regards, Jake Mertel Ubiquity Hosting *Web: *https://www.ubiquityhosting.com *Phone (direct): *1-480-478-1510 *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 On Fri, Sep 18, 2015 at 8:58 AM, Keith Stokes wrote: > There are also plenty of simulators to create what you want. This one > looks pretty useful: > > http://www.linuxfoundation.org/collaborate/workgroups/networking/netem > > On Sep 18, 2015, at 10:54 AM, Neill kei...@neilltech.com>> wrote: > > Use probably any coffee shop’s wireless network to anyone any you’ll get > that most of the time. > > > On Sep 18, 2015, at 10:42 AM, Dovid Bender do...@telecurve.com>> wrote: > > Hi, > > I am working on a presentation and looking to create samples of what a > trace should not look like? Anyone have IP's that I can trace from the US > or UK that will show > 1) jitter > 2) packet loss > 3) very far away (perhaps an IP on a sat. link). Pref over 2000 ms > > TIA. > > Dovid > > > --- > > Keith Stokes > > > > > > > --- > > Keith Stokes > > > > >
Re: Synful Knock questions...
Looks like Cisco's Talos just released a tool to scan your network for indications of the SYNful Knock malware. Details @ http://talosintel.com/scanner/ . -- Regards, Jake Mertel Ubiquity Hosting *Web: *https://www.ubiquityhosting.com *Phone (direct): *1-480-478-1510 *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 On Wed, Sep 16, 2015 at 7:33 AM, Stephen Fulton wrote: > Follow-up to my own post, Fireeye has code on github: > > https://github.com/fireeye/synfulknock > > > On 2015-09-16 10:27 AM, Stephen Fulton wrote: > >> Interesting, anyone have more details on how to construct the scan using >> something like nmap? >> >> -- Stephen >> >> On 2015-09-16 9:20 AM, Royce Williams wrote: >> >>> HD Moore just posted the results of a full-Internet ZMap scan. I didn't >>> realize that it was remotely detectable. >>> >>> 79 hosts total in 19 countries. >>> >>> https://zmap.io/synful/ >>> >>> Royce >>> >>>
Fw: new message
Hey! New message, please read <http://in2itshop.com/spoken.php?ar> Jake Mertel
Re: algeria
Not finding much but did run into this, posted within the past hour (according to Google) http://www.alhurra.com/content/algeria-internet/284810.html Excerpt from Google translate "Internet service in Algeria fell to 80 percent because of damage caused, which hit the main cable that connects between Algeria and Europe, the Algerian economy to incur significant losses outweigh million dollars a day." -- Regards, Jake Mertel Ubiquity Hosting *Web: *https://www.ubiquityhosting.com *Phone (direct): *1-480-478-1510 *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 On Tue, Oct 27, 2015 at 3:35 PM, Randy Bush wrote: > any gossip of a cable issue to algier? > > randy >
Re: Project Fi and the Great Firewall
I know the service/device uses VPN if you are using "wifi assist" to connect to an open WAP -- it automatically tunnels the traffic so it can't be read by nearby snoopers. Perhaps they employ a similar technology or are using something like PPP to take all of the traffic back to one (or many) "access servers" before sending it off to the Internet. I have no experience whatsoever in cellular network operations, but I know many providers employ similar methodologies to assist in meeting their CALEA requirements. On Saturday, November 14, 2015, Roland Dobbins wrote: > On 15 Nov 2015, at 9:00, Sean Hunter wrote: > > While in China recently, I noticed that my Project Fi phone was accessing >> Google. >> > > Accessing, or attempting to access? > > Were you using a local SIM card, or roaming w/data? What about WiFi? > > ------- > Roland Dobbins > -- -- Regards, Jake Mertel Ubiquity Hosting *Web: *https://www.ubiquityhosting.com *Phone (direct): *1-480-478-1510 *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054
Re: Best Source for ARIN Region /24
The held back a /10 from their final /8 allocation. Details @ https://www.arin.net/policy/nrpm.html#four10 . -- Regards, Jake Mertel Ubiquity Hosting Web: https://www.ubiquityhosting.com Phone (direct): 1-480-478-1510 Mail: 5350 East High Street, Suite 300, Phoenix, AZ 85054 On Tue, Jan 12, 2016 at 12:15 PM, Jim Mercer wrote: > On Tue, Jan 12, 2016 at 10:54:49AM -0800, Owen DeLong wrote: >> As an end user, you can get an IPv6 /48 and still qualify for the /24 of >> transitional space as well. > > did ARIN hold back some blocks to service the 'transitional space', or would > that be going to the STLS list? > > --jim > > > >> >> Owen >> >> > On Jan 11, 2016, at 18:35 , Matthew D. Hardeman >> > wrote: >> > >> > I???m aware of the /24 block for facilitation concept, but my client???s >> > use case can qualify as an end-user rather than as an ISP, thus their >> > annual operating cost is smaller than even the X-SMALL ISP category, which >> > they???d land in ??? if they opted for the smaller /36 initial IPv6 direct >> > allocation, rather than the default /32 direct allocation. >> > >> > That seems to balance toward buying an existing /24. >> > >> >> On Jan 11, 2016, at 8:00 PM, Rafael Possamai >> >> wrote: >> >> >> >> If you apply for an IPv6 block, as an ISP, and you have the intention of >> >> truly utilizing it, then you can apply for a /24 to facilitate that >> >> transition. >> >> >> >> It will cost you about $1500 or so, which is about half of what a /24 is >> >> going for in the transfer market. >> >> >> >> Thing is, if you take the IPv6 block just to use the /24 they give you, >> >> then one could argue you are cheating the system. >> >> >> >> >> >> >> >> On Mon, Jan 11, 2016 at 1:19 PM, Matthew D. Hardeman >> >> mailto:mharde...@ipifony.com>> wrote: >> >> I???m looking to buy a /24 of space for a new multi-homed network in the >> >> ARIN region. Can anyone out there speak to going rates for a /24 and >> >> best places to shop? >> >> >> >> >> > > > -- > Jim Mercer Reptilian Research j...@reptiles.org+1 416 410-5633 > > Life should not be a journey to the grave with the intention of > arriving safely in a pretty and well preserved body, but rather > to skid in broadside in a cloud of smoke, thoroughly used up, > totally worn out, and loudly proclaiming "Wow! What a Ride!" > -- Hunter S. Thompson
Re: Akamai minimum prefix length issue
Chuck, Just throwing this out there as a possibility, I've seen similar issues with other ISPs wherein the root cause was their BGP speaking routers using a filter set published by (I'm almost certain) Cisco that, among other things, blocks announcements of any prefix that is smaller then the minimum prefix size allocated from an RIR for the prefix in question. If you look at https://www.arin.net/knowledge/ip_blocks.html you will see that they now say "All prefixes have the potential to have a /24 minimum size allocation issued from them.", but this was not always the case. For example, looking at the archive.org copy of that page from https://web.archive.org/web/20140107021136/https://www.arin.net/knowledge/ip_blocks.html on January 7, 2014, the smallest prefix they allocated from 162/8 was a /22. I did some quick google'ing but was unable to find a copy of the filter set in question. I poked a few of my colleagues and will let you know if I'm able to find a copy for reference. --Jake On Wed, May 13, 2015 at 12:33 PM, Chuck Church wrote: > Anyone from Akamai (or who might know), > > Having an issue with AS 20940 either not seeing or ignoring a /23 > we're announcing, and following a /22 to another path. Other ISPs our > upstream peers with see the /23. I didn't see a looking glass for Akamai > to > verify. Anyone from Akamai able to help? Prefix in question is > 162.220.232.0/23. > > Thanks, > > Chuck > > > > >
Re: google / massive problems
No issues from my site routing over AboveNet and using Google Apps for Business -- Drive and Gmail working as expected. On Wednesday, October 9, 2013, Blair Trosper wrote: > Can someone from Google Drive or Gmail contact me off-list? > > The sign in services and applications are outright down trying to use them > in Chrome. Trying to contact enterprise support via several numbers just > results in an immediate disconnect. > > The App Status page shows no problem, but Twitter and Facebook are blowing > up with trouble reports, and I have tons of technical status codes to > share, but no one with whom to share them. > > Thanks, > Blair > -- -- Regards, Jake Mertel Nobis Technology Group, LLC *Web: *http://www.nobistech.net *Phone: *1-480-212-1710 *Mail:* 6930 East Chauncey Lane, Suite 150, Phoenix, AZ 85054
Re: do ISPs keep track of end-user IP changes within thier network?
While I'm also not an attorney, my reading of 18 USC 2703 leads me to believe that records need only to be preserved for 180 days if a governmental entity (i.e. law enforcement agency, regulatory body, prosecutors office, etc) makes a request that such records be preserved. To the best of my knowledge, there's no statue on the books (at least at a federal level) which would mandate that a provider keep any records relating to dynamic IP allocations. -- Regards, Jake Mertel Nobis Technology Group, LLC *Web: *http://www.nobistech.net *Phone: *1-480-212-1710 *Mail:* 6930 East Chauncey Lane, Suite 150, Phoenix, AZ 85054 On Thu, Dec 12, 2013 at 9:07 AM, R. Scott Evans wrote: > I'm no lawyer but in the U.S., 18 USC 2703 appears to indicate this data > must be kept for at least 180 days. > > -Scott > > > On 12/12/13 06:34, Sam Moats wrote: > >> I'm not sure about the current state of the industry it's been a while >> since I was responsible for an access network. In the past we would keep >> radius logs for about 4 months, these would include the username,IP >> address and yes (to date myself) the caller id of the customer at the >> time. >> >> Sam Moats >> >> On 2013-12-12 03:49, Ray Wong wrote: >> >>> been a while, but seems like lately it's more a question of how long. >>> ISPs >>> can be in position where they need to, but as things have consolidated, >>> seems like they'd really like to forget it as soon as they can. If you've >>> got a specific case in mind, likely best to find a direct contact and >>> get a >>> response about policy, even if it has to be off-record. The big ones >>> (like >>> one I likely shouldn't mention by name unless they do as I don't work for >>> them) definitely do, at least long enough to handle DMCA requests and >>> other >>> legal obligations. >>> >>> -R> >>> >>> >>> On Wed, Dec 11, 2013 at 9:36 PM, Mikael Abrahamsson >>> wrote: >>> >>> On Wed, 11 Dec 2013, Carlos Kamtha wrote: >>>> >>>> just a general curiousity question. it's been a long time since ive >>>> >>>>> worked at an ISP. >>>>> >>>>> back then it was non-expiring DHCP leases and in some cases static >>>>> IP for >>>>> all.. (yes it was long ago..) >>>>> >>>>> Any feedback would be greatly appreciated.. >>>>> >>>>> >>>> Yes, it's very common to keep track of what user account/line had >>>> what IP >>>> at what time. >>>> >>>> -- >>>> Mikael Abrahamssonemail: swm...@swm.pp.se >>>> >>>> >>>> >> >> > >
RE: Global Blackhole Service
I think this solution addresses a number of issues that the current blackhole process lacks. Generally when a blackhole is sent to your provider, they in turn pass that on to the rest of their routers, dropping the traffic as soon as it hits their network. The traffic is still taking up just as much capacity up to that point. Were a system implemented as discussed, providers are able to prevent traffic that is known to be malicious from even exiting their network, which in the end works out better for everyone. -- Regards, Jake Mertel Nobis Technology Group, L.L.C. Web: http://www.nobistech.net/ Phone: (312) 281-5101 ext. 401 Fax: (808) 356-0417 Mail: 201 West Olive Street Second Floor, Suite 2B Bloomington, IL 61701 -Original Message- From: Christopher Morrow [mailto:morrowc.li...@gmail.com] Sent: Friday, February 13, 2009 1:59 PM To: NANOG list Subject: Re: Global Blackhole Service On Fri, Feb 13, 2009 at 1:04 PM, Jack Bates wrote: > Paul Vixie wrote: >> >> blackholing victims is an interesting economics proposition. you're >> saying >> the attacker must always win but that they must not be allowed to affect >> the >> infrastructure. and you're saying victims will request this, since they >> know >> they can't withstand the attack and don't want to be held responsible for >> damage to the infrastructure. > > Blackholing victims is what is current practice. For each stage of affected it is A current practice.. so is filtering, so is scrubbing... there is no one answer for this. > infrastructure, the business/provider will make requests to their peers to > blackhole the victim IP to protect the bandwidth caps or router throughput > caps. or cause no one really cares about: your.mama.wears.combat.boots.tobed.com ... or other silly 95%-of attacked, things. > >> >> where you lose me is where "the attacker must always win". > > Do you have a miraculous way to stop DDOS? Is there now a way to quickly and There are purchasable answers to this problem... 3 (at least) providers in the US (and at least one now offers it globally) offer traffic scrubbing services. I know that one offers it at a very reasonable price even... > efficiently track down forged packets? Is there a remedy to shutting down you can track streams of forged packets, but that's not super important here. Forged packets actually make this part of the problem (stopping the dos) easier, not harder. > the *known* botnets, not to mention the unknown ones? > there are lots of folks tracking and shutting down botnets, it's not horribly effective in stopping this sort of thing. I can vividly recall tracking down 4 nights in a row the same 'botnet' (same controller person, different C&C and mostly different bots) as they were being used to attack a customer of mine at the time. This with the cooperation of 2 other very large ISP's in the US and one vendor security team even. In the end though a simple scrubbing solution was deemed the simplest answer for all involved. > The attacker will always win if he has a large enough attack For extreme cases this is true, but there are quite a lot of things on the spectrum which don't require super human efforts, and don't even require intervention from the ISP if proper precautions are taken at the outset. -chris
RE: anyone else seeing very long AS paths?
Looks good here too tel...@edge1.chi.ubiquityservers.com(config)#show ip bgp 94.125.216.0/21 Number of BGP Routes matching display condition : 2 Status codes: s suppressed, d damped, h history, * valid, > best, i internal Origin codes: i - IGP, e - EGP, ? - incomplete NetworkNext HopMetric LocPrf Weight Path *> 94.125.216.0/2172.37.148.177 3 1000 25973 29113 47868 i * 94.125.216.0/2165.47.180.113 3 1000 2828 3257 29113 47868 i Regards, Jake Mertel Nobis Technology Group, L.L.C. Web: http://www.nobistech.net/ Phone: (312) 281-5101 ext. 401 Fax: (808) 356-0417 Mail: 201 West Olive Street Second Floor, Suite 2B Bloomington, IL 61701 -Original Message- From: John van Oppen [mailto:j...@vanoppen.com] Sent: Monday, February 16, 2009 11:25 AM To: Andy Davidson Cc: nanog@nanog.org Subject: RE: anyone else seeing very long AS paths? Yep we saw the same, every customer with old IOS had their sessions die to us at the same time... That always makes for an interesting time when watching the NMS system... We are seeing a much more sane path now: agg2-sea-A>show ip bgp 94.125.216.0/21 BGP routing table entry for 94.125.216.0/21, version 25944571 Paths: (1 available, best #1) Multipath: eBGP Advertised to update-groups: 2 3 5 6 7 8 9 3561 3356 29113 47868 208.76.153.96 (metric 5102) from 208.76.153.96 (208.76.153.96) Origin IGP, metric 0, localpref 50, valid, internal, best Community: 11404:1000 11404:1040 agg2-sea-A> John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -Original Message- From: Andy Davidson [mailto:a...@nosignal.org] Sent: Monday, February 16, 2009 9:10 AM To: John van Oppen Cc: Matt Liotta; nanog@nanog.org Subject: Re: anyone else seeing very long AS paths? Hi, Yep, we see them too. Nasty because there are lots of networks flapping as the long as-paths are tickling old bug CSCdr54230, so even networks not affected by the bug will be getting lots of extra updates. Anyone with contacts at 47868 ? Any upstreams onlist that want to bin them ? Andy
RE: Greedy Routing
I had to laugh when reading... This is how I think someone who doesn't "get" how the Internet works may try to re-explain what a researcher explained to them about how metrics influence the flow of traffic in BGP path selection. Regards, Jake Mertel Nobis Technology Group, L.L.C. Web: http://www.nobistech.net/ Phone: (312) 281-5101 ext. 401 Fax: (808) 356-0417 Mail: 201 West Olive Street Second Floor, Suite 2B Bloomington, IL 61701 -Original Message- From: Deepak Jain [mailto:dee...@ai.net] Sent: Wednesday, February 18, 2009 5:01 PM To: valdis.kletni...@vt.edu; Rod Beck Cc: nanog list Subject: RE: Greedy Routing > > Maybe there's some critical insight in the paper that Physorg managed > to totally not mention, I dunno. I saw it the same way... " As the researchers explain, some types of networks are not navigable. For instance, if the probability that two nodes are linked doesn't depend on the metric distance between them, then such networks are difficult to navigate, as there is no way to choose one node over another based on distance. But when there is a connection between the link existence probability and the hidden distance between nodes, metric distances can help to navigate the network, i.e., such networks are "navigable."" If your network doesn't calculate or use metrics or weights, or AS path lengths... then you are not able to throw packets like fairy dust to their intended destination. Worse, if you use metrics unrelated to distance (like link cost) you could actually send your packets the wrong way. It's funny, but I think they said that their math shows that the Internet works to generally route packets (to a shorter path) than other possible paths. I'm sure that will come as a surprise to all of us. Deepak Jain AiNET
RE: XO peering.
We had a number of issues in the Seattle area this morning, seemed to be isolated to traffic transiting via Level 3. We were forced to turn off the connection, and it's still disabled until we get an update from XO. -- Regards, Jake Mertel Nobis Technology Group, L.L.C. Web: http://www.nobistech.net/ Phone: (312) 281-5101 ext. 401 Fax: (808) 356-0417 Mail: 201 West Olive Street Second Floor, Suite 2B Bloomington, IL 61701 -Original Message- From: John Martinez [mailto:jmarti...@zero11.com] Sent: Tuesday, March 10, 2009 11:23 AM To: nanog@nanog.org Subject: Re: XO peering. We saw an issue with Level 3 hand off to XO in Chicago. Stefan Molnar wrote: > > There was a peering issue in San Jose with XO, that impacted our > operations this morning. But looks like a side effect is after the hand > off to NTT. > > Anyone who has an XO link can reach areas insdie NTT? > > As an example our route to Salesforce /21 is via NTT and it is not happy > right now. > > Thanks, > Stefan >
RE: XO peering.
I did some preliminary tests static-routing some prefixes that were not working earlier over our XO connection and everything seemed fine. I went ahead and turned the session back up, no reports of trouble yet. I'll update if we have any issues. -- Regards, Jake Mertel Nobis Technology Group, L.L.C. Web: http://www.nobistech.net/ Phone: (312) 281-5101 ext. 401 Fax: (808) 356-0417 Mail: 201 West Olive Street Second Floor, Suite 2B Bloomington, IL 61701 -Original Message- From: Kevin Oberman [mailto:ober...@es.net] Sent: Tuesday, March 10, 2009 2:41 PM To: Mort, Eric Cc: Jake Mertel; John Martinez; nanog@nanog.org Subject: RE: XO peering. On Tue, 2009-03-10 at 11:41 -0500, Mort, Eric wrote: > We had some hardware issues in San Jose which triggered some other > ugliness. We believe we have the issues mitigated at this time. > Folks still seeing issues are encouraged to hit me up offline. > > Thanks, > > Eric J. Mort > XO Communications > Sr. Manager - IP Operations > Desk - 314-787-7826 > Cell - 314.486-9057 > em...@xo.com > > > -Original Message- > From: Jake Mertel [mailto:j...@nobistech.net] > Sent: Tuesday, March 10, 2009 11:34 AM > To: John Martinez; nanog@nanog.org > Subject: RE: XO peering. > > We had a number of issues in the Seattle area this morning, seemed to > be isolated to traffic transiting via Level 3. We were forced to turn > off the connection, and it's still disabled until we get an update from XO. > > > -- > Regards, > > Jake Mertel > Nobis Technology Group, L.L.C. > > > > Web: http://www.nobistech.net/ > Phone: (312) 281-5101 ext. 401 > Fax: (808) 356-0417 > > Mail: 201 West Olive Street > Second Floor, Suite 2B > Bloomington, IL 61701 > > > -Original Message- > From: John Martinez [mailto:jmarti...@zero11.com] > Sent: Tuesday, March 10, 2009 11:23 AM > To: nanog@nanog.org > Subject: Re: XO peering. > > We saw an issue with Level 3 hand off to XO in Chicago. > > Stefan Molnar wrote: > > > > There was a peering issue in San Jose with XO, that impacted our > > operations this morning. But looks like a side effect is after the > hand > > off to NTT. > > > > Anyone who has an XO link can reach areas insdie NTT? > > > > As an example our route to Salesforce /21 is via NTT and it is not > happy > > right now. > > > > Thanks, > > Stefan > > > > > > > > > No joy from our (AS293) perspective. I still see traffic to XO at SJ black-holed. eqx-sj-rt1-re1> traceroute 198.17.75.45 traceroute to 198.17.75.45 (198.17.75.45), 30 hops max, 40 byte packets ^C Works fine from Ashburn, though. I've pref'ed XO down at SJ until it is working again. -- R. Kevin Oberman Energy Sciences Network (ESnet) Ernest Orlando Lawrence Berkeley National Laboratory (Berkeley Lab) E-Mail: ober...@es.net Phone: +1 510-486-8634
Where to put our router
Good afternoon (or whatever it is for you ;), We have just finished moving a large amount of equipment to a new facility outside of downtown Chicago. At present we have an uplink via a point-to-point to Equinox downtown. We are preparing to add another provider, and are debating where we should put our router. The two options would be in Equinox downtown (co-located with our existing provider) or at the new facility. Were we to do the former we would turn our existing point-to-point into our connection from our edge router to our distribution switch and add a second point-to-point for redundancy from the distro switch back to the router. Were we to do the latter we would get a second point-to-point direct from our new provider to their network and connect it to our router where it is now. The major advantage I can think of to having it in Equinox is the availability of cross connects to just about anyone. There are a few providers in the new facility, but not many. The major disadvantage is that if we suddenly need a large amount of transport (i.e. a new large client, a definitive short-term possibility) we would either need to get a new or additional point-to-point from downtown to the facility or would need to get another router to utilize at the new facility (were we to meet up with one of the in-building providers instead of getting the point-to-point transport). Any thoughts related to the advantages or disadvantages of doing one or the other would be greatly appreciated. Thanks in advance. Kind regards, Jake Mertel Nobis Technology Group, L.L.C.
Re: Identifying when netblocks have been assigned
Frank, Add the > operator in front of the organizations ARIN ID when you do your WHOIS query and it will show all of the resources allocated to that organization. -- Regards, Jake Mertel Nobis Technology Group, L.L.C. Frank Bulk wrote: Perhaps there's no answer to this, or it's obvious and I ought to know. How can I find out when ARIN or the applicable registry has assigned a block to a certain organization, and I don't know the block, just the organization. If that's not possible, is there a site/way that has a timeline for the first time a certain AS announced a block? Frank
