Archive for the ‘route’ tag
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.
OSPF and Loopback Interfaces
I was studying via Google+ Hangout the other day with CJ and Rob, and one of the topics that came up was that OSPFv2 advertises all loopbacks as 32-bit no matter what the configured mask is. I rarely use loopbacks outside of a lab and had no idea it did that, so I set up a quick lab to see for myself. Sure enough! That’s exactly what I saw.
Of course, being the inquisitive network guys that we are, we went on to discuss methods for making OSPF advertise the configured network instead of the single IP. The guys mentioned two methods – to redistribute the connected interfaces and to manually set the OSPF network type on the loopback. We were using IPv4 during the session, but I went back and added some IPv6 addresses and processes to compare.
The Basics
The whole lab consisted of R101 and R102 connected via their e0/0 interfaces; R101 also has a loopback interface as the guinea pig. Here are the interesting lines of config on R101; I think you can figure out the configs on R102.
interface Loopback0 ip address 172.16.0.1 255.255.255.0 ipv6 address 2001:DB8:101::1/64 ipv6 ospf 1 area 0 ! interface Ethernet0/0 ip address 10.0.0.101 255.255.255.0 ipv6 enable ipv6 ospf 1 area 0 ! router ospf 1 log-adjacency-changes network 10.0.0.0 0.0.0.255 area 0 network 172.16.0.0 0.0.0.255 area 0 ! ipv6 router ospf 1 router-id 192.0.2.101 log-adjacency-changes
So, what would I expect to see in the routing table on R102? From our discussions, I would guess that 172.16.0.1/32 and 2001:db8:101::1/128 would show up.
R102#sh ip route
[ SNIP ]
172.16.0.0/32 is subnetted, 1 subnets
O 172.16.0.1 [110/11] via 10.0.0.101, 00:00:03, Ethernet0/0
R102#show ipv6 route
[ SNIP ]
O 2001:DB8:101::1/128 [110/10]
via FE80::A8BB:CCFF:FE00:6500, Ethernet0/0
Hey! I’m right for once. Of course, that’s not really “right” (for definitions of the word). What if I have a service module on my router with an unnumbered IP address bound to the loopback interface. I’m thinking of something like a Unity Express (!). You want to advertise the whole network or else you can’t get to the module. Let’s look at our two options to fix that.
Redistribute Connected
I removed the loopback interface from both OSPFv2 and OSPFv3 processes and redistributed the connected interfaces (don’t forget the subnets option in OSPFv2). Here’s what the routing tables on R102 look like now.
R102#sh ip route
[ SNIP ]
172.16.0.0/24 is subnetted, 1 subnets
O E2 172.16.0.0 [110/20] via 10.0.0.101, 00:00:06, Ethernet0/0
R102#sh ipv6 route
[ SNIP ]
OE2 2001:DB8:101::/64 [110/20]
via FE80::A8BB:CCFF:FE00:6500, Ethernet0/0
We can now see the network as an E2 route with a proper mask in both routing protocols. I don’t like this solution, though, because I have a serious obsessive-compulsive disorder that won’t let me settle with having an internal route show up as external in OSPF. Let’s try the other solution and see if we have any better luck.
OSPF Network-type
For this part of the experiment, I removed the redistribute commands and added the looback interface back into the routing processes. When I manually configured the loopback interface as an OSPF point-to-point network, the networks were advertised as the network without being external. No more nervous ticks caused by my OCD!
! R101 config interface Loopback0 ip address 172.16.0.1 255.255.255.0 ip ospf network point-to-point ipv6 address 2001:DB8:101::1/64 ipv6 ospf network point-to-point ipv6 ospf 1 area 0 end
R102#sh ip route
[ SNIP ]
172.16.0.0/24 is subnetted, 1 subnets
O 172.16.0.0 [110/11] via 10.0.0.101, 00:01:04, Ethernet0/0
R102#sh ipv6 route
[ SNIP ]
O 2001:DB8:101::/64 [110/11]
via FE80::A8BB:CCFF:FE00:6500, Ethernet0/0
Send any type-2002 LSAs questions my way.
Redistribution Notes – Tagging
- Tagging provides a way to mark common or similar routes to manipulate later.
- In redistribution scenarios with mutual redistribution on two different routers, any routes that gets redistributed from one route process to another are tagged.
- When the other router sees those tags on the route, that route to keep from adding non-optimal routes to its routing table.
- Tags can also be used to do other manipulation such as setting higher metrics or changing ADs.
OSPF
R102#show run ... router ospf 1 log-adjacency-changes redistribute connected subnets route-map SETTAG network 192.0.2.0 0.0.0.255 area 0 ! route-map SETTAG permit 100 set tag 55555 ... R101#sh ip route 10.0.0.2 Routing entry for 10.0.0.0/24 Known via "ospf 1", distance 110, metric 20 Tag 55555, type extern 2, forward metric 10 Last update from 192.0.2.102 on Ethernet0/0, 00:00:13 ago Routing Descriptor Blocks: * 192.0.2.102, from 192.0.2.102, 00:00:13 ago, via Ethernet0/0 Route metric is 20, traffic share count is 1 Route tag 55555
EIGRP
R102#sh run
...
router eigrp 1
network 192.0.2.0
redistribute connected route-map SETTAG
no auto-summary
!
route-map SETTAG permit 100
set tag 55555
...
R101#sh ip route 10.0.0.2
Routing entry for 10.0.0.0/24
Known via "eigrp 1", distance 170, metric 409600
Tag 55555, type external
Redistributing via eigrp 1
Last update from 192.0.2.102 on Ethernet0/0, 00:00:14 ago
Routing Descriptor Blocks:
* 192.0.2.102, from 192.0.2.102, 00:00:14 ago, via Ethernet0/0
Route metric is 409600, traffic share count is 1
Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Route tag 55555
–
Corrections are encouraged.
BGP Notes – Route Reflectors
- Route reflectors remove the requirement of having a full mesh iBGP network.
- Any iBGP route a router reflector learns is sent to all route reflector clients.
- Non-client iBGP neighbors do not get the new route per iBGP rules.
- RR clients are configured like normal iBGP routers.
- All RR client config is done on the route reflector.
- RRs and clients are part of a cluster.
- RRs in each cluster must be neighbors with each other.
- Each cluster RR appends the cluster ID to the CLUSTER_ID PA; this is used similarly to AS_CONFED_SEQ.
- The ORIGINATOR_ID PA is set by and preserved by the RR.
- If a route contains the ORIGINATOR_ID of the receiving router, the update is ignored.
- Only best routes are passed to RR clients and non-client neighbors.
router bgp 123 no synchronization bgp cluster-id 1 neighbor 6.6.6.6 remote-as 123 neighbor 6.6.6.6 route-reflector-client
—–
Comment with corrections, please.
EIGRP Notes – Route Filtering
As always, correction are encouraged.
You can configure an EIGRP router to filter routes from being advertised or from being accepted.
Objective: Filter out the route to 10.0.254.1/32 from being advertised to the rest of the network via EIGRP.
ip prefix-list PRE1 deny 10.0.254.1/32 ip prefix-list PRE1 permit 0.0.0.0/0 le 32 ! router eigrp 1 distribute-list prefix PRE1 out -- OR -- ip access-list standard ACL1 deny 10.0.254.1 0.0.0.255 permit any ! router eigrp 1 distribute-list ACL1 out
Routing IPv6 with BGP – The Basics
Are you sensing a theme lately? Since we covered the basics of the main IGPs (I'm an enterprise guy, so no IS-IS comments, please.), I thought I'd try to describe the basics of advertising IPv6 routes over BGP. Yet again, we're not going to do any route manipulation or change any of the 948284928 BGP attributes. We're just trying to get routes exchanged.
Configuration
There's no new version of BGP for IPv6 here. It's the standard BGP version 4 that we've all been using for years, but we're going to take advantage of the multiprotocol support (MPBGP, RFC 2858 RFC 4760). We'll get to the differences in a second, but the first thing to do is to set up the BGP process as normal.
Just as with the IGPs covered so far, the router ID needs to be set somehow. Let's just manually set it for now. We'll be routing on behalf of AS 65001.
Router(config)#router bgp 65001
Router(config-router)#bgp router-id 192.0.2.1
Since we're not using that archaic IPv4 any more, we need to disable IPv4 unicast, which is enabled by default when you configure MPBGP.
Router(config-router)#no bgp default ipv4-unicast
All is good so far? Now comes the part that's different from your standard BGPv4 deployment with your ISP. To enable the protocol for IPv6, we need to use the address-family directive. This tells BGP which of the several protocols that you want to use in MPBGP. We'll use IPv6, obviously; the others are well beyond our scope.
Router(config-router)#address-family ipv6
This will take your to the address family config mode which is where you can configure your neighbors and network statements just like you did in more traditional configurations of BGP. A difference here is that you have to activate the neighbor before the address family is enabled for it. Luckily, that's so easy I won't even explain it; I'm confident you can figure out which command does this. Heh. Let's peer with the router at fc00::2 using AS 65002 and advertise fc00:1::/64 to it, shall we?
Router(config-router-af)#neighbor fc00::2 remote-as 65002
Router(config-router-af)#neighbor fc00::2 activate
Router(config-router-af)#network fc00:1::/64
Piece of cake, right?
I've got to note that this is just one way to configure the IPv6 address family under MPBGP; there are other orders of command entry that can be used to get to the same config. That's actually evident if you look at the config after your'e done.
router bgp 65001 bgp router-id 192.0.2.1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor FC00::2 remote-as 65002 ! address-family ipv6 neighbor FC00::2 activate network FC00:1::/64 exit-address-family
You'll see that config items don't land in the order and place that you configured them. The end results are the same.
Checking Our Work
First, let's see if we have a neighbor adjacency. We're all used to running show ip bgp summary, but we're not running IPv4. The equivalent is show bgp ipv6 unicast summary. The whole unicast/multicast thing is beyond both the scope of this article and of my comfortable knowledge. :)
Router#show bgp ipv6 unicast summary BGP router identifier 192.0.2.1, local AS number 65001 BGP table version is 3, main routing table version 3 2 network entries using 304 bytes of memory 2 path entries using 152 bytes of memory 3/2 BGP path/bestpath attribute entries using 372 bytes of memory 1 BGP AS-PATH entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory Bitfield cache entries: current 1 (at peak 1) using 32 bytes of memory BGP using 884 total bytes of memory BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd FC00::2 4 65002 15 15 3 0 0 00:10:29 1 Router#
We can see the neighbor is up and that we have a single prefix from that guy. Let's check out exactly which route that is with the show bgp ipv6 unicast neighbor fc00::2 routes command. That was a mouthful, eh?
Router#show bgp ipv6 unicast neighbors fc00::2 routes
BGP table version is 3, local router ID is 192.0.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> FC00:2::/64 FC00::2 0 0 65002 i
Total number of prefixes 1
Router#
It looks like we have a route to fc00:2::/64 through that neighbor. That's a good thing since we're trying to exchange routes. The next question is whether we are sending any routes to the neighbor. Run show bgp ipv6 unicast neighbor fc00::2 advertised-routes (even more of a mouthful!) to find out.
Router#show bgp ipv6 unicast neighbors fc00::2 advertised-routes
BGP table version is 3, local router ID is 192.0.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> FC00:1::/64 :: 0 32768 i
Total number of prefixes 1
Router#
That looks right. We're advertising the route to fc00:1::/64 just as we configured in our neighbor statement above. We're on a roll!
Finally, let's check the routing table to make sure that route from the neighbor landed there. Run show ipv6 route like we've done with the IGPs, and you should see prefix as a "B" like in the old days of IPv4.
Router#show ipv6 route
IPv6 Routing Table - 6 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route, M - MIPv6
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
D - EIGRP, EX - EIGRP external
C FC00::/64 [0/0]
via ::, FastEthernet0/0
L FC00::1/128 [0/0]
via ::, FastEthernet0/0
C FC00:1::/64 [0/0]
via ::, FastEthernet0/1
L FC00:1::1/128 [0/0]
via ::, FastEthernet0/1
B FC00:2::/64 [20/0]
via FE80::C001:1FF:FE18:0, FastEthernet0/0
L FF00::/8 [0/0]
via ::, Null0
Router#
Well, there it is. The only thing you may not have see is the concept of address families, but there's not much to that at all.
Send any as-path prepends questions to me.
OSPFv3 – The Basics
A few hours ago, the last of the IPv4 addresses were allocated by IANA. Now's the time to learn more about IPv6! Yesterday, I posted about EIGRP for IPv6, so I think I'll continue the trend by introducing OSPFv3, which is the IPv6 implementation of OSPF. As always, I'm using Cisco routers here. Just as yesterday, this is just a guide to the absolutely basics; if you want to do some funky OSPF magic, you won't find it here – perhaps in time, though.
Configuration
As with all IPv6 routing protocols, the first thing we need to do is enable IPv6 unicast routing.
Router(config)#ipv6 unicast-routing
OSPFv3 also has the same router ID problem as EIGRP for IPv6 has, so we have to sort that out. You can set the router ID either through a loopback interface with an IPv4 address on it or you can set it manually. I'll just do it manually for now. Let's use OSPF process ID 100.
Router(config)#ipv6 router ospf 100
Router(config-rtr)#router-id 192.0.2.1
Just like in OSPFv2 and in EIGRP for IPv6, we add interfaces to the routing protocol instead of using network statements; those don't exist in OSPFv3. Let's assume you already have IPv6 addresses on interface f0/0 and you want that network in area 0.
Router(config)#interface f0/0
Router(config-if)#ipv6 ospf 100 area 0
You can see that it's really easy to add interfaces to different areas as well.
Checking Our Work
Just like we did yesterday, let's check to make sure the right interfaces are participating in the routing protocol. We can do this with the show ipv6 ospf interface brief command.
Router#show ipv6 ospf interface brief Interface PID Area Intf ID Cost State Nbrs F/C Fa0/1 100 0 5 10 BDR 1/1 Fa0/0 100 2 4 10 DR 0/0
You can see that we've got two FastEthernet interfaces in two different OSPF areas. You can even see the state and neighbor count in the output.
That looks good, so let's check to see if we have any neighbors. Of course, we already saw that we have one off of f0/1 from the output above, but just humor me and run show ipv6 ospf neighbors.
Router#sh ipv6 ospf neighbor Neighbor ID Pri State Dead Time Interface ID Interface 192.0.2.2 1 FULL/DR 00:00:31 5 FastEthernet0/1
That looks good to me. The other guy is a DR and is full adjacent with our router. Cool.
One last command shows us the routing table. Can you guess what that command is without looking at the book? Very good, class. It's show ipv6 route.
Router#sh ipv6 route
IPv6 Routing Table - 6 entries
...
C FC00:1::/64 [0/0]
via ::, FastEthernet0/1
L FC00:1::1/128 [0/0]
via ::, FastEthernet0/1
C FC00:2::/64 [0/0]
via ::, FastEthernet0/0
L FC00:2::1/128 [0/0]
via ::, FastEthernet0/0
O FC00:3::/64 [110/20]
via FE80::C001:1CFF:FED0:1, FastEthernet0/1
OI FC00:4::/64 [110/30]
via FE80::C001:1CFF:FED0:1, FastEthernet0/1
L FF00::/8 [0/0]
via ::, Null0
Isn't that fancy? We seem to have both an area router (the O route) and an inter-area route (the OI route). We are ready for the big time now!
Send any tunnel broker recommendations questions my way.
Tagging External Routes in EIGRP
EIGRP allows you to tag external routes. That is, any route redistributed into EIGRP can be tagged with a numeric descriptor from 0 to 4294967295. Read the rest of this entry »
SLA Monitoring on the PIX/ASA
We're working on an data center design for a customer, and they've dropped in two ISP links – each with it's own managed router and public IP space off one of the Ethernet interfaces. The idea is that they want to use the Internet links in an active-passive setup without getting their own IP addresses to avoid running BGP with the ISPs. To top it off, the headend of their control is an ASA cluster, so we wind up with two interface on the Internet to treat with a local security level. Oh, the joys of doing network design.
Your first thought is probably to use the old fashioned floating static route where you have a weighted route that takes over if the primary route is withdrawn from the routing table. That only works if the next-hop of that route is no longer available…like when serial interface goes down and the next-hop isn't directly connected any more. This is Ethernet, though, so there's no way for the firewall doesn't know or doesn't care if a host on the network isn't there any more. This config has another problem, too. What about a scenario where the ISP's router is up, but it's interfaces are down? How about if there are routing issues farther upstream? You surely don't want to send traffic to a provider's router is the provider is having issues, right?
If you've ever tried to do something similar on an IOS router, then you've probably done IP SLA. An ASA has the same functionality, but it's just called SLA monitoring. You wind up with a config that is a very similar to IP SLA stuff on IOS routers, actually. I wrote a terrible blog post about it a few years back, and several other bloggers talk about it as well, but the idea is that you have a process, called an SLA monitor on the ASA, that monitors an IP address by pinging it. You then create a track object that watches the monitor's status. This track object is applied to a static route, and, if the SLA monitor fails, the route is removed from the routing table. We've all done something like this with HSRP tracking, so this shouldn't be totally foreign.
Let's take a look at the test network that I've used to simulate the setup at the customer site.
The test is to have INSIDE1 communicate with TARGET. Each ISP knows where TARGET is through a huge EIGRP AS, but we want to detect any routing problems on ISP1. If we find a problem, we want to roll over to ISP2 on the BACKUP interface. What do we monitor, though? We can monitor the IP of the ISP's router at the data center, but we'd miss any issues upstream. Let's monitor the IP of the second router on ISP1, which is 10.0.0.2. In the real world, we'd fine a host somewhere deep on the Intertubes that we think won't go down very often. In our test, 10.0.0.2 is the closest thing we can find to that.
Let's create a beautiful symphony of ICMP generation. First, we create the SLA monitor.
sla monitor 1
type echo protocol ipIcmpEcho 10.0.0.2 interface OUTSIDE
!
sla monitor schedule 1 life forever start-time now
I think you can see that we are creating an ICMP echo process that will ping 10.0.0.2 on the OUTSIDE interface. The third line is what controls the start and stop of the process; in this case, we start now and don't ever finish thanks to the word forever. We can't use the SLA monitor directly on our routes, so let's create a track object.
track 100 rtr 1 reachability
Now we have track object 100 that looks to SLA monitor 1 for reachability. We apply this to the route just like we do on IOS. We'll go ahead and add the weighted route as well.
route OUTSIDE 0.0.0.0 0.0.0.0 192.0.2.1 1 track 100
route BACKUP 0.0.0.0 0.0.0.0 192.0.2.129 240
Now the default will go through 192.0.2.1 until 10.0.0.2 is unreachable. If that happens, the route is removed from the routing table, and the weighted default route will take over. That's all you need. Of course, I would create another track object for ISP2 so you can at least get a syslog message or SNMP trap if a problem happens over there, but you can probably get away with just the one.
If you've ever done IP SLA on a router, you would call me on the fact that there's some stuff missing. If you don't force the ICMP packets to ISP1's router, the state of the SLA monitor will keep flopping; you flip to ISP2, the SLA check is healthy again, you flip back, the SLA check dies again…ad nauseum. That's not the case for the ASA, actually. Even though the default route has rolled over to the backup, the monitoring process continues to send requests to the old gateway.
Sometime I like it when my gear knows what I'm trying to do; this is one of those times.
Send any stray ICMP packets questions my way.
Audio Commentary
Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.
ROUTE – Epic Win!
Woohoo! I passed the ROUTE test this morning. That means I’m done with the CCNP track! :)
If you remember, I took it over a week ago and had some bad luck on it. Alright, bad luck is the wrong phrase. I didn’t study enough and failed it. This time, though, I had a special weapon on my side – the ROUTE Foundations book. I haven’t used the Foundations books before, but, I saw some tweets about this one, so I picked it up off of Safari. In just a couple pages, I realized that I was reading the answers to several questions directly out of the book. It was amazing. I only studied my weak points and wound up with 144 more points than I did last time. I can’t say that was entirely because of the book, but I must say it was a big reason.
The test, like last time, was actually really good. The questions were well-written and clear for the most part. There were, of course, some that were confusing, but there weren’t any traps like you usually see in the other tests. A couple asked you to do contradictory things. There were a couple that just blasted you with information, but, if you read the question and know the material, the answer just pops right out at you. Overall, another great test. That makes 2 I’ve taken…and they’re both the 642-902. :)
I’m quite excited about finishing up. I’ve had a lot of failures along the way, but the support from the online community has been tremendous. Thanks to everyone who kept pushing me and telling me I could do it. I’m also happy to report that I kept the testing costs below the cost of the CCIE lab (barely) and that I may hold the record for number of P-level tests (8 P-levels tests and 10 overall) and overall Cisco test questions answered (535 questions). What an honor. *denotes sarcasm*
So, what’s next? I think I’m going to take a month or two off from networking to study up for a ham radio license. We get a lot of hurricanes down here, and having a good radio around will help us and the community out if such a disaster happens. I’m calling it prep for CCIE-Wireless. Heh. When I get done with that, I either plan on hitting up the CCIE-R&S or going down the CCDP track. I’m not really sure, but we’ll see when we get there.
Don’t worry. The blog will stay network-related. With the feedback from the study questions format, I think I’ll start a problem question and answer format. I’m also thinking of generating scenarios to work through. Again, we’ll see when we get there.
Send any trips to Delaware questions my way.
Audio Commentary:
Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.