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.
JNCIS – Epic Win (Again)
I spent the last of my Juniper exam vouchers on the JNCIS-SEC exam and passed by the skin of my teeth today. Since I took a new job last month that’s 100% Cisco, this is the last Juniper exam I’ll take for the foreseeable future. Too bad, too. I really like the Juniper exams.
At my previous job, we were 90% Juniper with a whole mess of SRX firewalls around the world. Since this exam is really about that platform, it was pretty logical that I should do alright on it. Of course, a large part of the blueprint was on IDS and UTM, and I have no experience there. For my entire career, those type of devices have been handled by other groups, so I had some studying to do. That’s where I ran into problems. I have absolutely no interest in IDS. I have no interest in UTM. There’s nothing about content scanning and analysis that interests me at all. I promise you all that I tried my best to read up on these topics, but I was asleep after 10 words every time I tried. After rescheduling the exam twice to try and study a bit more, I finally decided it wasn’t worth the trouble and just took the exam…and passed.
The exam was typical Juniper with clearly-worded questions and perfectly-clear exhibits all around. A near-perfect exam yet again from Juniper. I was disappointed by three questions, though. The problem wasn’t with the technical details; they were just worded terribly. I’m definitely not shy about commenting on questions during the exam, so hopefully the exam team can use my comments to improve those bad apples. I’ll miss these exams; Cisco surely doesn’t produce any exam of this quality.
Send any Final Four tickets questions my way.
Junos – Logical Tunnel Interfaces with Virtual Routers
There are a few ways to leak routes in and out of virtual routers in Junos. On the list is a cool feature called the logical tunnel interface.
So, what am I talking about? One way to separate traffic on a router is to use virtual routers (VRs) so that you wind up with multiple routing tables on the same router. This separate traffic, but you will usually (read: always) have a demand to get traffic from one VR to another. There are a few different way to do that (see rib-group, instance-import, next-table, et al.), but one really cool way to do it is through logical tunnel interfaces.
The logical tunnel (lt-0/0/0) interface is a special little guy that allows you to connect its units to each other. The result is similar to connecting an Ethernet cable from one physical interface to another. With a little configuration, these guys provide a point-to-point interface that you can include in your routing setup. Let’s look at an example.
set interfaces lt-0/0/0 unit 100 encapsulation ethernet set interfaces lt-0/0/0 unit 100 peer-unit 200 set interfaces lt-0/0/0 unit 100 family inet address 192.168.0.100/24 set interfaces lt-0/0/0 unit 200 encapsulation ethernet set interfaces lt-0/0/0 unit 200 peer-unit 100 set interfaces lt-0/0/0 unit 200 family inet address 192.168.0.200/24
The encapsulation lines are pretty straightforward. In this case, I want the link to appear as an Ethernet interface, but you can choose frame-relay, vlan, bridging, and others.
The peer unit lines tell what unit is connected to what other unit. Each lt-0/0/0 unit is a point-to-point link, so you have to tell the router what’s on the other end of the link (sorry…no multiaccess here). In this case, I want unit 100 to connect to unit 200, so I configure both units with the appropriate peer unit.
Of course, we can all figure out that we’re using IPv4 on these new units as well. In this case, I’ve put both interfaces on the 192.168.0.0/24 network (how original!).
Now that we have our interfaces configured, we need to put these interfaces into the correct VR. Don’t forget the security zone, too, if you’re running in flow mode. That’s beyond the scope here, though.
set routing-instances VR100 instance-type virtual-router set routing-instances VR100 interface lt-0/0/0.100 set routing-instances VR100 interface lo0.100 set routing-instances VR200 instance-type virtual-router set routing-instances VR200 interface lt-0/0/0.200 set routing-instances VR200 interface lo0.200
I put lo0.100 and lo0.200 in there to have something to advertise. You’ll see that in a second.
Now, let’s see if we can ping across.
root@TestSRX# run ping 192.168.0.100 routing-instance VR200 PING 192.168.0.100 (192.168.0.100): 56 data bytes 64 bytes from 192.168.0.100: icmp_seq=0 ttl=64 time=1.879 ms 64 bytes from 192.168.0.100: icmp_seq=1 ttl=64 time=3.480 ms <SNIP>
Woot! It works. Now we can treat these new interaces as if they are regular ole Ethernet. Since I’m not ready to try and blog about IS-IS, let’s just use the standard OSPF. I’m not going to go through the steps to configure OSPF, but here’s the routing table after all the interfaces are included.
root@TestSRX# run show route
VR100.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.100/32 *[Direct/0] 00:41:33
> via lo0.100
10.0.0.200/32 *[OSPF/10] 00:00:28, metric 1
> to 192.168.0.200 via lt-0/0/0.100
192.168.0.0/24 *[Direct/0] 00:38:21
> via lt-0/0/0.100
192.168.0.100/32 *[Local/0] 00:38:21
Local via lt-0/0/0.100
224.0.0.5/32 *[OSPF/10] 00:01:18, metric 1
MultiRecv
VR200.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.100/32 *[OSPF/10] 00:00:28, metric 1
> to 192.168.0.100 via lt-0/0/0.200
10.0.0.200/32 *[Direct/0] 00:41:33
> via lo0.200
192.168.0.0/24 *[Direct/0] 00:38:21
> via lt-0/0/0.200
192.168.0.200/32 *[Local/0] 00:38:21
Local via lt-0/0/0.200
224.0.0.5/32 *[OSPF/10] 00:01:18, metric 1
MultiRecv
Look! OSPF routes! Sweet. Just to keep my OCD at bay, let’s ping from the loopback of one VR to the loopback of the other.
root@TestSRX# ping source 10.0.0.100 routing-instance VR100 10.0.0.200 PING 10.0.0.200 (10.0.0.200): 56 data bytes 64 bytes from 10.0.0.200: icmp_seq=0 ttl=64 time=1.463 ms 64 bytes from 10.0.0.200: icmp_seq=1 ttl=64 time=1.443 ms <SNIP>
Well, look at that. It works again.
Let’s look back at the topic we’re discussing, though. If we use OSPF between the VRs, we need to make sure our routing design allows us to filter routes between the VRs; the risk is that you may wind up having all the routes from each VR advertised to the other. Kind of defeats the purpose, eh? Running BGP between the VRs might be an option that allows you to control what routes go in and out. Statics might be the answer, as well. As long as you can filter the advertisements, you wind up with a pretty elegant solution for sharing routes between VRs.
Send any Marshmallow Peeps questions my way.
JNCIS – Epic Win!
I quit my job…by design. I start a new gig on Tuesday and am getting back to the world of Cisco. As a last nod to Juniper, I decided to use an exam voucher I had and take the JNCIS-ENT exam. Easy pass.
The content was right along with the exam objectives, so there were no surprises. Most of the topics are things I’ve done a thousand times on the job. There were some things, though, that were beyond my experience. IS-IS was the big one. The very first question I got was about IS-IS metrics, and I had absolutely no clue what the answer was. Nor did I have any clue about the other IS-IS questions. I went 0-for-3 on those guys. The only other problematic topic was HA, which didn’t really surprised me. I was able to answer the VRRP questions, but I’ve never done any GRES, ISSUe, RTG, etc., at any point in my career. It wasn’t surprising that I didn’t do too well on those. Everything else was cake, and I only missed 6 questions in my comfort zone.
The exam was yet another top-notch effort from Liz and the group, but there was one questions that didn’t meet the standard set by the others. It was a VRRP question, but it used some awkward wording that that I read over and over. I just used the context of the questions to give an answer and moved on.
There was really nothing else to report. It was a great exam, so don’t be afraid to take it if it’s next on your list.
Send any Cisco refresher courses questions my way.
Goals for the New Year
Yes, I know I’m late. Just remember I’m lazy, and it all makes sense.
This year I’ve decided to go a little more practical with my goals. Instead of “get this cert” or “learn about that”, I’ve decided to take some steps to help myself. That is, in order to learn and advance, I need make sure I give myself the opportunities to do so. Damn, that sounded like some crap from a marketing department, so let me use my own words.
- Find a place to study. When I took my current job, we moved to another city and to a very small apartment. Now I don’t have the spare bedroom as an office and a quiet place away from everything. Of course, my study schedule and quality has suffered because the only place to study I have now is less than 10 feet from the wife and the TV. I’ve got to find a place that’s quiet.
- Find a place to lab. Right now, I’ve got a pile of Cisco and Juniper gear sitting on a shelf at that same study location.. I’ve either got to find a way to access these remotely (somewhere quiet) or find a service to employ to get hands-on experience.
- Go to Cisco Live US. After missing last year, I won’t let myself miss it this year. It’s within driving distance, and, more importantly, the hotels will be cheap again in Orlando. There’s no excuse not to go.
If I can accomplish these goals, then I’ll be back on track for getting some new certs or finishing out some old goals. And I seriously do miss studying and learning.
See you guys at Cisco Live. Yes, I’m going to wear my Juniper Ambassador shirt.
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.
Junos Basics – Routing Instances
Here’s one that I use every day at work. We have multiple customers coming into the same router, and, as luck would have it, they all use 192.168.1.0/24 (OK…not really but it might happen). That means we have to separate them into their own routing instance, or virtual router, so pass traffic to their firewall. Think VRF lite on a Cisco router. Let’s conflagrate.
First, we configure the instance as a virtual-router.
set routing-instances CUST1 instance-type virtual-router
There are a handful of instance types, and, to tell the truth, I’ve never cared to really look into them all. Let’s use the good ol’ “beyond the scope of this document” excuse on that one so I look a little more prepared.
In practice, the virtual-router type creates a new routing table to isolate traffic on the same router. It’s pretty worthless to just create it and not do anything with it, so let’s take some of our interfaces and shove them into the new routing instance.
set routing-instances CUST1 interface ge-0/0/0.100 set routing-instances CUST1 interface ge-0/0/0.150 set routing-instances CUST1 interface vlan.200
Not hard. So, let’s add some static routes and some OSPF config to make it even more functional. With the base routing table, you just configure those under routing-options and protocols. It’s the same here, but you just shove that config under the routing instance tree. Something like this.
set routing-instances CUST1 routing-options static route 192.168.0.0/16 \
next-hop 10.1.100.1
set routing-instances CUST1 protocols ospf export REDIST-INTO-OSPF
set routing-instances CUST1 protocols ospf area 0.0.0.0 interface ge-0/0/0.100
set routing-instances CUST1 protocols ospf area 0.0.0.0 interface vlan.200
set routing-instances CUST1 protocols ospf area 0.0.0.150 interface ge-0/0/0.150
Now we have a new routing instance with 3 interfaces in it along with a static routes and OSPF. Great. Let’s see what the routing table looks like now. A show route does that job.
inet.0: 6 destinations, 6 routes (3 active, 0 holddown, 3 hidden)
+ = Active Route, - = Last Active, * = Both
...SNIP...
CUST1.inet.0: 15 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.1.0/24 *[OSPF/150] 1w5d 14:49:47, metric 0, tag 0
> to 10.1.100.1 via ge-0/0/0.100
...SNIP...
Now the CUST1 table shows up. Looks like we already have an OSPF route, too. That turned out better than I thought.
With routing instances, you’ll have to look at adding instance or routing-instance to your show commands to limit output to just a single instance. For example, show ospf neighbor instance X and show interfaces terse routing-instance X. Contextual help for the win!
NOTE: I’m going to leave it at that, but you may have to add more to this config to make it work. For example, on the SRX platform in flow-based processing mode (the default), you’ll have to create security zones for each interface along with appropriate policies and host-inbound-traffic. This is twice in one post that I’m claiming this is beyond the scope of this document. :)
Send any Halloween candy questions to me.
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.
Junos Basics – Configuring BGP
I’m stuck deep in Junos these days. I mean deep. I have an F5 load balancer and an ASA 5520; the rest of my stuff is Juniper. That means I have some learning to do.
Here’s one of the basics in Junos – configuring BGP. I guess I’ve always said that BGP is BGP. How much different can it be from IOS? Well, the end result is the same, but it’s different enough to have to look up how to do it. :) The first difference is the fact that all BGP configuration is done with groups just like peer groups in IOS. You can act like you’re configuring neighbors, but there’s no way around using groups. After going back and forth, I just settled with an group for eBGP neighbors and another for iBGP neighbors. If settings are different, I just set them in the neighbor. Here’s an example of that.
routing-options {
autonomous-system 65001;
}
protocols {
bgp {
group EBGP {
type external;
peer-as 65021;
neighbor 192.0.2.1;
}
group IBGP {
type internal;
neighbor 192.0.2.100;
}
}
}
You noticed that your own ASN isn’t configured in the BGP section, didn’t you? It’s actually configured in the routing-options configuration. Also notice the type directive there. For some reason (can someone speak to why?), you declare a group as either internal or external neighbors. If the type is external, you obviously have to declare the peer’s ASN.
This configuration won’t do very much. Actually, it pretty darn pointless. All it does is peer up with the two neighbors and accept their routes. We’re not sending them anything or doing anything funky with their routes as they come in. To do something cool, you’ll need to look at seemingly endless configuration items. Those are beyond scope here, though.
Did we configure BGP correctly? Let’s find out.
root@ROUTER> show bgp summary Groups: 2 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 494478 431927 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.0.2.1 65021 3819628 58226 0 3 1w2d21h 401542/415727/415727/0 0/0/0/0 192.0.2.100 65001 3554056 3457157 0 1 2w4d6h 30385/78751/78751/0 0/0/0/0
That’s horrible output, but you can see that we have two neighbors. You can also see their ASNs, how many routes we’re getting from them, how many we’re dampening, etc. One cool thing to notice is the routing table that is being used. We’re not running routing instances on this router, so we only see “inet.0″ in the list. That’s the base routing table. If we did indeed have BGP neighbors on a configured routing instance, you’d see it listed here as well. One more thing to notice – the 431k active paths. That’s a lot of routes!
How do I know what I’m sending to my BGP neighbors? Like I said, you’re sending nothing here. The default behavior of BGP in Junos is to not send anything; you’ll have to configure a policy-statement if you want to actually advertise something. If you put in a little more config (again, beyond scope here), you can see something like this. A single route for 199.199.199.0/24 coming from our external peer. Success!
root@ROUTER> show route advertising-protocol bgp 192.0.2.1 inet.0: 431634 destinations, 494173 routes (431634 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 199.199.199.0/24 Self I
That’s good enough for now. We’ll have to fill in the gaps over time.
Send any canoe rental vouchers questions to me.
Stubby Post – Time for a New Provider
After years of getting so-so service from my old hosting provider, I’ve finally migrated over to an unnamed competitor. After my thorough testing schedule, I have no doubt that everything nothing is broken. Surely I didn’t miss some diagrams or audio files or videos or anything. If you happen to find anything amiss (and you won’t), let me know.
Maybe I’ll actually have a real blog article one of these days.