Re: Issues with Gmail
Jim Wininger wrote: Anyone else seeing issues with gmail? More specifically? -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: Datacenter recommendations - China and Latin America
Shane Ronan wrote: I'd recommend Equinix which has a site in Hong Kong which I would recommend over mainland China. http://www.equinix.com/locations/map/asiapacific/hongkong/ What is the Great Firewall relationship between Hong Kong and the mainland PRC, as compared to the mainland PRC vs. the rest of the world? -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: Repeated Blacklisting / IP reputation
Joe Greco wrote: I'm sorry, I agree that there's a problem, but this just sounds like it isn't feasible. Some people suffer from the culturally ingrained inability to understand that certain kinds of problems just can't. Be. Solved. And/or they aren't worth solving under present circumstances. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: CLEC Mailing List
Scott Berkman wrote: I am looking for a CLEC related mailing list. I looked through the archives and it looks like ISP-CLEC is dead. Does anyone know of a mailing list that picked up the slack? It's not exactly the same crowd, but it's a highly usable and sufficiently overlapping substitute. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: cross connect reliability
Seth Mattinen wrote: Michael J McCafferty wrote: All, Today I had yet another cross-connect fail at our colo provider. From memory, this is the 6th cross-connect to fail while in service, in 4yrs and recently there was a bad SFP on their end as well. This seemes like a high failure rate to me. When I asked about the high failure rate, they said that they run a lot of cables and there is a lot of jiggling and wiggling... lots of chances to get bent out of whack from activity near my patches and cables. Until a few years ago my time was spent mostly in single tenant data centers, and it may be true that we made fewer cabling changes and made less of a ruckus when cabling... but this still seems like a pretty high failure rate at the colo. I am curious; what do you expect the average reliability of your FastE or GigE copper cross-connects at a colo? Never to fail? Seriously; if you're talking about a passive connection (optical or electrical) like a patch panel, I'd expect it to keep going forever unless someone damages it. That's truly wishful thinking, as are the assumptions that insulate it from damaging factors. Nothing lasts forever. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: TDM data analyzer
j...@seminte.lt wrote: Hello fellow NANOGers. Slightly offtopic, but I would greatly appreciate your suggestions. For my telecommunications engineering degree I am designing a TDM data analyzer, and I need suggestion, what you would like in an appliance like that. Right now my idea is that it should be a transparent device that plugs in between two E1/T1/J1 devices and then connect to FastEthernet for data uplink. All data traveling between two devices is sent to central server that can accept data from one or more capture devices. End user (i.e. NANOGer debugging a problem) has a program to connect to data acquisition server and can see decoded Q921/Q931 signaling data and to play-out what's happening in any one of voice channels. BERT tester and signal level indication with remote fault monitoring and logging would be included also. End user will have ability to record voice data with supplemental information too. So my question to the community is what other features you would like to see in a device? And most of all - if you had a device like that would you find it useful? All replies off list greatly appreciated. I would like to ask people to forward this email to colleagues that work with voice systems or to a voice operators group if you are a member of one. Well, what do you presume to be entailed in "TDM?" ISDN is not necessarily implied. You could analyse E&M wink on D4 superframe. ;) Much simpler. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: SMS
Shane Ronan wrote: On that same note, can someone point me in the direction of an SMS gateway service? I would like to be able to send SMS messages from my monitoring systems, but I am unsure about how to go about it. Appreciate the assistance. Why not use an e-mail to SMS gateway from whichever carrier? -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: operations contact @ facebook?
Patrick W. Gilmore wrote: On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: Would anyone happen to have an operations contact at Facebook by anychance? Our systems are being overwhelmed by a facebook application that we were neither aware of nor condoned. Clearly I do not have all the information, so please forgive me for being confused. But since when do I[*] have to ask you before I put an application on my server? If FB put an application on your server, that seems like something you should have known up front. The original poster is from Paris. Do consider the possibility that there are different jurisdictional rules or service terms in force from your own. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: operations contact @ facebook?
Patrick W. Gilmore wrote: On Oct 5, 2009, at 11:10 AM, Alex Balashov wrote: Patrick W. Gilmore wrote: On Oct 5, 2009, at 10:46 AM, Leland Vandervort wrote: Would anyone happen to have an operations contact at Facebook by anychance? Our systems are being overwhelmed by a facebook application that we were neither aware of nor condoned. Clearly I do not have all the information, so please forgive me for being confused. But since when do I[*] have to ask you before I put an application on my server? If FB put an application on your server, that seems like something you should have known up front. The original poster is from Paris. Do consider the possibility that there are different jurisdictional rules or service terms in force from your own. I certainly did not. And I would suggest we refuse to do so as an industry. The UN lists 192 countries, and there are several others (e.g. Vatican City, Scotland, etc.) which others may count. Many of these have provinces or states or whatever, and almost all have cities, towns, counties, etc., each of which may have its own laws & regulations. Operationally speaking (see, this is on-topic :), trying to consider every single one of those possible laws, rules, social norms, preferences, political slants, religious authorities, and whatever else may come into the mix when putting an object or code onto the Internet is simply not possible. Giving in to it, even a little bit, leads to ridiculous restrictions and stifling of many things on the 'Net. We should all push back HARD whenever someone over here tries to tell someone over there what to do. The OP responded with a quite reasonable answer (shared infrastructure) that had nothing to do with local jurisdiction. That is an operational issue. What laws your country, province, county, town, or church has set up for you should have zero operational impact on me if my gear is not in the same place. And maybe someday we can even get away from that whole "in the same place" idea. (Hey, one can dream.) That is a very fair point. I cannot come up with any appealing counterarguments. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: ISP/VPN's to China?
OpenVPN is ideal. It functions purely over application-level UDP transport (IP-IP) instead of using GRE/IPSec/other encapsulation protocols that could potentially be blocked by a protocol filter on a router. Route that traffic to a server outside of China and NAT it out to the rest of the Internet. The default port is UDP 1194, but can easily be changed. Anyone who wants to block it risks blocking any applications that use UDP in general, such as online games, Skype, etc. It is precisely because the traffic has no signature distinguishable from normal application traffic - aside from the fact that the payload is encrypted - that it makes a good fit. It's also open-source and free. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: ISP/VPN's to China?
Fred Baker wrote: On Oct 21, 2009, at 4:36 PM, Alex Balashov wrote: It is precisely because the traffic has no signature distinguishable from normal application traffic oh my goodness. You're behind on your reading... I didn't mean DPI. I meant in a way that can be inferred from the headers themselves, and aside from the port number. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: ISP/VPN's to China?
I was not aware that tools or techniques to do this are widespread or highly functional in a way that would get them adopted in an Internet access control application of a national scope. Tell me more? -- Sent from mobile device On Oct 21, 2009, at 9:27 PM, Adrian Chadd wrote: On Wed, Oct 21, 2009, Alex Balashov wrote: oh my goodness. You're behind on your reading... I didn't mean DPI. I meant in a way that can be inferred from the headers themselves, and aside from the port number. You don't think that statistical analysis of traffic patterns of your UDP traffic wouldn't identify it as a likely tunnel? :) Adrian
Re: ISP/VPN's to China?
Chris Edwards wrote: Doesn't necessarily have to be hugely accurate. The authorities could simply identify a few likely suspect tunnels, then knock-on-doors and ask you to explain what the traffic in question is... Understood. I guess the angle I was going more for was: Is this actually practical to do in a country with almost as many Internet users as the US has people? I had always assumed that broad policies and ACLs work in China, but most forms of DPI and traffic pattern analysis aren't practical simply for computational feasibility reasons. Not unless the system were highly distributed. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
What DNS Is Not
Thought-provoking article by Paul Vixie: http://queue.acm.org/detail.cfm?id=1647302 -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: What DNS Is Not
Dave Temkin wrote: Alex Balashov wrote: Thought-provoking article by Paul Vixie: http://queue.acm.org/detail.cfm?id=1647302 I doubt Henry Ford would appreciate the Mustang. I don't think that is a very accurate analogy, and in any case, the argument is not that we should immediately cease at once all the things we do with DNS today. DNS is one of the more centralised systems of the Internet at large; it works because of its reliance on intermediate caching and end-to-end accuracy. It seems to me the claim is more that DNS was not designed to handle them and that if this is what we want to do, perhaps something should supplant DNS, or, alternate methods should be used. For example, perhaps in the case of CDNs geographic optimisation should be in the province of routing (e.g. anycast) and not DNS? -- Alex -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: What DNS Is Not
When I write applications that make DNS queries, I expect the request to turn NXDOMAIN if the host does not exist - HTTP as well as non-HTTP, but especially non-HTTP. Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why this could possibly be controversial. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Re: [NANOG] NREN Network Design
Tarig, I am not quite sure what you mean, but it sounds like you're suggesting that different pieces of your network are fragmented across different connections to different ISPs. Depending on what exactly the problem is, the solution would be either (a) to get a provider-independent IP block from your RIR and route-peer with each of these ISPs in order to announce independent address space that travels with you wherever you buy connectivity, and/or (b) some sort of Layer 2 or 3 tunneling like VPN or MPLS, if I'm not understanding the problem correctly. -- Alex -- Alex Balashov - Principal Evariste Systems LLC Tel: +1 678-954-0670 Direct : +1 678-954-0671 Web: http://www.evaristesys.com/
Re: The Internet Revealed - A film about IXPs v2.0: now available
On 02/10/2010 09:46 AM, Mikael Abrahamsson wrote: But one factual error for instance, a TCP session (a picture being transfrred) doesn't take multiple paths, that's just wrong to say so. So showing a picture being chopped up in packets and sent over different paths, well that just doesn't happen in normal operation. But it introduces the audience to the idea that the packets *could* be routed over multiple paths in principle, even if it would constitute evidence of abnormal operation to have this happen within a single session. I think that's the intended take-away, from a pedagogical perspective. -- Alex Balashov - Principal Evariste Systems LLC Tel: +1 678-954-0670 Direct : +1 678-954-0671 Web: http://www.evaristesys.com/
Re: T1 aggregation and data center gateways
On 03/09/2010 08:00 PM, Tim Sanderson wrote: Currently have T1 aggregation on some Cisco 7206VXR routers. Core switches and data center gateways on a couple of Cisco 6509's. Looking for a model that could collapse both functions into just two devices, one being for hardware redundancy. Any recommendations on a good L3 switch that is also a good T1 aggregation device? Anyone have any experience with the newer Cisco stuff like the ASR 1000/7600/CRS-1? Forgive the dumb question, but what's wrong with using a 6509 as a T1 aggregation device? Port density not cost-effective? I've seen it used that way on a number of occasions with cheap M13 muxes and DS3 interfaces. -- Alex Balashov - Principal Evariste Systems LLC Tel: +1 678-954-0670 Direct : +1 678-954-0671 Web: http://www.evaristesys.com/
