Frontier AS5650 IPv6 Peering
Anyone with a clue from 5650 monitoring this list? I'm in the process of turning up a new transit circuit from 5650 and my account management team has been less than helpful. The normal contacts aren't getting me anywhere. Thank you!
Re: Anyone got a contact at OpenAI. They have a spider problem.
On Thu, Apr 11, 2024 at 3:40 PM Randy Bush wrote: > > Amazon's spider got stuck there a month or two ago but fortunately I was > > able to find someone to pass the word and it stopped. Got any contacts > > at OpenAI? > > why? you are doing a societal good by ensnaring them. dig a deeper > hole. > > randy > Yeah. Who should we donate compute resources to so that we can further this project?
Re: 365 Datacenters Tampa AC Failure
James, Any word on how redundant systems failed at the same time? Or why the secondary was untested and not known-working? It seems like HVAC maintenance was done by the night crew which was quietly eliminated at some point. On Tue, Jun 13, 2023 at 12:02 AM James Ashton wrote: > Hello all, > From our side (365 Data Centers) We saw the issue start at a little after > 6:30 PM yesterday. We had a component failure and we saw a rise in > temperature. We brought additional capacity online while we were working > with our vendors on getting replacement hardware. > The hardware has now been replaced and the system is back online. > This unit and others in this suite are on the block for replacement this > year as we add cooling capacity to our various spaces within the Franklin > Exchange building. > > On a side note, this was not related to the issue mentioned from earlier > in the month. This was a straight component failure and replacement. > > Any customers impacted can reach out to the 365 Customer Service Center > for details and documentation. > > Thank you, > James Ashton > VP Network Engineering > 365 Data Centers > > > > -- > *From: *"NANOG mailing list" > *To: *"George Herbert" > *Cc: *"NANOG mailing list" > *Sent: *Monday, June 12, 2023 8:03:10 PM > *Subject: *Re: 365 Datacenters Tampa AC Failure > > Issue started a little after 2am, I was hard down till about 11:30am > (servers did a high temp shutdown) > > On Jun 12, 2023 8:01 PM, Michael Spears wrote: > > Yep there's issues over there. They had some compressors go down. Should > be getting back to normal now... Hasn't been a good month for them in > regards to cooling.. > > On Jun 12, 2023 7:15 PM, George Herbert wrote: > > Oof. Get ready to replace all spinning media you may have there. > > -George > > Sent from my iPhone > > > On Jun 12, 2023, at 4:06 PM, Nick Olsen wrote: > > > > > > Just a heads up to anyone else colo'd at 365 TPA1/TAMSFLDE. Currently > seeing floor temps of ~105F as reported by equipment. Started yesterday at > ~5:30PM eastern. 2nd AC failure in the last 30 days. They have not sent any > advisory notices as of yet. > > > >
365 Datacenters Tampa AC Failure
Just a heads up to anyone else colo'd at 365 TPA1/TAMSFLDE. Currently seeing floor temps of ~105F as reported by equipment. Started yesterday at ~5:30PM eastern. 2nd AC failure in the last 30 days. They have not sent any advisory notices as of yet.
Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging
Not that it's a "Fix" but have you tried rebooting the box? If this is a bug in the forwarding plane that might clear/rebuild it. And maybe it works correctly after that. Friend saw something similar on a Juniper MX with DPC cards that had run out of FIB space. It would show correctly in all places, but was failing to install in FIB (Router cut a error about it in the log). So the actual traffic didn't follow the same path. I saw you specifically referenced "forwarding" in one of your copy pastes. And it looked right. But I don't know enough about Cisco to say if that's really what is in FIB. Or just what it thinks is in FIB. On Tue, Apr 4, 2023 at 5:47 PM Mike Hammett wrote: > Via all mechanisms I could find in the router, it thinks the best path is > the direct path, the packets just don't go that way. > > The in traffic isn't a concern at this time, just the out (from my > perspective). > > > > - > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > -- > *From: *"David Bass" > *To: *"Mike Hammett" > *Cc: *"Matthew Huff" , "NANOG" > *Sent: *Tuesday, April 4, 2023 11:39:26 AM > *Subject: *Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging > > If you are both connected to the same upstream, but the customer wants > traffic destined to the upstream to go through you (in and out), then they > need to do something on their devices to try and affect the inbound path to > their AS. From the upstream carrier in question they’ll take the best path > to a prefix, which direct connection is generally going to be preferred > over a transit AS (basic BGP best path algorithm stuff) unless there is > some manipulation of the prefix advertisement happening. > > To confirm the path being taken you should be able to do a few trace > routes from various locations as well as use looking glasses. > > Now the sflow data is an entirely different thing to analyze. > > On Tue, Apr 4, 2023 at 7:45 AM Mike Hammett wrote: > >> >> sh ip bgp neighbor advertised-routes shows the only routes being >> advertised to Y are the routes that should be advertised to them. I checked >> a variety of other peers and have the expected results. >> >> >> >> From my perspective: >> >> Packets come in on port A, supposed to leave on port X, but they leave on >> port Y. All of the troubleshooting steps I've done on my own (or suggested >> by mailing lists) say the packets should be leaving on the desired port X. >> >> >> From the customer's perspective, they're supposed to be coming from me on >> port X, but they're arriving on port Y, another network. >> >> Port X in both scenarios is our direct connection, while port Y is a >> mutual upstream provider. >> >> >> Without knowing more about the specific platform, it seems to me like a >> bug in the platform. If all indicators (not just configurations, but show >> commands as well) say the packet should be leaving on X and it leaves on Y, >> then I'm not sure what else it could be, besides a bug. >> >> >> >> - >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> -- >> *From: *"David Bass" >> *To: *"Mike Hammett" >> *Cc: *"Matthew Huff" , "NANOG" >> *Sent: *Monday, April 3, 2023 9:12:52 PM >> >> *Subject: *Re: Cisco Nexus 3k Route Selection\Packet Forwarding Debugging >> >> You said that they are seeing traffic from another upstream…are you >> advertising the prefix to them? Are you advertising their prefix to your >> upstream? >> >> Looks like the route maps are involved in some dual redistribution…might >> want to make sure everything is matching correctly, and being advertised >> like you want. >> >> On Mon, Apr 3, 2023 at 4:20 PM Mike Hammett wrote: >> >>> I don't see any route-maps applied to interfaces, so there must not be >>> any PBR going on. I only see ACLs, setting communities, setting local pref, >>> etc. in the route maps that are applied to neighbors. >>> >>> >>> >>> - >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> Midwest-IX >>> http://www.midwest-ix.com >>> >>> -- >>> *From: *"Mike Hammett" >>> *To: *"Matthew Huff" >>> *Cc: *"NANOG" >>> *Sent: *Monday, April 3, 2023 8:26:30 AM >>> >>> *Subject: *Re: Cisco Nexus 3k Route Selection\Packet Forwarding >>> Debugging >>> >>> Only two VRFs, default and manangement. IIRC, everything I saw before >>> mentioned the default VRF. >>> >>> I do see a ton of route-maps. It's mostly Greek to me, so I'll have to >>> dig through this a bit to see what's going on. >>> >>> >>> >>> - >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> Midwest-IX >>> http://www.midwest-ix.com >>> >>> -- >>> *From: *"Matthew Huff" >>> *To: *"Mike Hammett" >>> *Cc: *"NANOG" >>> *Sent: *Monday, April 3, 2023
Re: Strange behavior on the Juniper MX240
Nehul, He was running the 15 code train. I think 15.1R6.7. But don't take that as fact. I just know it was 15 for sure. From: Nehul Patel Sent: Thursday, May 5, 2022 6:40 PM To: Nick Olsen Cc: nanog@nanog.org Subject: Re: Strange behavior on the Juniper MX240 Hi Nick, Thank you for the feedback on it. Would you please let me know which Juno OS version he had installed on the MX Chassis that works with the extended memory command of it? On Thu, May 5, 2022 at 12:50 PM Nick Olsen mailto:n...@141networks.com>> wrote: Friend of mine had this issue recently on an MX chassis running DPC's and RE-2000's. The extend memory command others have mentioned worked for him. His instance drove us crazy for a bit. The device would learn a route, show that it was installed (show routes) but traffic to said prefix would bounce net unreachable. We even pushed a static just for S's and that still didn't resolve it. It was a single prefix that a customer had reported. Some things to consider, as others have mentioned. 1. IPv6 routes share the same space. And use more per-route. You can extend the life of this box (probably considerably) by dropping full tables for IPv6. Perhaps taking just a default (Same goes for v4). 2. It seems from your previous output that you're taking ~1 full v4 table. And 2x v6 tables. Do you really need a full table if you're only taking 1 v4 table? Consider switching to a default only? In my Colleagues case, he was taking 2 full tables of v4 and v6 until he hit the same issue. 3. While you're RE's could use a nice upgrade too. Your linecards are actually the problem here. If you move to anything > DPC you get the trio chipset with much more FIB space (2 Million routes I believe?). I'd consider new RE's and new line cards for this box. Which might also mean new switch fabric controllers Basically, we'd be talking a full overhaul sans the power supplies and chassis. 4. Consider taking a default + full routes. Then filtering > /24 (if you even have anything < /24 learned now) (/48 on IPv6). Start with the memory command first and see where that gets you. But keep a watchful eye out for this to happen again (as the DFZ grows). Eventually your only option will be to filter routes and rely on a default or upgrade. From: NANOG mailto:141networks@nanog.org>> on behalf of Nehul Patel mailto:nehul.pa...@gmail.com>> Sent: Wednesday, May 4, 2022 3:56 PM To: nanog@nanog.org<mailto:nanog@nanog.org> mailto:nanog@nanog.org>> Subject: Strange behavior on the Juniper MX240 Hi NANOG, We are seeing some strange behavior on our Juniper MX240 Chassis it is randomly dropping the routes to the certain destination IP address getting the following errors on the MX240 Chassis If Someone has seen these errors before please suggest how to resolve it May 4 12:42:00 cr01 newsyslog[44735]: logfile turned over due to size>1024K May 4 12:42:01 /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 (Invalid) May 4 12:42:01 /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, err 5 (Invalid) May 4 12:42:01 last message repeated 4 times May 4 12:42:01 fpc0 RT: IPv6:0 - 2600:40fc:1011::/48 (add rt entry into jtree failed) May 4 12:42:01 fpc0 RT-HAL,rt_entry_add_msg_proc,2028: rt_halp_vectors->rt_create failed May 4 12:42:01 fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv6,len 48 prefix 2600:40fc:1011::/48 nh 1048576 May 4 12:42:01 fpc0 RT-HAL,rt_msg_handler,540: route process failed May 4 12:42:01 fpc0 RT: Failed prefix add IPv6 - 2001:67c:20fc::/48 (No memory) on FE 0 May 4 12:42:01 fpc0 RT: IPv6:0 - 2001:67c:20fc::/48 (add rt entry into jtree failed) May 4 12:42:01 fpc0 RT-HAL,rt_entry_add_msg_proc,2028: rt_halp_vectors->rt_create failed May 4 12:42:01 fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv6,len 48 prefix 2001:67c:20fc::/48 nh 1048576 May 4 12:42:01 fpc0 RT-HAL,rt_msg_handler,540: route process failed May 4 12:42:01 fpc0 RT: Failed prefix add IPv6 - 2606:2800:e004::/48 (No memory) on FE 0 May 4 12:42:01 fpc0 RT: Failed prefix add IPv6 - 2a05:3181:::/48 (No memory) on FE 0 May 4 12:42:01 /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, err 5 (Invalid) May 4 12:42:01 /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 (Invalid) May 4 12:42:01 /kernel: RT_PFE: RT msg op 2 (PREFIX DELETE) failed, err 5 (Invalid) May 4 12:42:02 fpc0 RT: Failed prefix add IPv4 - 79.120.22/24 (No memory) on FE 0 May 4 12:42:02 fpc0 RT: IPv4:0 - 79.120.22/24 (add rt entry into jtree failed) May 4 12:42:02 fpc0 RT-HAL,rt_entry_add_msg_proc,2028: rt_halp_vectors->rt_create failed May 4 12:42:02 fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv4,len 24 prefix 79.120.22/24 nh 1048583 May 4 12:42:02 /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 (Invalid) May
Re: Strange behavior on the Juniper MX240
Friend of mine had this issue recently on an MX chassis running DPC's and RE-2000's. The extend memory command others have mentioned worked for him. His instance drove us crazy for a bit. The device would learn a route, show that it was installed (show routes) but traffic to said prefix would bounce net unreachable. We even pushed a static just for S's and that still didn't resolve it. It was a single prefix that a customer had reported. Some things to consider, as others have mentioned. 1. IPv6 routes share the same space. And use more per-route. You can extend the life of this box (probably considerably) by dropping full tables for IPv6. Perhaps taking just a default (Same goes for v4). 2. It seems from your previous output that you're taking ~1 full v4 table. And 2x v6 tables. Do you really need a full table if you're only taking 1 v4 table? Consider switching to a default only? In my Colleagues case, he was taking 2 full tables of v4 and v6 until he hit the same issue. 3. While you're RE's could use a nice upgrade too. Your linecards are actually the problem here. If you move to anything > DPC you get the trio chipset with much more FIB space (2 Million routes I believe?). I'd consider new RE's and new line cards for this box. Which might also mean new switch fabric controllers Basically, we'd be talking a full overhaul sans the power supplies and chassis. 4. Consider taking a default + full routes. Then filtering > /24 (if you even have anything < /24 learned now) (/48 on IPv6). Start with the memory command first and see where that gets you. But keep a watchful eye out for this to happen again (as the DFZ grows). Eventually your only option will be to filter routes and rely on a default or upgrade. From: NANOG on behalf of Nehul Patel Sent: Wednesday, May 4, 2022 3:56 PM To: nanog@nanog.org Subject: Strange behavior on the Juniper MX240 Hi NANOG, We are seeing some strange behavior on our Juniper MX240 Chassis it is randomly dropping the routes to the certain destination IP address getting the following errors on the MX240 Chassis If Someone has seen these errors before please suggest how to resolve it May 4 12:42:00 cr01 newsyslog[44735]: logfile turned over due to size>1024K May 4 12:42:01 /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 (Invalid) May 4 12:42:01 /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, err 5 (Invalid) May 4 12:42:01 last message repeated 4 times May 4 12:42:01 fpc0 RT: IPv6:0 - 2600:40fc:1011::/48 (add rt entry into jtree failed) May 4 12:42:01 fpc0 RT-HAL,rt_entry_add_msg_proc,2028: rt_halp_vectors->rt_create failed May 4 12:42:01 fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv6,len 48 prefix 2600:40fc:1011::/48 nh 1048576 May 4 12:42:01 fpc0 RT-HAL,rt_msg_handler,540: route process failed May 4 12:42:01 fpc0 RT: Failed prefix add IPv6 - 2001:67c:20fc::/48 (No memory) on FE 0 May 4 12:42:01 fpc0 RT: IPv6:0 - 2001:67c:20fc::/48 (add rt entry into jtree failed) May 4 12:42:01 fpc0 RT-HAL,rt_entry_add_msg_proc,2028: rt_halp_vectors->rt_create failed May 4 12:42:01 fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv6,len 48 prefix 2001:67c:20fc::/48 nh 1048576 May 4 12:42:01 fpc0 RT-HAL,rt_msg_handler,540: route process failed May 4 12:42:01 fpc0 RT: Failed prefix add IPv6 - 2606:2800:e004::/48 (No memory) on FE 0 May 4 12:42:01 fpc0 RT: Failed prefix add IPv6 - 2a05:3181:::/48 (No memory) on FE 0 May 4 12:42:01 /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, err 5 (Invalid) May 4 12:42:01 /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 (Invalid) May 4 12:42:01 /kernel: RT_PFE: RT msg op 2 (PREFIX DELETE) failed, err 5 (Invalid) May 4 12:42:02 fpc0 RT: Failed prefix add IPv4 - 79.120.22/24 (No memory) on FE 0 May 4 12:42:02 fpc0 RT: IPv4:0 - 79.120.22/24 (add rt entry into jtree failed) May 4 12:42:02 fpc0 RT-HAL,rt_entry_add_msg_proc,2028: rt_halp_vectors->rt_create failed May 4 12:42:02 fpc0 RT-HAL,rt_entry_add_msg_proc,2092: proto ipv4,len 24 prefix 79.120.22/24 nh 1048583 May 4 12:42:02 /kernel: RT_PFE: RT msg op 1 (PREFIX ADD) failed, err 5 (Invalid) May 4 12:42:02 fpc0 RT-HAL,rt_msg_handler,540: route process failed May 4 09:33:17 fpc0 RSMON: Resource Category:jtree Instance:jtree2-seg0 Type:free-pages Available:20 is less than LWM limit:1638, rsmon_syslog_limit() May 4 09:33:17 fpc0 RSMON: Resource Category:jtree Instance:jtree2-seg0 Type:free-dwords Available:1280 is less than LWM limit:104857, rsmon_syslog_limit() May 4 09:33:18 fpc0 RSMON: Resource Category:jtree Instance:jtree3-seg0 Type:free-pages Available:19 is less than LWM limit:1638, rsmon_syslog_limit() May 4 09:33:18 fpc0 RSMON: Resource Category:jtree Instance:jtree3-seg0 Type:free-dwords Available:1216 is less than LWM limit:104857, rsmon_syslog_limit() May 4 09:33:18 fpc1 RSMON:
Re: SITR/SHAKEN implementation in effect today (June 30 2021)
Not all have implemented it yet. But if you haven't. You were supposed to implement some kind of robo calling mitigation plan (Or atleast certify that you have one). At $dayjob we're fully deployed (inbound and outbound). I received my first ever STIR/SHAKEN signed (iPhone Check mark, highly scientific) spam call on my personal Cell phone on 6/30. It was a Telnyx number. Had the call terminated to $dayjob network. I fully would have collected all various information and ticketed it with Telnyx. Time will tell how truly effective this is. But we have better originating information now (breadcrumbs) to follow back to the source. On Thu, Jul 1, 2021 at 5:42 PM Andreas Ott wrote: > > > On Thu, Jul 1, 2021 at 12:56 PM Keith Medcalf wrote: > >> ... and the end carrier is making money for terminating them. > > > Survey (of n=1) says: nothing has changed, aka the new technology is not > working. I just received the same kind of recorded message call of > "something something renew auto warranty" on my AT u-Verse line. This > time when I called back the displayed caller ID number it was > ring-no-answer, versus the previous "you have reached a number that is no > longer in service". By terminating the call the carrier made probably more > money than it would cost them to enforce the new rules. > > Other than the donotcall.gov portal, is there a new way to report the > obvious failure of STIR/SHAKEN? > > -andreas >
Re: Frontier Tampa issues
Nail on the head, David. I've got ~3 dozen IPSEC connections that land back at our DC. Only a few were affected. Some physically near each other...etc No rhyme or reason to the selection. So LAG hashing makes perfect sense. Due to the moderator queue, my message was delayed. It started around Noon Saturday. As of this morning (monday), It's resolved. I did spend about an hour trying to get a ticket in. And did, but never heard back. Took me about a half-hour to convince the rep I didn't want someone dispatched. Yes, In this case the AS path was 5650>6939>Me. However, The return is Me>174>3356>5650. 5650 and 6939 peer across the FL-IX in MIA. But 6939 isn't accepting any routes from 5650 on that session. After talking to HE about it, They claim it's intentionally filtered due to capacity issues on the port, Waiting for 5650 to augment. Sounds like the classic peering staring contest to me. It was nice for a while. And kept us out of trouble during the last "nationwide" level 3 outage. As all other paths crossed 3356. Given the outbound route from the Frontier circuit didn't touch level 3 (in my case). And that's where my loss was occurring (What left the CPE, never made it to my 6939 port). It doesn't look like this was specific to a LAG between 5650 and 3356 though. On Sun, Jan 24, 2021 at 9:19 PM David Hubbard wrote: > Yes, exactly same issue for us, and it has happened in the past a few > years ago fortunately. Any chance the route takes a Level 3 (3356) path? > I’m just theorizing here, but my belief is they have some kind of link > aggregation in the path from TB to 3356 (or maybe just internal near some > edge) and some traffic is getting hashed onto a problematic > link/interface/linecard, etc. where IPSec gets dropped. One of our > locations lost IPSec ability to some normal VPN endpoints but not others. > And here’s why I think this is the issue…. if you change the source and/or > destination IP address by one, you may find some or all of your sessions > magically work again. > > > > In our case, one of our office locations has a static assignment of > (fortunately) five IP’s. We only have one external exposed, four site to > site VPN’s. Two began failing Saturday morning. I moved the office > firewall’s external IP minus 1 and that fixed both, but broke one that had > been fine. On the remote end fortunately I have equipment that’s able to > override the local IP for VPN traffic, so without impacting other things it > talks to, I was able to add a new IP one off from the previous, and use > that for traffic just to this office location; that fixed the remaining > issue. > > > > If I’d not seen this previously several years ago, and wasted who knows > how many hours trying to figure it out, it would have once again taken > forever to resolve. Trying to get through their support layer to someone > who can really help is impossible. The support is really complete garbage > at this point after the Verizon dump; I was going to say service, but > that’s been stable outside of these random weird issues that are impossible > to resolve with support. > > > > I tried to be a nice guy and raise this through the support channels, but > could not make it past the layer where they want me to take our office down > to have someone plug a laptop in with our normal WAN IP and “prove” ipsec > isn’t working with different equipment. I was like dude I just told you > what I did to get it working again, offered packet captures, just escalate > it, but ultimately gave up and hung up. > > > > David > > > > *From: *NANOG on > behalf of Nick Olsen > *Date: *Sunday, January 24, 2021 at 8:42 PM > *To: *"nanog@nanog.org" > *Subject: *Frontier Tampa issues > > > > Anyone else seeing weird things on Tampa/Bradenton FIOS connections? > > > > I've got three unrelated customers that cant establishes IPsec back to me. > > > > And a third that can't process credit cards out to their third party > merchant. > > > > Customers are in 47.196.0.0/14. > > > > In All instances, I see the traffic leave the CPE behind the FIOS circuit. > The IPSEC traffic never makes it to my DC. And no clue on the credit card > traffic. But it goes un-ack'd > > > > And just now a fifth has appeared that can't query DNS against 8.8.8.8. > Responses go out and never come back. > > > > The first four all started around noon today. >
Frontier Tampa issues
Anyone else seeing weird things on Tampa/Bradenton FIOS connections? I've got three unrelated customers that cant establishes IPsec back to me. And a third that can't process credit cards out to their third party merchant. Customers are in 47.196.0.0/14. In All instances, I see the traffic leave the CPE behind the FIOS circuit. The IPSEC traffic never makes it to my DC. And no clue on the credit card traffic. But it goes un-ack'd And just now a fifth has appeared that can't query DNS against 8.8.8.8. Responses go out and never come back. The first four all started around noon today.
Re: DSLAMs
Not sure about 320+ ports. But I've used the Huawei MA5616 with decent success. They've got 32 port ADSL2+ (And VDSL) line cards that give you 128 ports per chassis. POTS passthrough per card. Don't expect any support. Pretty sure they're not intended for the US market. On Tue, Dec 31, 2019 at 10:26 AM Nick Edwards wrote: > Howdy y'all > > Chasing some info, does dlink still sell DAS4672 - 672 port adsl2+ dslams? > > after simple IP based units with pppoe pass through. > We could buy a bunch of planet 48 ports, which we used before, but we > hoping someone still puts out high capacity (320 plus port) units with > inbuilt pots splitters > > thanks >
Re: Protecting 1Gb Ethernet From Lightning Strikes
This. Very little will protect you from a direct strike. Working for a WISP for a long time as a past life, I've seen radios physically split in half. Chunks of concrete taken out of walls near the equipment. Black ethernet ports that have functionally soldered themselves into the jack. Six figures worth of lost gear over the years (Does sound like much, But at ~$80 a pop for cheap wisp gear. That's a lot of equipment.) Outside of a direct strike, You can still melt gear left and right. The fix is no one solution, But multiple. 1. Shielded Ethernet with proper shielded and bonded ends. 2. Proper Grounding 3. Ethernet Surge Suppressors. 4. Proper Grounding. 5. Proper Grounding. The key is to make your sensitive electronic equipment a higher resistance path instead of your grounding system. You're going to get inductance build up on cables you just have to get it to ground through something that isn't your site switch/router. And it's going to get there one way or another. Sometimes this can be harder then one might think. Even considering sinking your own ground rod, And replacing it every few years. As a ground rod becomes less and less effective with every strike (Depending on what it's sunk in). Ethernet Surge Suppressors CAN help. But only in assisting in getting whatever was already on the cable to ground. And don't forget ground potential differences between different grounding systems. Doing the above will get you through most near by strikes. But all bets are off on direct strikes. The above can also help you with a ton of other interference. Like a giant FM transmitter running at 100KW a stones throw away from your equipment but that's another story for another thread. On Wed, Aug 14, 2019 at 1:34 PM Chris Knipe wrote: > Think surge protectors will protect against strikes that is far away, and > the residual surge it creates. > > A direct strike? Don't think there's anything that will really protect > against that. > > On Wed, Aug 14, 2019 at 7:29 PM wrote: > >> >> Are "surge protectors" really of much use against lightning? I suspect >> not, other than minor inductions tho perhaps some are specially >> designed for lightning. I wouldn't assume, I'd want to see the word >> "lightning" in the specs. >> >> I once had a lightning strike (at Harvard Chemistry), probably just an >> induction on a wire some idiot had strung between building roofs (I >> didn't even know it existed) and the board it was attached to's solder >> was melted and burned, impressive! More impressive was the board >> mostly worked, it was just doing some weird things which led me to >> inspect it...oops. >> >> My understanding was that the only real protection is an "air gap", >> which a piece of fiber will provide in essence, and even that better >> be designed for lightning as it can leap small gaps. >> >> Check your insurance, including the deductibles, keep spares on hand. >> >> P.S. My grandmother would tell a story about how what sounded like the >> ever-controversial "ball lightning" came into her home when she was >> young. Good luck with that! >> >> https://en.wikipedia.org/wiki/Ball_lightning >> >> -- >> -Barry Shein >> >> Software Tool & Die| b...@theworld.com | >> http://www.TheWorld.com >> Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD >> The World: Since 1989 | A Public Information Utility | *oo* >> > > > -- > > Regards, > Chris Knipe >
Re: UK, NL, & Asia LTE Providers for Opengear Console Servers
I've got a line on my Fi account that almost exclusively roams in the UK. Only been on-net in the US a few times and they've never complained about excessive roaming. It roams on 3UK. And works fine. Albeit the LTE deployment isn't near as wide there as it is in the US. And you end up on HSDPA pretty frequently. On Thu, Aug 1, 2019 at 10:04 AM Matt Corallo wrote: > When using a data-only Fi SIM (which are free if you have an account, just > pay the bandwidth), they always just act as a T-Mobile US MVNO and route > back through the US. Still, latency aside, I've found it incredibly > reliable (plus in many countries you can pick from multiple networks). > > If you have an Android phone it may switch to 3UK/Hutch's global network, > though I have less experience with that. > > Matt > > > On Aug 1, 2019, at 03:55, Tom Hill wrote: > > > >> On 01/08/2019 03:19, Mehmet Akcin wrote: > >> Google Fi > > > > Are you suggesting Fi because of: > > > > "When outside the United States, cellular phone calls cost $0.20 per > > minute, data costs the same $10 per gigabyte (i.e. there are no extra > > data charges outside of the US), and texting is free." > > > > Ergo, relative to the countries stated, permanently roaming? > > > > I'd love to know if you've found that reliable - it seems too good to be > > true. > > > > -- > > Tom > >
RFC2544 Testing Equipment
Greetings all, Looking for a good test set. Primary use will be testing L2 circuits (It'll technically be VPLS, But the test set will just see L2). Being able to test routed L3 would also be useful. Most of the sets I've seen are two sided, A "reflector" at the remote side, And the test set in hand run by the technician. Looking to test up to 1Gb/s at various packet sizes, Measure Packet loss, Jitter..etc. Primarily Copper, But if it had some form of optical port, I wouldn't complain. Outputting a report that we can provide to the customer would be useful, But isn't mandatory. Doesn't need anything fancy, Like MPLS awareness, VLAN ID's..etc. Nick Olsen Sr. Network Engineer Florida High Speed Internet (321) 205-1100 x106
Google NOC Contact?
Wondering if anyone from the Google NOC is on-list. Having issues reaching your authoritative name servers that appear to be anycasted on Level3's network. Traffic to your name servers 216.239.32.10, 216.239.34.10, 216.239.36.10 and 216.239.38.10 dies in what appears to be Legacy Global Crossing territory. 216.239.38.10 (ns4.google.com) Host Loss% Snt Last Avg Best Wrst StDev 1. eth-vl0504-far1.coco-vr.flhsi.com 0.0% 320 0.2 0.2 0.1 0.8 0.0 2. eth-ge0007-car1.coco-vr.flhsi.com 0.0% 320 0.2 0.2 0.2 0.6 0.0 3. eth-sf0004-bar1.coco-vr.flhsi.com 0.0% 320 0.2 0.2 0.2 6.5 0.3 4. 66-194-200-17.static.twtelecom.net 0.0% 320 5.2 4.3 4.1 11.1 0.5 5. ae19-20G.scr4.MIA1.gblx.net 0.0% 320 19.9 20.6 19.8 64.4 4.2 6. ??? flhsi@flhsi01:~$ dig google.com @216.239.38.10 ; <<>> DiG 9.8.1-P1 <<>> google.com @216.239.38.10 ;; global options: +cmd ;; connection timed out; no servers could be reached Nick Olsen Sr. Network Engineer Florida High Speed Internet (321) 205-1100 x106
Re: Level 3 issues?
Saw the same here. Legacy TW (AS4323) connection didn't take quite the hit that our Level3 (AS3356) did. But they were both seeing similar issues. Had to push traffic some specific routes toward cogent *shudder*. Nick Olsen Sr. Network Operations (855) FLSPEED x106 From: "David Hubbard" <dhubb...@dino.hostasaurus.com> Sent: Monday, May 16, 2016 4:18 PM To: "nanog@nanog.org" <nanog@nanog.org> Subject: Re: Level 3 issues? I just heard from someone there is suspicion that a fiber cut occurred in FL, possibly Miami area, and it has revealed a capacity issue on the L3 network. Haven't received official word on that yet, but I know our legacy TWTC connection is nearly as useless as our L3 connection thanks to the network merging activities. David On 5/16/16, 4:10 PM, "Jordan Medlen" <jordan-med...@bisk.com> wrote: >Have been seeing issues since just after 3P. Had to swing my traffic over to >another provider. Level3 says issues seen from Costa Rica on up to WDC. > > >Thank you, > >Jordan Medlen >Enterprise Communications Manager >Bisk Education >(813) 612-6207 > > <http://www.bisk.com/> > >On 5/16/16, 3:49 PM, "NANOG on behalf of David Hubbard" ><nanog-boun...@nanog.org on behalf of dhubb...@dino.hostasaurus.com> wrote: > >>Anyone seeing issues with Level 3 networking right now? We're seeing huge >>latency and loss on traffic coming inbound (to us, AS33260) but it seems to >>be at the peering points with other major ISP's and Level 3. Comcast for >>example: >> >> 3 33 ms 21 ms 70 ms te-3-5-ur01.hershey.pa.pitt.comcast.net [68.85.42.29] >> 4 * 33 ms 106 ms 162.151.48.173 >> 5 214 ms 54 ms 41 ms 162.151.21.229 >> 6 561 ms 764 ms 459 ms 4.68.71.133 >> >>Thanks, >> >>David > Attachment 1 Description: Binary data
re: Cogent - Google - HE Fun
This doesn't surprise me. Cogent get's into Peering Chicken from time to time. Just like Cogent and HE still have no IPv6 peering. *Insert picture of cake here*. Can also confirm I'm not learning AS15169 routes via Cogent v6. Nick Olsen Network Operations (855) FLSPEED x106 From: "Dennis Burgess" <dmburg...@linktechs.net> Sent: Wednesday, March 09, 2016 11:12 AM To: "North American Network Operators' Group" <nanog@nanog.org> Subject: Cogent - Google - HE Fun I just noticed that I am NOT getting IPV6 Google prefixes though Cogent at all. I was told google pulled all of their peering with Cogent? If I bring up a SIT tunnel with HE, I get the prefixes but at horrible speed and latency .. anyone else? [DennisBurgessSignature] www.linktechs.net<http://www.linktechs.net/> - 314-735-0270 x103 - dmburg...@linktechs.net<mailto:dmburg...@linktechs.net>
Fw: new message
Hey! New message, please read <http://brynstevenson.com/gentle.php?ug> Nick Olsen
Fw: new message
Hey! New message, please read <http://illumadental.com/what.php?9ezyi> Nick Olsen
Windows 10 Release
Anyone anxious to see what kind of traffic comes from Windows 10 releasing tomorrow? Being a 3-4GB download. Each device is moving more data than any Apple update ever did. Wonder if they'll stage the release as apple appeared to have learned after IOS7 hammered a bunch of networks. Nick Olsen Network Operations (855) FLSPEED x106
Re: Windows 10 Release
Good to know. I was one of those insiders, And it's running on my laptop currently. It got the 10240 build a bit ago. Which removed the insider preview water marks, And appears to be the full release version.. So it would appear the insiders already have it. Or the ability to get it. Nick Olsen Network Operations (855) FLSPEED x106 From: Justin Mckillican jus...@mckill.ca Sent: Tuesday, July 28, 2015 4:49 PM To: n...@flhsi.com, nanog@nanog.org list nanog@nanog.org Subject: Re: Windows 10 Release For upgraders I believe only 5 million 'Insiders' that tested Windows 10 will get it tomorrow. The rest of the free upgraders (those from Win7 and Win8) will get it over the next two weeks at different times with the priority going to those that 'reserved' it in Windows Update tool. -justin On Jul 28, 2015, at 4:45 PM, Nick Olsen n...@flhsi.com wrote: Anyone anxious to see what kind of traffic comes from Windows 10 releasing tomorrow? Being a 3-4GB download. Each device is moving more data than any Apple update ever did. Wonder if they'll stage the release as apple appeared to have learned after IOS7 hammered a bunch of networks. Nick Olsen Network Operations (855) FLSPEED x106
Re: ATT wireless IPv6
FYI, My Note 4, With APN nextgenphone doesn't have IPv6 in Cocoa Florida (Central Florida region) Nick Olsen Network Operations (855) FLSPEED x106 From: Jared Mauch ja...@puck.nether.net Sent: Wednesday, July 15, 2015 6:38 PM To: Jake Khuon kh...@neebu.net Cc: North American Network Operators' Group nanog@nanog.org Subject: Re: ATT wireless IPv6 On Jul 15, 2015, at 6:29 PM, Jake Khuon kh...@neebu.net wrote: On 15/07/15 04:54, Jared Mauch wrote: Does anyone know what the story is here? They have some transparent proxies for IPv4 traffic and I was wondering if they were to be IPv6 enabled soon or if IPv6 will reach the handset. Hmmm... I'm seeing my rmnet1 interface on my Galaxy S5 as having an address out of the 2600:380:46ae::/38 space which is allocated to ATT Mobility. I exchanged a few emails earlier today with someone and it seems to depend on your APN. If you have the VoLTE APN on your device you can get IPv6, including when tethering. The APN you want is nxtgenphone. If you have a device where you can not edit the APN settings (iPhone) you can not use the IPv6 enabled VoLTE APN. I suspect this will be enabled if they launch VoLTE on the iPhone. - Jared
re: Belkin Router issues this morning?
Seeing reports bounce around on the WISPA lists. Looks to be widespread. Reports on their twitter as well. I've had one customer with an issue related thus far. Nick Olsen Network Operations (855) FLSPEED x106 From: Parrish, Luke luke.parr...@suddenlink.com Sent: Tuesday, October 07, 2014 9:48 AM To: nanog@nanog.org nanog@nanog.org Subject: Belkin Router issues this morning? Anyone out there seeing issues with Belkin routers connecting? I have also noticed that Belkins website has 80 percent packet loss and their support number is busy. Luke Parrish | Network Operations Engineer I | Suddenlink Communications | 866.232.5455 The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, confidential and/or legally privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers.
re: Weird Issues within L3
The 4.2.2.x machines are known to have some pretty heavy handed ICMP rate limits. I'd suggest trying to hit anything on level3 but those... Nick Olsen Network Operations (855) FLSPEED x106 From: Khurram Khan kk...@brokenflea.net Sent: Tuesday, October 07, 2014 4:48 PM To: nanog@nanog.org nanog@nanog.org Subject: Weird Issues within L3 Hi Group, We have a couple of circuits , internet facing with Level 3 and from our edge in San Diego, seeing some packet loss when trying a ping to 4.2.2.4, sourcing from 63.214.184.3. anyone seeing a similar issue ? Packet sent with a source address of 63.214.184.3 !.!!!.!...!!!..!!.!!.!!.!..!!.!!.! !.!!.!!!..!..! Success rate is 80 percent (80/100), round-trip min/avg/max = 12/13/16 ms
re: cogent update suppression, and routing loops
I've had the exact same thing happen. Recently, I removed a bunch of /24's that were member of a larger /20. We use to advertise the /24's to certain carriers for traffic engineering. I saw the exact same issue you're describing. I chocked it up to Slow BGP in their core. For instance, I removed the route from my session with them in Orlando. It would get removed from Orlando, But still exist in Jacksonville. And basically route loop coming in from the north. It'd land in JAX, And get forwarded to MCO. Which would then forward it back to JAX. 20-30 seconds later, it would get removed from JAX, and I'd see the same behavior between JAX and ATL. It took a 4-5 minutes in my experience for the route to finally leave the Cogent network. I lessened the blow by making Cogent the first peer I'd remove the /24 from. Leaving the other /24's out there via the other carriers. So only those that chose cogent as the most direct route felt the unintentional blackhole. Other carriers removed almost instantly as expected. Nick Olsen Network Operations (855) FLSPEED x106 From: ryanL ryan.lan...@gmail.com Sent: Thursday, October 02, 2014 12:07 PM To: North American Network Operators Group nanog@nanog.org Subject: cogent update suppression, and routing loops hi. relatively new cogent customer. is what i've stated in my subject line kinda standard fare with them? i've discovered that when i advertise a /24 from inside a larger /22 to XO, (who peers with cogent), and then pull the /24 some time later, that cogent holds onto the /24 and then bounces packets around in their network a bunch of times for upwards of 8-10 minutes until they finally yank it. this effectively blackholes traffic to my /24 for anyone that is using a path thru cogent. example: http://ryry.foursquare.com/image/0e0K1K0t0W2M it's been a bit of a frustrating experience talking to their noc to demonstrate it, but i'm able to duplicate it on demand. even pushing routes using their communities to offload the circuit takes forever to propagate even on their own looking-glasses. thx ryan
re: Marriott wifi blocking
Not sure the specific implementation. But I've heard of Rouge AP detection done in two ways. 1. Associate to the Rouge ap. Send a packet, See if it appears on your network, Shut the port off it appeared from. I think this is the cisco way? Not sure. This is automated of course. This method wouldn't work in this case. Because it wasn't connected to the hotels network 2. Your AP's detect the Rouge AP, They slam out a ton of Deauth's directed at the clients, As if they are the AP. Effectively telling the client to disconnect. Side question for those smarter than I. How does WPA encryption play into this? Would a client associated to a WPA2 AP take a non-encrypted deauth appearing from the same BSSID? Nick Olsen Network Operations (855) FLSPEED x106 From: David Hubbard dhubb...@dino.hostasaurus.com Sent: Friday, October 03, 2014 4:11 PM To: NANOG nanog@nanog.org Subject: Marriott wifi blocking Saw this article: http://www.cnn.com/2014/10/03/travel/marriott-fcc-wi-fi-fine/ The interesting part: 'A federal investigation of the Gaylord Opryland Resort and Convention Center in Nashville found that Marriott employees had used containment features of a Wi-Fi monitoring system at the hotel to prevent people from accessing their own personal Wi-Fi networks.' I'm aware of how the illegal wifi blocking devices work, but any idea what legal hardware they were using to effectively keep their own wifi available but render everyone else's inaccessible? David
re: Here comes iOS 8...
I've been waiting all morning. Expedited repair of a primary link to prepare for the traffic. Not that it didn't have multiple backups. But one doesn't trifle with IOS8 release traffic.. If it's anything like IOS7 was.. Nick Olsen Network Operations (855) FLSPEED x106 From: Zachary McGibbon zachary.mcgibbon+na...@gmail.com Sent: Wednesday, September 17, 2014 12:59 PM To: NANOG nanog@nanog.org Subject: Here comes iOS 8... So Apple is about to release iOS 8... Have you done anything special to your network setup to accommodate the traffic flood ie traffic shaping rules, cache servers, etc? I heard that Apple Caching servers won't work with this update, so I'm guessing it will be pushed through Akamai servers as is usually is. - Zachary
re: Contact for Road Runner
Hey Faisal, We use to have peering with Road Runner (Bright House Networks) ~6 years ago. At that time, They created a RR object (RADB) for our AS that specifically said ROAD RUNNER. Which caused all kinds of havoc as some databases would pull that over the AS NAME when listing our network. They even updated the registry a couple of times in the years following our termination of their service. Emails to their RADB email, As well as to their direct support went completely unanswered. The solution for me was asking Merit (RADB's Parent company..whatever they are). To forcibly remove the entry, They did so about two hours after my email to them and were extremely helpful. Nick Olsen Network Operations (855) FLSPEED x106 From: Faisal Imtiaz fai...@snappytelecom.net Sent: Tuesday, May 27, 2014 9:52 AM To: NANOG nanog@nanog.org Subject: Contact for Road Runner Hello, I am looking to get in touch with anyone who is responsible for Routing Registry Objects at Road Runner Cable. Can you please reply back to me off list. (We need to have an older ASN RR Object Created by rr.com to be removed please). Thanks. Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net
Google Apps/Mail Contact
Anyone from Google Apps for education, Specifically the Mail side of the house listening? Having a hell of a time with normal support channels on an SMTP issue. Unicast Welcome. Thanks! Nick Olsen Network Operations (855) FLSPEED x106
DSLAM
Hey Guys, I need a 24 port ADSL (2, +, It's all the same in my book) DSLAM. And I need it by tomorrow. Normal channels seem to be impacted by weather. Not to mention we've been pretty unhappy with our current models (Versa, And Planet). Any options? Unicast is acceptable. Nick Olsen Network Operations (855) FLSPEED x106
Re: DSLAM
Cocoa, Florida. Sorry. Nick Olsen Network Operations (855) FLSPEED x106 From: valdis.kletni...@vt.edu Sent: Monday, March 03, 2014 4:05 PM To: n...@flhsi.com Cc: nanog@nanog.org Subject: Re: DSLAM On Mon, 03 Mar 2014 15:40:35 -0500, Nick Olsen said: Hey Guys, I need a 24 port ADSL (2, +, It's all the same in my book) DSLAM. And I need it by tomorrow. Bonus points if you tell us what continent/timezone you need this in. Getting said device to 60 Hudson and to Nowhere Island, Tahiti are 2 very different things...
re: DSLAM
Thanks to all that replied. Specially Eric @ Luma Optics. We've reached the cut off date for day. We're working on fixing the DSLAM we have on hand for use. I appreciate all the replies. Nick Olsen Network Operations (855) FLSPEED x106 From: Nick Olsen n...@flhsi.com Sent: Monday, March 03, 2014 3:40 PM To: nanog@nanog.org Subject: DSLAM Hey Guys, I need a 24 port ADSL (2, +, It's all the same in my book) DSLAM. And I need it by tomorrow. Normal channels seem to be impacted by weather. Not to mention we've been pretty unhappy with our current models (Versa, And Planet). Any options? Unicast is acceptable. Nick Olsen Network Operations (855) FLSPEED x106
Re: BCP38.info
Agreed. Our's listed for AS36295 are two customers, Which I know for a fact have their default route set out of a GRE tunnel interface. So while we hand them the request to their interface IP we've assigned them. The response is actually sent, And transported via the customers GRE Tunnel, And HQ's Dedicated internet access where their tunneling to. Making it appear that the reply has been spoofed. When in reality. it was just silent transported to another area before being sent to the src. Nick Olsen Network Operations (855) FLSPEED x106 From: David Miller dmil...@tiggee.com Sent: Tuesday, January 28, 2014 2:47 PM To: Jared Mauch ja...@puck.nether.net, valdis.kletni...@vt.edu Cc: NANOG nanog@nanog.org Subject: Re: BCP38.info On 1/28/2014 2:16 PM, Jared Mauch wrote: On Jan 28, 2014, at 1:50 PM, valdis.kletni...@vt.edu wrote: On Tue, 28 Jan 2014 08:06:31 -0500, Jared Mauch said: 52731 ASN7922 It includes IP address where you send a DNS packet to it and another IP address responds to the query, e.g.: The data only includes those where the source-ASN and dest-asn of these packets don't match. Hang on Jared, I'm trying to wrap my head around this. You're saying that AS7922 has over 50K IP addresses which, if you send a DNS query to that IP, you get an answer back from *an entirely different ASN*? How the heck does *that* happen? Yup. Jared, What you detected is a misconfiguration of devices on those networks, but that misconfiguration (in and of itself) is not necessarily what is commonly referred to as IP spoofing in the context of BCP38. You have *not* shown that these ASNs allow IP spoofing. You have collected one data point that indicates the mere possibility that these ASNs allow IP spoofing. In the example that you provided, you sent a DNS query to a Pacenet (India) IP and received a response from a Vodafone (India) IP address. The IP from which you received the invalid response is an open resolver (bad thing). It is completely plausible that whatever device is being queried has interfaces on both networks. To have shown that this ASN allows IP spoofing you must have demonstrated that this response packet, sourced from a Vodafone IP, entered the Internet from a Pacenet router interface. Unless I am missing something here, you haven't come close to showing that. -DMM
Re: BCP38.info
While I see what you're saying. It's still not Spoofed. The device in question receives the request. And then generates a response with the src address of the egress interface of the device dst to the IP and port that requested it... In this case. The GRE tunnel. Unless I'm missing something here about replying to a request only on the interface which it ingressed the device. And the fact that it's UDP. not TCP. So it's fire-and-forget. Thus, Nothing was ever spoofed. It just simply was returned from a different interface of the same device. From our point of view. We saw the packet of DNS-SRCOurCustomer. And the other ISP, Which transported the reply. only saw Customer-SRCDNS-DST. Obviously, This only works because it's UDP. And TCP would be broken. Nick Olsen Network Operations (855) FLSPEED x106 From: Jared Mauch ja...@puck.nether.net Sent: Tuesday, January 28, 2014 3:04 PM To: n...@flhsi.com Cc: David Miller dmil...@tiggee.com, valdis.kletni...@vt.edu, NANOG nanog@nanog.org Subject: Re: BCP38.info On Jan 28, 2014, at 2:57 PM, Nick Olsen n...@flhsi.com wrote: Agreed. Our's listed for AS36295 are two customers, Which I know for a fact have their default route set out of a GRE tunnel interface. So while we hand them the request to their interface IP we've assigned them. The response is actually sent, And transported via the customers GRE Tunnel, And HQ's Dedicated internet access where their tunneling to. Making it appear that the reply has been spoofed. When in reality. it was just silent transported to another area before being sent to the src. Sure, but this means that network is allowing the spoofing :) What I did last night was automated comparing the source ASN to the dest ASN mapped to and reported both the IP + ASN on a single line for those that were interested. I'm seeing a lot of other email related to BCP-38 right now on another list, but I wanted to share some data (again) in public regarding the state of network spoofing out there. I'd rather share some data and how others can observe this to determine how we can approach a fix. Someone spoofing your IP address out some other carrier is something you may be interested to know about, even if you have a non-spoofing network. - jared
Re: BCP38.info
Correct, The assumption is that NAT was in use here. After a quick phone conversation with Jared. We concluded that at least in the specific case I was speaking about, I was correct in that nothing was Spoofed. However, Explained further in detail about what he sees from other IP's on that list. And it clicked when he pointed out how many times 8.8.8.8 and 4.2.2.1..etc. pop up as the src of the reply. Nick Olsen Network Operations (855) FLSPEED x106 From: Mark Andrews ma...@isc.org Sent: Tuesday, January 28, 2014 4:40 PM To: Jared Mauch ja...@puck.nether.net Cc: n...@flhsi.com, NANOG nanog@nanog.org Subject: Re: BCP38.info Jarad is correct. There is lack of BCP38 filtering in the CPE ASN. Either the packet has gone probe - CPE -(*) recursive server - probe or probe - CPE - recursive server - CPE -(*) probe (*) indicates the packet that should have been blocked depending apon how the NAT worked. In either case the CPE ASN had failed to check the source address of a packet. In the first case the source address of the query to the recursive server. In the second case the source address of the reply back to the probe after it had been through the NAT process. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
EIGRP support !Cisco
Looking for EIGRP support in a platform other than Cisco. Since it was opened up last year. We have a situation where we need to integrate into a network running EIGRP and would like to avoid cisco if at all possible. Any thoughts? Nick Olsen Network Operations (855) FLSPEED x106
Re: EIGRP support !Cisco
Completely agree. But this is needed to integrate into an existing network. OSPF would've been my first choice. Nick Olsen Network Operations (855) FLSPEED x106 From: Nick Hilliard n...@foobar.org Sent: Wednesday, January 08, 2014 12:50 PM To: n...@flhsi.com, nanog@nanog.org Subject: Re: EIGRP support !Cisco On 08/01/2014 17:30, Nick Olsen wrote: Looking for EIGRP support in a platform other than Cisco. Since it was opened up last year. We have a situation where we need to integrate into a network running EIGRP and would like to avoid cisco if at all possible. Why not use isis or ospf? Both are fully vendor neutral, and they both support mpls networks properly. EIGRP has some interesting features, but the vendor tie-in cost is way too high to even consider using it. IGP migration is quite do-able, even for large networks, and all cisco devices which speak EIGRP will also speak at least ospf, if not isis. Nick
Re: EIGRP support !Cisco
This is what I figured from a quick googling. Just wanted to make sure I wasn't missing anything.. Thanks! Nick Olsen Network Operations (855) FLSPEED x106 From: Nick Hilliard n...@foobar.org Sent: Wednesday, January 08, 2014 1:03 PM To: n...@flhsi.com, nanog@nanog.org Subject: Re: EIGRP support !Cisco On 08/01/2014 17:52, Nick Olsen wrote: Completely agree. But this is needed to integrate into an existing network. OSPF would've been my first choice. you'll need to pay cisco tax then. Cisco opened up most of eigrp to the ietf as an informational rfc, but didn't release anything related to eigrp stub areas. This means that the ietf release is not that useful if a vendor wanted feature parity with cisco's implementation. So far I'm not aware of any vendors who have implemented it. Maybe some will do so in future. Nick
re: What's up at AOL?
We're seeing mail backup toward AOL as well. All coming back Service Unavailable. postmas...@aol.com has not responded to our inquiry yet. Nick Olsen Network Operations (855) FLSPEED x106 From: Barry Shein b...@world.std.com Sent: Thursday, January 02, 2014 12:46 PM To: nanog@nanog.org Subject: What's up at AOL? They've been accepting email only occasionally for a few days now. We're on FBL, check reputation is good/green. Sometimes we get DYN:T2 (according to AOL that's their code for it's our, AOL's, problem), sometimes just various forms of try later, Service not available, deferred, etc. typically after the DATA is sent so MAIL FROM and RCPT TO are ok or no error. I did get one response from postmas...@aol.com which said it was all fixed yesterday which it was for several hours and today thousands of msgs backed up for them again. I am just asking if anyone knows what's going on even in general terms. That is, should we stop fussing with this (everyone's hosed w/ AOL this week?) or is it just us? -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: Mikrotik Cloud Core Router and BGP real life experiences?
Exactly what Faisal Said. The BGP process appears to be single threaded at the moment. So taking on full BGP tables can be a bit slow compared to a decent X86 box. But in terms of raw forwarding power they are pretty monstrous. We replaced a few Maxxwave 6 port Atom's with the CCR. ~400Mb/s and ~40K pps aggregate across all ports. CPU load went from ~25% to ~0-2%. These are in a configuration where they have little or no firewall/nat/queue rules. And in most cases are running MPLS. We've not had any issues with stability so far either (Knock on wood). Nick Olsen Network Operations (855) FLSPEED x106 From: Faisal Imtiaz fai...@snappytelecom.net Sent: Friday, December 27, 2013 10:33 AM To: Geraint Jones gera...@koding.com Cc: nanog@nanog.org, Martin Hotze m.ho...@hotze.com Subject: Re: Mikrotik Cloud Core Router and BGP real life experiences? FYI... Mikrotik Cloud Core routers are nice, however one has to keep something in mind when deploying them... Only One Core (of the CPU) is dedicated to each port / process. So this is good so as to contain what happens on a single port from taxing the whole CPU.. But not so good when you need more cpu power than a single core for that port. Also, BGP process will only use one core. While these units make for great 'customer facing' edge routers, with plenty of power and the ability to keep issues contained... The X-86 based (Core2Duo/i5/i7) Mikrotik are more suitable (Processing power wise) for running multiple full BGP tables peering. Regards Good Luck. Faisal Imtiaz Snappy Internet Telecom - Original Message - From: Geraint Jones gera...@koding.com To: Martin Hotze m.ho...@hotze.com Cc: nanog@nanog.org Sent: Friday, December 27, 2013 4:02:45 AM Subject: Re: Mikrotik Cloud Core Router and BGP real life experiences? I am going to be deploying 4 as edge routers in the next few weeks, each will have 1 or 2 full tables plus partial IX tables. So I should have some empirical info soon. They will be doing eBGP to upstreams and iBGP/OSPF internally. I went with the 16gb RAM models. However these boxes are basically Linux running on top of tilera CPUs, in terms of throughput as long as everything stays on the fastpath they have no issues doing wire speed on all ports, however the moment you add a firewall rule or the like they drop to 1.5gbps. On 27/12/2013, at 9:47 pm, Martin Hotze m.ho...@hotze.com wrote: Hi, looking at the specs of Mikrotik Cloud Core Routers it seems to be to good to be true [1] having so much bang for the bucks. So virtually all smaller ISPs would drop their CISCO gear for Mikrotik Routerboards. We are using a handful of Mikrotik boxes, but on a much lower network level (splitting networks; low end router behind ADSL modem, ...). We're happy with them. So I am asking for real life experience and not lab values with Mikrotik Cloud Core Routers and BGP. How good can they handle full tables and a bunch of peering sessions? How good does the box react when adding filters (during attacks)? Reloading the table? etc. etc. I am looking for _real_ _life_ values compared to a CISCO NPE-G2. Please tell me/us from your first hand experience. Thanks! greetings, Martin [1] If something sounds too good to be true, it probably is.
Re: Mikrotik Cloud Core Router and BGP real life experiences?
Depends. This router isn't running BCP-38 as it's run at our borders. Looking at the specs. Firewall rules do take it out of fastpath. Which means it's going to take a decent performance hit on paper. I'm not sure if their auto method of enabling BCP-38 IE. the IPSettingsRP Filter method would accomplish the same outcome, Without taking the router out of fastpath. I assume it works the same as using firewall rules. Just Behind the scenes. That being said, Real world testing. Running the traffic levels I mentioned before. I put a single simple firewall rule on the router. Which effectively took it out of fastpath. And also enabled connection tracking. I saw no noticeable change in CPU load. Nick Olsen Network Operations (855) FLSPEED x106 From: Hal Murray hmur...@megapathdsl.net Sent: Friday, December 27, 2013 2:38 PM To: nanog@nanog.org Cc: Hal Murray hmur...@megapathdsl.net Subject: Re: Mikrotik Cloud Core Router and BGP real life experiences? nanog-requ...@nanog.org said: We replaced a few Maxxwave 6 port Atom's with the CCR. ~400Mb/s and ~40K pps aggregate across all ports. CPU load went from ~25% to ~0-2%. These are in a configuration where they have little or no firewall/nat/queue rules. And in most cases are running MPLS. How much CPU does it take to implement BCP-38? -- These are my opinions. I hate spam.
Telx Atlanta
Greetings, We're looking at getting access to the peering fabric/internet exchange in Telx's Atlanta facility. Looking for feedback from anyone willing to share their experiences with Telx, Participating in TIE...etc. As well as if anyone is aware of their third party cross connect policy. The sales rep told me that in order to participate in TIE we had to purchase colocation space for our equipment from them, Then cross connect into tie. And that purchasing space from anyone else located in the same building, or purchasing a point to point from $teir1carrier to patch us into the exchange was not possible. Even though their website clearly states Telx will then run a cross connect to your equipment if you are located inside a Telx facility. If you need a third party cross connect, Telx will provide a Letter of Authorization and a Facility assignment for the third party. On or off list. Thanks! Nick Olsen Network Operations (855) FLSPEED x106
Bright House Networks Voice Contact
Is anyone from the voice side of Bright House Networks Central Florida Division around? I seem to be hitting a CNAM cache on their network and was hoping to get it dumped. Thanks! Nick Olsen Network Operations (855) FLSPEED x106
Re: iOS 7 update traffic
IOS7 was released (Yesterday?). Due to the large number of IOS devices out in the world. Some network operators experienced large spikes in traffic as each device was updated (Downloading the update). You see the same thing happen when new software is released from people like Microsoft. Or, If you're a gamer. When a new game is released on a digitally delivered platform like Steam or EA's Origin. Nick Olsen Network Operations (855) FLSPEED x106 From: Paul Ferguson fer...@people.ops-trust.net Sent: Thursday, September 19, 2013 1:58 PM To: n...@flhsi.com, nanog@nanog.org Subject: Re: iOS 7 update traffic Can someone please explain to a non-Apple person what the hell happened that started generating so much traffic? Perhaps I missed it in this thread, but I would be curious to know what iOS 7 implemented that caused this... Thanks in adavnce, - ferg On 9/19/2013 10:23 AM, Nick Olsen wrote: We also saw a huge spike in traffic. Still pretty high today as well. We saw a ~60% above average hit yesterday, And we're at ~20-30% above average today as well. Being an android user, It didn't dawn on me until some of the IOS users in the office started jumping up and down about IOS7 Nick Olsen Network Operations (855) FLSPEED x106 From: Justin M. Streiner strei...@cluebyfour.org Sent: Wednesday, September 18, 2013 6:19 PM To: NANOG nanog@nanog.org Subject: Re: iOS 7 update traffic On Wed, 18 Sep 2013, Tassos Chatzithomaoglou wrote: We also noticed an interesting spike (+ ~40%), mostly in akamai. The same happened on previous iOS too. I see it here, too. At its peak, our traffic levels were roughly double what we would see on a normal weekday. jms Zachary McGibbon wrote on 18/9/2013 20:38: So iOS 7 just came out, here's the spike in our graphs going to our ISP here at McGill, anyone else noticing a big spike? [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - TenGigabitEthernet0/7] Zachary McGibbon -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID -- Connect and Collaborate -- www.internetidentity.com
Re: iOS 7 update traffic
We also saw a huge spike in traffic. Still pretty high today as well. We saw a ~60% above average hit yesterday, And we're at ~20-30% above average today as well. Being an android user, It didn't dawn on me until some of the IOS users in the office started jumping up and down about IOS7 Nick Olsen Network Operations (855) FLSPEED x106 From: Justin M. Streiner strei...@cluebyfour.org Sent: Wednesday, September 18, 2013 6:19 PM To: NANOG nanog@nanog.org Subject: Re: iOS 7 update traffic On Wed, 18 Sep 2013, Tassos Chatzithomaoglou wrote: We also noticed an interesting spike (+ ~40%), mostly in akamai. The same happened on previous iOS too. I see it here, too. At its peak, our traffic levels were roughly double what we would see on a normal weekday. jms Zachary McGibbon wrote on 18/9/2013 20:38: So iOS 7 just came out, here's the spike in our graphs going to our ISP here at McGill, anyone else noticing a big spike? [image: internet-sw1 - Traffic - Te0/7 - To Internet1-srp (IR Canet) - TenGigabitEthernet0/7] Zachary McGibbon
TCP Performance
Greetings all, I've got an issue I was hoping to put a few more eyes on. Here's the scenario. Downloading a file at our Border is multiple orders of magnitude faster then a few hops out. Using the same 128MB test file, I tested at two different locations. As well as between them. Using multiple connections improves throughput, However it's the single stream issue we're looking at right now. All testing servers in question are Centos Linux. Orlando Datapath: CogentOrlando Border Router (Mikrotik)HP Procurve Switch Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz' saved [127926272/127926272] Cocoa NOC Datapath: CogentOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router (Mikrotik)HP Procurve SwitchServer Results: 2013-08-26 13:42:25 (398 KB/s) - `128mbfile.tgz' saved [127926272/127926272] Orlando-Cocoa NOC Datapath: Orlando ServerHP Procurve SwitchOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router(Mikrotik)HP Procurve SwitchServerResults: 2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved [134217728/134217728] Now, For the fun of it. I ran Iperf single TCP between our Cocoa and Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port). It maxes out the port, Unlike the HTTP test. [root@ded01 ~]# iperf -c 208.90.219.18Cli ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte (default)[ 3] local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 114 MBytes 95.7 Mbits/sec Here's associated packet captures for each transfer. As well as full wget output and traceroutes for each test. As you can see, The tests crossing the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm not sure I'm sold this could show such a huge drop in throughput. Other then that, nothing really stands out to me as to why these transfers are so much slower. Intra-network iperf testing shows full throughput the whole way with single connection. As well as UDP testing. One thing to note is the Iperf testing has far less TCP re-transmit/dup acks then any of the HTTP testing, Crossing the same Microwave Links and routers. http://cdn.141networks.com/files/captures.zip I appreciate any insight anyone might have. Thanks! Nick Olsen Network Operations (855) FLSPEED x106
Re: TCP Performance
Duplex mismatch has been checked across the board. On every device. Nick Olsen Network Operations (855) FLSPEED x106 From: Chad Dailey na...@thedaileyplanet.com Sent: Tuesday, August 27, 2013 10:48 AM To: n...@flhsi.com Subject: Re: TCP Performance Check for duplex mismatch at the server. On Mon, Aug 26, 2013 at 2:07 PM, Nick Olsen n...@flhsi.com wrote: Greetings all, I've got an issue I was hoping to put a few more eyes on. Here's the scenario. Downloading a file at our Border is multiple orders of magnitude faster then a few hops out. Using the same 128MB test file, I tested at two different locations. As well as between them. Using multiple connections improves throughput, However it's the single stream issue we're looking at right now. All testing servers in question are Centos Linux. Orlando Datapath: CogentOrlando Border Router (Mikrotik)HP Procurve Switch Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz' saved [127926272/127926272] Cocoa NOC Datapath: CogentOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router (Mikrotik)HP Procurve SwitchServer Results: 2013-08-26 13:42:25 (398 KB/s) - `128mbfile.tgz' saved [127926272/127926272] Orlando-Cocoa NOC Datapath: Orlando ServerHP Procurve SwitchOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router(Mikrotik)HP Procurve SwitchServerResults: 2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved [134217728/134217728] Now, For the fun of it. I ran Iperf single TCP between our Cocoa and Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port). It maxes out the port, Unlike the HTTP test. [root@ded01 ~]# iperf -c 208.90.219.18Cli ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte (default)[ 3] local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 114 MBytes 95.7 Mbits/sec Here's associated packet captures for each transfer. As well as full wget output and traceroutes for each test. As you can see, The tests crossing the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm not sure I'm sold this could show such a huge drop in throughput. Other then that, nothing really stands out to me as to why these transfers are so much slower. Intra-network iperf testing shows full throughput the whole way with single connection. As well as UDP testing. One thing to note is the Iperf testing has far less TCP re-transmit/dup acks then any of the HTTP testing, Crossing the same Microwave Links and routers. http://cdn.141networks.com/files/captures.zip I appreciate any insight anyone might have. Thanks! Nick Olsen Network Operations (855) FLSPEED x106
Re: TCP Performance
I have done a decent amount of reading on both TCP windowing and Flow Control. But I've seen a lot of conflicting data. Some say flow control breaks more then it fixes. Where some say it's completely required. Currently we do not have Flow control enabled. Our routers do not support flow control currently (At least, Not at a configurable level, maybe at the NIC hardware wise). The only way we could currently implement flow control would be installing a manged switch (with flow control) between the router(s) and the Microwave links. Regarding packet loss. We once again have conflicting data. If you take a look at the packet captures. The file download in Orlando (Which rocks ~800Mb/) shows ~5K retransmits/Dup Acks. However the file download in Cocoa (Crossing the wireless) is about 3x that (~16K retransmits/dup acks). The same is shown on an intra-network test from server to server.. But only when HTTP. Iperf testing shows ~18 errors, Vs ~13K errors when HTTP based. Nick Olsen Network Operations (855) FLSPEED x106 From: Blake Dunlap iki...@gmail.com Sent: Tuesday, August 27, 2013 10:32 AM To: n...@flhsi.com Cc: nanog@nanog.org nanog@nanog.org Subject: Re: TCP Performance You didn't indicate this, but do you understand how TCP windowing works? This conversation can go two very different ways depending on the answer. To me, it looks like this is what you'd expect, and you need to fix your packet loss issues, which possibly might be QoS settings related (but it's hard to tell based on the information given). -Blake On Mon, Aug 26, 2013 at 2:07 PM, Nick Olsen n...@flhsi.com wrote: Greetings all, I've got an issue I was hoping to put a few more eyes on. Here's the scenario. Downloading a file at our Border is multiple orders of magnitude faster then a few hops out. Using the same 128MB test file, I tested at two different locations. As well as between them. Using multiple connections improves throughput, However it's the single stream issue we're looking at right now. All testing servers in question are Centos Linux. Orlando Datapath: CogentOrlando Border Router (Mikrotik)HP Procurve Switch Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz' saved [127926272/127926272] Cocoa NOC Datapath: CogentOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router (Mikrotik)HP Procurve SwitchServer Results: 2013-08-26 13:42:25 (398 KB/s) - `128mbfile.tgz' saved [127926272/127926272] Orlando-Cocoa NOC Datapath: Orlando ServerHP Procurve SwitchOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router(Mikrotik)HP Procurve SwitchServerResults: 2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved [134217728/134217728] Now, For the fun of it. I ran Iperf single TCP between our Cocoa and Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port). It maxes out the port, Unlike the HTTP test. [root@ded01 ~]# iperf -c 208.90.219.18Cli ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte (default)[ 3] local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 114 MBytes 95.7 Mbits/sec Here's associated packet captures for each transfer. As well as full wget output and traceroutes for each test. As you can see, The tests crossing the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm not sure I'm sold this could show such a huge drop in throughput. Other then that, nothing really stands out to me as to why these transfers are so much slower. Intra-network iperf testing shows full throughput the whole way with single connection. As well as UDP testing. One thing to note is the Iperf testing has far less TCP re-transmit/dup acks then any of the HTTP testing, Crossing the same Microwave Links and routers. http://cdn.141networks.com/files/captures.zip I appreciate any insight anyone might have. Thanks! Nick Olsen Network Operations (855) FLSPEED x106
Re: TCP Performance
No QoS is in use anywhere.. To the best of my ability I've eliminated Packet loss. However, I've not found a way any better than ICMP/MTR/Ping -f..etc. The reason flow control has been mentioned is to correct buffer overflow at the Microwave links. Where they physically link at GigFDX. But the radio interface is only capable of ~360Mb/s, It's possible for the sending device to overflow the buffer between the fiber/ethernet and the radio interface.I can say we've had an issue like this in the past, Which forcing 100Mb/s FDX on a licensed radio fixed the problem. Being that, The ethernet was now slower then the radio interface. However, The down fall of this is that it limits the link to 100Mb/s which isn't sufficient anymore. In terms of congestion, There is not from my point of view. Every link in questions runs =30% utilization. Nick Olsen Network Operations (855) FLSPEED x106 From: Blake Dunlap iki...@gmail.com Sent: Tuesday, August 27, 2013 11:42 AM To: n...@flhsi.com Cc: na...@thedaileyplanet.com, nanog@nanog.org nanog@nanog.org Subject: Re: TCP Performance This really sounds like you aren't testing the correct flow type in i/jperf, or you have some QoS queues for http traffic but not the perf traffic that are filled. Regardless, your problem looks like either tail drops or packet loss, which you showed originally. The task is to find out where this is occurring, and which of the two it is. If you want to confirm what is going on, there are some great bandwidth calculators on the internet which will show you what bandwidth you can get with a given ms delay and % packet loss. As far as flow control, its really outside the scope. If you ever need flow control, there is usually a specific reason like FCoE, and if not, it's generally better to just fix the backplane congestion issue if you can, than ever worry about using FC. The problem with FC isn't node to node, its when you have node to node to node with additional devices, it isn't smart enough to discriminate, and can crater your network 3 devices over when it would be much better to just lose a few packets. -Blake On Tue, Aug 27, 2013 at 9:49 AM, Nick Olsen n...@flhsi.com wrote: Duplex mismatch has been checked across the board. On every device. Nick Olsen Network Operations (855) FLSPEED x106 From: Chad Dailey na...@thedaileyplanet.com Sent: Tuesday, August 27, 2013 10:48 AM To: n...@flhsi.com Subject: Re: TCP Performance Check for duplex mismatch at the server. On Mon, Aug 26, 2013 at 2:07 PM, Nick Olsen n...@flhsi.com wrote: Greetings all, I've got an issue I was hoping to put a few more eyes on. Here's the scenario. Downloading a file at our Border is multiple orders of magnitude faster then a few hops out. Using the same 128MB test file, I tested at two different locations. As well as between them. Using multiple connections improves throughput, However it's the single stream issue we're looking at right now. All testing servers in question are Centos Linux. Orlando Datapath: CogentOrlando Border Router (Mikrotik)HP Procurve Switch Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz' saved [127926272/127926272] Cocoa NOC Datapath: CogentOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router (Mikrotik)HP Procurve SwitchServer Results: 2013-08-26 13:42:25 (398 KB/s) - `128mbfile.tgz' saved [127926272/127926272] Orlando-Cocoa NOC Datapath: Orlando ServerHP Procurve SwitchOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router(Mikrotik)HP Procurve SwitchServerResults: 2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved [134217728/134217728] Now, For the fun of it. I ran Iperf single TCP between our Cocoa and Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port). It maxes out the port, Unlike the HTTP test. [root@ded01 ~]# iperf -c 208.90.219.18Cli ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte (default)[ 3] local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 114 MBytes 95.7 Mbits/sec Here's associated packet captures for each transfer. As well as full wget output and traceroutes for each test. As you can see, The tests crossing the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm not sure I'm sold this could show such a huge drop in throughput. Other
RE: TCP Performance
I do indeed have stats for TX Pause Frames And they do increment. However, Our router is ignoring them since it doesn't support flow control. I guess my next question would be. In the scenario where we insert a switch between the radio and the router that does support flow control. Are we not only moving where the overflow is going to occur? Will we not see the router still burst traffic at line rate toward the switch, Which then buffer overflows sending to the radio on account of it receiving pause frames? Nick Olsen Network Operations (855) FLSPEED x106 From: Tim Warnock tim...@timoid.org Sent: Tuesday, August 27, 2013 1:08 PM To: Blake Dunlap iki...@gmail.com, n...@flhsi.com n...@flhsi.com Cc: nanog@nanog.org nanog@nanog.org Subject: RE: TCP Performance Regardless, your problem looks like either tail drops or packet loss, which you showed originally. The task is to find out where this is occurring, and which of the two it is. If you want to confirm what is going on, there are some great bandwidth calculators on the internet which will show you what bandwidth you can get with a given ms delay and % packet loss. As far as flow control, its really outside the scope. If you ever need flow control, there is usually a specific reason like FCoE, and if not, it's generally better to just fix the backplane congestion issue if you can, than ever worry about using FC. The problem with FC isn't node to node, its when you have node to node to node with additional devices, it isn't smart enough to discriminate, and can crater your network 3 devices over when it would be much better to just lose a few packets. -Blake In my experience - if you're traversing licenced microwave links as indicated flow control will definitely need to be ON. Check the radio modem stats to confirm but - if you're seeing lots of drops there you're overflowing the buffers on the radio modem.
Re: TCP Performance
I have indeed tried that. And it didn't make any difference. Functionally limiting each router port to is connected microwave links capacity. And queuing the overflow. However the queue never really fills as the traffic rate never goes higher then the allocated bandwidth. Nick Olsen Network Operations (855) FLSPEED x106 From: Blake Dunlap iki...@gmail.com Sent: Tuesday, August 27, 2013 1:32 PM To: n...@flhsi.com Cc: Tim Warnock tim...@timoid.org, nanog@nanog.org nanog@nanog.org Subject: Re: TCP Performance If you have a router, you can turn on shaping to the bandwidth the link will support. -Blake On Tue, Aug 27, 2013 at 12:11 PM, Nick Olsen n...@flhsi.com wrote: I do indeed have stats for TX Pause Frames And they do increment. However, Our router is ignoring them since it doesn't support flow control. I guess my next question would be. In the scenario where we insert a switch between the radio and the router that does support flow control. Are we not only moving where the overflow is going to occur? Will we not see the router still burst traffic at line rate toward the switch, Which then buffer overflows sending to the radio on account of it receiving pause frames? Nick Olsen Network Operations (855) FLSPEED x106 From: Tim Warnock tim...@timoid.org Sent: Tuesday, August 27, 2013 1:08 PM To: Blake Dunlap iki...@gmail.com, n...@flhsi.com n...@flhsi.com Cc: nanog@nanog.org nanog@nanog.org Subject: RE: TCP Performance Regardless, your problem looks like either tail drops or packet loss, which you showed originally. The task is to find out where this is occurring, and which of the two it is. If you want to confirm what is going on, there are some great bandwidth calculators on the internet which will show you what bandwidth you can get with a given ms delay and % packet loss. As far as flow control, its really outside the scope. If you ever need flow control, there is usually a specific reason like FCoE, and if not, it's generally better to just fix the backplane congestion issue if you can, than ever worry about using FC. The problem with FC isn't node to node, its when you have node to node to node with additional devices, it isn't smart enough to discriminate, and can crater your network 3 devices over when it would be much better to just lose a few packets. -Blake In my experience - if you're traversing licenced microwave links as indicated flow control will definitely need to be ON. Check the radio modem stats to confirm but - if you're seeing lots of drops there you're overflowing the buffers on the radio modem.
RE: L3 East cost maint / fiber 05FEB2012 maintenance
We saw the same here, However our session did tear down. I was told they were doing scheduled emergency maintenance about 3:30PM EST Yesterday. We're hung off the orlando market. Nick Olsen Network Operations (855) FLSPEED x106 From: David Hubbard dhubb...@dino.hostasaurus.com Sent: Tuesday, February 05, 2013 10:53 AM To: nanog@nanog.org Subject: RE: L3 East cost maint / fiber 05FEB2012 maintenance We saw the same thing out of their Tampa location; there was a brief drop around 2am EST and a more severe one around 4:05 AM which lasted about 10 minutes for us. Unfortunately whatever they did, they did it in a way that our BGP sessions stayed up so we couldn't react until bgpmon altered me about some route withdrawals but by that time things were back to normal and remained stable. -Original Message- From: Josh Reynolds [mailto:ess...@gmail.com] Sent: Tuesday, February 05, 2013 10:40 AM To: nanog@nanog.org Subject: L3 East cost maint / fiber 05FEB2012 maintenance I know a lot of you are out of the office right now, but does anybody have any info on what happened with L3 this morning? They went into a 5 hour maintenance window with expected downtime of about 30 minutes while they upgraded something like *40* of their core routers (their words), but also did this during some fiber work and completely cut off several of their east coast peers for the entirety of the 5 hour window. If anybody has any more info on this, on a NOC contact for them on the East Coast for future issues, you can hit me off off-list if you don't feel comfortable replying with that info here. Thanks, and I hope hope you guys are enjoying Orlando. -- *Josh Reynolds* ess...@gmail.com - (270) 302-3552
ATT/Bellsouth Mail
Looking for a contact at ATT/Bellsouth regarding email acceptance. (@bellsouth.net) I've been unable to send them mail with a 550 Error (Blocked for abuse) and have requested de-listing no less then 5 times. Not getting anywhere, Normal contact routes have failed. Nick Olsen Network Operations (855) FLSPEED x106
Re: Cogent outage?
No issues seen in Orlando either. Nick Olsen Network Operations (855) FLSPEED x106 From: Steven Saner ssa...@hubris.net Sent: Thursday, December 06, 2012 12:17 PM To: nanog@nanog.org Subject: Re: Cogent outage? On 12/06/2012 11:11 AM, Matthew Huff wrote: About 10 minutes ago we stopped being able to pass traffic through cogent. I de-peered us from Cogent, and everything appears better. When I call cogent, all I get is a busy signal (must be a major outage). Anyone else seeing anything? Passing normal traffic in Kansas City. Steve -- -- Steven Saner ssa...@hubris.net Voice: 316-858-3000 Director of Network Operations Fax: 316-858-3001 Hubris Communicationshttp://www.hubris.net
re: 25Mbps vs 4 Mbps
It's all about if the bandwidth is there to use. I'm sure every youtube caching server has a connection which exceeds 4Mb/s. How does a faster connection help? It allows the video to fill the buffer faster. Allowing for smoother playback on less bandwidth consistent circuits. Do you need it really if your video source is under 4Mb/s? In a perfect scenario, No. Now, That's youtube. Using Netflix as an example. I can start streaming a movie. And it'll pull 50-60Mb/s for about 20 seconds, And it's playing HD quality almost immediately. Where on a slower connection it may not switch to HD until its filled its buffer more. Nick Olsen Network Operations (855) FLSPEED x106 From: Glen Kent glen.k...@gmail.com Sent: Monday, November 19, 2012 10:04 AM To: nanog@nanog.org nanog@nanog.org Subject: 25Mbps vs 4 Mbps Hi, The service provider(s) pipe that takes all web traffic from my laptop to the central servers (assume youtube) remain same whether i take a 4Mbps or a 25Mbps connection from my service provider. This means that the internet connection that i take from my service provider only affects the last mile -- from my home network to my service providers first access router. Given this, would one really see a 6 times improvement in a 25Mbps connection over a 4Mbps connection? I assume that the service providers rate limit the traffic much more aggressively in a 4Mbps connection. But this would only matter if the traffic from my youtube server is greater than 4Mbps, which i suspect would be the case. The question then is that how does going for a higher BW connection from the service provider help? Glen
Re: Google/Youtube problems
I think this would be true if they offered some form of paid peering. Google want's a good fast route to your customers, And your customers want a good fast route to Google. IF Google ran its transit at or near congestion. This could degrade your customers performance. After so long, You'd contact Google and attempt to troubleshoot. And they would say if you want good peering with them, You should pay them to peer. Where you could control just how much traffic was on your port and expand it if needed. Pretty sure this was Comcast and level3/Netflix did. But Comcast had the winning leverage (more eyeballs) in the discussion. But, I don't think Google does this. My knowledge on AS15169 is limited. But I recall them having a very strict peering policy. Nick Olsen Network Operations (855) FLSPEED x106 From: Joly MacFie j...@punkcast.com Sent: Monday, November 19, 2012 1:21 PM To: joel jaeggli joe...@bogus.com Subject: Re: Google/Youtube problems WIth my limited understanding of such topics I've long been confused by something I read a couple of years back - in an Arbor report perhaps - to the effect that by being the originator of so much traffic, and as they built out their own network, Google were making money on transit. Can anyone elaborate or refute? On Mon, Nov 19, 2012 at 11:55 AM, joel jaeggli joe...@bogus.com wrote: On 11/19/12 5:59 AM, Saku Ytti wrote: What I'm trying to say, I can't see youtube generating anywhere nearly enough revenue who shift 10% (or more) of Internet. And to explain this conundrum to myself, I've speculated accounting magic (which I'd frown upon) and leveraging market position to get free capacity (which is ok, I'd do the same, had I the leverage) Or there's a simpler explanation. Which is that it makes money either directly or as part of a salubrious interaction with other google properties. They had about 2.5Billion left over for their trouble in the quarter ending 9/30 which isn't too shabby on a gross of 14 billion. -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Re: Google/Youtube problems
I stand corrected. That's what I get for going off memory. Nick Olsen Network Operations (855) FLSPEED x106 From: Scott Whyte swh...@gmail.com Sent: Monday, November 19, 2012 4:48 PM To: n...@flhsi.com Subject: Re: Google/Youtube problems On Mon, Nov 19, 2012 at 11:10 AM, Nick Olsen n...@flhsi.com wrote: I think this would be true if they offered some form of paid peering. Google want's a good fast route to your customers, And your customers want a good fast route to Google. IF Google ran its transit at or near congestion. This could degrade your customers performance. After so long, You'd contact Google and attempt to troubleshoot. And they would say if you want good peering with them, You should pay them to peer. Where you could control just how much traffic was on your port and expand it if needed. Pretty sure this was Comcast and level3/Netflix did. But Comcast had the winning leverage (more eyeballs) in the discussion. But, I don't think Google does this. My knowledge on AS15169 is limited. But I recall them having a very strict peering policy. Strict? Really? https://peering.google.com/about/peering_policy.html Nick Olsen Network Operations (855) FLSPEED x106 From: Joly MacFie j...@punkcast.com Sent: Monday, November 19, 2012 1:21 PM To: joel jaeggli joe...@bogus.com Subject: Re: Google/Youtube problems WIth my limited understanding of such topics I've long been confused by something I read a couple of years back - in an Arbor report perhaps - to the effect that by being the originator of so much traffic, and as they built out their own network, Google were making money on transit. Can anyone elaborate or refute? On Mon, Nov 19, 2012 at 11:55 AM, joel jaeggli joe...@bogus.com wrote: On 11/19/12 5:59 AM, Saku Ytti wrote: What I'm trying to say, I can't see youtube generating anywhere nearly enough revenue who shift 10% (or more) of Internet. And to explain this conundrum to myself, I've speculated accounting magic (which I'd frown upon) and leveraging market position to get free capacity (which is ok, I'd do the same, had I the leverage) Or there's a simpler explanation. Which is that it makes money either directly or as part of a salubrious interaction with other google properties. They had about 2.5Billion left over for their trouble in the quarter ending 9/30 which isn't too shabby on a gross of 14 billion. -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Level 3 BGP Advertisements
Greetings all. In practice, We've always advertised our space all the way down to /24's but also the aggregate block (the /20 or the /21). Just so there was still reachability to our network in the event that someone made the foolish mistake of filtering lets say prefixes smaller /23... Anyways, I've always thought that was standard practice. And its never been a problem. Until we brought up peering with level 3.. I noticed that while the /24's made it out to the world. The larger counterparts (2 /21's and a /20) did not. So, I start sniffing around. Find that I do indeed see the prefixes in Level 3's looking glass but they aren't handing it off to peers. So, Naturally, I land on this being some kind of prefix filtering issue and open a ticket with Level 3. They tell me this is standard practice. And If I want to see the /20 or /21's make it out to the rest of the world, I need to stop sending the /24's. Does this sound normal? Is what I'm doing (Advertising the aggregate prefix) a good rule of thumb? Any other thoughts? Nick Olsen Network Operations (855) FLSPEED x106
Re: Level 3 BGP Advertisements
Thanks for the input Jon. I should note that is exactly what we are doing. The /24's are actually tagged with the advertise to customers, prepend to peers community. Nick Olsen Network Operations (855) FLSPEED x106 From: Jon Lewis jle...@lewis.org Sent: Wednesday, August 29, 2012 3:48 PM To: Nick Olsen n...@flhsi.com Subject: Re: Level 3 BGP Advertisements On Wed, 29 Aug 2012, Nick Olsen wrote: Anyways, I've always thought that was standard practice. And its never been a problem. Until we brought up peering with level 3.. No...I'd call that global table pollution. In general, there's no reason you should announce your CIDRs and all their /24 subnets. I noticed that while the /24's made it out to the world. The larger counterparts (2 /21's and a /20) did not. So, I start sniffing around. Find that I do indeed see the prefixes in Level 3's looking glass but they aren't handing it off to peers. So, Naturally, I land on this being some kind of prefix filtering issue and open a ticket with Level 3. They tell me this is standard practice. And If I want to see the /20 or /21's make it out to the rest of the world, I need to stop sending the /24's. Does this sound normal? No. I announce to Level3 our IP space and 2 subnets of each CIDR (i.e. /17 + 2 /18 subnets of that /17, etc.), but I use community tags (and other tricks) to mark the more specifics as advertise to [certain] L3 customers only, and let the less specifics out to the world. The only problems I've had with this have been when L3 peers have become customers, and one L3 customer doing something odd (never did find out what) that caused them to effectively null route our space until I kept them from seeing the more specifics (creative abuse of loop detection). Level3's prefix filter for your session should be built based on IRR data. If it's not doing what you want, you probably haven't setup the IRR data properly. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Level 3 BGP Advertisements
I hear you guys, It's done that way for a bit of traffic steering. If I could get away with just the aggregates I would, Trust me. Nick Olsen Network Operations (855) FLSPEED x106 From: Berry Mobley be...@gadsdenst.org Sent: Wednesday, August 29, 2012 3:45 PM To: nanog@nanog.org Subject: Re: Level 3 BGP Advertisements [...] Please, unless you really know why you need to do otherwise, just originate your aggregates. +1
Re: Testing 1gbps bandwidth
Agreed. We actually started hosting our own speedtest.net server in order to get some more consistent results. Still nothing like iperf. But a decent Quick and dirty type of test. Nick Olsen Network Operations (855) FLSPEED x106 From: Nick Hilliard n...@foobar.org Sent: Tuesday, August 14, 2012 11:09 AM To: nanog@nanog.org Subject: Re: Testing 1gbps bandwidth On 14/08/2012 15:43, valdis.kletni...@vt.edu wrote: case trying to use one of the speedtest.net servers - we had a clear 10G path out through like 3 AS's in a row, the bottleneck was speedtest.net's server. :) you'll have to forgive me for being the cynical type, but I gave up on Speedtest the day they reported 146Mbit/sec download over a link which was hard-wired to 100Mbit/sec full duplex, and later that day they reported 2Mbit from another nearby server to the same box. I figured a stddev of 2 orders of magnitude wasn't going to give me figures accurate enough for my requirements. But hey, this is the Internet: ymmv, ianal, lolwut, bbq. Nick
Re: job screening question
+1 I have people waive the I'm Cisco Certified flag in my face all the time. Then proceed to ask me if we have a T1. To the point that it's no longer a valuable achievement in my eyes. I'm certified to perform CPR in the state of Florida... I should go apply for a surgeon position at the local hospital. Nick Olsen Network Operations (855) FLSPEED x106 From: James M Keller jmkel...@houseofzen.org Sent: Thursday, July 05, 2012 1:19 PM To: Oliver Garraux oli...@g.garraux.net, nanog@nanog.org Subject: Re: job screening question On 7/5/2012 1:11 PM, Oliver Garraux wrote: Seems fairly straightforward to me. It'll break path MTU discovery. I would hope someone applying for an IP expert position would know that. Could HR be mangling the question or something? Oliver - Oliver Garraux Check out my blog: www.GetSimpliciti.com/blog Follow me on Twitter: twitter.com/olivergarraux On Thu, Jul 5, 2012 at 1:02 PM, William Herrin b...@herrin.us wrote: Hi folks, I gave my HR folks a screening question to ask candidates for an IP expert position. I've gotten some unexpected answers, so I want to do a sanity check and make sure I'm not asking something unreasonable. And by unexpected I don't mean naively incorrect answers, I mean oh-my-God-how-did-you-get-that-cisco-certification answers. The question was: You implement a firewall on which you block all ICMP packets. What part of the TCP protocol (not IP in general, TCP specifically) malfunctions as a result? My questions for you are: 1. As an expert who follows NANOG, do you know the answer? Or is this question too hard? 2. Is the question too vague? Is there a clearer way to word it? 3. Is there a better screening question I could pass to HR to ask and check the candidate's response against the supplied answer? Thanks, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 You would be surprised by some of the people I get off the street applying for senior network engineering positions who couldn't connect up a SOHO router and a dumb switch and make them work, let alone understand how PMTU discovery works. -- --- James M Keller
re: EBAY and AMAZON
I think it might just be coincidence. I've gotten about 10 of them and haven't been to ebay or amazon in months. Most of them have been for 60 dollar books. Nick Olsen Network Operations (855) FLSPEED x106 From: Brandt, Ralph ralph.bra...@pateam.com Sent: Monday, June 11, 2012 1:28 PM To: nanog@nanog.org Subject: EBAY and AMAZON I have received bogus emails from both of the above on Friday. These look like I bought something that in both cases I did not buy. The EBAY was a golf club for $887 and the Amazon was a novel for $82, far more than I would have spent on either. I think I looked at the novel on Amazon and I remember the golf club came up on a search with something else on Ebay. How this information could get to someone spoofing is a little disconcerting. I have changed EBAY and Paypal Passwords as instructed. Ralph Brandt Communications Engineer HP Enterprise Services Telephone +1 717.506.0802 FAX +1 717.506.4358 Email ralph.bra...@pateam.com 5095 Ritter Rd Mechanicsburg PA 17055
RE: airFiber
It will need perfect line of site. And won't deal with NLOS like most 2/5 ghz gear can. It's 24ghz. They claim 15Km. Maybe in the desert. In any climate with rain, Like our's here in Florida even 2 miles is going to be a stretch as 24ghz will rain fade easy. A great application for this would be like between two buildings requiring highspeed backhaul. (Were talking roof-top to roof-top of maybe a few thousand feet or more between them. Nick Olsen Network Operations (855) FLSPEED x106 From: Drew Weaver drew.wea...@thenap.com Sent: Thursday, March 29, 2012 1:27 PM To: Jared Mauch ja...@puck.nether.net, Eugen Leitl eu...@leitl.org Subject: RE: airFiber I've read that it requires perfect line of sight, which makes it sometimes tricky. Thanks, -Drew -Original Message- From: Jared Mauch [mailto:ja...@puck.nether.net] Sent: Thursday, March 29, 2012 12:45 PM To: Eugen Leitl Cc: NANOG list Subject: Re: airFiber On Thu, Mar 29, 2012 at 06:34:21PM +0200, Eugen Leitl wrote: Claim: 1.4 GBit/s over up to 13 km, 24 GHZ, @3 kUSD/link price point. http://www.ubnt.com/airfiber Yeah, I got this note the other day. I am very interested in hearing about folks experience with this hardware once it ships. I almost posted it in the last-mile thread. Even compared to other hardware in the space the price-performance of it for the bitrate is amazing. I also recommend watching the video they posted: http://www.ubnt.com/themes/ubiquiti/air-fiber-video.html You are leaving out that it's an unlicensed band, so you can use this to have a decent backhaul to your house just by rigging it yourself on each end. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Synology Disk DS211J
It's updates, I've got a 1511+ here and at the office. It phones home to check for updates. I noticed this the day I got it. Blocked the dst IP and that was the only thing that broke. Nick Olsen Network Operations (855) FLSPEED x106 From: Pierre-Yves Maunier na...@maunier.org Sent: Friday, September 30, 2011 8:32 AM To: Jones, Barry bejo...@semprautilities.com Subject: Re: Synology Disk DS211J 2011/9/29 Jones, Barry bejo...@semprautilities.com Hey all. A little off topic, but wanted to share... I purchased a home storage Synology DS1511+. After configuring it on the home net, I did some captures to look at the protocols, and noticed that the DS1511+ is making outgoing connections to 59.124.41.242 (www) and 59.124.41.245 (port 81 89) on a regular basis. These addresses are owned by Synology and Chungwa Telecom in Taiwan. So far, I've not been able to find much information on their support sites, or Synology's wiki, but I wanted to put it out there. Maybe it's for checking new firmware update availability... -- Pierre-Yves Maunier
RE: IPv6 side of www.charter.com has been down since Friday, September 16 5:12 am Central
Takes our HE tunnel to get out. Were also Native with Cogent (Not that it gets us anything..) No dice. [root@bench ~]# wget -6 www.charter.com --2011-09-19 13:53:17-- http://www.charter.com/ Resolving www.charter.com... 2607:f428:3:1:80:80:80:1 Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... Times Out [root@bench ~]# traceroute6 www.charter.com traceroute to www.charter.com (2607:f428:3:1:80:80:80:1), 30 hops max, 40 byte packets 1 (2606:2400:141::1) 1.169 ms 1.157 ms 1.145 ms 2 (2606:2400:222::d) 31.685 ms 36.812 ms 37.104 ms 3 (2606:2400:222::5) 37.387 ms 37.456 ms 37.477 ms 4 brevardwireless-1.tunnel.tserv7.ash1.ipv6.he.net (2001:470:1f0d:c5::1) 123.090 ms 123.371 ms 123.334 ms 5 v104.core1.ash1.he.net (2001:470:0:40::2) 122.542 ms 122.523 ms 122.516 ms 6 10gigabitethernet1-2.core1.atl1.he.net (2001:470:0:1b5::2) 142.508 ms 129.220 ms 131.762 ms 7 2001:470:0:115::2 (2001:470:0:115::2) 131.537 ms 131.696 ms 131.739 ms 8 bbr01sghlga-tge0-2-0-1.ga.sghl.charter.com (2001:506:100:326::1) 143.856 ms bbr01sghlga-tge0-0-0-0.ga.sghl.charter.com (2001:506:100:308::1) 140.164 ms 140.196 ms 9 bbr01blvlil-tge0-3-0-4.il.blvl.charter.com (2001:506:100:42::2) 151.880 ms 152.019 ms 151.955 ms 10 bbr01olvemo-tge0-1-0-6.mo.olve.charter.com (2001:506:100:8::1) 151.669 ms 151.681 ms 151.665 ms 11 bdr01tncomo-tge1-1.mo.tnco.charter.com (2001:506:100:23::2) 149.784 ms 149.851 ms 149.852 ms 12 2001:506:100:6c::2 (2001:506:100:6c::2) 147.953 ms 147.470 ms 147.479 ms 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * Nick Olsen Network Operations (855) FLSPEED x106 From: Frank Bulk frnk...@iname.com Sent: Monday, September 19, 2011 1:38 PM To: PC paul4...@gmail.com Subject: RE: IPv6 side of www.charter.com has been down since Friday, September 16 5:12 am Central I've been told by someone else offline that it's fine for them, too. Last hop according to tcptraceroute6 is Qwest. Anyone else going to www.charter.com (IPv6) through Qwest? nagios:/home/fbulk# tcptraceroute6 www.charter.com traceroute to www.charter.com (2607:f428:3:1:80:80:80:1) from 2607:fe28:0:1000::5, port 80, from port 43838, 30 hops max, 60 bytes packets 1 2607:fe28:0:1003::2 (2607:fe28:0:1003::2) 1.075 ms 1.258 ms 1.857 ms 2 router-core.mtcnet.net (2607:fe28:0:1000::1) 1.625 ms 2.271 ms 1.331 ms 3 sxct.sxcy.mtcnet.net (2607:fe28:11:1002::197) 2.581 ms 1.568 ms 1.215 ms 4 v6-siouxcenter.sxcy.137.netins.net (2001:5f8:7f06::5) 3.347 ms 3.007 ms 2.640 ms 5 v6-ins-db1-te-13-2-219.desm.netins.net (2001:5f8:1:1::1) 7.441 ms 7.121 ms 6.798 ms 6 v6-ins-dc1-et-8-2.desm.netins.net (2001:5f8::1:1) 8.682 ms 8.294 ms 7.910 ms 7 2001:428:3801:210:0:1:0:1 (2001:428:3801:210:0:1:0:1) 20.790 ms 20.447 ms 20.133 ms 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * nagios:/home/fbulk# Frank From: PC [mailto:paul4...@gmail.com] Sent: Monday, September 19, 2011 12:13 PM To: frnk...@iname.com Cc: nanog@nanog.org Subject: Re: IPv6 side of www.charter.com has been down since Friday, September 16 5:12 am Central Works fine here. # wget -6 www.charter.com --2011-09-19 10:24:37-- http://www.charter.com/ Resolving www.charter.com... 2607:f428:3:1:80:80:80:1 Connecting to www.charter.com|2607:f428:3:1:80:80:80:1|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: `index.html' [ = ] 112,940 288K/s in 0.4s 2011-09-19 10:24:43 (288 KB/s) - `index.html' saved [112940] traceroute to www.charter.com (2607:f428:3:1:80:80:80:1), 30 hops max, 80 byte packets 1 2607:f2f8:::1 (2607:f2f8:::1) 18.721 ms 18.699 ms 18.689 ms 2 2001:504:13::1a (2001:504:13::1a) 1.256 ms 1.672 ms 1.428 ms 3 10gigabitethernet1-2.core1.den1.he.net (2001:470:0:15d::1) 26.498 ms 26.486 ms 26.466 ms 4 10gigabitethernet1-1.core1.chi1.he.net (2001:470:0:1af::1) 49.986 ms 49.529 ms 49.521 ms 5 2001:470:0:114::2 (2001:470:0:114::2) 50.105 ms 49.632 ms 49.626 ms 6 bbr02chcgil-tge0-1-0-0.il.chcg.charter.com (2001:506:100:313::1) 55.805 ms 54.254 ms bbr02chcgil-tge0-0-0-0.il.chcg.charter.com (2001:506:100:305::1) 55.880 ms 7 bbr01olvemo-tge0-4-0-4.mo.olve.charter.com (2001:506:100:55::1) 69.465 ms 63.351 ms 63.314 ms 8 bdr01tncomo-tge1-1.mo.tnco.charter.com (2001:506:100:23::2) 60.018 ms 59.597 ms 59.586 ms 9 2001:506:100:6c::2 (2001:506:100:6c::2) 60.251 ms 60.245 ms 60.236 ms 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * On Mon, Sep 19, 2011 at 11:08 AM, Frank Bulk frnk...@iname.com wrote: The IPv6 side of www.charter.com
Re: What do you do when your Home ISP is down?
- Original Message - From: Jon Lewis jle...@lewis.org It can be frustrating talking to their frontline people, but unless you have contacts there in network engineering, what else are you going to do? I just want to put in a tip o' the hat here to the BHN/RoadRunner *business* support people who handle Tampa Bay. I have had to call them, oh, 20 or 30 times in the last 5-7 years, mostly on behalf of clients, and their front line is *sharp*. They understand CIDR, they don't freak out about DNS, and they understand MTR -- hell, some of them *use* MTR. And they don't get scared when you know what you're talking about. Agreed. The same can be said for the Business support here in Central Fl Bright House region. They are generally pretty decent. If you tell them you bypassed the modem and tested. Or it's a problem off your network (routing issue upstream) they don't waste your time with making you do it again. I think the big difference here is the Residential BHN service first sends the call to the national Road Runner help desk. And when you get a level 2 and above, Your talking to a local person. You skip right to local if the sees your modem is dead. Where is the business support is always a local person. /2cents
re: Comcast Bussiness Class and GRE Tunnels
I had to deal with this Exact problem last week. Never got EOIP to work, Spent hours on it. I had to use a GRE Tunnel Which is the same thing. And is only available under RouterOS 5.x+. Came right up when EOIP wouldn't. I don't know how to peg the problem. As PPTP, EOIP, GRE...etc All use the GRE protocol 47. So you would think they all would show the same problem. I never even attempted to contact comcast support as I wasn't about to spend another 3 hours explaining my problem only for them to say they aren't blocking anything and it must be my side.. Nick Olsen Network Operations (855) FLSPEED x106 From: Nate Burke n...@blastcomm.com Sent: Tuesday, July 26, 2011 11:07 AM To: NANOG list nanog@nanog.org Subject: Comcast Bussiness Class and GRE Tunnels Hello, I'm hoping that someone here might have run into a similar issue and might be able to offer me some pointers. I have a customer that I am providing redundant paths to, one link over a microwave connection, and a backup link over a Comcast Business Class Connection. Everything on the Microwave link is working fine. On the Comcast Connection, I have a Static IP from Comcast, and I want to setup a vendor specific GRE tunnel (Mikrotik EoIP) from my NOC to the Comcast Static IP Address. It looks like the SPI Firewall inside the SMC Gateway required by comcast is blocking the GRE packets, I'm basing this on the fact that when I power cycle the modem, I get 1 ICMP Packet through the GRE Tunnel while the modem is booting up, then it stops again. I have gotten to Tier2 support who swears that all Firewalls on the SMC Gateway are disabled. As a workaround, I was able to establish a PPTP tunnel to my NOC, however it seems like the tunnel will only run for a few hours, then becomes slow to the point of being unusable. In my mind this would be no different than setting up a permanent VPN back to a corporate office, which I would think happens all the time, so I'm not sure why I'm running into issues with it. Anyone with Insights or comments would be appreciated. Thanks, Nate Burke
Cogent IPv6
I'm sure someone here is doing IPv6 peering with cogent. We've got a Gig with them, So they don't do that dual peering thing with us. (They do it on another 100Mb/s circuit we have... I despise it.) Just kind of curious how they go about it. Do they issue you a small IPv6 block for your interface, just like they do for IPv4? Is it a separate session? Any things to be aware of before pulling the trigger on it? (Other then them not having connectivity to HE's IPv6 side of things, Wish they would fix that already...) Nick Olsen Network Operations (855) FLSPEED x106
re: Cogent HE
Correct, The only way around this currently is to peer with both cogent and HE. If you have cogent, You can 6to4 w/BGP with HE. I would consider that just a patch for the problem. I would do it just for the reachablility. Nick Olsen Network Operations (855) FLSPEED x106 From: Dennis Burgess dmburg...@linktechs.net Sent: Wednesday, June 08, 2011 3:45 PM To: nanog@nanog.org Subject: Cogent HE Just noted that cogent does not have a IPv6 route to any subnet in HE, and HE does not have any routes to Cogent! Looks like we have different Global IPv6 tables? Or does Cogent just NOT peer IPv6 peer with anyone else! Dennis
Re: (OT) Firearms Was: UN declares Internet access a human right
Don't leave the house without my Glock 23 on my side. Truck always has a loaded 12ga in it. In the house, I've got a handful of pistols and my SR-556 (AR-15) in the Guns and servers closet. I've had people call me Paranoid more then once. My stance is Better to have it and not need it, Then need it and not have it. By banning guns from a community, Your only taking them out of the hands of law abiding citizens. Not like most criminals get guns via legal channels in the first place. -Nick Olsen From: Daniel Seagraves dseag...@humancapitaldev.com Sent: Monday, June 06, 2011 10:34 AM To: nanog@nanog.org Subject: Re: (OT) Firearms Was: UN declares Internet access a human right On Jun 6, 2011, at 8:41 AM, valdis.kletni...@vt.edu wrote: Nice try, but the human right you just made a case for is the right to rid yourself of criminals and despots. A fundamental right for citizens to have firearms does *not* automatically follow. Yes, despots usually need to be removed by force. What Ghandi showed was that the force didn't have to be military - there are other types of force that work well too... I believe that as a law-abiding citizen, I should have the right to be at least as well-armed as the average criminal. If the average criminal has access to firearms, then I should have that option as well. I should not be forced into a disadvantage against criminals by virtue of my compliance with the law. Once law enforcement is effective enough to prevent the average criminal from having access to firearms, then the law-abiding population can be compelled to disarm. This stance can result in an escalation scenario in which criminals strive to remain better-armed than their intended victims, but the job of law enforcement is to prevent them from being successful. At present, the average criminal in my area does not have firearms, and so I do not own one. Gun crime is on the increase, however, so this situation may change.
re: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a human right
I've got a 4 inch Springfield XD service model in .45ACP, I actually prefer the .40 round. Its a bit better at inducing Hydrostatic shock just because of its velocity:energy ratio. The handgun just to get me to the bigger guns :D -Nick Olsen From: Andrew Kirch trel...@trelane.net Sent: Monday, June 06, 2011 11:42 AM To: nanog@nanog.org Subject: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a human right nothing like 40 short and wimpy! Might I interest you in a 45? :) On 6/6/2011 11:37 AM, Nick Olsen wrote: Don't leave the house without my Glock 23 on my side. Truck always has a loaded 12ga in it. In the house, I've got a handful of pistols and my SR-556 (AR-15) in the Guns and servers closet. I've had people call me Paranoid more then once. My stance is Better to have it and not need it, Then need it and not have it. By banning guns from a community, Your only taking them out of the hands of law abiding citizens. Not like most criminals get guns via legal channels in the first place. -Nick Olsen From: Daniel Seagraves dseag...@humancapitaldev.com Sent: Monday, June 06, 2011 10:34 AM To: nanog@nanog.org Subject: Re: (OT) Firearms Was: UN declares Internet access a human right On Jun 6, 2011, at 8:41 AM, valdis.kletni...@vt.edu wrote: Nice try, but the human right you just made a case for is the right to rid yourself of criminals and despots. A fundamental right for citizens to have firearms does *not* automatically follow. Yes, despots usually need to be removed by force. What Ghandi showed was that the force didn't have to be military - there are other types of force that work well too... I believe that as a law-abiding citizen, I should have the right to be at least as well-armed as the average criminal. If the average criminal has access to firearms, then I should have that option as well. I should not be forced into a disadvantage against criminals by virtue of my compliance with the law. Once law enforcement is effective enough to prevent the average criminal from having access to firearms, then the law-abiding population can be compelled to disarm. This stance can result in an escalation scenario in which criminals strive to remain better-armed than their intended victims, but the job of law enforcement is to prevent them from being successful. At present, the average criminal in my area does not have firearms, and so I do not own one. Gun crime is on the increase, however, so this situation may change.
RE: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access ahuman right
Hence the (OT) tag. -Nick Olsen From: Mike Rae mike@sjrb.ca Sent: Monday, June 06, 2011 12:20 PM To: nanog@nanog.org Subject: RE: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access ahuman right Hi All : How is this an operational related discussion ? Perhaps it can be taken to more appropriate forum. thanks Mike -Original Message- From: Nick Olsen [mailto:n...@flhsi.com] Sent: Monday, June 06, 2011 10:15 AM To: Andrew Kirch; nanog@nanog.org Subject: re: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access ahuman right I've got a 4 inch Springfield XD service model in .45ACP, I actually prefer the .40 round. Its a bit better at inducing Hydrostatic shock just because of its velocity:energy ratio. The handgun just to get me to the bigger guns :D -Nick Olsen From: Andrew Kirch trel...@trelane.net Sent: Monday, June 06, 2011 11:42 AM To: nanog@nanog.org Subject: [SPAM-Low] Re: (OT) Firearms Was: UN declares Internet access a human right nothing like 40 short and wimpy! Might I interest you in a 45? :) On 6/6/2011 11:37 AM, Nick Olsen wrote: Don't leave the house without my Glock 23 on my side. Truck always has a loaded 12ga in it. In the house, I've got a handful of pistols and my SR-556 (AR-15) in the Guns and servers closet. I've had people call me Paranoid more then once. My stance is Better to have it and not need it, Then need it and not have it. By banning guns from a community, Your only taking them out of the hands of law abiding citizens. Not like most criminals get guns via legal channels in the first place. -Nick Olsen From: Daniel Seagraves dseag...@humancapitaldev.com Sent: Monday, June 06, 2011 10:34 AM To: nanog@nanog.org Subject: Re: (OT) Firearms Was: UN declares Internet access a human right On Jun 6, 2011, at 8:41 AM, valdis.kletni...@vt.edu wrote: Nice try, but the human right you just made a case for is the right to rid yourself of criminals and despots. A fundamental right for citizens to have firearms does *not* automatically follow. Yes, despots usually need to be removed by force. What Ghandi showed was that the force didn't have to be military - there are other types of force that work well too... I believe that as a law-abiding citizen, I should have the right to be at least as well-armed as the average criminal. If the average criminal has access to firearms, then I should have that option as well. I should not be forced into a disadvantage against criminals by virtue of my compliance with the law. Once law enforcement is effective enough to prevent the average criminal from having access to firearms, then the law-abiding population can be compelled to disarm. This stance can result in an escalation scenario in which criminals strive to remain better-armed than their intended victims, but the job of law enforcement is to prevent them from being successful. At present, the average criminal in my area does not have firearms, and so I do not own one. Gun crime is on the increase, however, so this situation may change.
Downstream Usage-BGP Communites
Greetings NANOG, Was hoping to gain some insight into common practice with using BGP Communities downstream. For instance: We peer with AS100 (example) AS100 peers with TW Telecom (AS4323). Since I happen to know that AS100 doesn't sanitize the communities I send with my routes. I can take advantage of TW Telecom's BGP communities for traffic engineering. Such as 4323:666 (Keep in TWTC Backbone). Would this be something that is generally frowned upon? Still under the assumption that the communities aren't scrubbed off my routes. Could I do this with other AS's beyond TW Telecom? Such as TW's peering with Global Crossing (AS3549)? Nick Olsen Network Operations (855) FLSPEED x106
Re: Downstream Usage-BGP Communites
Ah, Sorry for the confusion. We have a mutual agreement with AS100 (call it transit or peering) we send them full routes, They send us full routes. AS100 is a transit customer of AS4323. I understand I would be at the mercy of how people have things setup. I do know for a fact I'm not filtered by AS100 as I've already tested it. Thanks to everyone for the info so far. Nick Olsen Network Operations (855) FLSPEED x106 From: Richard A Steenbergen r...@e-gerbil.net Sent: Tuesday, May 10, 2011 6:27 PM To: Nick Olsen n...@flhsi.com Subject: Re: Downstream Usage-BGP Communites On Tue, May 10, 2011 at 05:52:39PM -0400, Nick Olsen wrote: Greetings NANOG, Was hoping to gain some insight into common practice with using BGP Communities downstream. For instance: We peer with AS100 (example) AS100 peers with TW Telecom (AS4323). Since I happen to know that AS100 doesn't sanitize the communities I send with my routes. I can take advantage of TW Telecom's BGP communities for traffic engineering. Such as 4323:666 (Keep in TWTC Backbone). Would this be something that is generally frowned upon? Still under the assumption that the communities aren't scrubbed off my routes. Could I do this with other AS's beyond TW Telecom? Such as TW's peering with Global Crossing (AS3549)? Well first off, if you're using the words peers with in the normal sense, your routes would never propagate to AS4323 in the first place. Assuming what you actually mean is that at least one of those sessions is a transit feed, essentially all (non-stupid) networks will filter their own TE communities from their transits/peers, so the odds of this working are almost non-existant. You also have about a 50/50 shot of AS100 stripping your communities before they even make it to AS4323 (or any other network). Personally my belief is that this is a bad thing, and you should only filter communities in your own name-space (i.e. $YOURASN:*), but this doesn't stop a large number of obnoxious networks from doing it anyways. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
re: Bright House residential IPv6
Bright House does Not provide any IPv6 on any service at this time. It looks like they are allocated a prefix from ARIN, But They do not announce it. Expect them to be the last to support it. Nick Olsen Network Operations (855) FLSPEED x106 From: Thomas York strate...@fuhell.com Sent: Monday, May 02, 2011 10:17 AM To: nanog@nanog.org Subject: Bright House residential IPv6 I'm a new Bright House residential customer and I have their new 40/5 'Lightning' service, which is rumored to have free native IPv6. I've called them, but of course no one I talked to knew anything about IPv6. Do any of you have this service and have native? If you do, what did you do to get it activated for your line? Thomas York
IPv6 Prefix announcing
Greetings NANOG, I've always been under the impression its best practice to only announce prefixes of a /24 and above when it comes to IPv4 and BGP. I was wondering if something similar had been agreed upon regarding IPv6. And if That's the case, What's the magic number? /32? /48? /64? Nick Olsen Network Operations (855) FLSPEED x106
re: ARIN and IPv6 Requests
We requested our initial allocation without any such questions. Is this your initial or additional? Nick Olsen Network Operations (855) FLSPEED x106 From: adw...@dstsystems.com Sent: Thursday, February 10, 2011 2:38 PM To: nanog@nanog.org Subject: ARIN and IPv6 Requests Why does ARIN require detailed usage of IPv4 space when requesting IPv6 space? Seems completely irrelevant to me. -- Adam Webb EN ES Team desk: 816.737.9717 cell: 916.949.1345 --- The biggest secret of innovation is that anyone can do it. --- - Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
Network Naming
Whats the rule of thumb for naming gear these days (routers,switches...etc). Or is there one? looks like level3 does something like interface.routertype.location.level3.net Nick Olsen Network Operations (855) FLSPEED x106
Looking for fiber
We are looking for fiber in the Port St Lucie/Stuart area of Florida, Maybe as north as Fort Pierce. Anyone have, Or know who has fiber in this area? Feel free to hit me on or offlist. Thanks. Nick Olsen Network Operations (855) FLSPEED x106
IPv6
Curious as to who is running IPv6 with TW Telecom or Cogent. I'm wanting to turn up native IPv6 with them, And wanted to hear thoughts/experiences. I assume it should be a non-event. We've already got a prefix from arin that we are going to announce. Nick Olsen Network Operations (855) FLSPEED x106
Re: IPv6
TW Telecom, Not Time Warner Cable. And TW Telecom already told me it was a simple change order with a NRC of 25.00 Haven't talked to cogent about it yet. Nick Olsen Network Operations (855) FLSPEED x106 From: Jon Auer j...@tapodi.net Sent: Thursday, November 18, 2010 5:19 PM To: nanog@nanog.org Subject: Re: IPv6 Technically it was a non-event. Layer 8 wise, they refused to turn up IPv6 without a renewal or new order. Time Warner Cable is demanding a new order and additional costs to support V6. On Thu, Nov 18, 2010 at 3:39 PM, Nick Olsen n...@flhsi.com wrote: Curious as to who is running IPv6 with TW Telecom or Cogent. I'm wanting to turn up native IPv6 with them, And wanted to hear thoughts/experiences. I assume it should be a non-event. We've already got a prefix from arin that we are going to announce. Nick Olsen Network Operations (855) FLSPEED x106
Re: IPv6
Ah, I'm always quick to jump to the TWT !=TWC point. As many people I talk to get that wrong. But yes, Great data point. Seems like most of the bigger upstreams support IPv6. Nick Olsen Network Operations (855) FLSPEED x106 From: Jon Auer j...@tapodi.net Sent: Thursday, November 18, 2010 5:36 PM To: nanog@nanog.org Subject: Re: IPv6 Good to know about TWT, and yes, I know that TWT != TWC... Figured it was a good datapoint considering the concurrent discussion of providers charging for v6... On Thu, Nov 18, 2010 at 4:24 PM, Nick Olsen n...@flhsi.com wrote: TW Telecom, Not Time Warner Cable. And TW Telecom already told me it was a simple change order with a NRC of 25.00 Haven't talked to cogent about it yet. Nick Olsen Network Operations (855) FLSPEED x106 From: Jon Auer j...@tapodi.net Sent: Thursday, November 18, 2010 5:19 PM To: nanog@nanog.org Subject: Re: IPv6 Technically it was a non-event. Layer 8 wise, they refused to turn up IPv6 without a renewal or new order. Time Warner Cable is demanding a new order and additional costs to support V6. On Thu, Nov 18, 2010 at 3:39 PM, Nick Olsen n...@flhsi.com wrote: Curious as to who is running IPv6 with TW Telecom or Cogent. I'm wanting to turn up native IPv6 with them, And wanted to hear thoughts/experiences. I assume it should be a non-event. We've already got a prefix from arin that we are going to announce. Nick Olsen Network Operations (855) FLSPEED x106
Re: IPv6
That's what I'm hearing. Cogent refuses to peer with HE via IPv6. So cogent IPv6 Customers currently can not hit things at HE. And they can't do anything about it. Besides 6to4 tunneling and BGP peering with HE (or native, If they can). Nick Olsen Network Operations (855) FLSPEED x106 From: Mike Tancsa m...@sentex.net Sent: Thursday, November 18, 2010 5:45 PM To: Lee Riemer lrie...@bestline.net Subject: Re: IPv6 On 11/18/2010 5:14 PM, Lee Riemer wrote: Try tracerouting to 2001:500:4:13::81 (www.arin.net) or 2001:470:0:76::2 (www.he.net) via Cogent. Interesting. I noticed a similar issue with ipv6.cnn.com today. I dont see it via TATA, but see it via Cogent. So whats the story behind it and ARIN not being seen through cogent ? Is it due to no v6 relation bewtween he.net and Cogent ? 2620:0:2200:8::::8901 (whats with the crazy 8s?) see http://lg.as6453.net/lg/ Router: gin-mtt-mcore3 Site: CA, Montreal - MTT, TATA COMM. INT. CENTER Command: traceroute ipv6 2620:0:2200:8::::8901 Tracing the route to 2620:0:2200:8::::8901 1 * * * 2 * * * 3 * * * 4 * * * ---Mike
re: AS path question.
They are prepending routes. Looks like both 43022 are prepending, As well as 47359...Multiple times... They do this to make that route look bad so it comes in other transit they have. Nick Olsen Network Operations (855) FLSPEED x106 From: Greg Whynott greg.whyn...@oicr.on.ca Sent: Wednesday, November 10, 2010 3:23 PM To: nanog@nanog.org list nanog@nanog.org Subject: AS path question. Recently I adjusted the maxas-limit option on our router,logs started reporting routes being refused because the AS path is to long. seems to work as expected. when I looked at the logs I was a bit confused at what i was looking at... why is it there are multiple AS's in the path that appear to be the same AS? I expected an AS path comprised of mostly unique ASs. instead of this: 476330: Nov 10 14:55:07.247 EDT: %BGP-6-ASPATH: Long AS path 549 26677 6939 21011 43022 43022 43022 43022 43022 47359 47359 47359 47359 47359 47359 47359 47359 received from isp router: More than configured MAXAS-LIMIT i expected it would look more like: 476330: Nov 10 14:55:07.247 EDT: %BGP-6-ASPATH: Long AS path 549 26677 6939 21011 43022 47359 received from . .. . thanks for your time again, greg -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.
re: Cell sites
Well, I'm not sure if there is a database of who is actually colo'ed on a tower. But as for who a tower is owned by, The FCC database works. They also have a cool google earth file that will show you the location of all of them http://www.fccinfo.com/fccinfo_google_earth.php Nick Olsen Network Operations (855) FLSPEED x106 From: harbor235 harbor...@gmail.com Sent: Tuesday, October 26, 2010 11:47 AM To: NANOG list nanog@nanog.org Subject: Cell sites I am hoping someone can guide me to a internet resource that provides information on newly contstructed cell sites and what provider they are affiliated with? I did some google fu and found a couple sites like antennasearch,towersource etc still no joy, in all cases this new tower does not exist. thanx in advance, harbor235 ;}
re: Anyone can share the Network card experience
IMHO, Nothing beats a good intel NIC. I'm a big fan of the intel pro/1000GT. In terms of performance, I think it is more determined by the card chipset. Nick Olsen Network Operations (877) 804-3001 x106 From: Deric Kwok deric.kwok2...@gmail.com Sent: Tuesday, October 05, 2010 10:01 AM To: nanog list nanog@nanog.org Subject: Anyone can share the Network card experience Hi Anyone can share the Network card experience ls onborad PCI Expresscard better or Plug in slot PCI Express card good? How are their performance in Gig transfer rate? Thank you so much
re: do you use SPF TXT RRs? (RFC4408)
We use SPF. Lots of the bigger guys require it. Along with DK/DKIM signing. In our spam weight based filtering, if it hardfails it drops it, softfail(no spf record) we don't add or remove points at all. If it passes SPF we remove a few points of the spam weight. Nick Olsen Network Operations (877) 804-3001 x106 From: Greg Whynott greg.whyn...@oicr.on.ca Sent: Monday, October 04, 2010 12:48 PM To: nanog@nanog.org list nanog@nanog.org Subject: do you use SPF TXT RRs? (RFC4408) A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record. I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. When a client's email doesn't arrive somewhere, we will hear about it quickly, and its investigated/reported upon. I'm not opposed to putting one in our DNS, and probably will now - for completeness/best practice sake.. how many of you are using SPF records? Do you have an opinion on their use/non use of? take care, greg
re: Akamai Traffic Spikes
Didn't see any spikes here, But from the looks of that graph something sure happened. It was huge, And only for a short period, Strange. Nick Olsen Network Operations (877) 804-3001 x106 From: Scott, Robert D. rob...@ufl.edu Sent: Monday, October 04, 2010 3:51 PM To: nanog@nanog.org nanog@nanog.org Subject: Akamai Traffic Spikes We were trying to diagnose an issue we had around 1 PM EDST, and were looking at net flow data. The data indicated a significant change in our traffic patterns, all coming from Akamai address space. The Akamai utilization graphs show a near doubling of retail traffic in the same time period that we had traffic spikes. Does anybody have any idea what caused such a major surge in traffic? http://www.akamai.com/html/technology/nui/retail/charts.html Robert D. Scott rob...@ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services352-392-2061 CNS Phone Tree University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611321-663-0421 Cell 3216630...@messaging.sprintpcs.com
Re: Transporting QinQ across a Layer 2 link locked at 1518 octets AND across a Layer 3 link
Only input I can give is on EOIP tunnels and MTU. Scenario is we had 1 remote router running, Tunneled back to our network using EOIP so that the remote network could use our ip space. Don't remember how I figured it out, But I was using the MTU of 1458 (On the EOIP interface). Everything was great, But weird things started happening. Certain sites wouldn't load, MSN.cometc it was strange. Jacking it back up to 1500 flat fixed it. Nick Olsen Network Operations (877) 804-3001 x106 From: Francois Menard franc...@menards.ca Sent: Sunday, September 12, 2010 10:13 PM To: Francois Menard franc...@menards.ca Subject: Re: Transporting QinQ across a Layer 2 link locked at 1518 octets AND across a Layer 3 link Oops two typos - sunday evening casualties. On 2010-09-12, at 10:06 PM, Francois Menard wrote: Folks, Question #1: Is it possible for me to put an MPLS router on both ends of a circuit leased from a transport service provider which does not support QinQ (i.e. packets of 1526 bytes), and which requires us to tag traffic onto a well specified set of VLANs (i.e. if we want two VLANs, the service provider tells us which two VLANs to use). I was thinking of lowering the MTU size on my MPLS router such that I could do QinQ over VPLS, over MPLS, over Ethernet transport locked at @ 1514 octets. I would imagine that my effective IPv4 payload would be reduced to something like (not taking into account CRC removed in the Ethernet driver) 1514 minus 8 bytes for MPLS label minus 4 bytes for VPLS control word minus 4 bytes for VLAN tag #1 minus 4 bytes for VLAN tag #2 = 1514 -8 -4 -4 -4 -4 = 1490 octets So if I set my MTU on my MPLS router at 1490 octets and send QinQ over VPLS over , wouldn't that allow for all of the above mentioned overhead to pile-up without exceeding the 1514 octets size allowed by my transport provider ? So if I set my MTU on my MPLS router at 1490 octets and send QinQ over VPLS over MPLS over Ethernet, wouldn't that allow for all of the above mentioned overhead to pile-up without exceeding the 1514 octets size allowed by my transport provider ? Question #2: I have another link, which is restricted by the transport service provider, which is an MPLS-VPN service, and which does not support QinQ, nor supports layer 2 bridging. An option available to me is to use an EoIP tunnel on a Mikrotik RouterOS router, which maps Ethernet over GRE over IP, causing some 28 octets of overhead. This is proprietary to Mikrotik. So in this case, assuming that I want to do something as dangerous as: QinQ over VPLS over MPLS over Ethernet over EoIP (over GRE, over IP) And accordingly set my MTU to: 1480 (from above) minus 28 octets (Ethernet over GRE over IP) = 1452 octets 1490 (from above) minus 28 octets (Ethernet over GRE over IP) = 1462 octets So if I set my MTU on my MPLS router at 1452 octets, wouldn't that allow for all of the above mentioned overhead to be successfully transported across an IP layer 3 circuit, effectively ending up with 1462 octets QinQ over MPLS over Ethernet over IP ? What are the consequences of setting the MTU as low as 1452 octets? What applications end-up breaking ? 1462 octets -=Francois=-
Level3 Contact
Anyone have a Level3 sales contact? I've called the 800 number and was told I would get a call in 48 hours, a week later, and a second call into them and I still haven't gotten a call back. Nick Olsen Network Operations (321) 205-1100 x106
re: Did your BGP crash today?
No down time here, Would have been all over the news and everything if it really do crash the internet. Nick Olsen Network Operations (321) 205-1100 x106 From: Kasper Adel karim.a...@gmail.com Sent: Friday, August 27, 2010 1:27 PM To: NANOG list nanog@nanog.org Subject: Did your BGP crash today? Havent seen a thread on this one so thought i'd start one. Ripe tested a new attribute that crashed the internet, is that true? Kim
Re: Did your BGP crash today?
Well played, Sir. Nick Olsen Network Operations (321) 205-1100 x106 From: valdis.kletni...@vt.edu Sent: Friday, August 27, 2010 1:32 PM To: Kasper Adel karim.a...@gmail.com Subject: Re: Did your BGP crash today? On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said: Havent seen a thread on this one so thought i'd start one. Ripe tested a new attribute that crashed the internet, is that true? If it in fact crashed the internet, as opposed to gave a few buggy routers here and there indigestion, you wouldn't be posting to NANOG looking for confirmation. :)
Re: Numbering nameservers and resolvers
So lets say that you have multiple DNS resolvers in the same ip space that you advertise from multiple locations. All would be fine for the most part. But if you had a location equidistant network wise from two POP's wouldn't it load balance and possibly break some TCP sessions? How would someone get around this? This is also what OpenDNS does from what I understand. Nick Olsen Network Operations (321) 205-1100 x106 From: Doug Barton do...@dougbarton.us Sent: Tuesday, August 17, 2010 2:12 PM To: Sven Olaf Kamphuis s...@cb3rob.net Subject: Re: Numbering nameservers and resolvers On 08/17/2010 05:11, Sven Olaf Kamphuis wrote: tcp/zonetransfer not working reliably is no longer a problem TCP is a MUST for DNS. It's used as a fallback in the normal resolution process if an answer can't fit in a UDP packet for whatever reason. This is true even for common things like large A record lists, but is only becoming more frequent in the age of DNSSEC, , etc. It is unfortunately even more necessary than we had hoped it would be due to many local network operators not getting the memo regarding EDNS. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso
Re: IPv4 Exhaustion...
We get them pretty often. Always the same email with a different movie and IP. If its one of our hotspots or open AP's. We just ignore it for the most part. If its a res/commercial customer we contact them and let them know someone is watching. Never has gone past the cookie cutter email we get from media sentry. Nick Olsen Network Operations (321) 205-1100 x106 From: David E. Smith d...@mvn.net Sent: Friday, July 23, 2010 1:46 PM To: nanog@nanog.org Subject: Re: IPv4 Exhaustion... On Fri, Jul 23, 2010 at 12:11, Positively Optimistic positivelyoptimis...@gmail.com wrote: How do ISPs handle RIAA notices when NATTING customers.. ? We have several customers that don't require public address space that could be moved to private.. We're reluctant to make the move due to legal liabilities.. On a related note, what's the best way to handle RIAA/MPAA requests for end-users that intentionally run open APs, especially when the notices don't show up for days or weeks (by which time the offender, a hotel guest, has long since moved on)? David Smith MVN.net
re: Rate Limiting on Cisco Router
That's strange, Are you paying for a CIR of 80Mb/s? Normally they only leave the limiting up to you if its more of a burstable connection, Like you pay for 80Mb/s but its a full line rate interface and its billed per Mb/s over 80 on a 95th percentile scheme. If that is the case you can safely go over 80Mb/s for a certian amount of time per month, Assuming its billed monthly. Nick Olsen Network Operations (321) 205-1100 x106 From: Alan Bryant a...@gtekcommunications.com Sent: Thursday, July 08, 2010 6:07 PM To: nanog@nanog.org Subject: Rate Limiting on Cisco Router Thanks again for all the responses to my previous post. We have a Cisco 7206VXR router with IOS of 12.4(12) and a PA-POS-1OC3 card ofr our OC3. The problem we have now is that we are only paying for 80 MB/s of the OC-3, and the ISP is leaving the capping of it up to us. I have googled and the only things I can find is that you can not do a real cap on this type of interface. We have tried the rate-limit command with various parameters and we are unable to keep it at 80. I have read that this is not the correct way to do it, but I'm not sure what is. Any advice? Pointers appreciated. -- Alan Bryant | Systems Administrator Gtek Computers Wireless, LLC. a...@gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405
