RE: Recommended 10GE ISCSI SAN switch
If price is a major concern, take a look at the Force10 S2410. They tend to go for under $2k on ebay. Very basic L2 cut-through low-latency switch. Only drawback is your choice is XFP or CX4 for ports, but if you have server nics with CX4 then you are off the races for very little money. Whatever switch you use, don't forget to adjust MTU to 9k+. +1 for SSD based storage, if you are using a vmware environment the newer versions of vsan support all-flash-arrays, worth taking a look at. Sk. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Matt Taylor Sent: Tuesday, May 12, 2015 9:36 PM To: nanog@nanog.org Subject: Re: Recommended 10GE ISCSI SAN switch We've been using Dell 8024F's for over 2 years now. No problems at all. On 12/05/2015 23:36, Paul S. wrote: > Hi guys, > > We're shortly going to be getting some 10G SANs, and I was wondering > what people were using as SAN switches for 10G SANs. > > It is my understanding that low buffer sizes make most 'normal' 10G > ethernet switches unsuitable for the job. > > We're pretty much an exclusive Juniper shop, but are not biased in any > way -- best tool for the job is what I've been tasked with to find. > > Keeping that in mind, how would something like a EX4550 fare in the > role? Are there better devices in the same price range? > > Thanks!
Network Solutions blacklisted mail
Has anyone had any luck in getting a clued individual from NS to contact them concerning blacklist removal? I am going on four days and still spinning my wheels despite multiple contacts claiming it would be handled.
Akamai minimum prefix length issue
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: Akamai minimum prefix length issue
Akamai does not follow BGP perfectly, for many reasons, including BGP preferring crappy paths much of the time. ISPs should email netsupport-...@akamai.com to get help with traffic engineering, performance, and other questions. (Or at least that used to be the case a year ago.) -- TTFN, patrick > On May 13, 2015, at 15:33 , 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: 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: Akamai minimum prefix length issue
Akamai does not do this. -- TTFN, patrick > On May 13, 2015, at 15:42 , Jake Mertel wrote: > > 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: Rasberry pi - high density
On 05/11/2015 06:50 PM, Brandon Martin wrote: 8kW/rack is something it seems many a typical computing oriented datacenter would be used to dealing with, no? Formfactor within the rack is just a little different which may complicate how you can deliver the cooling - might need unusually forceful forced air or a water/oil type heat exchanger for the oil immersion method being discussed elsewhere in the thread. You still need giant wires and busses to move 800A worth of current. ... This thread brings me back to 1985, what with talk of full immersion cooling (Fluorinert, anyone?) and hundreds of amps at 5VDC reminds me of the Cray-2, which dropped 150-200KW in 6 rack location units of space; 2 for the CPU itself, 2 for space, and 2 for the cooling waterfall [ https://en.wikipedia.org/wiki/File:Cray2.jpeg by referencing floor tile space occupied and taking 16 sq ft (four tiles) as one RLU ]. Each 'stack' of the CPU pulled 2,200A at 5V [source: https://en.wikipedia.org/wiki/Cray-2#History ]. At those currents you use busbar, not wire. Our low-voltage (120/208V three-phase) switchgear here uses 6,000A rated busbar, so it's readily available, if expensive.
Re: Akamai minimum prefix length issue
Hi Patrick, Correct answer. No surprise. And yes, netsupport-...@akamai.com is still the way to go for these types of issues. Thanks for the help! Best, -M< // AS 20940 On Wed, May 13, 2015 at 3:37 PM, Patrick W. Gilmore wrote: > Akamai does not follow BGP perfectly, for many reasons, including BGP > preferring crappy paths much of the time. > > ISPs should email netsupport-...@akamai.com to get help with traffic > engineering, performance, and other questions. (Or at least that used to be > the case a year ago.) > > -- > TTFN, > patrick > > > On May 13, 2015, at 15:33 , 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 > > > > > > > >
Is anyone working on an RFC for standardized maintenance notifications
Like the "Automated Copyright Notice System" (http://www.acns.net/spec.html) except I don't think they went through any official standards body besides their own MPAA, or whatever. I get circuits from several vendors and get maintenance notifications from them all the time. Each has a different format and each supplies different details for their maintenance. Most of the time there are core things that everyone wants and it would be nice if it were automatically readable so automation could be performed (i.e., our NOC gets the email into our ticketing system. It is recognized as being part of an existing maintenance due to maintenance id# (or new, whatever) and fields are automatically populated or updated accordingly. If you're uncomfortable with the phrase "automatically populated accordingly" for security reasons then you can replace that with "NOC technician verifies all fields are correct and hits update ticket." or whatever. The main fields I think you would need: 1. Company Name 2. Maintenance ID 3. Start Date 4. Expected length 5. Circuits impacted (if known or applicable) 6. Description/Scope of Work (free form) 7. Ticket Number 8. Contact
Re: Is anyone working on an RFC for standardized maintenance notifications
Hi Robert, I'm not aware of an RFC for standardized maintenance notifications. A group of people are currently working on a NANOG BCOP for maintenance notifications. Many of the fields you list match those we've identified as critical for inclusion in any maintenance notification. Most of the discussion takes place via a group on Facebook: https://www.facebook.com/groups/85573849323/ We also have bi-weekly conference calls. If you (or anyone else) are interested in participating, contact me off list and I'll get you caught up on our work so far. Erik On Tue, May 12, 2015 at 8:19 AM, Robert Drake wrote: > Like the "Automated Copyright Notice System" (http://www.acns.net/spec.html) > except I don't think they went through any official standards body besides > their own MPAA, or whatever. > > I get circuits from several vendors and get maintenance notifications from > them all the time. Each has a different format and each supplies different > details for their maintenance. Most of the time there are core things that > everyone wants and it would be nice if it were automatically readable so > automation could be performed (i.e., our NOC gets the email into our > ticketing system. It is recognized as being part of an existing maintenance > due to maintenance id# (or new, whatever) and fields are automatically > populated or updated accordingly. > > If you're uncomfortable with the phrase "automatically populated > accordingly" for security reasons then you can replace that with "NOC > technician verifies all fields are correct and hits update ticket." or > whatever. > > The main fields I think you would need: > > 1. Company Name > 2. Maintenance ID > 3. Start Date > 4. Expected length > 5. Circuits impacted (if known or applicable) > 6. Description/Scope of Work (free form) > 7. Ticket Number > 8. Contact >
