How Route Analytics Help Detect BGP Route Hijacking

How Route Analytics Detect BGP Route Hijacking

Previously, I have talked about BGP route hijacking as a security threat and various techniques being developed to secure it. In this blog entry, I will talk about how route analytics technology can help detect BGP route hijacking in the meantime. 

There are two instances of route hijacking that need detecting. The first is when one of your prefixes is being hijacked; that is, someone is redirecting your traffic elsewhere and you are the victim. The second is when someone passes you a hijacked route; that is, you are being used as an instrument to hijack someone else. Route Analytics can help with both of these cases. However, the data sources that are needed for the analysis are different. 

When your routes are being hijacked, you cannot look at the data that is in your BGP routers in the majority of the cases. Because of the way BGP AS_path attribute works, these routes will contain your AS number and therefore, BGP will not pass them back to your routers in order to avoid loops. However, if you have access to external BGP sessions Continue reading

Framing SDN as Network as a Service (NaaS)

Framing SDN as Network as a Service (NAAS)

Tom Nolle absolutely nails the real promise of SDN in his latest blog post – Should SDN be About OpenDaylight and not OpenFlow? – which is essentially to create Network as a Service (NaaS). Readers of the Knetwork Knowledge blog will know that we have been advocating for some time that SDN is a lot more than just the separation of the network’s control and data planes, and that OpenFlow is “merely” a mechanism (not the only one) for SDN controllers to pass forwarding instructions to the underlying infrastructure. Our industry often gets lost in the technology details and misses the point, which in this case is about creating malleable network infrastructures that flex efficiently with business demands. The really interesting, valuable, and (yes) hard work is to supply the controllers with the intelligence they need to make smart infrastructure changes.   

And equally important is the recognition that we have to be able to deliver NaaS with existing network gear: A forklift upgrade to support new southbound protocols is not an option. We also need to be open to the notion Continue reading

Select group/pool by query URI

Lab goal

Setup

I'll use my Loadbalancer Lab Setup.

Alteon configuration

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

attach group g1
attach group g2
attach group g3

when HTTP_REQUEST {
    set group_exists [regexp -nocase {group=(g[0-9]+)(&.*)*$} [HTTP::query] a group_name]
    if {$group_exists == 1} {
        group select $group_name
     Continue reading

Network Admin in Cary NC

I’m helping a company (as a favor) that’s looking for a network administrator in the Cary, NC area. The company is moving from another area, and hence rebuilding their office and backend systems. They rely heavily on their IT “stuff,” as they’re essentially in the information business. Please send me an email if you’re interested […]

Author information

Russ White

Principle Engineer at Ericsson

Russ White is a Network Architect who's scribbled a basket of books, penned a plethora of patents, written a raft of RFCs, taught a trencher of classes, and done a lot of other stuff you either already know about, or don't really care about. You want numbers and letters? Okay: CCIE 2635, CCDE 2007:001, CCAr, BSIT, MSIT (Network Design & Architecture, Capella University), MACM (Biblical Literature, Shepherds Theological Seminary). Russ is a Principal Engineer in the IPOS Team at Ericsson, where he works on lots of different stuff, serves on the Routing Area Directorate at the IETF, and is a cochair of the Internet Society Advisory Council. Russ will be speaking in November at the Ericsson Technology Day. he recently published The Art of Network Architecture, is currently working on a new book in the area Continue reading

RFCs You Should Know: 6250

Most RFCs are deeply technical — and they follow the “Yaakov rule” for intelligibility (if you didn’t write it, or you didn’t sit with one of the authors in a bar someplace to talk about it, you can’t understand it), there are a few here and there every network engineer should know. RFC 6250 is […]

Author information

Russ White

Principle Engineer at Ericsson

Russ White is a Network Architect who's scribbled a basket of books, penned a plethora of patents, written a raft of RFCs, taught a trencher of classes, and done a lot of other stuff you either already know about, or don't really care about. You want numbers and letters? Okay: CCIE 2635, CCDE 2007:001, CCAr, BSIT, MSIT (Network Design & Architecture, Capella University), MACM (Biblical Literature, Shepherds Theological Seminary). Russ is a Principal Engineer in the IPOS Team at Ericsson, where he works on lots of different stuff, serves on the Routing Area Directorate at the IETF, and is a cochair of the Internet Society Advisory Council. Russ will be speaking in November at the Ericsson Technology Day. he recently published The Art of Network Architecture, is currently working on a new book in the area Continue reading

What is CHI-NOG (Chicago-NOG)

Over the last year, I haven’t been writing many new blog posts. I have been pretty busy with a new job, but also starting a new networking group called the Chicago Network Operators Group (CHI-NOG). The idea behind it is that there aren’t that many places where network engineers can meet to talk about technology, learn something new and network with each other. The communities are mostly virtual and that’s something I wanted to change by creating CHI-NOG.

Chicago Network Operators Group

Last year Brian McGahan, Jason Craft and I met to talk about the void of the networking community. A lot of times people only know each other from email or forum exchanges. We wanted to bring in the Chicago community together and have a place to met and discuss the topics that interests us and learn from each other.

We try to host CHI-NOG events 3 times a year. So far our events have been in the evenings for few hours. For each event we have a number of guest speakers. They present on any topic relating to networking, which is a good way to spark conversation for the social hours that start right after.

This October Continue reading

Geneve – Ecosystem Support Has Arrived

[This post was authored by T. Sridhar and Jesse Gross.]

Earlier this year, VMware, Microsoft, Red Hat and Intel published an IETF draft on Generic Network Virtualization Encapsulation (Geneve). This draft (first published on Valentine’s Day no less) includes authors from the each of the first generation encapsulation protocols — VXLAN, NVGRE, and STT. However, beyond the obvious appeal of unification across hypervisor platforms, the salient feature of Geneve is that it was designed from the ground up to be flexible. Nobody wants an endless cycle of new encapsulation formats as network virtualization designs and controllers mature, certainly not the vendors that have to support the ever growing list of acronyms and RFCs.

Of course press releases, standards bodies and predictions about the future mean little without actual implementations, which is why it is important to consider the “ecosystem” from the beginning of the process. This includes software and silicon implementations in both commercial and open source varieties. This always takes time but since Geneve was designed to accommodate a wide variety of use cases it has seen a relatively quick uptake. Unsurprisingly, the first implementations that landed were open source software — including switches such as Open Continue reading

Controller Cluster Is a Single Failure Domain

Some OpenFlow-focused startups are desperately trying to tell you how redundant their architecture is. Unfortunately all the whitepapers (and the prancing unicorns) cannot change a simple fact: an SDN controller (OpenFlow-based or otherwise) is in some aspects a single failure domain.

Network Aware Software: Rubbish idea or OpenDayLight Function?

“Sir, Skynet is self aware…”

Not really the line anyone wants to hear, especially after watching the Terminator films! This however isn’t what this post is about, so if you’re a bit of a rebel, fear not. No network vendor branded termination thing (maybe other than poor documentation or code) will result in your death.

Since the era of the abacus, little consideration has been given to how software that relies upon a computer network actually interacts with it. Sure, most developers know how to drive a socket library and make things happen at a session level, but almost no consideration is given by a developer on how to deploy an enterprise application to a production environment.

This post represents a set of thoughts that have been maturing over the last few months. They are very much my own thoughts and do not represent those of others. I would be interested to hear if you have the same thoughts or any interesting different takes.

Where does this story begin?

Before smart phones and tablets came along, software for the domestic populous provided a means of typing and printing spell checked letters to your pen pals, figuring out your weekly shopping Continue reading

What I Learned by Being Laid Off

There’s nothing quite so unnerving as being laid off. I know, because I’ve been let go in a “limited restructuring” twice in my life. Through the process, I learned some “life lessons,” that apply to just about every engineering in the world. While I’m safely ensconced in a great place at Ericsson, I thought it might be useful to reflect on the lessons I’ve learned — especially as it seems to be layoff season in other places (or maybe it’s layoff season all the time?).

First, it doesn’t matter if it’s about you, the politics, or just a random event. I still harbor a suspicion that both times I was laid off there was more going on in the background than just “we don’t need your services any longer.” There were probably politics. On the other hand, the politics in these situations are always bigger than you, no matter how personal it might seem. There’s always some back story, there’s always some power play in progress, there’s always some internal struggle.

But the truth is — it doesn’t matter. You can either stew on the past, or move on with your life. Stewing in the past isn’t going Continue reading

Common Network Design Concepts Part-2

In the first article of this series, reliability and resiliency has been explained. Every component and every device can and eventually will fail, thus system should be resilient enough to re converge/recover to a previous state. Resiliency can be achieved with redundancy. But how much redundancy is best for the resiliency is another consideration to […]

Author information

Orhan Ergun

Orhan Ergun, CCIE, CCDE, is a network architect mostly focused on service providers, data centers, virtualization and security.

He has more than 10 years in IT, and has worked on many network design and deployment projects.

In addition, Orhan is a:

Blogger at Network Computing.
Blogger and podcaster at Packet Pushers.
Manager of Google CCDE Group.
On Twitter @OrhanErgunCCDE

The post Common Network Design Concepts Part-2 appeared first on Packet Pushers Podcast and was written by Orhan Ergun.

Is Anyone Using DMVPN-over-IPv6?

One of my readers sent me an interesting challenge: they’re deploying a new DMVPN WAN, and as they cannot expect all locations to have native (non-NAT) IPv4 access, they plan to build the new DMVPN over IPv6. He was wondering whether it would work.

Apart from “you’re definitely going in the right direction” all I could tell him was “looking at the documentation I couldn’t see why it wouldn’t work” Has anyone deployed DMVPN over IPv6 in a production network? Any hiccups? Please share your experience in the comments. Thank you!

See You in Bern on September 9th

TL;DR: I'll be in Bern on September 9th. If you'd like to drop by and discuss network design or automation challenges, read on…

IP Subnetting Part 4: Subnetting a Class C Network

At this point in the PacketU subnetting series, we have worked through the following–

• What is a Subnet?
• Simple Subnetting Examples
• Understanding the Binary

This article takes the concept of subnetting to the next step. Today we are going to look at the concepts required to subnet a Class C network. As we reflect on the Classful IP rules, we recall that a Class C network has the following characteristics–

• First octet begins with binary 110…..
• The first Octet will be in the range of 192 to 223
• The first three (three leftmost) octets represent a Network
• The last octet (rightmost) Octet represents a Host on a network

We also know that this single IP network can be further subdivided into multiple, but smaller, networks. This process is known as subnetting.

Continuing with the syntax used in previous articles, we might represent a Class C Network as follows–

192.168.100.0

In this example--

Blue  represents a Classful Network
Green represents a Host address

In this case the host address value is 0, so only the network is being represented here. Based on this information, we only have one IP network that can be assigned. That one network could Continue reading

Scalability Enhancements in Cisco Nexus 1000V

The latest release of Cisco Nexus 1000V for vSphere can handle twice as many vSphere hosts as the previous one (250 instead of 128). Cisco probably did a lot of code polishing to improve Nexus 1000V scalability, but I’m positive most of the improvement comes from interesting architectural changes.

Vuln bounties are now the norm

AppShape++ and SSL offloading

Internal Networking for the new UCS Modular Chassis

Ansible On the Road: September

My first week working at Cumulus Networks: Beyond A First Impression

Working at Cumulus Networks – it’s probably the most fun I’ve had at a job in a really long time.

The narrow stairway at 463 (and a half) Bryant Street was my first impression of working at Cumulus Networks. Victoria opened the door, and I said, “Wow, this door is tiny and those stairs- what is this, a speakeasy?” I got the sly, dry smile that I have come to see as indicative of Victoria and was escorted inside to the conference room of what looked like an empty apartment turned into an office. There, I met Kathleen and we chatted for half an hour. It was one of the most informal, comfortable, genuine experiences I’d ever had in a job search.

“Do you think you can commit to working at Cumulus Networks a few months, understanding it’s sort of up in the air right now, the future of this office, etc.?”

“Yeah, I think so. I mean, unless I become like, a famous author over night, or something. Which probably isn’t going to happen.”

Victoria glanced at my resume. “It says here that you published a book.”

“Two, actually. But you know… that’s how I Continue reading