June 2015 - Test - lists.nanog.org

Re: Regulators now regulating Internet History? Really?
by Larry Sheldon 09 Jun '15

09 Jun '15

On 6/8/2015 08:46, Jay Farrell via NANOG wrote: > The article is nothing more or less than what you'd expect to read from the > American Enterprise Institute. "All regulation totally sucks" is their only > message ever. Unaddressed so far, is the appearance that the regulator quoted (without apparent bias from the AEI author) has "tinkered" with the history. -- sed quis custodiet ipsos custodes? (Juvenal)

1 0

Assistance troubleshooting a route between my network and Comcast in Georgia
by Drew Hastings 08 Jun '15

08 Jun '15

I'm new to this list, and I apologize in advance if this is an inappropriate submission. I'm having an issue with my traffic routing between my network and Comcast in the Georgia region. Aside from this specific ISP and that geographic region, I haven't seen any issues with traffic. My network is 198.91.24.0/21 ASN 32647 Is there a particular contact to get in touch with someone at Comcast for assistance? What can I do, if anything, to resolve this from my end? Here is a successful traceroute, which doesn't originate from my network, going to a router I'd like to reach from my network. This network shares our upstream providers, which is why I've used it to compare. 4 te0-0-0-0.nr11.b023003-0.phx02.atlas.cogentco.com (38.88.34.21) 0.973 ms 1.013 ms te0-0-0-1.nr11.b023003-0.phx02.atlas.cogentco.com (38.104.116.73) 1.052 ms 5 154.24.18.197 (154.24.18.197) 2.200 ms 154.24.18.201 (154.24.18.201) 2.229 ms 154.24.18.205 (154.24.18.205) 0.926 ms 6 be2124.ccr21.phx02.atlas.cogentco.com (66.28.4.193) 2.360 ms 2.737 ms 2.809 ms 7 be2331.ccr22.lax01.atlas.cogentco.com (154.54.30.193) 12.796 ms be2330.ccr21.lax01.atlas.cogentco.com (154.54.30.189) 14.156 ms 14.120 ms 8 be2019.ccr21.lax04.atlas.cogentco.com (154.54.88.10) 14.109 ms 13.642 ms be2017.ccr21.lax04.atlas.cogentco.com (154.54.0.237) 13.916 ms 9 be-201-pe01.losangeles.ca.ibone.comcast.net (50.248.118.249) 15.341 ms 15.304 ms 15.290 ms 10 he-0-4-0-1-cr02.losangeles.ca.ibone.comcast.net (68.86.85.29) 13.283 ms he-0-4-0-0-cr02.losangeles.ca.ibone.comcast.net (68.86.85.13) 13.119 ms he-0-4-0-1-cr02.losangeles.ca.ibone.comcast.net (68.86.85.29) 13.238 ms 11 be-11315-cr01.dallas.tx.ibone.comcast.net (68.86.85.141) 38.441 ms 38.433 ms 38.354 ms 12 be-11314-cr02.56marietta.ga.ibone.comcast.net (68.86.85.22) 55.604 ms 56.516 ms 57.727 ms 13 et-2-0-0-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.89.66) 55.706 ms 54.596 ms 54.688 ms 14 xe-10-3-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.86.106.58) 54.073 ms 54.066 ms xe-11-3-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.86.106.90) 54.607 ms 15 xe-9-3-0-sur02.a2atlanta.ga.atlanta.comcast.net (68.86.110.233) 54.793 ms 55.331 ms 55.320 ms The traceroute reaches 68.86.110.233 successfully without issue. That same traceroute, from my network takes a similar route, but ultimately fails: 6 te0-0-1-1.nr11.b023003-0.phx02.atlas.cogentco.com (38.104.116.185) 0.789 ms 0.720 ms te0-0-0-0.nr11.b023003-0.phx02.atlas.cogentco.com (38.88.34.21) 0.688 ms 7 154.24.18.201 (154.24.18.201) 2.295 ms 2.288 ms 154.24.18.205 (154.24.18.205) 1.062 ms 8 be2125.ccr22.phx02.atlas.cogentco.com (154.54.1.101) 1.248 ms 1.618 ms be2124.ccr21.phx02.atlas.cogentco.com (66.28.4.193) 2.601 ms 9 be2331.ccr22.lax01.atlas.cogentco.com (154.54.30.193) 13.444 ms be2330.ccr21.lax01.atlas.cogentco.com (154.54.30.189) 14.857 ms 13.868 ms 10 be2017.ccr21.lax04.atlas.cogentco.com (154.54.0.237) 13.942 ms be2019.ccr21.lax04.atlas.cogentco.com (154.54.88.10) 15.295 ms be2017.ccr21.lax04.atlas.cogentco.com (154.54.0.237) 13.176 ms 11 be-201-pe01.losangeles.ca.ibone.comcast.net (50.248.118.249) 14.048 ms 11.872 ms 11.864 ms 12 he-0-4-0-2-cr02.losangeles.ca.ibone.comcast.net (68.86.85.93) 14.454 ms he-0-4-0-1-cr02.losangeles.ca.ibone.comcast.net (68.86.85.29) 14.267 ms he-0-4-0-2-cr02.losangeles.ca.ibone.comcast.net (68.86.85.93) 12.086 ms 13 be-11315-cr01.dallas.tx.ibone.comcast.net (68.86.85.141) 35.729 ms 35.723 ms 39.375 ms 14 * * * 15 * * * 16 * * * A traceroute back to my network on Comcast in that region fails in a similar fashion: 1 <1 ms 1 ms 1 ms 192.168.10.1 2 29 ms 8 ms 10 ms 96.120.4.213 3 10 ms 7 ms 9 ms xe-5-1-0-sur01.b2marietta.ga.atlanta.comcast.net [68.85.173.93] 4 11 ms 13 ms 12 ms xe-4-1-18-0-ar01.b0atlanta.ga.atlanta.comcast.ne t [68.86.106.190] 5 16 ms 19 ms 17 ms he-0-4-0-6-cr02.56marietta.ga.ibone.comcast.net [68.86.90.81] 6 * * * Request timed out. 7 * * * Request timed out. 8 * * * Request timed out. It seems like xe-5-1-0-sur01.b2marietta.ga.atlanta.comcast.net is not routing this traffic. I appreciate any assistance that can be provided. Thank you for taking the time to read this.

1 0

Re: eBay is looking for network heavies...
by Scott Weeks 08 Jun '15

08 Jun '15

--- Valdis.Kletnieks(a)vt.edu wrote: On Mon, 08 Jun 2015 17:10:25 -0700, Jeroen van Aart said: > You sort of nailed it though. I think ready knowledge > about the internals of utilities such as traceroute > or ping is nice to have, however if you don't know Describe the top 3 gotchas of using traceroute to diagnose network problems. :) That's something you're not likely to look up if you're in the middle of a connectivity event.... ------------------------------------------------ It's these types of questions that're hard for some in an interview even though they know their stuff. One might get nervous wondering if (s)he gave the interviewer the three that they're looking for and stumble on the next question even though the next question seems easy to the interviewer. I'd ask the question a little differently: I have a network problem between 2 sites and there is a firewall between them that is blocking ICMP and nothing else. How would you complete a traceroute to troubleshoot? (Use BSD or tcptraceroute, for example) Then, it turns the questioning into operational. scott

2 1

T-mobile contact?
by Anne Mitchell 08 Jun '15

08 Jun '15

Is there anyone from T-mobile here, or does anybody have a T-mobile contact with whom they can put me in touch? Anne Anne P. Mitchell, Esq. CEO/President ISIPP SuretyMail Email Reputation, Accreditation & Certification http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Member, California Bar Cyberspace Law Committee Member, Colorado Cybersecurity Consortium Ret. Professor of Law, Lincoln Law School of San Jose 303-731-2121 | amitchell(a)isipp.com | @AnnePMitchell | Facebook/AnnePMitchell

1 0

Re: NANOG Digest, Vol 89, Issue 8
by Ramy Hashish 08 Jun '15

08 Jun '15

> > > On 8 Jun 2015, at 17:57, Ramy Hashish wrote: > > > a BGP session has to be established over a GRE tunnel over the > > internet between the ISP/NSP/DC and the cloud scrubbing center, > > This is incorrect. > > In most cloud overlay DDoS mitigation scenarios (e.g., end-customer > obtains service from an MSSP which isn't providing them with transit), > a) there is no BGP relationship whatsoever between the end-customer and > the MSSP, and b) the GRE tunnel is used strictly for re-injection of > clean traffic (i.e., post-mitigation) to the end-customer. > > In some scenarios, DNS is also used in place of/in addition to BGP-based > diversion. > > But GRE is used for re-injection only. > > > Roland, I am talking about the case where the ISP/NSP is having their own DDoS mitigation solution -to protect their NW infrastructure- and then providing the service to their end customers. However I have some concerns on your comments: Even if the transit provider won't be involved in the mitigation process and the GRE tunnel is used only for injecting the traffic back to the end customer, the customer's dirty traffic will pass through some congestion points (most likely near the IGWs) throughout the transit provider network. And concerning point b) as per Arbor representatives in my region, Arbor's system takes up to five minutes to mitigate the attack (starting from the hit of the first dirty packet), so there will be a period of time where the dirty traffic (or at least some of it) will be coming down all the way to the end customer until you completely mitigate the attack. I hope now it become more clear. Ramy

2 1

Regulators now regulating Internet History? Really?
by Larry Sheldon 08 Jun '15

08 Jun '15

Looks to me that there are issues of interest here. http://www.aei.org/publication/tom-wheeler-tries-to-rewrite-internet-histor… -- sed quis custodiet ipsos custodes? (Juvenal)

4 3

RE: Tunable SFP
by Frank Bulk 07 Jun '15

07 Jun '15

Thanks, that's very helpful. They have several models there: https://www.flexoptix.net/en/produkte/transceiver.html?fo_tra_formfactor=sfp #fo_tra_formfactor=sfp&fo_tra_interface=05_dwdm_100ghz&gan_data=true Frank -----Original Message----- Sent: Saturday, June 06, 2015 1:44 PM To: Frank Bulk Subject: Re: Tunable SFP Check out https://www.flexoptix.net/en/ This topic came up last month and a lot of people recommended this vendor. Hope it helps. On 6/6/2015 10:45 AM, Frank Bulk wrote: > Thanks -- can you point me to any suppliers? > > Frank > > -----Original Message----- > From: Jared Mauch [mailto:jared@puck.nether.net] > Sent: Saturday, June 06, 2015 12:41 PM > To: Frank Bulk > Cc: <nanog(a)nanog.org> > Subject: Re: Tunable SFP > > They do exist. They tend to have tighter link budgets as compared to XFP > tunable optics. Don't expect to go as far due to the receiver sensitivity. > > Jared Mauch > >> On Jun 6, 2015, at 1:29 PM, Frank Bulk <frnkblk(a)iname.com> wrote: >> >> Anyone know if tunable SFPs exist? I've googled around on this, but only >> found fixed wave-length SFPs. >> >> Or of a tunable SFP+ that can operate in SFP port as 1G? >> >> Frank > >

5 7

Should I Reboot, and Why? (was Re: [RDD] No Play out on Cart Wall)
by Jay Ashworth 07 Jun '15

07 Jun '15

----- Original Message ----- > From: "Cowboy" <curt(a)cwf1.com> > On Sunday 31 May 2015 03:49:10 pm Graham Wilman wrote: > > after getting the play out working on clienta terminal for the past > > 6 days > > the decision was taken today to get clientb terminal working which > > it now partially is > > unfortunately once all 3 terminals the server.clienta and clientb > > were rebooted I could > > not get play out to work on clienta again > > Re-booted why ? > I've often said that rebooting a *nix machine is usually a bad idea. And, again, a good to recap some of Good Sysadmin Practice: In the Windows world, it's often recommended that you reboot a machine that is acting -- as we say in support -- hincky. That's because Windows is sufficiently complicated and fragile that things can get corrupt at runtime, and the simple fact you rebooted it can fix a problem. That's traditionally not been true in the *nix world; particularly on purpose-built single function servers, there simply isn't enough code running at once to allow for the sort of complicated, multiplicative complexity failures that you see in many Windows machines. But does that mean you should never reboot a Linux box, just because you usually don't *have* to, to fix your problem? No, it doesn't, and here's why: Some of the things you might change in your configuration can affect how things start *when* you boot up, and if you've adjusted one of them, the time to boot it and find out *is right now, when you've just made the change and it's fresh in your mind*, not 6 months from now at 3 in the morning, when you don't remember what you did. Well, I suppose you could look in your logbook. Or check your ticketing system. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

3 2

Re: PoC for shortlisted DDoS Vendors
by nanogml＠ddos-mitigator.net 07 Jun '15

07 Jun '15

hi nanog, back in april, Mohamed was reviewing the shortlist of DDoS appliances, would you mind posting a summary of your findings # partial list of DDoS appliances DDoS-Mitigator.net/Competitors ----- ? does anybody know which DDoS appliances uses IPtables to do its mitigation ?? iptables is good because it supports tarpit which can be used to counter attack the incoming TCP-based DDoS attackers ? Does any colo/datacenter ( in silicon valley or Las Vegas ) allow the customers to put a firewall at the ISP end of the pipe to prevent these ICMP/UDP floods from going down the pipe to the customer thanx alvin DDoS-Simulator.net === Simulate DDoS attacks DDoS-Mitigator.net === Defend against incoming DDoS attacks

1 0

RE: PPPoE/IPoE, any recommendations for upgrade?
by Murat Kaipov 07 Jun '15

07 Jun '15

Hello Nasser. We use IPoE in our small ISP. But in my case we use DHCP option 82 and IP address as username for authentication and accounting purposes. As BRAS we configure Cisco ISG. Отправлено с устройства Samsung -------- Исходное сообщение -------- От: Nasser Heidari <nasser(a)rasana.net> Дата: 07.06.2015 9:46 (GMT+03:00) Кому: nanog(a)nanog.org Тема: PPPoE/IPoE, any recommendations for upgrade? Hi, We are currently using PPPoE in our network. I have seen some articles regarding migration of so-called legacy PPPoE to IPoE. After reviewing some of them and implementing IPoE in lab environment using Cisco ASR I didn't fine it that much beneficial to migrate whole system as I need to change a lot of things. For example: - I need to add it's support to our radius and obviously BSS system (E.g. using NAS-PORT-ID instead of username). - For the addressing part, as I have already using distributed BNG's, I need to change some of our policies. (For example assigning address blocks is much easier in PPPoE using framed-route) - I need to change our customers CPE configuration to use Ethernet encapsulation. - I haven't used DHCP in large scale environment. - I don't have any clear Idea/understanding regarding its maintainability/troubleshooting and also security. (Please add if I'm missing any other issue which may run into if I migrate to IPoE) Although it has some benefits, I'm not sure if it's that essential to migrate. Would you please kindly? - Share your Ideas/experiences/best practices in this regard? - If you are already using IPoE, tell more why should I upgrade? - Considering a DSL network with more than 800K customers using PPPoE, do you recommend this migration? Kind Regards, Nasser

1 0