All times are UTC - 6 hours [ DST ]
Bookmark this link to save your settings:
A couple months ago, I announced a proposal to start a Stack Exchange site dedicated to answering questions concerning network engineering, similar to how Stack Overflow and Server Fault cater to the concerns of programmers and systems administrators, respectively.
I'm happy to announce that the proposal has made it through the definition and commitment phases and last week was opened as a public beta site at networkengineering.stackexchange.com! The beta process is critical for shaping the content and style of the site, so the more people use it the better we can refine and nurture its content.
Why a Stack Exchange site? The platform has proven immensely useful for directed troubleshooting and answering targeted questions. As opposed to discussion forum threads, which often digress into tangents and off-topic conversation over the course of days or weeks, the streamlined question-and-answer format of the site leverages community feedback and voting to promote what is accepted at the best answer (which the asker can optionally confirm). This medium is much better suited to questions which can be directly answered (e.g. "How can I...?" and not "What's the best...?"); please keep this in mind if you decide to participate in the beta.
Most readers are probably familiar with the switchport analysis (SPAN) feature on Cisco's Catalyst switches. SPAN replicates all ingress and/or egress traffic from one or several interfaces to another for the purposes of packet capture or traffic monitoring. This is especially helpful when deploying a network-based IDS. Unfortunately, it's often not possible to install the IDS on the same physical switch as the ports from which you want to capture.
Remote SPAN (RSPAN) can be employed to extend a SPAN session between source and destination points on disparate switches, however it requires a layer two path end-to-end. When we need to replicate layer two traffic across a layer three network, we turn to encapsulated remote SPAN (ERSPAN). ERSPAN transports traffic inside a point-to-point GRE tunnel between arbitrary IP endpoints.
For this lab, we'll configure an ERSPAN session from an NX-OS source (a Nexus 7K) to an IOS destination (a Cisco 7600) to provide an example configuration for both platforms. MPLS transport is used between the two switches and routing of the ERSPAN tunnel will take place inside a VRF named Capture.
I had a couple of requests to post the .net and config files for my Carrier Supporting Carrier post. So there it is. Click here to download. Note that I’ve taken these configs from the end of that post, so it’s actually the CSCSC configs. There are a couple of ‘extra’ config statements in the [...]
I’ve seen a fair amount of debate where people are saying Cisco ‘stole’ the commit command from Juniper. Perhaps. But Juniper wasn’t the first to have a command available for staging configs before making them active. Let’s look at this ancient (but still live) Riverstone RS3000: RS135# conf RS135(config)# vlan create vlan26 ip id 26 [...]
CSC, or Carrier Supporting Carrier, takes inter-AS L3 VPN to the next level. Let’s say that you are an ISP and you are offering L3VPN MPLS services to your customers in England. You take over another ISP located in say, Australia, and two of your UK customers are also located in Australia. They would like [...]
A couple months back, my host decided to stop hosting. I’ve been busy (read: lazy) and didn’t find any other hosts who seemed like a good fit. I’ve finally found one and they seem to be great so far. So I apologize for the extended outage. I’d love to say I’ll actually be posting some…
If you follow any number of news feeds or vendor accounts on Twitter, you've no doubt noticed the term "software-defined networking" or SDN popping up more and more lately. Depending on whom you believe, SDN is either the most important industry revolution since Ethernet or merely the latest marketing buzzword (the truth, of course, probably falls somewhere in between). Few people from either camp, however, take the time to explain what SDN actually means. This is chiefly because the term is so new and different parties have been stretching it to encompass varying definitions which serve their own agendas. The phrase "software-defined networking" only became popular over roughly the past eighteen months or so.
So what the hell is it? Before we can appreciate the concept of SDN, we must first examine how current networks function. Each of the many processes of a router or switch can be assigned to one of three conceptual planes of operation:
For example, you might SSH into the CLI of a router (the management plane) and configure EIGRP to exchange routing information with neighbors (the control plane), which gets installed into its local CEF table (the forwarding plane). All of these operations occur within the same device, and each node in the network operates autonomously to make its own forwarding decisions based on its local configuration. It's critical to recognize that, although this allows for highly dynamic and automatic forwarding decisions through the use of robust protocols, the end result is ultimately dependent on each node's independent configuration. For the purposes of establishing context, we can think of this as administratively-defined networking.
If you’re configuring an IOS router remotely with a chance of losing the device, most engineers might decide to do a reload in 5 before starting. If you happen to lose connection to the box after a change, the router will reload in 5 minutes erasing any unsaved changes. This works, but is less than [...]