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.  :)

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

CCNP Routing and Switch Quick Reference, 2nd Edition :  This doesn’t have the required details, but I read it to get the rust off the more-basic topics.  A good read-through at lunch does wonders for the memory.

CCIE Routing and Switching Certification Guide, 4th Edition : I’m using this book as the cornerstone of my studies, and my study schedule is based off of the topics in here.  I’m not expecting all the details to be in this book, but it seems to be going along with the blueprint pretty well.  We shall see, shan’t we?

Routing TCP/IP Volume I, 2nd Edition, Routing TCP/IP Volume 2 : I’m not reading the Doyle Bibles cover-to-cover; instead, I’m using them for cross reference.  If I’m reading anything that makes no sense or that is worded awkwardly, I just read that section of the Doyle Bible to clear it up.  It’s been working great so far.

RFCs : Any RFC mentioned in the text goes into my pile of reading materials.  A lot of these are fairly short, but some of them are a huge struggle to work through.  I would find it hard to believe if you told me you enjoyed RFC 2328.

Obviously, I hope this will be enough to get me through the exam.  We’ll know in less than a month, won’t we?  This would put me halfway through my goals for the year with many months to spare…months I’ll need for a lab attempt.

Send $1400 any questions my way.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

The config is quite easy and involves my favorite config item in all of Ciscodom – route-maps!  You create a route-map that sets the tag value and apply it to the redistribution.  There are a few ways to skin this cat, but I'll use an outbound distribute-list here.  Here's the config save the basics for getting EIGRP going.

route-map TAGIT permit 100
 set tag 2000
!
router eigrp 1
 redistribute static
 distribute-list route-map TAGIT out
!
ip route 172.16.0.0 255.255.255.0 Null0

If you do a show ip route on one of the other routers, you can see the tag that has been applied.  Check out the last line of the output.

R1#sh ip route 172.16.0.1
Routing entry for 172.16.0.0/24
  Known via "eigrp 1", distance 170, metric 28160
  Tag 2000, type external
  Redistributing via eigrp 1
  Last update from 192.168.0.2 on FastEthernet0/0, 00:00:09 ago
  Routing Descriptor Blocks:
  * 192.168.0.2, from 192.168.0.2, 00:00:09 ago, via FastEthernet0/0
      Route metric is 28160, traffic share count is 1
      Total delay is 100 microseconds, minimum bandwidth is 100000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
      Route tag 2000

Remember that you can only tag routes external to the AS.  That means you can't have a router tag all the internal routes (which may be a cool thing to be able to do).  You can, however, tag any route that is redistributed – including another EIGRP AS. 

Tags are also used in OSPF and BGP.  Our MPLS provider actually tags the routes they distribute to us with their BGP AS number.

Send any infinite-hop routes questions my way.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

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

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

Study Notes

• What do IPSec tunnels give you when a branch office is on a broadband connection?

Privacy through encryption
Authentication of the remote peer through ISAKMP
Delivery of private data over the public Internet

• What do you need to configure to get your branch router talking to the Internet?

ISP connection configuration such as PPPoE or PPPoA
DHCP server configuration for internal users
NAT
Firewall services like inspection and filtering

• What kind of routes would you normally see on a small branch router with a single IPSec tunnel home?

You would usually just see a default route to the ISP; IPSec will intercept interesting traffic and take care of sending the packets home without having routes for home networks configured.

• What’s a really easy way to get routes to fail from a WAN link to a GRE tunnel when the WAN link dies?

Floating static routes

• What do GRE tunnels allow you to do that native IPSec tunnels don’t?

Run a routing protocol

• Your DSL provider has given you a VPI/VCI of 1/50 to use on your branch router’s ATM 0/0 interface.  Show me the full configuration to get basic web surfing working (ignore DNS and DHCP).

interface ATM0/0
no ip address
pvc 1/50
encapsulation aal5mus ppp dialer
dialer pool-member 1
!
interface Dialer9
encapsulation ppp
ip address negotiated
dialer pool 1
ppp authentication chap callin
ppp chap password MYPASSWORD
ip nat outside
!
interface E0/0
ip add 192.168.1.1 255.255.255.0
ip nat inside
!
ip route 0.0.0.0 0.0.0.0 Dialer9

• For what would you use an ACL when configuring IPSec tunnels?

You define interesting traffic with ACLs.

• What are the two basic configuration items in a crypto map for an IPSec tunnel?

Matching ACL
IPSec peer IP

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

Study Questions

• What’s the most primitive way to get traffic destined to a single host to use a different path than your dynamic IGP dictates?

Use a static route.

• What’s the most primitive way to get traffic sourced from a single host to use a different path than your dynamic IGP dictates?

Use policy-based routing (PBR).

• What’s the most primitive way to get traffic sourced from a single host and destined for another host to use a different path than your dynamic IGP dictates?

Use PBR.

• What are the steps to configure PBR?

Configure a route-map to match the desired traffic
Apply that route-map to an interface with the ip policy route-map command

• Configure PBR to send traffic that arrives on F0/0 from 10.0.0.5 destined for for 192.168.3.3 to be sent out the s0/0 interface.

R1(config)#ip access-list extended PBR-ACL1
R1(config)#permit ip host 10.0.0.5 host 192.168.3.3
R1(config)#route-map PBR-F0/0
R1(config-route-map)#match ip address PBR-ACL1
R1(config-route-map)#set interface s0/0
R1(config-route-map)#int f0/0
R1(config-if)#ip policy route-map PBR-F0/0

• What happens if you use PBR to redirect traffic to an IP that becomes unreachable?

That clause in the route-map is ignored, and the normal routing table is used.

• What difference does using default make in the set directive of the route-map?

If you use the default parameter in the set directive, then the router will first try to use the routing table to forward traffic before using the PBR settings.  The one caveat, though, is the default chosen for the traffic cannot be the default route; a more-specific route must be in the routing table or else the PBR logic rears its head.

• What is IP SLA?

IP SLA is a feature of a Cisco IOS device where a process measures the behavior of the network.

• Why is this topic in the ROUTE book?

You can configure a track object to use IP SLAs to get a “failed” or “ok” status.  That track object can be applied to static routes and PBR so that the routing is changed if the IP SLA measures a characteristic outside of normal parameters.

• What are the steps to configure IP SLA?

Create an IP SLA operation.
Define the type and parameters for the operation.
Define the frequency to run the operation.
Schedule when to start the operation.

• How do I use IP SLA to check if a host is pingable?

You use the icmp-echo as the operation type along with, at minimum, the IP address to ping.

• How can I use IP SLA to know whether a static route is usable or not?

First, create an IP SLA operation to ping the gateway for that route.

R1(config)#ip sla 5
R1(config-ip-sla)#icmp-echo 1.1.1.1
R1(config-ip-sla)#frequency 60  [ in seconds ]
R1(config-ip-sla)#exit
R1(config)#ip sla schedule 5 start-time now life forever

Then create a track object that references the IP SLA operation you just created.

R1(config)#track 2 ip sla 5 state
R1(config-track)#delay up 90 down 90 [ up if delay is below 90, down if above 90 ]

Finally, add the track to the static route.

R1(config)#ip route 10.0.0.0 255.255.0.0 1.1.1.1 track 2

Now, if the router can’t ping 1.1.1.1, the static route will be taken out of the routing table.

• What’s an IP SLA responder?

That’s (usually) a router that has been configured to interact with the IP SLA operation of another router to get characteristics of the connection between the two.  These characteristics include jitter and TCP establishment times.

• How can I use a track object in PBR?

In the set directive, you use the track parameter.  The sequence parameter is also used, but it’s not a part of the tracking process; it’s used to have the router go down a list of next hops until it finds on that’s available.  Here’s an example.

set ip next-hop verify-availability 192.168.0.1 1 track 5

• Ummm…the book doesn’t have anything about that; what gives?

The cert guide leaves that part out for some reason even though it’s a very important part of IP SLA and PBR.  Go figure.

What Command Was That

What command…

• …shows interfaces that have PBR configured on them?

show ip policy

• …shows the routing table and includes all the PBR configuration?

There isn’t one.  You have to remember to check for PBR when traffic isn’t flowing as you think it should.

• …shows the IP SLA configuration?

show ip sla configuration [ Duh! ]

• …shows the IP SLA statistics?

show ip sla statistics [ Duh, again! ]

• …shows the track objects on a router?

show track

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

This single Czech provider announcing a single prefix caused a huge increase in the global rate of updates, peaking at 107,780 updates per-second. This peak occurred at 16:30:54 UTC, less than 8 minutes after the first announcement.

At Renesys, we call a prefix impacted in a given hour if either suffers an outage or has a non-trivial amount of instability. In the hour before this event, there were 1215 impacted prefixes globally out of a total of 271,175. During the event, that number surged to 12,920 or 4.8% of all prefixes on earth. One announcement from one provider and we have a 10-fold increase in planetary routing instability for an hour. North America suffered the most, increasing from 0.35% to 4.76%, while South America suffered the least, increasing from 0.52% to 1.75%.

It’s an interesting read and shows another example of just how vulnerable the Internet is as a whole.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

Cheat Sheets – Packetlife.net

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

• Corporate traffic had to go across the frame relay link during normal operations.
• Internet traffic had to go across the DSL line during normal operations.
• If the DSL circuit went down, Internet traffic should be moved over to the frame relay circuit to use the corporate Internet link.
• If the frame went down, traffic should be sent out the VPN tunnel for access to corporate stuff.

We set the default routes of the machines (via DHCP) to the frame relay router. That router’s default route sent traffic to the DSL router, which, of course, had a default route towards the provider. Both routers were participating in EIGRP with the rest of the corporate network, so they all knew where to route traffic destined for corporate traffic. If there was a frame outage, the default routes kicked in and sent traffic to the DSL router, which had the VPN tunnels. The problem came when there was a DSL outage.

At first, we were just monitoring the DSL IP and manually changing default routes when there was an outage, but you know DSL. We were lucky to have only 3 or 4 a day go down, so it was taking up a lot of our time just moving default routes around. We had to go to an automated solution, so we looked at doing object tracking but came up just short; it just didn’t do what we wanted. We had to go one more step and discovered reliable static routing (RSR).

In normal object tracking, you can track an interface or a route to an IP. With RSR, you can track reachability to an IP via ICMP (or a whole list of other things). This is just what we needed. We figured Yahoo was a site that would always be up, so we went about tracking one of Yahoo’s IPs from the frame routers, and, if it went down, we could send traffic back across the frame relay cloud.

To set up RSR, you have to set up an IP SLA entry, build a tracking object, then have the default route track the object. First, the IP SLA entry that we made.

ip sla monitor 1
type echo protocol ipIcmpEcho 66.94.234.13
frequency 10


This built IP SLA entry 1 to ping 66.94.234.13 every 10 seconds. With IP SLA, you also have to set a schedule for it to run. We wanted it to start ASAP and run forever, so we just did one of these.

ip sla monitor schedule 1 start-time now

This schedules entry 1 to start now, so every time the box came up, the IP SLA process started pinging away. You then combine the entry with a tracking object like this.

track 100 rtr 1 reachability

We built object 100 to monitor the reachability of SLA entry 1, so now we have an object to track if a host is unreachable. Sweet. How about the static part of the route? We set the default route of the frame router as the LAN IP of the DSL router tracking object 100. We also set a weighted default route pointing out the frame relay circuit to use when the object fails. Assume 10.0.0.0/24 for the frame cloud and 192.168.0.0/30 for the LAN.

ip route 0.0.0.0 0.0.0.0 192.168.0.1 track 100
ip route 0.0.0.0 0.0.0.0 10.0.0.254 250

In this setup, the default route is the DSL router, and, if the tracking object fails, it rolls to the frame cloud. Can you spot the flaw, though? When the route changes over, the object has recovered since it can reach Yahoo through the corporate Internet, and the default route get moved back to the DSL router…which then fails again…and rolls back…and…ack! An easy fix is to set a static route for the tracked IP to the DSL router.

ip route 66.94.234.13 255.255.255.255 192.168.0.1

This route also lets the frame monitor monitor the DSL service, so, when it comes back up, the tracking object recovers. Of couse, if someone at the site tried to get to Yahoo on that IP during a DSL outage, they would time out (shouldn’t they be working?), but, when the DSL recovered, the router would know.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

That sucks, right? One of several fixes for this is the route-reflector-client directive under the BGP neighbor configuration. A route-reflector literally reflects the routes from one client to the others just as if you’ve got a fully meshed network. Here’s a sample config for the reflector, R0.

router bgp 65000
neighbor 10.0.0.11 remote-as 65000
neighbor 10.0.0.11 route-reflector-client
neighbor 10.0.0.12 remote-as 65000
neighbor 10.0.0.12 route-reflector-client

There’s actually no additional config on R1 and R2 at all; the router reflection is transparent to them. They actually see the route just as though they got the update directly from the originating router, so any routes received from the reflector appear as though they came from the originator. In that same breath, you have to realize that R1 and R2 must have routes to each other since the untouched BGP routes will have a next-hop address as the originating router.

Edit: Here’s a crayon drawing I did to show an example of where you would use route-reflectors. R0 is connected to R1 and R2 via different WANs, but R1 and R2 aren’t connected at all.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts