Posts by Ruairi

So, we should name the leaks instead of actually fixing the broken system which is currently in place? Yupp, it's the IETF at work again!

I'm looking at you, ROA, IRR sets and manual configuration changes. Until we are able to validate a route inside of the BGP process, we will continue to see route leaks.

Lastly: A niggly point, but Telias outage was due to an IS-IS cost, not a BGP leak.

So there was a post about this from sunet about how DDoS has been reported on. It's a good read and can be found here:

https://www.sunet.se/blogg/showerthoughts-ddosing-an-important-social-institution-and-fixing-it-part1/

Where's the datasheet?

What's optic will it take?

Oversubscription? Density/module?

What spec does it conform to?

To be fair, you dont leave your management interfaces exposed to the public at large when you're talking about networking devices.

*Even* if you're running 10-15 year old kit that does not support SSH, it's in it's own private/management VLAN that's heavily firewalled/no access to the outside world.

Yet another WordPress vuln: Image furtler plugin lets BADNESS in

<pedantic>

Dont you mean "Yet another WordPress plugin vuln: Image furtler plugin lets BADNESS in"

</pedantic>

Will ACI and NFV still be "long term" goals when they re-invent the next big thing in 12 months?

This company is going nowhere new fast.

Have one for about a month now. The 4.2.2 update was pushed to me last week, so you might want to update the article.

I'm upgrading from the ZR, which I absolutely love. The compact is a really awesome phone. I get 3 days with heavy usage (WiFi,4G,GPS). Early OS revs were a bit fruity, but it seems that most issues are addressed now. The camera is really impressive, and the AR mode is hilariously awesome.

The only negative things I can say about the phone is that the lack of option to disable vibrate on touch is *annoying* and the plastic back scratches all too easily.

I'm surprised at this for a number of reasons.

Any single competent network engineer would just drop AS13414 at the border, and be done with it (And AS35995/AS54888, since Twitter have multiple AS's). However that's not the case... So I can only assume the technical advisor to the government either didnt want to have a functional ban in place, or was not competent enough to advise correctly.

I'm also surprised that Twitter dont start the whack-a-mole game of spinning up EC2 instances as light weight reverse proxies for their service, then GeoDNS to target Turkish users.

Hang on, seems like you guys missed out the real fun in this story

And later:

So it took an engineering company 2 years to figure out it was bad memory, and the same time frame to admit to customers they were exploring an issue (They denied all knowledge until this PR stunt was ready to be pushed out the door).

I dont know about you, but that seems like a very long time, a significant portion of the shelf life of most of these products.

Can any of you tell malice from incompetence? Why assume malevolence when incompetence is the more likely answer.

This saga is non-trivial, and it's got many moving points, namely:

1. Netflix's peering policy ( https://signup.netflix.com/openconnect/guidelines , min 2Gbit _each way_ at 95th percentile).

2. Netflix's Open Connect program - ISP's dont want to lose rack space + power to these boxes.

3. ISP's want to make the content providers pay for content traversing their network.

What's more than likely happening is that Netflix traffic is taking the congested path (They are a victim of their own success) inside of Verizon's network. I dont think there is malevolence involved here, however at the same time, there's nothing to be gained right now for Verizon. They're not losing customers, and _if_ they do lose customers over this Netflix saga, it's the customers who tend to cost them more in transit bills.

BCP38 people - ask for it from your upstream provider.

Also, for any of you running any networks - drop NTP on your border, drop ingress traffic with a source address of your address space at the border. Drop egress traffic that does not match your address space at your border.

Been saying it for years - Cisco is going to lose the switching market, and probably the routing market after that.

I see them being relevant in corporate IT (Voice, user access) and servers (I'm guessing that their switching market share will collapse into the embedded switches they're building into UCS chassis).

I'm not 100% sure that home grown devices are mature enough right now for the regular DC. However from an OS perspective, Cumulus Networks should change this in the coming years, and hopefully a larger install base of Trident I / II based boxes will also level the playing field.

Interesting times ahead, and not even one mention of SDN (d'oh!)

What I'd really like to see is event correlation in an intelligent way...

By parsing flow data in almost-real time, looking for patterns in syslog, interface changes (ie: flap, or an interface counter going +/- X% across samples), and snarfing up accounting data. Hell, even take an iBGP feed of updates from my eBGP peers, and a feed of OSPF LSA's and correlate an event with a specific set of updates. There's so much room for correlation, there's just nothing about that I've found that works for me.

I think overall, we have all the tools we need to do this, but the time needed to integrate them all, make them talk nicely, and set intelligent thresholds, relative thresholds and even a little historical predication based on previous events is just not worth it. Lately, instead of spending time on this, I'm fighting to get nfsen/observium/smokeping/homegrown scripts to talk together and give me a coherent view of my traffic patterns.

I'm battling with the stupidity of SNMP traps, SNMP's format and the absurdity of 5 minute samples when I have 40Gbit interfaces.

Monitoring makes me stabby.

Why do people need to invent the wheel. The B.A.T.M.A.N protocol exists to solve this exact problem in IPv4, and can be easily ported to IPv6.

Nothing new here....

> Our Future Internet should know no barriers, least of all barriers created because we did not prepare for the data revolution.

Sorry, darlin', speed of light is a constant.

@AC:

In this case, it's a problem with how WiFi is setup, rather than TCP. WiFi is a shared medium, so you're going to get collisions (CSMA/CA attempts to give fair access to the medium). TCP is affected as it sees a collision as a drop, so it scales back throughput wise. That's why they're dropping new sessions, and giving priority to the existing data flows (It's kinda cheating, throughput wise).

TCP has quite a few throughput hacks in it (Window Scaling, SACK, binary backoff Vs exponential etc), and is quite predictable and mature. The real issue here is wireless ethernet being "non switched", thus having collisions and packet loss with many users.

Not again

Didnt Apple make the same mistake with Cisco with the iPhone as they're making now with IOS?

RE: Unified communications. Pfaw

>> The reality is that no matter how many lines of communication you offer a given employee, you can't change the fundamental fact that it is their CHOICE to respond or not.

Agree, however you have presence awareness. At least now the boss knows the employee is unable to respond.

@Bruce Sinton

Nope, one machine can never live up to that level of service :)

But, say you have a farm of 10 machines behind a load balancer (in fault tolerant mode), with the correct type of probing configured on the load balancers (so that machines which still ping, but say, dont serve out HTTP, are not used for a load balancing decision), 99.999% should be an attainable goal.

You hardly think that MS or Apple use just one machine for these types of services?