Archive for the ‘cisco’ tag
My Schedule for Cisco Live 2013
I’m all set up to go to Cisco Live in Orlando this year. Good thing, too, since I couldn’t make it to San Diego last time. It’ll be a great and fun time as usual, and I’m quite excited.
As it turns out, ARRL Field Day happens to be the weekend leading up to the festivities. I’ve been in contact with the local Orlando club, and they say the attendees are more than welcome to join them. They are meeting at the City of Orlando Emergency Operations Center, which is about 20 minutes away from the Convention Center.
Anyway, here’s my schedule for the week.
Saturday, 22 June 14:00 : Field Day begins and runs for 24 hours. 17:00 : I'll make my way over to Field Day for a few hours. Sunday, 23 June Open Monday, 24 June 08:00 : CCIE R&S Written (again) 10:00 : BRKARC-3437 - Cisco Catalyst 3750 / 3560 and 2960 Series Switching Architecture 13:00 : BRKARC-2013 - Cisco Nexus 3548 Switch Architecture 15:30 : GENSK-1294 - Enterprise Network Keynote: Getting You Where You Want to Go Tuesday, 25 June 08:00 : BRKDCT-2218 - Scalable Midsize Data Center Designs 10:00 : GENKEY-1295 - KEYNOTE: Tomorrow Starts Here 12:30 : BRKSEC-3021 - Maximizing Firewall Performance 15:00 : BRKSEC-2020 - Firewall Deployment Wednesday, 26 June 08:00 : BRKSEC-1050 - Are you choosing the right VPN technology for your network? 10:00 : GENKEY-1296 - KEYNOTE: Unlocking the Value of Innovation 13:30 : BRKIPM-2264 - Multicast Troubleshooting 16:00 : BRKRST-2041 - WAN Architectures and Design Principles Thursday, 27 June 08:00 : BRKRST-2513 - QoS Design For IPSec VPNs 10:00 : BRKSEC-2691 - Identity Based Networking: IEEE 802.1X and Beyond 12:30 : BRKCRS-3090 - Implementing Network Automation 14:30 : GENKEY-1297 - Celebrity Closing Keynote 16:00 : BRKSEC-2014 - Identifying and Mitigating Network Threats Friday, 28 June Unknown : Leave for home
Does this mean I’m actually going to attend over a dozen classes? Probably not. I’ve got to save some time for socializing and exploring the World of Solutions.
Send any Game of Thrones premiers questions to me.
The Usual End of the Year Tripe
The year is finally coming to an end, so it’s time yet again to look at goals and embarrass myself by publicly admitting that I didn’t meet them. Oh, well. Let’s get this done so I can go back to sleep.
I changed the layout of the blog, so the page with my goals isn’t really visible. Here’s what I claimed I would do this past year.
- Select a CCIE training vendor – Yeah…this didn’t happen. This is a very high-priced item, and I simply couldn’t afford the packages I wanted. We’re talking $8k – $10k for everything. Yikes! I asked management at work to pay for it. They said they would but that I would have to agree not to leave the company for some long length of time. I didn’t want to put myself in a situation where finding a new job meant writing a check for $10k, so I decided to pass on it. Without the financial backing, this ended with me just sighing pitifully on my couch.
- Take the CCIE R&S lab – Of course this didn’t happen without the first one. I guess I could have bought the materials that I could and just got on a bus to Raleigh to see what happens. This whole thing was complicated by the fact that the new job is 95% Juniper. My waking hours at work and my study time at home were spent trying to figure out how Junos works; I tried my best, but it was just too difficult for me to study both at the same time. For the trifecta of excuses, I also had an issue with my study area. I went from a 4-bedroom house to a 1-bedroom apartment when we moved for the new job. There’s no quiet space at all to study at all – a huge problem I need to fix.
- Pass JNCIA-Junos exam – Wo! I actually did this one. I took this exam a few months back and passed it without any problems. Good for me! One out of three!
As for my goals, it really wasn’t a very good year. Even for me, it was bad. I’ll tell you, though, it’s very hard to study when you don’t have one subject or a place to do so. Definitely things I need to work on in 2013.
Since the Mayan doom did not hit us, we move into 2013. I hope you all have a prosperous and happy new year. The best of luck to you all.
An Interesting Interview Story
We’ve been looking for a new Network Engineer for quite a while but are having no luck at all. There is plenty of talent out there, but finding a high-end Juniper guy is almost impossible around here. We’ve loosened up our requirement for Juniper experience just to get someone in for interviews. This led us to one prospect and an interesting story.
This guy’s resume was very impressive. For the last 5 years, he’s been the Network Architect at a very large company. His experiences were off the chart. Large-scale Enterprise deployments. Monster PCI environments. Years of Juniper experience. Years of Cisco experience. I had to talk to this guy, so I got a phone interview with him.
His phone interview was great. We talked about all of the different models of Juniper gear. All the different Cisco routers. Checkpoint. F5. He even had experience with the FWSM and CSM (I’m the only other guy I know who’s dealt with those modules!). This guy was dead on target with what we needed. Before I knew it, it was 2 hours later, and I had to stop the call before we went too late into the night. We hung up, and the other engineer and I huddled to talk about this guy. There was no doubt about it; it was time to get this guy in for a face-to-face. My Director and I met him for dinner the next week. He was well prepared for everything we had for him. He knew about the company. He knew about each of us. He had all the answers we wanted. All thumbs up, so we moved on to the technical lab the next week.
I told him to be prepared for a BGP and an OSPF lab that would be on both Cisco 1800s and Juniper SRX 240s. When he showed up, he had a notebook full of notes and configurations. He had his laptop full of examples and implementation notes. Wonderfully prepared this guy was, so I drew the lab on the whiteboards for him. An routed VPN tunnel with BGP between a couple routers. Some OSPF and redistribution here. Some VRF/RI there. Not very complicated, but not very easy either.
I expected him to be done in about 3 hours or so. After 20 minutes, I asked him how we was doing. He was still configuring IP addresses on interfaces. After an hour, he was still working on getting OSPF working. After two hours of struggling, I helped him get the VPN tunnel up and running. Hour four was spent working through the VRFs and leaking. I finally just called it done to give him a chance at the Juniper stuff in hopes that he was faster in Junos than IOS. Nope. At the 7 total hour mark, I finally just told him he had to go.
I was ready to hire this guy after the phone interview. My Director’s loved him after the face-to-face and actually said he was worried that this guy would be bored in our environments. The obvious moral of the story is that you have to actually challenge a potential coworkers before making a hiring decision.
And I will never think about hiring anyone without putting them through the paces.
CCIE R&S Written – Epic WIN!
The wife and I had a romantic day driving several hours to a small town to take Cisco exams. If this doesn’t get me some action, I don’t know what else to try.
I’ve already used the phrases “skin of my teeth” and “a pass is a pass” on Twitter today for good reason. Passing is a score of 790, and I blew that away with a 790. One more lapse in concentration and I would have been making up more excuses instead of smiling. I think I’ve mentioned this before, but I have this weird reaction to taking exams where I don’t get nervous at all until after I’m finished. Walking into the testing center, I was fine. Walking out, I was shaking like Northern Virginia. It was so bad that I could barely hold on to the door knob when trying to leave, so I guess that I’m really prouder than I thought I was.
The exam was a total piece of crap. Nearly every diagram was so compressed and blurry that I couldn’t see them at all. Most of the time I can infer what the diagram is showing, but, when your bridge priorities are listed there, it’s pretty hard to find root ports. Absolutely horrible. There were the inevitable spelling errors in there, too. Most of those are fine, but STP and SPT are two different topics that are both covered on this exam. I had no problems figuring out which one they were talking about, but it’s pretty unacceptable to have spelling errors in this exam. Of course, there were also the questions that I feel are unanswerable. Switches in VTP transparent mode behave differently from version 1 to version 2, eh?
After being recommended at Cisco Live this year, I added the Boson ExSIM-Max to the pile of prep materials. It not only helped teach a few new things, but it cleared up a bunch of foggy details. I’m sure that using any other study materials will do the same to some extent, but the Boson stuff provided something else – it helped to teach me to take the exams. I was able to go through the questions and practice figuring out what was being asked, which choices were completely wrong, and how to not get utterly frustrated with the questions. Practice makes perfect, right?
The wife came with me to take her ICND1 exam. She did better than she thought she would, but, alas, no dice this time. She says that she’s glad she’s been through it now and knows exactly what to study. I’m trying to convince her to start her own blog since she’s starting up her cert journey from such a unique place. We’ll see how that works out.
What’s next? I have to find a company to help me prep for the lab now. I’m sure that’s not cheap at all. Maybe I should just blindly sit the lab and see what happens. Maybe not. :)
OSPF Notes – Neighbor States
My prediction about covering network types was wrong. I’m going to puke out some information about neighbor states for now. As is always the case, corrections are welcome.
Down : No hellos have been received from this router.
Attempt : This state only applies to manually-configured neighbors on an NBMA network. In this state, a router has sent unicast hellos to the neighbor but has not received any back from it.
Init : The router has received hellos, but none of the hellos have the router’s RID included as a known neighbor.
2way : The router has received hellos with its RID included. This means the other router has received the hellos from this router, so they now have 2-way communication going. The DR and BRD is elected at the end of this stage.
ExStart: When a router grows up and starts to have feelings for other routers, it enters the ExStart state to have further relations with a neighbor. This is where the master/slave relationship and the initial sequence numbers are established.
Exchange : Once we know who wears the pants in this relationship, the master sends over a DBD with it’s LSAs listed. In response, the slave does the same so that both routers have all the LSA headers they both know.
Loading : This is where the LSRs and LSUs flow. If a router need the full LSA from the neighbor, it sends an LSR, and the neighbor should send an LSU in response.
Full : After the LSR/LSU exchange, the routers should both be in sync, so they each send an LSAck to the other to confirm.
As a bonus, here’s a nifty little animation showing neighbor states.
OSPF Notes – LSA Types
Yes, it is inevitable that I cover these. I’m sure network types will be next. Per my usual request, please correct my stupidity.
Type 1 – Router : This LSA type lists all the routers by RID as well as the networks to which that router connects.
Type 2 – Network : These LSAs represent broadcast network where more than one OSPF router may live. Think Ethernet or multipoint segment. These LSAs are flooded by the DR for that segment.
Type 3 – Net Summary : An area border routers take the type 1s and 2s from one area and floods them as type 3s into another, so all of these LSAs are from other areas. No topology information is included in these LSAs; it’s basically an advertisement from the ABR saying the route is through him.
Type 4 – ASBR Summary : These LSAs make sure that all routers in all areas have a path to an ASBR that’s flooding type 5 LSAs. Those routes in the area with the ASBR won’t see these.
Type 5 – AS External : These are flooded by an autonomous system boundary router and are routes redistributed into OSPF from another routing process like EIGRP or BGP. Since these routes come from a different source, there’s no way to discover the topology past the ASBR, so we just have to trust the rumor that the network exists that way. E1 routes gets the OSPF path cost added as it crosses the network, while E2 routes (the default) have a static cost.
Type 6 – Group Membership : This is for Multicast OSPF and not supported by IOS
Type 7 – NSSA External : An ABSR in an NSSA floods routes to the external routing process through type 7 LSAs. ABRs will translate these to type 5s when flooding other areas.
Type 8 – External Attributes : Back in the day, OSPFv2 had plans to overthrow iBGP. Type 8 LSAs would have been used to carry BGP attributes while the routes themselves would be of type 5. Type 8s aren’t supported in IOS.
Type 9,10,11 – Opaque : Something…something…traffic engineering…blah, blah, blah.
OSPF Notes – Message Types
I have had my nose deep in several books in preparation for my CCIE R&S written exam, so I haven’t been blogging much at all. Now that I’ve made it to the more familiar topics, I’m hoping to get some notes posted. I’ll start with OSPF message types.
As always, please feel free to correct me here. I’m learning just like the rest of us.
Hello : These messages are used to establish neighbors and serve as keepalives among other things.
Destination: 224.0.0.5 Important Fields: Hello interval Dead interval Router priority (for DR election) Known DR Known BDR Active neighbors
Database Descriptor (DBD or DD) : These messages send summaries of a router’s known LSAs to a new neighbor. Receiving routers can use this information to compare to their database and ask for more details if needed.
Destination: Unicast IP of the new neighbor Important Fields: LSA header
Link State Request (LSR) : Once a router has received a DBD, it parses through the info in it to see if the message is either more up-to-date or if it has some new info in it (like a new network). If the router needs an update, it asks for the full LSA through an LSR.
Destination: Unicast IP of the router that sent the DBD Important Fields: LSA type LSA requested
Link State Update (LSU) : When a router receives an LSR, it responds with an LSU that contains the details information for the requested LSA. It also sends an unsolicited LSU whenever it learns of new LSAs such as when you turn up a new interface.
Destination: Unicast IP of the requesting router, 224.0.0.5, or 224.0.0.6 depending on who's updating whom Important Fields: LS age LS sequence number Full LSA
Link State Acknowledgement (LSAck) : If a router receives an LSU, it responds with an LSAck to acknowledge it was received.
Destination: 224.0.0.5 Important Fields: LS sequence number
Home-grown IOU Scripts
I’m sure you’ve all heard of Cisco IOU by now, and I’m finally catching up with the other bloggers of the world by mentioning it. It’s an executable version of an IOS image that runs on a Unix (or Unix-like) platform and it’s the backend behind Cisco’s Learning Labs. Instead of running an emulator and loading up various images, you just run the executable and you’re on the console of a Cisco router. It has layer 2 support, so you can fire up switches as well. Being a binary makes it way more efficient than GNS3 will ever be, and the layer 2 support is a wonderful, wonderful feature to have.
Being lazy and hating doing things over and over and over again, I wrote a few bash scripts to help set up any labs you may want to run. First and foremost, I am not a bash programmer; I mostly stole and chiseled some old code I had from back in the day to get these working. The end result, though, is pretty good for what I’m trying to do. You can define a lab setup with various files and start up all the routers (or switches) along with terminal server-like access to the consoles through a process wrapper.
genRouter/genSwitch
At the heart of the system is a script I call genRouter (or genSwitch if using layer 2). Yes, I learned to program in Java when it was cool, and that’s why I name all my stuff like object methods. Anyway, genRouter takes 4 command line parameters and, along with the variables that are set in the script, fires up a new router. A common deployment is to use a wrapper application to bind the router process to a TCP port to use as a console, and that functionality is included in the script. Here are the variables included. You’ll need to change a bunch of these for the script to work.
$IOUFILES – This is a variable that tells where the IOU files are kept.
$L3IOU – This is variable that sets what IOU executable you want to use for a router.
$WRAPPEREXE – This is the full path to the process wrapper you want to use and is defined in the script.
$ETHCOUNT – This is the number of Ethernet interfaces you want to bring up on the router. This is taken from the command line as $1.
$SERCOUNT – This is the number of serial interfaces you want to bring up on the router. This is taken from the command line as $2.
$MEMCOUNT – This is the amount of memory you want to give the router. This is taken from the command line as $3. The script takes this variable, but it doesn’t do anything with it due to memory declaration problems with the IOU image. The default is 128M. This is something to work on later.
$INSTID – This is the IOU instance ID. This is taken as $4 from the command line and is used to differentiate the different routers you have running simultaneously.
genSwitch does the same thing except that it uses $L2IOU to point to the layer-2 image instead of the layer-3 image. There is a better way to do this, but I haven’t given it enough thought (or asked Google) yet.
When either script is called, it generates a TCP port number by appending the instance ID to the number 10. If you fire up instance 842, then the TCP port to which to telnet for access to this router is 10842. This is good for 3-digit IDs, but there will be service clashes if you use instance ID 9 or something. That also sounds like something that needs to be fixed.
Each script also takes the process ID of the router and stores it in a file for use later. The file is actually ./pid/$INSTID.pid, and you’ll have to create that directory. This is a common technique to watch processes and will be used later.
startProject
The “human interface” script – the one your run from the command line – is called startProject. This script looks in the current directory for a file called routers.db, and, using the info in there, fires off all the routers for you through genRouter. In this file, you put in values to be used by genRouter to define $ETHCOUNT, $SERCOUNT, $MEMCOUNT, and $INSTID. Each line is a new router, so you can use this file to start up a whole mess of them at once.
Something like this.
1 0 128 100
1 0 128 101
0 1 128 102
IOU uses a netmap file to define how router interfaces are connected to each other. Using the same netmap file for all your labs isn’t very flexible, so I just set the NETIO_NETMAP environment variable to “./project.netmap” to run different labs from different directories. Make sure that your routers.db and netmap files both reference the correct instance ID for each router; you’ll obviously get unexpected results if they don’t.
startProject doesn’t take any arguments; everything it needs is in your routers.db or your netmap file. Just run startProject from wherever you put those files.
I have a “labs” directory in my $HOME, and, under that, I created directories for each thing I’m studying. If I’m doing an OSPFv3 lab, I create a directory called “ospfv3″ or something and put my routers.db file, my netmap file, and my pid directory there. I then fire off startProject from there to get the whole thing going.
startProject is terribly written. It doesn’t check any values at all, and just send what it reads directly to genRouter without asking any questions. A real sysadmin would laugh hysterically at this script (as I do). Perhaps someone can fix it up. :)
killProject
I bet you know what this does. It goes into ./pid/ and kills off all the processes that are stored there. Nothing fancy at all.
The Files
Here are the scripts themselves. Just put them somewhere in your path and change the variables as in genRouter and genSwitch as needed. You may have to do a “Save As…” or just copy-and-paste the text into files yourself.
genRouter
genSwitch
startProject
killProject
All of them in a tar.gz
I don’t want any trouble from anyone, so I don’t have a copy of IOU to give away. Please use your own set of sleuthing skills to find a copy on the dark parts of the InterWebs. :)
Send any bbq recipes questions to me.
Cisco Live 2011 Schedule
For the first time ever, I’m headed to Cisco Live – the big Cisco users conference in Las Vegas! I usually don’t go to these things since I wind up just hanging out by myself, but I’m meeting all sorts of people there – from bloggers to Tweeps to personal friends. It should be a huge blast, and I can’t wait to get there.
For those interested, here’s my schedule.
Sunday, 10 July
13:00: CCIE R&S Written (Woohoo…one of my goals for 2011!)
Monday, 11 July
09:30 – 11:30: BRKRST-2311 – IPv6 Planning, Deployment and Operation Considerations
12:30 – 14:30: BRKSEC-2003 – IPv6 Security Threats and Mitigations
15:00 – 17:00: BRKIPM-1261 – Introduction to IP Multicast (I know NOTHING about multicast)
Tuesday, 12 July
08:00 – 09:30: BRKCRS-3466 – Understanding the ACL Architecture on the Catalyst 6500
10:00 – 11:00: GENKEY-4700 – Keynote and Welcome Address
12:30 – 14:30: BRKRST-2500 – Campus QoS Design
16:00 – 18:00: BRKRST-2312 – An Overview of IPv6 Routing
Wednesday, 13 July
08:00 – 10:00: BRKARC-2350 – Routing Operations in Cisco IOS Routers
10:30 – 11:30: GENKEY-4701 – Cisco Technology Keynote
12:30 – 14:30: BRKRST-2501 – WAN and Branch QoS Design
16:00 – 18:00: BRKRST-2042 – Highly Available Wide Area Network Design
Thursday, 14 July
08:00 – 10:00: BRKRST-2301 – Enterprise IPv6 Deployment
12:00 – 14:00: BRKSEC-2202 – Understanding and Preventing Layer 2 Attacks in IPv4 Networks
14:30 – 15:30: GENKEY-4702 – Closing Keynote (SHATNER!)
16:00 – 17:30: BRKCDN-1109 – XDE: an Environment for Customizing Network Management
Friday, 15 July
Fly home at some unknown time
It should be a great time indeed. Be gentle, though; it’s my first time.
Stubby Post – Final Tally of 3750 Failures
It’s pretty widely known that I hate Cisco 3750 switches. We’ve had so many hardware and software failures with them that I’ve got a seriously bad taste in my mouth. Since I’m leaving for a new company, I thought I’d publish some statistics while I still have access to the numbers.
Total TAC cases opened related to 3750s: 21
Number of 3750G-12S-S replaced: 21
Number of 3750G-24TS replaced: 7
Total number of RMAs issued: 28
Total number of 3750s in the company: ~120
Failure rate: 23.3%
I can accept a handful of failures, but 23%?!?!? That’s one fine platform you’ve developed there, Cisco. Keep up the good work.