I was able to watch a good chunk of the morning session of the OpenFlow Symposium in San Jose. The stream was having issues at the beginning of the afternoon session, plus I was pulled away for other issues, so I was only able to watch the morning session. I’d like to provide a bit of a write-up from what I was able to catch, and point out some of the highlights that I took interest in from the day’s speakers.
I’ve been trying to get more into networking message boards like Networking Forum and TechExams.net lately. It’s a great way to get in touch with fellow packet lovers and gain some interesting perspectives along the way. In fact, it’s great for anyone in networking, whether you’re a hardened veteran or a newbie - there’s usually a place for you in at least one of these sites. As a result, I’ve seen quite a few posts asking about fundamental concepts, which is great because it shows that new networkers are getting out there and learning new things proactively.
Partial Mesh [pahr-shuhl mesh] noun
A type of networking where each node must not only capture and disseminate its own data, but also serve as a _relay_ for other nodes, that is, it must collaborate to propagate the data in the network.
What happens to your screen doors when you get cats
Image and definition credit: Wikipedia
Like most others that start tinkering with IPv6, I quickly learned that there was no such thing as broadcasts on v6 networks. Since I thought that was a pretty revolutionary concept, I started thinking about all the protocols that until now have relied upon the ability to send via broadcast. The first that came to mind was ARP, which resolves known IP addresses to unknown MAC addresses by sending to the Layer 2 broadcast address of FF:FF:FF:FF:FF:FF.
I’m currently working on a project that, among other things, involves the installation of two Catalyst 6509 switches. I was recently shown a redundancy feature that I had never heard of before called Virtual Switching System (VSS). The more I looked at it, the cooler it was.
The main reason for VSS is something that is typically addressed when there are redundant routing platforms on a network. There are actually quite a few solutions that can be used in the presence of redundant devices, such as the popular and Cisco-proprietary Hot Standby Router Protocol (HSRP), or the IETF open standard Virtual Router Redundancy Protocol (VRRP).
Hello.
Let me begin by saying you have arrived.
Pardon me, where are my manners? I am CiscoMan - the comforting presence at the top of a large number of Cisco documents such as configuration and installation notes for Catalyst switches.
I’m here to tell you that everything is going to be alright - that it’s okay to be scared. CiscoMan is here to help you out.
Believe me, you’re not my first.
I woke up this morning and realized that I had broken my 3-week long streak of blog posting, where I had gotten in the habit of making a new post nearly every day of the week. Since I have been unemployed for the past three weeks and my primary priority was to study for the CCNP, it was easy to come up with new blog content at a relatively rapid pace.
It’s important to remember that since BGP is the routing protocol of the internet, there are quite a few attributes that it uses to give preference to a single route out of several redundant paths to a given destination.
I was recently contemplating several of these and it occurred to me that two of these attributes in particular are pretty similar. I’d like to compare and contrast them and give reasoning for situations that call upon one or the other.
In a previous post, I explored the basics of IP routing, and in the process, we discovered an interesting default feature of OSPF. When there were two OSPF routes in the routing table to a network, and both routes had the same cost, the router performed load balancing between the two. Take, for instance, the following route:
172.16.2.0 [110/12] via 1.1.1.13, 00:09:24, FastEthernet0/0 [110/12] via 1.1.1.2, 00:09:24, FastEthernet0/1 In this example, every packet sent would take one of two routes.
When it came to networking, my university classes didn’t teach me much more than the basics of network infrastructure, and a little bit of route/switch. Now that I’ve graduated, I continue to learn as I strive for the next steps. So far, it’s been CCNP ROUTE, since I knew I wanted to go for it soon after CCNA. Because of this trend, I’ve been pretty devoted to routing, with a small segway into security as I obtained my Security+ certification.
I’ve been pretty deep into my CCNP ROUTE studies, which is mostly WAN and routing protocols, so I haven’t had much chance to dive any deeper when it comes to datacenter stuff.
I’d seen several ads for the Brocade whitepaper titled “Five Reasons Classic Ethernet Switches Won’t Support the Cloud” and I figured I’d give it a shot. The whitepaper is not long, and is quite easy to understand. It contrasted well between traditional switches and Ethernet Fabric switches in terms of supporting SaaS application requirements, pointing out that while STP is a necessary evil in a classic Ethernet switched infrastructure, it creates several problems for “the cloud”.
Commonly used routing protocols like OSPF and EIGRP utilize multicast addresses to distribute hello messages, and routing information. In a broadcast-capable layer 2 network like Ethernet, EIGRP will send a packet containing a hello message to the address 224.0.0.10, which results in a corresponding layer2 destination 01:00:5e:00:00:0a.
Something I used to wonder about all the time is how routing protocols work over Non-Broadcast Multi-Access networks like Frame Relay. In these networks, there are no broadcasts or multicasts.
I was inspired by a (relatively) recent post by Jeremy Stretch at Packetlife.net that explained OSPF designated router configuration in Cisco IOS. I’d like to go into a bit more detail regarding the need for a designated router, and explore the same configuration steps on the Vyatta Core platform. I’ve already shown how easy it is to integrate a Cisco router with a Vyatta router using OSPF, so you can use a mix of Cisco and Vyatta gear if you wish.
I wrote a post a while back introducing OpenFlow, and I informed you of my thoughts concerning this relatively new technology. Regardless of your need for a programmable network, the concept is certainly interesting and warrants some tinkering. It’s important to remember that OpenFlow itself is just a protocol definition, and until recently, there wasn’t a lot of software available that implemented it, and thus, no in-home tinkering. I’d like to point out a few new projects that are implementing OpenFlow and making it relatively easy to implement on your own.
Today we’ll be looking at Routing Information Protocol, or RIP. This is an easy-to-use protocol to distribute routing information around a network. We’ll explore how to configure it on a Cisco router, and some of the tweaks necessary to get it to perform well in a modern network.
Download the Lab Outline
Download the GNS3 Lab used in this video
For years, discussions regarding the appropriate prefix length for IPv6 subnets have been waged, with high profile organizations and bloggers chipping in their $0.02 for all kinds of opinions.
IPv6 enthusiasts have long-adhered to their “A /64 for every subnet” approach, and they give many good reasons for this approach. There are others who recognize the sheer amount of waste from this method, and suggest much more restrictive prefixes, such as /126 for a point-to-point link, as that prefix allocates 2 addresses, identical to the /30 mask in the IPv4 world.
A while back I did a post called IPv6 Hacking - “thc-ipv6” Part 1 - it was, in fact, the first post here on Keeping It Classless. That post focused on the flood_router6 script, which unleashed a flood of IPv6 Router Advertisements (RAs) on a layer 2 network segment, bringing vulnerable operating systems like Windows 7 to their knees.
The “fake_router6” script is another member of the “thc-ipv6” suite that grants a powerful weapon to a would-be attacker.
This is a guide to configuring OSPF between Cisco IOS and the open-source Vyatta router platform. I was able to do all of this on my desktop PC, by running Cisco IOS in GNS3 and Vyatta as a virtual machine. I used the guide here to bridge both virtual routers together, so that communication could be established.
The Cisco side was pretty straightforward. I configured the FastEthernet interface and enabled OSPF on it:
Matt Oswalt