IPexpert Volume 2 Section 3 Review

I knocked this one out in about 5 hours, but scored roughly between 70-80. This was my favorite IPexpert lab so far. It had:

-IPv6 with OSPFv3 and RIPng redistribution, virtual links, and 3550/3560 configuration.
-Multicast with BSR and group filtering, it was easy though :)
-A VMPS task! I thought it was a task about dot1x...no wonder I couldn't find the right commands.
-Total of IPv6, Qos and IOS Feature section was 42 points. I missed 14 points there.

Here are the misses:

-4 Task 1.2 - Switching. VMPS server configuration. I tried dot1x, and it was obviously incomplete.

-4 Task 6.2 - IOS Features. Logging configuration was way off. Needed "logging trap errors" and "service sequence-numbers." I had "logging trap critical" and different facility for each switch. The task gave you a list of things for which logs should be generated and a list of things for which logs should not be generated. I guessed it was "critical" level (2) but it was the "errors" level (3). Spent awhile on the DocCD for this one, but found no help.

-3 Task 6.4 - IOS Features. I Forget "traps snmp" at the end of the snmp-server command. I had "snmp-server host 110.99.99.99 EIGRP" but it should have been "snmp-server host 110.99.99.99 EIGRP traps snmp." I always forget this...

-3 Task 8.2 - QoS. Didn't match "ftp-data" in my priority-queue configuration. I only put ftp in the high queue. Easy points and I missed them.

-4 Task 8.3 - QoS. Didn't enable FRTS between R2 and R5 back-to-back frame link. Task asked for FRTS on R2, R4, R5 and R6. They were all connected in the cloud but R2 and R5 also had a direct frame connection to one another. I was only focused on the cloud on this one. Something to keep an eye on in the future.

-2 Task 9.1 - Security. I only blocked traffic with destination port 80, not source. Task asked to block www traffic inbound on R8 ethernet. It would have been a question for the proctor. These questions are always worded weirdly, especially since they don't say where the servers are located.

-3 Task 9.2 - Security. I Enabled rotary on port 3023 instead of port 3033. Pure bonehead.

That completes 9 8-hour proctor lab session since last Saturday. I'll probably only have one this week before I go on a little vacation. I got tickets for the MLB playoffs, game 3 Dodgers vs Cubs. Hopefully the series is tied 1-1 (or 2-0 Dodgers!). I don't want to drive 700 miles to see the Dodgers get swept!

IPexpert Volume 2 Section 2 Review

This was another seemingly simple lab, but had quite a crazy redistribution scene. There also was no IPv6 or multicast. I finished with about 3 and half hours left in the session, and that was while doing laundry as well. And redistribution took me about 2 hours alone!

Because some of my solutions differed from the PG, I gave myself a range of 77-88 depending on how well my solutions measured up. I'll explain the ones I missed without a doubt, and then explain the ones I am not sure of.

MISSED FOR SURE:

-3 task 6.2 - OSPF. Should have made priority 255 for R5 f0/1. R5 was supposed to be DR ALWAYS, I configured the priority as 110, then R6 as 100. Should have put 255, no excuses.

-3 task 7.2 - BGP. Maximum-prefix configured on wrong neighbors. Task states: "R4 does not have much memory...Make sure no other AS sends more than 20 prefixes." I thought this meant go to the edges of R4's AS and configure the max-prefix there, but they want it on R4's neighbor statements. Go figure.

-3 task 8.2 - NTP. Forgot the "ntp authenticate" on the master. Time to review my own post on this subject!

-3 task 10.3 - QoS. Policy was supposed to be policing "coming in over" the frame link on R4. I had it configured outbound.

POSSIBLE MISSES:

-4 task 9.1 - QoS. Supposed to limit VLAN12 to 2Mbps. I configured a per-port per-vlan solution and applied to the access links in vlan 12. The PG had an aggregate policer. But the policer spanned multiple ports and I did not think that was allowed. An aggregate policer was what I wanted to configure. I am waiting to hear what they say about the aggregate being allowed to span ports...

-4 task 9.2 - QoS. Limit ports in VLAN567 from sending more than 3Mbps. I really over thought this one. The PG had simple policing applied inbound to the ports in the vlan. I used a hierarchical policy applied to an SVI.

-3 task 10.2 - QoS. Configure NBAR to drop all P2P traffic on R4. I had the policy applied outbound on R4 s0/0/0, PG has inbound on f0/0.

I think I am improving in speed, but I need to cut down on easy mistakes. This is probably the best I did at doing so thus far. Only 2 real dumb mistakes, OSPF DR and NTP. The rest were pretty hard, but QoS is something that I am working on a lot now and hope to improve. I know how to configure most of the switch QoS configurations, my only difficulty is understanding what solution to use.

3560 QoS - DSCP mutation

I am completely absorbing myself in 3560 qos. I love it. I love reading about it and labbing it. So browsing through the DocCD today, I decided to lab dscp-dscp mutation. It's fairly simple, but along the way I also learned how to monitor and a way to mark traffic.

Here is the topology (it's a mutated iewb topology)

R4====SW2====SW1====SW3---[int vlan 201,202]

R4 is trunk link carrying vlan 201,202:

interface Ethernet0/0.201
encapsulation dot1Q 201
ip address 155.1.201.4 255.255.255.0
!
interface Ethernet0/0.202
encapsulation dot1Q 202
ip address 155.1.202.4 255.255.2550

SW3 has two SVIs:

interface Vlan201
ip address 155.1.201.9 255.255.255.0

interface Vlan202
ip address 155.1.202.9 255.255.255.0

Other links are all dot1q trunks passing vlan 201 and 202.

1. SET UP SW2 TO CLASSIFY AND MARK

mls qos

access-list 1 permit 155.1.201.0 0.0.0.255
access-list 2 permit 155.1.202.0 0.0.0.255

class-map match-all VLAN202
match access-group 2
class-map match-all VLAN201
match access-group 1

policy-map MARK
class VLAN201
set precedence 1
class VLAN202
set precedence 2

interface FastEthernet0/4
service-policy input MARK

2. ON SW3 TRUST AND MONITOR QOS

mls qos

int f0/13
mls qos trust dscp
mls qos monitor dscp 0 8 16 24 32

SW3# show mls qos int f0/13 st
FastEthernet0/13
Ingress
dscp: incoming no_change classified policed dropped (in pkts)
0 : 19 19 200 0 0
8 : 200 100 0 0 0
16: 200 100 0 0 0
24: 0 0 0 0 0
32: 0 0 0 0 0
Others: 0 0 0 0 0
Egress
dscp: incoming no_change classified policed dropped (in pkts)
0 : 200 n/a n/a 0 0
8 : 100 n/a n/a 0 0
16: 100 n/a n/a 0 0
24: 0 n/a n/a 0 0
32: 0 n/a n/a 0 0
Others: 283 n/a n/a 0 0

You can see that we already have traffic coming in as DSCP 8 and 16. We will be mutating these on SW1.

3. CONFIGURE DSCP-to-DSCP MUTATION ON SW1

mls qos
mls qos map dscp-mutation MAP1 8 to 24
mls qos map dscp-mutation MAP1 16 to 32
int f0/13
mls qos trust dscp
mls qos dscp-mutation MAP1

4. PING FROM R4 to SVI on SW3

R4#ping 155.1.202.9 re 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 155.1.202.9, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/4 ms
R4#ping 155.1.201.9 re 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 155.1.201.9, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/8 ms
R4#

5. VERIFY MUTATION ON SW3

SW3# show mls qos int f0/13 st
FastEthernet0/13
Ingress
dscp: incoming no_change classified policed dropped (in pkts)
0 : 194 194 200 0 0
8 : 600 500 0 0 0
16: 700 600 0 0 0
24: 100 100 0 0 0
32: 100 100 0 0 0
Others: 0 0 0 0 0
Egress
dscp: incoming no_change classified policed dropped (in pkts)
0 : 200 n/a n/a 0 0
8 : 500 n/a n/a 0 0
16: 600 n/a n/a 0 0
24: 100 n/a n/a 0 0
32: 100 n/a n/a 0 0
Others: 2674 n/a n/a 0 0

Notice that we now have 100 packets each marked DSCP 24 and 32.

IPexpert Volume 2 Section 1 Review

This lab was not real difficult but it was just the first of section 2 labs I have attempted. I still have 2:16 left in proctor labs session and here I am writing this blog. I have already graded it myself, I graded myself hard as usual. I made some pretty dumb mistakes, but mostly I was in a rush and I was too anxious or sure of myself to double check everything. I barely looked at the doccd. I scored a 77 and here are the mistakes:

Points, Task #, Excuse

-3 1.1 Didn't put domain name at end of switch hostname. This was so CDP neighbors would be seen as cat.ipexpert.com, etc. Marked it off to review, but never went back.

-1 1.3 Didn't put enable secret for VTY access. Forgot that vty access sends you to the > prompt and you need to have enable set. If I verified telnet was setup I probably would have caught it.

-3 2.2 PPP reliable link. Everything on PPP was right except this command. The wording of the task was "allow extra buffering for error recovery at layer 2." I did come across this command in the doccd but I didn't make the connection.

-3 4.1 Forgot passive-interface loopback 0 on R5,R6,R7 and R8 in OSPF. Pure bonehead.

-2 4.7 I used "compatible rfc1583" instead of "no compatible rfc1583". The task said to disable the feature in 2328 regarding setting metrics in summary routes. I figured 1583 would disable the 2328 version. I didn't read about the command at all. Just found out in the doccd and remember coming across it a couple months ago.

-2 7.2 I used "show-timezone" instead of "localtime" in the service-timestamps command. Just misunderstood the question. Read it again and now it makes sense.

-3 7.3 Did not do snmp-server trap link ietf (no clue what this is). The task said to enable the traps supported in RFC2233. oh really?

-3 11.1 No byte-count was specified in the queue-list, but the PG had one. I used a queue-limit in my CQ configuration. The wording of the question confused me but now I see what they wanted.

-3 12.1 Time-range ACL was wrong. I had:

time-range WORKHOURS
periodic weekdays 0:00 to 7:59
periodic weekdays 18:00 to 23:59
access-list 101 deny tcp any any eq www time-range WORKHOURS
access-list 101 permit ip any any

But this still allows telnet traffic on Saturday and Sunday. Plus my theory at this task was different than the PG. They had a permit statement on the time-range, denying all www traffic below that, then a permit ip any any. I used my theory on 12.2 but remembered to deny sunday, saturday, etc.

Other possible issues, these worked but didn't match PG:

3.1 Didn't add loopback to rip on R2, it was in OSPF anyway. Task didn't say to put it in RIP.

4.1 I used point-to-multipoint on NBMA, PG used neighbor statements.

4.7 Didn't put local name in "ip host" command, only the neighbor

5.3 Didn't set bandwidth before eigrp percent command, is it really needed? maybe...

11.1 I already missed the points but I had:

queue-list 1 protocol ip 2 tcp 3389
queue-list 1 protocol ip 3 tcp telnet
queue-list 1 protocol ip 3 tcp 22

PG had:

queue-list 1 protocol ip 2 list 101
queue-list 1 protocol ip 3 list 102
access-list 101 permit tcp any any eq 3389
access-list 102 permit tcp any any eq 22
access-list 102 permit tcp any any eq telnet

So anyways, that all adds up to 23 points. I don't feel too bad. I think I made progress in my time. I can do frame-relay and switching now pretty easily. I rarely have problems with OSPF over frame-relay. My redistribution skills are improving (TAG and DROP! when in doubt). I still get stumped on things like ACLs, QoS and some IP Services stuff.

Back to the lab...

IPv6: Summarizing OSPFv3 addresses

This is from IPexpert volume 1 section 22. We have to summarize the following routes:

2020:100:100:2222::/64
2020:100:100:2666::/64

This is how I do it:

1) Identify the hextet ( I don't know if this is a word, I derived it from octet) where we will summarize. This is the 4th hextet. So we know our subnet will be somewhere between /48 and /64.

2) Break it down in binary:

2222 = 0010 0010 0010 0010
2666 = 0010 0110 0110 0110

Converting hex to binary is easy because we just treat each digit in the IPv6 address as a 4 bit binary number by itself. Notice how all the 2's broke down to 0010.

3) Find the common bits. I highlighted them in red below. We have 5 of them. We will use to get our mask.

2222 = 0010 0010 0010 0010
2666 = 0010 0110 0110 0110

4) Set the rest if the bits to 0 and calculate the summary, convert to hex.

summary = 0010 0000 0000 0000 = 2000

5) Calculate subnet mask by adding the common bits to the lower of our subnet range. This means we add 5 to /48 which makes /53.

So our summary address is 2020:100:100:2000::/53

In OSPFv3 we would enter:

R2(config)#ipv6 router ospf 1
R2(config-rtr)#area 1 range 2020:100:100:2000::/53

Check our other routers for the summary:

R4#show ipv6 route | inc 53
OI 2020:100:100:2000::/53 [110/129]

IPexpert Volume 1 Section 21 - IPv6, RIPng

This is not an extremely difficult lab but it did bring up some good troubleshooting. In it we have two RIPng processes running over each other, cisco12 and cisco275 are their names.

Here is the basic topology:

R1----R2====R5----R7

R2 and R5 have two connections, one via frame-relay, and another over an ipv6ip tunnel. RIPng process cisco275 runs from R7 to R5, and R5 to R2 over frame link. RIPng process cisco12 runs over the tunnel and R1 to R2.

After redistributing between the two processes on R5, R7 still cannot ping R1 even though it has a route. Both routes below belong to R1's loopbacks.

R7#show ipv6 route rip

R 2000:1:1:1100::/64 [120/5]
via FE80::21B:D5FF:FE0F:F358, FastEthernet0/0
R 2000:1:1:1111::/64 [120/5]
via FE80::21B:D5FF:FE0F:F358, FastEthernet0/0

When we ping from R7 here is the debug on R1:

R1#debug ipv6 packet
IPv6 unicast packet debugging is on
R1#
*Sep 23 01:22:44.255: IPV6: source 2000:1:1:75::7 (FastEthernet0/0)
*Sep 23 01:22:44.255: dest 2000:1:1:1111::1
*Sep 23 01:22:44.259: traffic class 0, flow 0x0, len 100+14, prot 58, hops 62, forward to ulp
*Sep 23 01:22:44.259: IPV6: source 2000:1:1:1111::1 (local)
*Sep 23 01:22:44.259: dest 2000:1:1:75::7
*Sep 23 01:22:44.259: traffic class 0, flow 0x0, len 100+14, prot 58, hops 64, Route not found

Whats the ulp!? don't know right now...Let's check R2 since it is upstream from R1:

R2#show ipv6 route 2000:1:1:75::

R 2000:1:1:75::/64 [120/2]
via FE80::5, Serial0/1/0.1

R2 is learning the route but why isn't it sending it to R1? If we debug ipv6 rip on R2 we will see why:

*Oct 4 20:18:45.243: RIPng: response received from FE80::9664:1905 on Tunnel0 for cisco12
*Oct 4 20:18:45.243: src=FE80::9664:1905 (Tunnel0)
*Oct 4 20:18:45.243: dst=FF02::9
*Oct 4 20:18:45.243: sport=521, dport=521, length=132
*Oct 4 20:18:45.243: command=2, version=1, mbz=0, #rte=6
*Oct 4 20:18:45.243: tag=0, metric=4, prefix=FEC0:0:0:6419::/64
*Oct 4 20:18:45.243: tag=0, metric=4, prefix=2000:1:1:5500::/64
*Oct 4 20:18:45.243: tag=0, metric=4, prefix=2000:1:1:75::/64
*Oct 4 20:18:45.243: tag=0, metric=1, prefix=2000:1:1:25::/64
*Oct 4 20:18:45.243: tag=0, metric=4, prefix=2002:2:2:2::/64
*Oct 4 20:18:45.243: tag=0, metric=4, prefix=2000:1:1:7700::/64

*Oct 4 20:18:55.915: RIPng: response received from FE80::5 on Serial0/1/0.1 for cisco275
*Oct 4 20:18:55.915: src=FE80::5 (Serial0/1/0.1)
*Oct 4 20:18:55.915: dst=FF02::9
*Oct 4 20:18:55.915: sport=521, dport=521, length=192
*Oct 4 20:18:55.915: command=2, version=1, mbz=0, #rte=9
*Oct 4 20:18:55.915: tag=0, metric=1, prefix=FEC0:0:0:6419::/64
*Oct 4 20:18:55.915: tag=0, metric=1, prefix=2000:1:1:5500::/64
*Oct 4 20:18:55.915: tag=0, metric=1, prefix=2000:1:1:75::/64
*Oct 4 20:18:55.915: tag=0, metric=4, prefix=2000:1:1:25::/64
*Oct 4 20:18:55.919: tag=0, metric=2, prefix=2000:1:1:7700::/64
*Oct 4 20:18:55.919: tag=0, metric=4, prefix=2000:1:1:2222::/64
*Oct 4 20:18:55.919: tag=0, metric=4, prefix=2000:1:1:2200::/64
*Oct 4 20:18:55.919: tag=0, metric=4, prefix=2000:1:1:1100::/64

R2 is hearing two advertisements for 2000:1:1:75::/64, one is coming through the tunnel process cisco12 and the other is coming through the frame-relay cloud process cisco275.

R2 is installing the one from cisco275 because it has a lower metric and thus not advertising it to R1 because that's where process cisco12 is running.

We resolve this by redistributing between cisco12 and cisco275 on R2.

R2(config)#ipv6 router rip cisco12
R2(config-rtr)#redistribute rip cisco275 include-connected metric 3
R2(config-rtr)#ipv6 router rip cisco275
R2(config-rtr)#redistribute rip cisco12 include-connected metric 3

Now we have reachability:

R7#ping 2000:1:1:1111::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2000:1:1:1111::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/20/20 ms
R7#

RSVP - Allowed reservable bandwidth

I don't see RSVP on the R&S blueprint but there is "signaling" so maybe I will see it. Anyways I had the following task today in IPexpert's volume 1 section 18:

- Link between R2-R5 is a T1
- Allow dynamic reservations done by applications using this link
- Allow oversubscription by 200% of the link speed.
- If RTP, make sure header is only 1-2 bytes

The last part is easy, it's juts RTP header compression. However the first 3 parts caused some trouble. Here's why:

R2(config)#int s0/2/0
R2(config-if)#ip rsvp bandwidth 3088

RSVP bandwidth (which is the bandwidth for the IP
headers and data inside them, but not the required
link layer headers) exceeds 75% of interface bandwidth.
It may be that you need to enter the 'bandwidth'
command to correct the system's understanding of the
available bandwidth. If that's not the case, then:
Due to bit-stuffing, layer 2 headers and layer 1
framing, and the need for routing and keep-alive
traffic, not to mention the RSVP messages themselves,
this is just plain too high. Configure your interface
realistically for the bandwidth available.

Easy right? Just set the max-reserved-bandwidth to 100% and set the bandwidth to 3088.

R2(config)#int s0/2/0
R2(config-if)#band 3088
R2(config-if)#max-reserved-bandwidth 100
R2(config-if)#ip rsvp bandwidth 3088

RSVP bandwidth (which is the bandwidth for the IP
headers and data inside them, but not the required
link layer headers) exceeds 75% of interface bandwidth.
It may be that you need to enter the 'bandwidth'
command to correct the system's understanding of the
available bandwidth. If that's not the case, then:
Due to bit-stuffing, layer 2 headers and layer 1
framing, and the need for routing and keep-alive
traffic, not to mention the RSVP messages themselves,
this is just plain too high. Configure your interface
realistically for the bandwidth available.

Not so fast! It turns out max-reserved-bandwidth doesn't apply to RSVP. So we have to set the bandwidth a little higher...how much higher?

3088/0.75 = 4118

R2(config-if)#band 4118
R2(config-if)#ip rsvp bandwidth 3088

VRRP - SLA tracking

Today I have been doing IPexpert's volume 1 section 14 and 15 labs. Section 15 has to do with router redundancy, namely HSRP, VRRP and GLBP. I ran into a tracking issue that stumped for a short time but I thought it would be wise to document it.

The task states that R2 should be master unless its ping time to 150.100.220.7 exceeds 80ms. So I configure as follows:

track 2 rtr 1
!
ip sla monitor 1
type echo protocol ipIcmpEcho 150.100.220.7
threshold 80

int f1/0
vrrp 1 ip 150.100.12.100
vrrp 1 priority 105
vrrp 1 track 2

Immediately I see this on R2:

*Sep 20 22:18:20.107: %SYS-5-CONFIG_I: Configured from console by conso
*Sep 20 22:18:22.287: %VRRP-6-STATECHANGE: Fa1/0 Grp 1 state Master -> Backup

So I check my ping times:

R2#ping 150.100.220.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.100.220.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms

Way under 80 ms! What gives?

Turns out I never enabled the SLA!!

So I do this:

R2(config)#ip sla monitor schedule 1 start-time now
R2(config)#
*Sep 20 22:20:04.883: %VRRP-6-STATECHANGE: Fa1/0 Grp 1 state Backup -> Master
R2(config)#

I am glad this only took a few minutes to figure out but hopefully if you see this you will recognize the problem.

New Job

Well some of you may have noticed that I haven't posting a lot, or as much as I usually do, lately. Don't worry, I will get back in the swing of things soon enough =) I have been in about a month-long job hunt which looks to have finally ended today. I don't want to go into details because I like my anonymity, but I was interviewed by a group which included a couple CCIEs for a team lead position for a small team of network engineers working on Cisco gear in a NOC environment. Shortly after I pulled in my driveway after the interview I had the offer. =)

I was pretty overtaken with how impressed they were of me, because I was more impressed with their network and their skills. They have a CCIE lab!! I have been working in IT for about 5 years from the very bottom, fixing PC's and help desk to now what is a pretty sweet position for a great company. The key for me in this interview and my advice for anyone is to show some enthusiasm. Show some life. Show how much you care about the job you want. Don't be afraid to smile and let your passion show! Good things will happen!!

Even and Odd matching in ACLs

I used to think think this was a pretty difficult topic, but now it seems a lot easier once you break it down the right way. When dealing with even and odd filtering we are only concerned with 1 bit! That is the right-most bit of whatever octet the question is having you focus on. Sometimes questions can be vague so I would say it's a good idea to ask a proctor what octet you need to filter if it's ambiguous.

The rest of this blog will just be examples with short explanations. I will use the word "match" as opposed to "permit" or "deny." Once you now the correct bit pattern you can just insert it into your ACL as necessary.

1) Match the networks with an odd numbered 3rd octet.

Starting off, we don't care about the first, second or third octets so we have:

0.0.x.0 255.255.x.255

The x will be for matching odd numbered networks. All odd numbered networks have one thing in common, they have a 1 in the right-most bit. So now we have:

0.0.1.0 255.255.x.255

Now we need to make sure our wildcard mask matches all networks with a 1 in the right-most bit. In other words, we "care" to match this bit. We don't care about any other bits in this octet so we set them to 1. Now we have:

0.0.1.0 255.255.254.255

2) Match all even networks in the 3rd octect.

What do all even-numbered networks have in common? A 0 in the right-most bit. So we have:

0.0.0.0 255.255.254.255

3) Match odd numbered-networks in the second octet.

Same as example 1 except we are in the 2nd octet.

0.1.0.0 255.254.255.255

4) and so on, you should get the idea by now :)

Lock and Key

Here is the example I am following, pretty much to a T, except I am doing BGP for routing protocol and the topology is different.

Lock-and-Key: Dynamic Access Lists

Here is my topology:

[R1]----[R2]----[R3]

The goal is to prevent R1 from telnetting to R3 (172.12.23.3) unless it has authenticated to R2 first, via telnet. All configuration is on R2, but remember to configure your vty on R3.

First create a username and password on R2

R2(config)#username test password test

Next setup the router to allow access once telnet session is established:

R2(config)#line vty 0 4
R2(config-line)#autocommand access-enable
R2(config-line)#login local

Next create and apply the the ACL. Note that I am using BGP for a routing protocol and I need to allow that before anything else is configured.

R2(config)#access-list 120 permit tcp any any eq bgp
R2(config)#access-list 120 permit tcp any eq bgp any eq bgp
R2(config)#access-list 120 dynamic testlist timeout 15 permit ip any any
R2(config)#access-list 120 permit tcp any host 172.12.12.2 eq telnet
R2(config)#int s1/0
R2(config-if)#ip access-group 120 in

Let's try to telnet to R1 from R3:

R1#telnet 172.12.23.3
Trying 172.12.23.3 ...
% Destination unreachable; gateway or host down

R1#

Now let's telnet to R2 first, notice that our session gets dropped immediately:

R1#telnet 172.12.12.2
Trying 172.12.12.2 ... Open


User Access Verification

Username: test
Password:
[Connection to 172.12.12.2 closed by foreign host]
R1#

Now let's try and telnet to R3:

R1#telnet 172.12.23.3
Trying 172.12.23.3 ... Open


User Access Verification

Password:
R3>

Perfect! Some things to remember about lock and key are:

1) always allow your routing protocol at the top (lines 1 and 2 of the ACL)
2) allow telnet to the local router interface (line 4 of the above ACL)

Class-Based TCP header compression, traveling the DocCD

I was playing around with header compression today and noticed an issue (no longer an issue, I found my problem, see comments section) with class-based header compression. First, here is my topology:

R2-----ethernet-----[R3]-----serial-----[R4]

On R3 I have the following:

class-map match-all TELNET
match protocol telnet
!
policy-map OUT2R4
class TELNET
compress header ip
!
interface Serial1/1
ip address 172.12.34.3 255.255.255.0
service-policy output OUT2R4

When I telnet to R4 from R2 nothing happens, it opens up but I get no password prompt:

R2#telnet 4.4.4.4
Trying 4.4.4.4 ... Open




When I disable compression it works fine. So on R4 I tried to enable compression:

R4(config)#class-map TELNET
R4(config-cmap)#match protocol telnet
R4(config-cmap)#exit
R4(config)#policy-map INBOUND
R4(config-pmap)#class TELNET
R4(config-pmap-c)#compression header ip
R4(config)#int s1/1
R4(config-if)#service-policy input INBOUND
Header compression: Can be enabled as an output feature only
R4(config-if)#^Z

So I tried this instead:

R4(config-if)#ip tcp header-compression

But still it didn't work. So I headed to the DocCD:

First stop was 12.4 Quality of Service Configuration Guide. From there I went to Part 6: Link Efficiency Mechanisms. Next I clicked the "Header Compression" link then to "Configuring Class-Based RTP and TCP Header Compression." I already had what I thought was the correct CBWFQ configuration but nevertheless, I started here.

After shortly browsing this topic I found "Configuring TCP Header Compression" link. Here is where I found the treasure in the configuration example:

"ip tcp header-compression [passive | iphc-format | ietf-format]"

But my R4 doesn't have the iphc-format option listed:

R4(config-if)#ip tcp header-compression ?
passive Compress only for destinations which send compressed headers


But it took as a hidden option:

R4(config-if)#ip tcp header-compression iphc-format

And it worked!

R2#telnet 4.4.4.4
Trying 4.4.4.4 ... Open


User Access Verification

Password:
R4>

Not sure if all the links above will be available in the real lab, but it still was a good exercise in getting through the documentation. I started off with QoS, made my to Class-based compression and then ultimately found the command I was looking for - one that wasn't even in my context help!

The waiting, checking the ego, reviewing bonehead mistakes...

A wise man once said (Tom Petty!) that the waiting is the hardest part. Well I am determined not to make it too difficult. I finally scheduled my lab over the weekend, giving myself more than a few months more time to prepare. I feel very confident right now with what they call the "core" topics. This includes sections I, II and III of the blueprint.

My only real problem I have is making stupid mistakes. Over the last couple weeks I have been documenting them so I do not repeat them. Below are some of them.

Switching and Frame relay:

- Not trimming vlans off all the proper trunks. I did it for two trunks, but missed on another one.
- Did not disable DTP with "nonegotiate", I just used "switchport mode trunk." I have made this mistake multiple times.
- Incorrectly using MST instance 0 for a set of vlans, instead of using a new instance number
- Calculated the burst size wrong on FRTS. I know how to do this, just made a bonehead move.

Routing:

- Putting networks in wrong OSPF area (they were supposed to be "intra-area" but I read too fast and thought it said "inter-area"). I have made this mistake more than once.
- Forgot to disable auto-summary in EIGRP. Don't know if I would have been marked down. it did not affect my reachability. But I think I should remember to turn it off.
- Forgot send-community on BGP neighbor.
- Applied multicast commands to physical LAN interface when there was a subinterface. I do this with WAN interfaces occasionally too. This is a matter of paying attention where you are in the topology and what the goal of the task is. Had I used proper verification commands I would have noticed this.
-Wrong subnet mask on BGP aggregate. I needed to make it /17 instead of 16. No excuse for this at this stage of the game.

These are some common mistakes that I categorize as "bonehead" because I should never get them wrong. Yet, in every lab I do, they are there. In one case I lost 17 points because of these! I do grade myself hard because there no sense in given yourself credit for something you didn't pass yet :).

Anyways, I hope this list does not grow to big. We all learn in school that those who fail to learn from their mistakes are doomed to repeat them. So my advice is to document and learn why you made the error. The reasons are usually carelessness or reading the task too fast. Sometimes I am just so anxious to move on, I configure something and don't verify it adequately.

So, what does your list look like? :)