IPexpert Volume 3 Mock Lab 1 - Take 2

I did this lab again today mainly to see how much I improved since the first time. If your curious, here was my original post:

IPexpert Volume 3 Mock Lab 1 - Take 1

That was just over 5 months ago, and I more than doubled my score and finished in about half the time. I got a 91 this time, missing 3 tasks. The first one was a grading script error. The second one was a bonehead mistake because the task said to prevent odd routes and I blocked odd (BGP task).

The last one was tricky and I skipped it because I did not know how to complete it without messing up another task. It was 2 points vs 3 points and I took the 3-pointer. I will explain what the issue was and how to resolve it.

The first task had you allow telnet only on port 3005 of R9. Then you create a privilege 15 user named cisco with a password cisco. The next task says that the user cisco should only be allowed to do show commands and not configure anything. Menus are not allowed.

Well....since user cisco is a level 15 user he can do anything he wants. And he HAS to be a level 15 user according to the first task. The solution was to configure AAA which basically ignores privilege levels that are assigned to username commands. Now, when user cisco logs in, he is actually in level 1 and he cannot get to configuration mode (without an enable password). Do you think this violates the previous task?

Anyways, it felt good to know that I have retained a lot of info. I'm going to do another mock lab tomorrow morning from IPexpert (Before the Super Bowl of course!). Then next week I have an IE mock lab and another proctor lab session scheduled. The week after that, it will be Cisco Assessor Labs on the 14th and 15th (if my schedule gets accepted).

That leaves one more weekend of nothing which I plan on just reviewing and tying up loose ends. Probably play around on the home lab most of the time. Then the next weekend I will be in San Jose :-)

RSPAN between 3550 and 3560 - Multiple Sources

Topology is as follows:

R5----SW1----SW2----SW4----R4/R6

R4 and R6 are on VLAN 300, 192.168.250.0/24 subnet
R5 is on VLAN 100, connected to port f0/5 of SW1
Inter-switch links are dot1q trunks
I will set up RSPAN between the switches and use debug ip packet with an ACL to verify.

3550 is the source:

SW4(config)#vlan 999
SW4(config-vlan)#remote-span
SW4(config)#monitor session 1 source vlan 300 rx
SW4(config)#monitor session 1 destination remote vlan 999 reflector-port f0/12

3560 is connected to the monitor:

SW1(config)#monitor session 1 source remote vlan 999
SW1(config)#monitor session 1 destination interface f0/12

On R5 We can verify like this:

R5(config)#access-list 1 permit 192.168.250.4 0.0.0.0
R5(config)#access-list 1 permit 192.168.250.6 0.0.0.0
R5(config)#no service timestamps debug
R5#debug ip packet 1 detail
IP packet debugging is on (detailed) for access list 1
IP: s=192.168.250.4 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89
IP: s=192.168.250.6 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89
IP: s=192.168.250.4 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89
IP: s=192.168.250.6 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89

Here we can see EIGRP packets from VLAN 300, which verifies our monitoring is working. The only place I specified "remote-span" under a VLAN was the source 3550. However, I have read that that this required on all switches that carry the remote-span VLAN.

Let's add a source on SW2, where R2 is plugged into f0/2. We will put it on a different VLAN just to prove it is working:

SW2(config)#int f0/2
SW2(config-if)#sw a v 150
SW2(config)#vlan 999
SW2(config-vlan)#remote-span
SW2(config)#monitor session 1 source interface f0/2
SW2(config)#monitor session 1 destination remot vlan 999

If we jump to R5, we won't see any packets from R2...hmm...oh yeah, the ACL!

R5(config)#access-list 1 permit 192.168.0.2 0.0.0.0

There we go:

IP: s=192.168.0.2 (Ethernet0/0), d=224.0.0.2, len 48, rcvd 0
UDP src=1985, dst=1985
IP: s=192.168.0.2 (Ethernet0/0), d=224.0.0.5, len 88, rcvd 0, proto=89
IP: s=192.168.250.4 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89
IP: s=192.168.0.2 (Ethernet0/0), d=224.0.0.2, len 48, rcvd 0
UDP src=1985, dst=1985
IP: s=192.168.250.6 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89

Looks like we got HSRP packets from R2 and OSPF packets from R4 and R6.

Key things to remember:

-Reflector port needed on 3550
-remote-span command used under the RSPAN VLAN. In this example, I only did it on the source, but I would verify that you need it on all devices with this VLAN.
-To allow destination port to connect back to the network use "ingress" keyword on session destination command

EIGRP Bounded updates

I was reading about EIGRP in Routing TCP/IP Volume 1 by Jeff Doyle and focusing on the comparisons between it and distance vector and link-state protocols. One characteristic of EIGRP that sets it part from other protocols is that updates are "bounded" meaning that they are only sent to the "affected" neighbors. I was trying to find a way to see this behavior in action so I created this summarization scenario.

R4 is in the middle of the star with R3,R5 and R7 at the edges:

R4-R5 = 192.168.45.0/24
R4-R7 = 192.168.47.0/24
R4-R3 = 192.168.34.0/24

R4 is advertising a summary of 192.168.44.0/22 to R3.
If a new link was brought up in the /22 range, R4 will not send an update to R3.

Here it is in action:

R3#debug eigrp packets update
R4#debug eigrp packets update
R5#debug eigrp packets update

R3#sho ip route eigrp
D 192.168.44.0/22 [90/2681856] via 192.168.34.4, 00:02:54, Serial1/1

R7 is off of R4 serial 1/1, R3 is off of R4 serial 1/0:

R4#sho ip eigrp ne
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 192.168.47.7 Se1/1 10 00:11:55 75 450 0 8
2 192.168.34.3 Se1/0 13 00:30:39 106 636 0 8
0 192.168.45.5 Se1/2 12 00:32:16 106 636 0 8
R4#

Let's add a new loopback on R5 in the range of the summary:

R5(config)#int lo 1
R5(config-if)#ip address 192.168.46.5 255.255.255.0
R5(config-if)#router eigrp 1
R5(config-router)#network 192.168.46.5 0.0.0.0

*Mar 1 20:02:59.075: EIGRP: Enqueueing UPDATE on Serial1/0 iidbQ un/rely 0/1 serno 8-8
*Mar 1 20:02:59.079: EIGRP: Enqueueing UPDATE on Serial1/0 nbr 192.168.45.4 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 8-8
*Mar 1 20:02:59.087: EIGRP: Sending UPDATE on Serial1/0 nbr 192.168.45.4
*Mar 1 20:02:59.095: AS 1, Flags 0x0, Seq 8/20 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 8-8
*Mar 1 20:02:59.235: EIGRP: Received UPDATE on Serial1/0 nbr 192.168.45.4
*Mar 1 20:02:59.235: AS 1, Flags 0x0, Seq 26/8 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

R5 sends an update to R4. R4 only sends it to R7:

*Mar 1 20:02:59.515: EIGRP: Received UPDATE on Serial1/2 nbr 192.168.45.5
*Mar 1 20:02:59.519: AS 1, Flags 0x0, Seq 8/20 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Mar 1 20:02:59.563: EIGRP: Enqueueing UPDATE on Serial1/1 iidbQ un/rely 0/1 serno 11-11
*Mar 1 20:02:59.567: EIGRP: Enqueueing UPDATE on Serial1/1 nbr 192.168.47.7 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 11-11
*Mar 1 20:02:59.575: EIGRP: Sending UPDATE on Serial1/1 nbr 192.168.47.7
*Mar 1 20:02:59.579: AS 1, Flags 0x0, Seq 24/8 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 11-11
*Mar 1 20:02:59.583: EIGRP: Enqueueing UPDATE on Serial1/0 iidbQ un/rely 0/1 serno 11-11
*Mar 1 20:02:59.587: EIGRP: Enqueueing UPDATE on Serial1/0 nbr 192.168.34.3 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 11-11
*Mar 1 20:02:59.587: EIGRP: Enqueueing UPDATE on Serial1/2 iidbQ un/rely 0/1 serno 11-11
*Mar 1 20:02:59.591: EIGRP: Enqueueing UPDATE on Serial1/2 nbr 192.168.45.5 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 11-11
*Mar 1 20:02:59.591: EIGRP: Sending UPDATE on Serial1/2 nbr 192.168.45.5
*Mar 1 20:02:59.591: AS 1, Flags 0x0, Seq 26/8 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 11-11

And of course on R3 we see nothing. What's really interesting is we see R4 "Enqueuing" the update but never actually sending it as it does to R5 and R7.

I am still not sure of one thing though. Is this a fundamental characteristic of EIGRP itself or the fact that we are summarizing? I cannot think of another scenario where this "bounded" update scenario would take place without summarization. If you can, please drop a comment.

OSPFv3 Neighbors do not need to be on same subnet

Check it out:

R2 F0/0 <-----> F0/0 R3

Here is R2's config:

R2#sho run int f0/0
Building configuration...

Current configuration : 153 bytes
!
interface FastEthernet0/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:2::2/64
 ipv6 address FE80::2 link-local
 ipv6 ospf 1 area 0
end

Here is R3's config:

R3#sho run int f0/0
Building configuration...

Current configuration : 153 bytes
!
interface FastEthernet0/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:3::3/64
 ipv6 address FE80::3 link-local
 ipv6 ospf 1 area 0
end

R2's show commands:

R2#sho ipv6 ospf ne   

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
3.3.3.3           1   FULL/DR         00:00:35    4               FastEthernet0/0

R2#sho ipv6 route  
IPv6 Routing Table - 5 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       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
C   2001:2::/64 [0/0]
     via ::, FastEthernet0/0
L   2001:2::2/128 [0/0]
     via ::, FastEthernet0/0
O   2001:3::/64 [110/10]
     via ::, FastEthernet0/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0

R2 can now ping 2001:3::3

R2#ping 2001:3::3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:3::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/56 ms
R2#

This is possible because neighbors are known by their router-ids and link-local addresses are used as next hops, not the actual interface addresses.

Dynamic ARP Inspection with NON-DHCP hosts

The Dynamic ARP Inspection concept is well understood, but sometimes the commands and requirements can be hard to remember. This scenario shows how DAI works with DHCP snooping to block ARP requests from untrusted ports and how NON-DHCP clients can still be apart of the network.

R1,R3 and R5 are all on VLAN100, connected to switch SW1:

R1 = Static host
R3 = DHCP Server
R5 = DHCP client

SW1 has ARP Inspection and DHCP snooping enabled already, with trust enabled on the port connected to R3.

SW1#sho run | inc snoop|arp
ip dhcp snooping vlan 100
ip dhcp snooping
ip arp inspection vlan 100
 ip dhcp snooping trust

R5 gets an IP address from R3 and now we have the following entry on SW1:

SW1#sho ip dhcp snooping binding 
MacAddress         IpAddress   Lease(sec) Type           VLAN  Interface
------------------ ----------- ---------- -------------  ----  ---------------
00:00:00:00:00:05  192.168.0.5 86381      dhcp-snooping  100   FastEthernet0/5
Total number of bindings: 1

R5 tries to ping R1 but can't:

R5#ping 192.168.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:

*Jan  7 09:36:20.361: IP: tableid=0, s=192.168.0.5 (local), d=192.168.0.1
            (Ethernet0/0), routed via RIB
*Jan  7 09:36:20.361: IP: s=192.168.0.5 (local), d=192.168.0.1 (Ethernet0/0),
             len 100, sending
*Jan  7 09:36:20.361:     ICMP type=8, code=0
*Jan  7 09:36:20.361: IP ARP: creating incomplete entry for IP address:
             192.168.0.1 interface Ethernet0/0
*Jan  7 09:36:20.361: IP ARP: sent req src 192.168.0.5 0000.0000.0005,
                 dst 192.168.0.1 0000.0000.0000 Ethernet0/0

On SW1 we see this:

SW1#debug arp 
07:43:49: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/1, vlan 100.
([0000.0000.0001/192.168.0.1/0000.0000.0005/192.168.0.5/07:43:49 UTC Mon Mar 1 1993])

SW1 is not allowing the ARP reply from R1 because the port is untrusted in the arp inspection configuration and R1's address is not in the DHCP snooping database. We can see the request make it on R1:

R1#
*Mar  2 00:31:09.685: IP ARP: rcvd req src 192.168.0.5 0000.0000.0005,
             dst 192.168.0.1 Ethernet0/0
*Mar  2 00:31:09.685: IP ARP: sent rep src 192.168.0.1 0000.0000.0001,
                 dst 192.168.0.5 0000.0000.0005 Ethernet0/0

But R5 never gets the reply. For NON-DHCP hosts we can create an ARP ACL and apply it to the DAI configuration:

SW1(config)#arp access-list ARP-TEST  
SW1(config-arp-nacl)#permit ip host 192.168.0.1 ?
  mac  Sender MAC address
SW1(config-arp-nacl)#permit ip host 192.168.0.1 mac ?
  H.H.H  Sender MAC address
  any    Any MAC address
  host   Single Sender host
SW1(config-arp-nacl)#permit ip host 192.168.0.1 mac host 0000.0000.0001
SW1(config-arp-nacl)#exit
SW1(config)#ip arp inspection filter ARP-TEST vlan 100 

Now let's ping:

R5#ping 192.168.0.1

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

There is another option for the DAI filter and that is "static".

SW1(config)#ip arp inspection filter ARP-TEST vlan 100  ?
  static  Apply the ACL statically
  

If we applied this argument to the command, DAI would only check the ARP ACL and not fallback to the DHCP snooping database. That would prevent R5 ARPs from being allowed:

SW1(config)#ip arp inspection filter ARP-TEST vlan 100  static 

R5#ping 192.168.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R5#

Check debugs on SW1:

SW1#
07:52:53: %SW_DAI-4-ACL_DENY: 1 Invalid ARPs (Req) on Fa0/5, vlan 100.
([0000.0000.0005/192.168.0.5/0000.0000.0000/192.168.0.1/07:52:53 UTC Mon Mar 1 1993])

Requests are being denied inbound on f0/5 now.

RSH/RCP - quick and easy

This is one of those topics that probably won't be in the exam, but it can't hurt to learn it if its easy enough.

On R3, I have:

R3#sho run | inc rcmd
ip rcmd remote-username R3
ip rcmd source-interface Loopback0

On R5, I have:

R5#sho run | inc rcmd
ip rcmd rsh-enable
ip rcmd remote-host cisco 172.16.0.3 R3 enable
ip rcmd source-interface Loopback0

On R3:

R3#rsh 172.16.0.5 /user cisco sho run int lo0

Building configuration...

Current configuration : 63 bytes
!
interface Loopback0
ip address 172.16.0.5 255.255.255.255
end

R3#

Now Let's do some RCP file copying:

R5(config)#ip rcmd rcp-enable
R5(config)#^Z
R5#copy run r5test.txt
Destination filename [r5test.txt]?
Erase flash: before copying? [confirm]n
Verifying checksum... OK (0xFD5B)
2714 bytes copied in 4.856 secs (559 bytes/sec)
Rack1R5#

Copy from R3:

R3#copy rcp://cisco@172.16.0.5/R5test.txt flash:
Destination filename [R5test.txt]?
Accessing rcp://cisco@172.16.0.5/R5test.txt...
Erase flash: before copying? [confirm]n!
Verifying checksum... OK (0xFD5B)
2714 bytes copied in 0.644 secs (4214 bytes/sec)
R3#

Key things to remember:

-Server side has two names in that rcmd command
-First one must match /user on client
-Second one must match client hostname or client "remote-username" command

IPexpert Volume 3 Mock Lab 9 Review

This lab was actually pretty fun, though I made a lot of mistakes. I was short on time so I did not have any time to verify. I had a previous conflict in schedule so I had to take an hour+ off in the middle of the lab. There was a little bit of everything here from IPv6 redistribution, routing loops (if your not careful), mls qos, hierarchical MQC, and some interesting multicast stuff.

Here's a summary of what I missed:

IGP

Forgot to add "no-summary" to an NSSA ABR. The task said "no intra-area" routes, and I guess I saw "no inter-area" instead.

I needed to traffic engineer OSPF to influence path selection in two directions, and I only did one way. I was going to come back after all the redistribution tasks, and I did not have time.

R1 was to only accept RIP routes from BB1. Without using authentication, the way to do this would be to make RIP AD 255, then use another neighbor-specific distance command for BB1. I missed this.

BGP

I had to prevent BB1/BB2 routes from being exchange to each other. Usually you would use an as-path filter, but the task did not allow this. I used community no-export, which I knew was over-filtering but for some reason I still used it. I should have just used community values like a tag, and then drop them on the way to each BBR.

I also had to find out what timers BB1 was using without looking at the config. I thought if I debugged keepalives I could tell. This does not work if your router has lower configured timer values. The peers use the lower value. The answer was to make your timers really high and then see what is negotiated. This is something I have read before but for some reason it didn't stick. I shall never forget again.

Multicast

I missed all 3 multicast tasks which was surprising because I am usually strong in this area. We need to make R6 an RP for the GLOP address ending with a 1. I used 233.0.0.1 but the middle octets are supposed to be the AS number (5051). Also, my multicast rate limiting statement wasn't specific enough because I didn't use a source list. And then I forget "filter-autorp" at the end of my multicast boundary statement. There was a lot more than this to configure but these items cost me the points.

Services

On DHCP, I forgot to disable dhcp conflict logging which I need to start remembering to do. I never disable it and I never have any problems, but the PG always has it disabled.

Security

Finally I missed a VTY security task to limit "telnet" access to only certain hosts. I made the ACL but forgot the transport input telnet.

One more volume 3 lab to go, which I start in a few hours. Next weekend I plan on doing Lab 1 again. This is the one I bombed on back in July when I was a wee little CCIE wannabe. It's been long enough for me to forget the details of that lab, so I want to see how much I have improved.

Renumbering IPv6 with ease via ipv6 general-prefix

This is rather neat IPv6 feature that eases renumbering. We define a general prefix globally and then assign interface addresses based on that interface. Should you change providers or ever have to renumber the network, all you have to do is change the general prefix. Here's how it works:

R5(config)#ipv6 general-prefix TEST 2001:5::/48           
R5(config)#
R5(config)#int s1/0
R5(config-if)#ipv6 address TEST 2001:5::/48 eui-64 

R5#sho ipv6 interface s1/0 | inc :
  IPv6 is enabled, link-local address is FE80::E1B8:5FF:FE4C:9CDD 
  Global unicast address(es):
    2001:5::, subnet is 2001:5::/48 [GEN]
    2001:5::E1B8:5FF:FE4C:9CDD, subnet is 2001:5::/48 [EUI]
  Joined group address(es):
    FF02::1
    FF02::2
    FF02::1:FF00:0
    FF02::1:FF4C:9CDD
  ND DAD is enabled, number of DAD attempts: 1
R5#

We now have an IPv6 address assigned based on the EUI-64 method. The address is 2001:5::E1B8:5FF:FE4C:9CDD. Now suppose we need to change our prefix to 2001:6.

R5(config)#no ipv6 general-prefix TEST 2001:5::/48        
R5(config)#ipv6 general-prefix TEST 2001:6::/48   
R5(config)#
R5(config)#^Z
R5#sho ipv6 interface s1/0 | inc :
  IPv6 is enabled, link-local address is FE80::E1B8:5FF:FE4C:9CDD 
  Global unicast address(es):
    2001:6::, subnet is 2001:6::/48 [GEN]
    2001:6::E1B8:5FF:FE4C:9CDD, subnet is 2001:6::/48 [EUI]
  Joined group address(es):
    FF02::1
    FF02::2
    FF02::1:FF00:0
    FF02::1:FF4C:9CDD
  ND DAD is enabled, number of DAD attempts: 1
R5#

Image if we had more interfaces, this would make things so much easier. Especially considering each interface would have its own subnet. Imagine if we had interfaces on the 2001:5:0:1, 2001:5:0:2 (and so on) networks. We could change all of these to /48 prefix 2001:6:0:x:/64 with a couple commands. When you do change the general prefix, it does not overwrite the already configured one. This way you can have two prefixes during transition and eventually remove the older one as we did above.

CBAC with APPFW

I have begun my goal of reading the entire 12.4 Security Configuration Guide. I likely won't read it all because many things are probably unrelated to CCIE R&S, but you never really can tell. Especially since the blueprint has "Other Security Features" on it. This configuration is part of CBAC and so I thought I would test a small scenario.

R4----s1/0 R5----R6

R4 is the http server and R6 is the client. Here is how I set them up to verify it's working:

R4#copy run test.html
Destination filename [test.html]?
Erase flash: before copying? [confirm]
Erasing the flash filesystem will remove all files! Continue? [confirm]
Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...erased
Erase of flash: complete
Verifying checksum... OK (0x7071)
1942 bytes copied in 4.628 secs (420 bytes/sec)
R4#
R4#dir
Directory of flash:/

1 -rw- 1942 test.html

7864316 bytes total (7862308 bytes free)
R4#conf t
R4(config)#ip http path flash:

R4 is setup, let's test R6 the client:

R6#copy http://192.168.45.4/test.html flash:
Destination filename [test.html]?
Erase flash: before copying? [confirm]
Erasing the flash filesystem will remove all files! Continue? [confirm]
Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...erased
Erase of flash: complete
Loading http://192.168.45.4/test.html !
Verifying checksum... OK (0x7071)
1942 bytes copied in 0.688 secs (2823 bytes/sec)
R6#

Good, so we know that works. Now we can configure R5 as the HTTP Application FW. This does require CBAC as well as some new appfw commands which I have never used. There are MANY more options besides this, so I suggest you read the DocCD for a more in depth explanation. I just wanted to get the gist of it here:

ip inspect name APPFW appfw HTTPFW
ip inspect name APPFW http
!
appfw policy-name HTTPFW
application http
strict-http action allow alarm
content-length minimum 1945 action reset alarm
port-misuse tunneling action reset

interface Serial1/0
description TO R4
ip inspect APPFW out

Notice the minimum content length is 1945 byes. This will prevent R6 from copying the file via HTTP (test.html is 1942 bytes as we can see above):

6#copy http://192.168.45.4/test.html flash:
Destination filename [test.html]?
Erase flash: before copying? [confirm]n
%Error opening http://192.168.45.4/test.html (I/O error)
R6#

Jump to R5 and see the message:

R5#
*Mar 2 05:34:02.708: %APPFW-4-HTTP_CONT_TYPE_SIZE: Sig:11 Content size 1942 out of range - Reset - Content size out-of-bounds from 192.168.56.6:25101 to 192.168.45.4:80

If we change the minimum content legth to 1942, everything works as expected:

R5(config)#appfw policy-name HTTPFW
R5(cfg-appfw-policy)#application http
R5(cfg-appfw-policy-http)#content-length minimum 1942 action reset alarm

R6#copy http://192.168.45.4/test.html flash:
Destination filename [test.html]?
%Warning:There is a file already existing with this name
Do you want to over write? [confirm]y
Erase flash: before copying? [confirm]n
Loading http://192.168.45.4/test.html !
Verifying checksum... OK (0x7071)
1942 bytes copied in 0.396 secs (4904 bytes/sec)
R6#

AS_SET not used in AS Path length comparison

I was reading Chapter 3 today of Routing TCP/IP Volume 2 and it says that AS_SET is not considered when determining shortest AS_PATH. So I decided to lab it and see for myself. R4 is learning the 192.168.0.0/16 aggregate from R5 and R7 each with differing AS_SET lengths.

R4#sho ip bgp | be Net
   Network          Next Hop     Metric LocPrf Weight Path
*  192.168.0.0/16   192.168.47.7      0             0 7 {8,900} i
*>                  192.168.45.5      0             0 5 {6,600,6000,3033} i

The longest one is winning! AS_SET does count as 1 AS by the way.

R4#sho ip bgp 192.168.0.0
BGP routing table entry for 192.168.0.0/16, version 4
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
     1         
  7 {8,900}, (aggregated by 7 192.168.78.7)
    192.168.47.7 from 192.168.47.7 (192.168.78.7)
      Origin IGP, metric 0, localpref 100, valid, external
  5 {6,600,6000,3033}, (aggregated by 5 192.168.56.5)
    192.168.45.5 from 192.168.45.5 (192.168.56.5)
      Origin IGP, metric 0, localpref 100, valid, external, best
R4#

All other things being equal it looks like the most recent path is winning. If we clear BGP on R5, R7 would be the most recent:

R5#clear ip bgp *
R5#
R5#
*Mar  1 01:34:11.475: %BGP-5-ADJCHANGE: neighbor 192.168.45.4 Down User reset
*Mar  1 01:34:11.479: %BGP-5-ADJCHANGE: neighbor 192.168.56.6 Down User reset
*Mar  1 01:34:11.667: %BGP-5-ADJCHANGE: neighbor 192.168.56.6 Up 
*Mar  1 01:34:12.287: %BGP-5-ADJCHANGE: neighbor 192.168.45.4 Up 

R4#sho ip bgp | be Net   
   Network          Next Hop     Metric LocPrf Weight Path
*  192.168.0.0/16   192.168.45.5      0             0 5 {6,600,6000,3033} i
*>                  192.168.47.7      0             0 7 {8,900} i
R4#

For more details, you can read this document which I am sure we have all seen by now. But little things like this may be forgotten:

BGP PATH SELECTION

IPexpert Volume 3 Mock Lab 8 Review

At first read through, this lab appears very difficult because the number of routing protocol domains. 2 EIGRP domains, 3 OSPF domains, 1 RIP domain and almost every router and switch running 2 or 3 protocols. I attacked this by creating ACLs matching every set of networks, example:

ip access-list standard EIGRP134
ip access-list standard EIGRP24
ip access-list standard OSPF1
ip access-list standard OSPF2
ip access-list standard OSPF3
ip access-list standard RIP

Each ACL contained the networks in that domain. I then altered distance on each border router as needed so I could force the router to learn a route from that direction. In OSPF you can only specify one distance command so I had to merge the RIP and EIGRP ACL's in one case. The goal was to prevent route-feedback by ensuring that routes were learned through the best protocol to begin with. It took me about an hour but it worked great.

Another task had me configure clustering which is not as hard as it seems. A few commands on the commander and I was done. I had to read through the DocCD to figure some stuff out.

Side note: If you need to ping your own interface on a frame-relay task but are not allowed to use "frame-relay map", you can use Multilink interface and run MLPPPoFR.

BGP Section was pretty convoluted and I did not complete it. The main section revolved around using prepends so that distant ASes would disallow certain networks. I thought I could do this, but I did a bad job of reading ahead so I did not have the required confederations for this task. I did not fell like going back and re-doing BGP.

Another new command: "no service disable-ip-fast-frag"

IPv6 was pretty easy, I used tunnels to get everywhere.

QOS: Misunderstood the Flow Based WRED task, instead configured WRED + WFQ in a policy-map. I also configured the Be wrong and forgot adaptive shaping in a FRTS task.

Last task said to keep traffic stats for a host that might be under a DoS attack. I used accounting, but the PG has ip source-track. I should have got this, as I was just reviewing this topic in the DocCD last week.

I am not doing as good as I want to be doing. The last few labs in Volume 3 have been tougher, but there's nothing that I should not be able to get or find in the DocCD at this point. It's just a matter of staying focused and keeping the skills sharp.

IPexpert Volume 3 Mock Lab 7 Review

This is a very challenging lab. I missed quite a few things, and there was a LOT of troubleshooting involved when things wouldn't work.

To begin with, all switches have dot1q trunk links to each other. However SW2 and SW3 are using flex-links. At first nothing seems wrong, then all of a sudden in the IGP section, SW1 becomes unbearably slow and R4 and R7 keep dropping EIGRP adjacencies. I noticed the RIP and IP INPUT processes on R1 were eating up the CPU. RIP and EIGRP packets were being looped over and over and over because STP does not run over Flex links! I shut the links down and attacked it later.

Another task asked to configure MLPPP over Frame Relay without using a multilink group. I created a multilink interface, but the answer was to use ppp multilink on a virtual-template and forget about the multilink interface.

BGP, Multicast, IP Services and IPv6 were pretty easy. I was glad because I had already spent 4+ hours getting through IGP. I did miss the HSRP task because they wanted the highest group possible. I used 255 but you were supposed to switch to version 2 and use group 4096!

Missed some delicate stuff regarding QoS. Byte counts were easy enough configure but the task said you should assume packet sizes of 100. This means you needed to adjust queue-limits also, which I did not do.

Another tricky one was a CQ to MQC conversion task. They displayed the CQ conversion as using a TCP syslog port. If you use NBAR to match syslog, it only uses UDP buy default. So you had to create a custom port-map. Tough one to see right away.

There was a login task that asked me to enable SSH for VTY lines. I forgot to create the key so it never would have worked. I should have verified this by attempting to login via SSH.

Finally, when I went back to the flex-link tasks I just used "switchport trunk allowed vlan none" to get it to work. The PG pruned even VLANs off from SW3 to SW2, then pruned the odd ones from SW2 to SW4. Then they shut the link from SW1 to SW2. Anyways, there were probably a number of ways to do it. It didn't really matter as long as you have connectivity.

Next up: Lab 8 tomorrow.

IPexpert Volume 3 Mock Lab 6 Review

This lab took me about 7 hours to complete, verify and grade. There a few things I did not think I would get, but I ended up with solutions for everything and pretty much all of them worked. There was a task for something I had never heard of, SSG, which I got by looking in the DocCD and browsing the context sensitive help. The question mark is your friend!

Also another tricky one was R5 had a new loopback that needed to be NATTED based on the outgoing interface. I spent a good chunk of time on this but once I figured it out, it was pretty basic. I just had to match interfaces and addresses in a route-map, and use the route-map on a few NAT statements.

Here's part of it:

access-list 55 permit 55.55.55.55
route-map VLAN15 permit 10
match ip address 55
match interface FastEthernet0/0
ip nat inside source route-map VLAN15 interface FastEthernet0/0 overload

Here's what I missed:

-7 Task 1.1, 1.2 Switching

Didn't create vlan 400 on CAT1 or CAT2 and didn't make CAT4 root for that vlan. Vlan 400 did not have any hosts but was used as a native vlan. The task said to make CAT4 root for any vlans you have to create on that switch. CAT4 had no hosts, but nevertheless we had to create the vlan and make it root. This task involved a lot of stuff so to lose points for a couple unnecessary things is a bummer.

-3 Task 5.1 Multicast

IGMP Filter task said to deny 227.0.0.43 - 227.0.0.99 but only use a permit statement. Silly me included 227.0.0.1-42 and 100-255. I completely forgot this was denying all the 224/8, 225/8, etc groups.

-3 Task 8.1 QOS

I don't know if I would have got this wrong but I kind of misunderstood it. R9 has a Fastethernet connection while BB3 has an Ethernet. The task said to base your MQC percentages of off BB3's link speed. Well, I used "bandwidth 10000" under R9's interface so all the percentages worked out. The SG modified the percentages themselves. For example, the task said to give SMTP 25%, so the SG gave it bandwidth 2500 as opposed to 25000.

Other differences:

Task 3.3 - SG had an extra OSPF VL between R2 and R6 in area 246. Not really needed but probably a good idea.

Task 4.4 - SG used cost-community to influence path selection, I used "set origin" in a route-map. So much easier!

Well that's it for tonight. Lab 7 tomorrow and lab 8 on Monday. I am almost done with all the IPexpert material. I have watched and/or listened to all the bootcamp stuff at least once or twice as well. I bought an IE mock lab for next month, and I am planning on doing the Cisco Assessor labs as well.

SNAT: Making it work?

This is a poorly documented feature and I really just played around with it until I got it to work. If you see anything missing or unnecessary, please comment. The one thing I worry about is I am using secondary addresses which may or may not be allowed in the lab. If you know another way, PLEASE let me know. Other than that, it was all kind of patchwork but it does the job :-)

Here is the topology:


R6 will be our test host who will telnet to R4 at 4.4.4.4. If all goes well, after we shut the link from R1 to R2 (whos is HSRP Active), R6 session will stay up. We will then look at the NAT translation table on R2 and R3.

Here is the configuration for R2:

interface FastEthernet0/0
ip address 10.0.0.2 255.255.255.0
ip nat inside
standby 1 ip 10.0.0.1
standby 1 priority 105
standby 1 preempt
standby 1 name SNAT
standby 1 track Serial1/0

interface Serial1/0
ip address 172.12.23.202 255.255.255.0 secondary
ip address 172.12.12.2 255.255.255.0
ip nat outside

ip nat Stateful id 1
redundancy SNAT
mapping-id 10

ip nat pool POOL 172.12.23.1 172.12.23.254 prefix-length 24
ip nat inside source list LAN pool POOL mapping-id 10 overload

R3 is pretty much the same except for the IP addresses:

interface FastEthernet0/0
ip address 10.0.0.3 255.255.255.0
ip nat inside
standby 1 ip 10.0.0.1
standby 1 preempt
standby 1 name SNAT
standby 1 track Serial1/0

interface Serial1/0
ip address 172.12.23.203 255.255.255.0 secondary
ip address 172.12.13.3 255.255.255.0
ip nat outside

ip nat Stateful id 1
redundancy SNAT
mapping-id 10

ip nat pool POOL 172.12.23.1 172.12.23.254 prefix-length 24
ip nat inside source list LAN pool POOL mapping-id 10 overload

I had to put secondary addresses on the serial links. These routers need to share an address space so they can use the same address to translate and so R1 and R4 no how to reach the translated address range. This secondary address range is being advertised in ospf:

R1#sho ip route 172.12.23.0
Routing entry for 172.12.23.0/24
Known via "ospf 1", distance 110, metric 128, type intra area
Last update from 172.12.12.2 on Serial1/0, 00:07:58 ago
Routing Descriptor Blocks:
* 172.12.13.3, from 172.12.35.3, 00:07:58 ago, via Serial1/1
Route metric is 128, traffic share count is 1
172.12.12.2, from 2.2.2.2, 00:07:58 ago, via Serial1/0
Route metric is 128, traffic share count is 1

Also note that the HSRP group name "SNAT" is referenced in the stateful NAT configuration. The mapping ID is then referenced in the NAT statement itself.

Let's telnet from R6 to R4, we will first verify that we route through R2:

R6#telnet R4
Translating "R4"
% Unknown command or computer name, or unable to find computer address
R6#telnet 4.4.4.4
Trying 4.4.4.4 ... Open

R4#
R4#!here we are!

Shut the interface on R1 to R2:

R1(config)#int s1/0
R1(config-if)#shut

Check back on R4. This may take awhile because HSRP still has to failover:

R4#
R4#
R4#!Hey we're still alive!
R4#
R4#exit

[Connection to 4.4.4.4 closed by foreign host]
R6#trace 4.4.4.4

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1 10.0.0.3 56 msec 48 msec 60 msec
2 172.12.13.1 132 msec 68 msec 104 msec
3 172.12.14.4 148 msec * 184 msec

We are going through R3! If we did not have SNAT, our session would have dropped when R4 noticed that our address has changed.

Let's look at our address translations:

R2#sho ip nat translations
Pro Inside global Inside local Outside local Outside global
udp 172.12.23.5:37518 10.0.0.6:37518 4.4.4.4:33441 4.4.4.4:33441
udp 172.12.23.5:39661 10.0.0.6:39661 4.4.4.4:33442 4.4.4.4:33442
udp 172.12.23.5:42398 10.0.0.6:42398 4.4.4.4:33437 4.4.4.4:33437
udp 172.12.23.5:36656 10.0.0.6:36656 4.4.4.4:33439 4.4.4.4:33439
udp 172.12.23.5:39090 10.0.0.6:39090 4.4.4.4:33438 4.4.4.4:33438
udp 172.12.23.5:35099 10.0.0.6:35099 4.4.4.4:33440 4.4.4.4:33440

R3#sho ip nat translations
Pro Inside global Inside local Outside local Outside global
udp 172.12.23.5:37518 10.0.0.6:37518 4.4.4.4:33441 4.4.4.4:33441
udp 172.12.23.5:39661 10.0.0.6:39661 4.4.4.4:33442 4.4.4.4:33442
udp 172.12.23.5:42398 10.0.0.6:42398 4.4.4.4:33437 4.4.4.4:33437
udp 172.12.23.5:36656 10.0.0.6:36656 4.4.4.4:33439 4.4.4.4:33439
udp 172.12.23.5:39090 10.0.0.6:39090 4.4.4.4:33438 4.4.4.4:33438
udp 172.12.23.5:35099 10.0.0.6:35099 4.4.4.4:33440 4.4.4.4:33440
R3#

Exactly the same! Have no idea where these ports came from, but let's watch closer at the interaction between R2 and R3.

R2#clear ip nat translation *
R3#clear ip nat translation *

R6#telnet 4.4.4.4
Trying 4.4.4.4 ... Open

R4#

Here we go:

R2#sho ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.23.6:47684 10.0.0.6:47684 4.4.4.4:23 4.4.4.4:23

R3#sho ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.23.6:47684 10.0.0.6:47684 4.4.4.4:23 4.4.4.4:23

Some more commands:

R2#sho ip snat distributed
Stateful NAT Connected Peers

SNAT: Mode IP-REDUNDANCY :: STANDBY
    : State READY
    : Local Address 10.0.0.2
    : Local NAT id 1
    : Peer Address 10.0.0.3
    : Peer NAT id 1
    : Mapping List 10 

R3#sho ip snat distributed 

Stateful NAT Connected Peers

SNAT: Mode IP-REDUNDANCY :: ACTIVE
    : State READY
    : Local Address 10.0.0.3
    : Local NAT id 1
    : Peer Address 10.0.0.2
    : Peer NAT id 1
    : Mapping List 10 
R3#

R3 has already been updated and is ready to take over when needed.

Troubleshooting PIM-SM issues on a LAN segment

Below is the topology for this lab. R1 is the Mapping Agent and the RP. PIM-SM is enabled everywhere except the link between R1 and R3.

All routers also have the following debug command:

debug ip pim 239.0.0.1

Let's take a look at what happens R5 joins group 239.0.0.1

R5(config)#int f0/0
R5(config-if)#ip igmp join-group 239.0.0.1
Mar 1 00:51:50.599: PIM(0): Check RP 1.1.1.1 into the (*, 239.0.0.1) entry

R4#ping 239.0.0.1 re 5 sou s1/0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 172.12.14.4
.....
R4#

Hmmm....a quick check of the RP mapping and everyone knows about 1.1.1.1 (R1) as the RP. Let's take a look at the mroute table on R1:

R1#sho ip mrou 239.0.0.1 | be \(
(*, 239.0.0.1), 00:01:38/stopped, RP 1.1.1.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(172.12.14.4, 239.0.0.1), 00:01:38/00:01:46, flags: PT
Incoming interface: Serial1/2, RPF nbr 0.0.0.0
Outgoing interface list: Null

R1 is seeing the packets from R4 but it's outgoing interface list is NULL. Let's take a look at R2's mroute table:

R2#sho ip mrou 239.0.0.1 | be \(
(*, 239.0.0.1), 00:03:27/00:02:57, RP 1.1.1.1, flags: SP
Incoming interface: Serial1/0, RPF nbr 172.12.12.1
Outgoing interface list: Null

NULL also, what gives? Let's wait and see if we get any debugs on R2:

R2#
00:55:42: PIM(0): Received v2 Join/Prune on FastEthernet0/0 from 172.12.25.6, not to us
00:55:42: PIM(0): Building Periodic Join/Prune message for 239.0.0.1

Interesting...It appears that R6 has become the DR for this segment and is responsible for sending (*,G) joins to the RP. R2 is hearing them, but ignoring them...why? What exactly is in the packet that tells R2 its not for us. Well since this is a dynamips lab, we can find out!

Here is a screenshot of the packet capture:

We can see that when R6 sends this join it is using a multicast address of 224.0.0.13. But inside of the PIM packet we can see R6 specifies an upstream neighbor of 172.12.25.3 which is R3.

Also on R6 we see the following debug messages:

R6#
*Mar 1 01:02:48.847: PIM(0): Building Periodic Join/Prune message for 239.0.0.1
*Mar 1 01:02:48.847: PIM(0): Insert (*,239.0.0.1) join in nbr 172.12.25.3's queue
*Mar 1 01:02:48.851: PIM(0): Building Join/Prune packet for nbr 172.12.25.3
*Mar 1 01:02:48.855: PIM(0): Adding v2 (1.1.1.1/32, 239.0.0.1), WC-bit, RPT-bit, S-bit Join
*Mar 1 01:02:48.859: PIM(0): Send v2 join/prune to 172.12.25.3 (FastEthernet0/0)

Can we fix this? Of course!

R6(config)#ip mroute 1.1.1.1 255.255.255.255 172.12.25.2

*Mar 1 01:05:52.019: PIM(0): Building Periodic Join/Prune message for 239.0.0.1
*Mar 1 01:05:52.019: PIM(0): Insert (*,239.0.0.1) join in nbr 172.12.25.2's queue
*Mar 1 01:05:52.023: PIM(0): Building Join/Prune packet for nbr 172.12.25.2
*Mar 1 01:05:52.027: PIM(0): Adding v2 (1.1.1.1/32, 239.0.0.1), WC-bit, RPT-bit, S-bit Join
*Mar 1 01:05:52.027: PIM(0): Send v2 join/prune to 172.12.25.2 (FastEthernet0/0)

Ping now:

R4#ping 239.0.0.1 re 5 sou s1/0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 172.12.14.4

Reply to request 0 from 172.12.25.5, 244 ms
Reply to request 1 from 172.12.25.5, 104 ms
Reply to request 2 from 172.12.25.5, 72 ms
Reply to request 3 from 172.12.25.5, 52 ms
Reply to request 4 from 172.12.25.5, 44 ms

But wait! There's one more solution. We can make R2 the DR for the segment (Remove the mroute on R6 and clear the mroute table on R2):

R2(config)#int f0/0
R2(config-if)#ip pim dr-priority 300000

01:07:09: PIM(0): Changing DR for FastEthernet0/0, from 172.12.25.6 to 172.12.25.2 (this system)
01:07:09: %PIM-5-DRCHG: DR change from neighbor 172.12.25.6 to 172.12.25.2 on interface FastEthernet0/0 (vrf default)
01:07:09: PIM(0): Check RP 1.1.1.1 into the (*, 239.0.0.1) entry
01:07:09: PIM(0): Building Triggered Join/Prune message for 239.0.0.1
01:07:09: PIM(0): Insert (*,239.0.0.1) join in nbr 172.12.12.1's queue
01:07:09: PIM(0): Building Join/Prune packet for nbr 172.12.12.1
01:07:09: PIM(0): Adding v2 (1.1.1.1/32, 239.0.0.1), WC-bit, RPT-bit, S-bit Join
01:07:09: PIM(0): Send v2 join/prune to 172.12.12.1 (Serial1/0)

R2#sho ip mrou 239.0.0.1 | be \(
(*, 239.0.0.1), 00:01:28/00:02:31, RP 1.1.1.1, flags: SJC
Incoming interface: Serial1/0, RPF nbr 172.12.12.1
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:01:28/00:02:31

It's always good to have more than one solution up your sleeve :)

Sending Logs as SNMP Traps

I have been reading Chapter 9 of Routing TCP/IP Vol. II this week. It has a good overview of the non-core topics such as snmp, rmon, ntp, etc. I recommend it for anyone struggling with these topics or just wanting a concise review.

This example shows how to configure a router to send logs to an snmp-server and verify it.

The first thing you must do is configure a server. Without this, you want be able to see any debugging because the router won't send any packet out.

R8(config)#snmp-server host 4.4.4.4 public syslog
R8(config)#snmp-server enable traps syslog
R8(config)#logging console warnings
R8(config)#logging buffered 16384 debugging

I have also decided to buffer the logs instead of send them to the console. This is not required just a way to keep everything less cluttered on the console screen. What this configuration does is buffer all log messages of debugging level or lower. Then these messages are sent via SNMP to the server at 4.4.4.4. Let's debug snmp packets, then a quick shutting/no shutting of an interface will give us some messages to view:

R8#debug snmp packets
SNMP packet debugging is on

R8(config)#int f0/0
R8(config-if)#no snmp trap link-status
R8(config-if)#shut
R8(config-if)#no shut

R8#sho logging | beg Log Buffer
Log Buffer (16384 bytes):

*Mar 2 18:33:38.565: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar 2 18:33:40.117: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 192.168.8.8 on interface FastEthernet0/0 (vrf default)
*Mar 2 18:33:40.641: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar 2 18:33:40.669: SNMP: Queuing packet to 4.4.4.4
*Mar 2 18:33:40.669: SNMP: V1 Trap, ent ciscoSyslogMIB.2, addr 192.168.78.8, gentrap 6, spectrap 1
clogHistoryEntry.2.58 = LINK
clogHistoryEntry.3.58 = 4
clogHistoryEntry.4.58 = UPDOWN
clogHistoryEntry.5.58 = Interface FastEthernet0/0, changed state to up
clogHistoryEntry.6.58 = 15322065
*Mar 2 18:33:40.921: SNMP: Packet sent via UDP to 4.4.4.4
*Mar 2 18:33:42.513: %SYS-5-CONFIG_I: Configured from console by console

I disabled snmp trap link-status to show that we are not using this feature to send traps. Notice the entry labeled clogHistoryEntry.5.58, this is exactly the same message as our logging message a few lines up. We only get linkup messages with this basic config.

To modify the configuration we use the logging history command:

R8(config)#logging history ?
<0-7> Logging severity level
alerts Immediate action needed (severity=1)
critical Critical conditions (severity=2)
debugging Debugging messages (severity=7)
emergencies System is unusable (severity=0)
errors Error conditions (severity=3)
informational Informational messages (severity=6)
notifications Normal but significant conditions (severity=5)
size Set history table size
warnings Warning conditions (severity=4

R8(config)#logging history size 2

Here I set the history size to 2 so I am able to view the last 2 messages sent with the following command:

R8#sho logging history
Syslog History Table:2 maximum table entries,
saving level notifications or higher
149 messages ignored, 11 dropped, 0 recursion drops
57 table entries flushed
SNMP notifications enabled, 45 notifications sent
entry number 58 : LINK-3-UPDOWN
Interface FastEthernet0/0, changed state to up
timestamp: 15322065
entry number 59 : SYS-5-CONFIG_I
Configured from console by console
timestamp: 15345618

Pretty basic scenario. It is important to remember this is different from the usual way of sending linkup/linkdown traps. Here, we are not using "snmp-server enable traps snmp linkup linkdown" or the interface command "snmp trap link-status".

Also, I think I figured out why linkdowns are not being sent, if I manually configure the logging level to "notifications" it works:

R8(config)#logging history notifications
R8(config)#int f0/0
R8(config-if)#shut

R8#sho logging

*Mar 2 18:46:38.885: SNMP: Packet sent via UDP to 4.4.4.4
*Mar 2 18:46:39.981: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar 2 18:46:40.057: SNMP: Queuing packet to 4.4.4.4
*Mar 2 18:46:40.061: SNMP: V1 Trap, ent ciscoSyslogMIB.2, addr 192.168.78.8, gentrap 6, spectrap 1
clogHistoryEntry.2.72 = LINK
clogHistoryEntry.3.72 = 6
clogHistoryEntry.4.72 = CHANGED
clogHistoryEntry.5.72 = Interface FastEthernet0/0, changed state to administratively down
clogHistoryEntry.6.72 = 15399999
*Mar 2 18:46:40.309: SNMP: Packet sent via UDP to 4.4.4.4
*Mar 2 18:46:40.981: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
*Mar 2 18:46:41.033: SNMP: Queuing packet to 4.4.4.4
*Mar 2 18:46:41.033: SNMP: V1 Trap, ent ciscoSyslogMIB.2, addr 192.168.78.8, gentrap 6, spectrap 1
clogHistoryEntry.2.73 = LINEPROTO
clogHistoryEntry.3.73 = 6
clogHistoryEntry.4.73 = UPDOWN
clogHistoryEntry.5.73 = Line protocol on Interface FastEthernet0/0, changed state to down
clogHistoryEntry.6.73 = 15400099

Not sure why I needed that because according to the "show logging history", notifications were the default level. However, it appears they aren't because the command shows up in the config:

R8#sho run | inc logging his
logging history size 2
logging history notifications
R8#

Basic MSDP configuration

This is a short MSDP scenario designed to get familiar with the command to enable it and where you would use it. Below is the toplogy.


There are two domains, each with an RP. We seperate the domains by using the following commands on R3 and R4:

R3(config)#int s1/1
R3(config-if)#ip pim bsr-border

R4(config)#int s1/0
R4(config-if)#ip pim bsr-border

R2 and R4 have already been configured as the BSR and RP's for their respective domains. Let's verify on R1 and R5:

R1#sho ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 2.2.2.2 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 18:21:34, expires: 00:02:13

R5#sho ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 4.4.4.4 (?), v2
Info source: 4.4.4.4 (?), via bootstrap, priority 0, holdtime 150
Uptime: 18:19:56, expires: 00:01:52

R1 and R8 have already joined group 225.0.0.1. Let's see what happens when R6 sends a ping to this group:

R6#ping 225.0.0.1 re 10

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 225.0.0.1, timeout is 2 seconds:

Reply to request 0 from 192.168.78.8, 192 ms
Reply to request 1 from 192.168.78.8, 192 ms
Reply to request 2 from 192.168.78.8, 100 ms
Reply to request 3 from 192.168.78.8, 84 ms
Reply to request 4 from 192.168.78.8, 112 ms
Reply to request 5 from 192.168.78.8, 104 ms

Only R8 responds. This is because the PIM joins from Domain 1 never get sent to the RP in Domain 2. Thus R4 never knows to forward to R3. Let's configure MSDP between R2 and R4:

R2(config)#ip msdp peer 4.4.4.4 connect-source loopback 0

R4(config)#ip msdp peer 2.2.2.2 connect-source loopback 0

It may take a moment but we will see this message:

*Mar 1 19:56:14.343: %MSDP-5-PEER_UPDOWN: Session to peer 2.2.2.2 going up

If we debug we would see this:

R4#debug ip msdp de
MSDP Detail debugging is on

*Mar 1 19:56:15.263: MSDP(0): Received 3-byte TCP segment from 2.2.2.2
*Mar 1 19:56:15.263: MSDP(0): Append 3 bytes to 0-byte msg 1170 from 2.2.2.2, qs 1
*Mar 1 19:56:15.643: MSDP(0): Sent entire mroute table, mroute_cache_index = 0, Qlen = 0
*Mar 1 19:56:15.647: MSDP(0): start_index = 0, sa_cache_index = 0, Qlen = 0
*Mar 1 19:56:15.651: MSDP(0): Sent entire sa-cache, sa_cache_index = 0, Qlen = 0
*Mar 1 19:56:16.275: MSDP(0): Received 3-byte TCP segment from 2.2.2.2
*Mar 1 19:56:16.275: MSDP(0): Append 3 bytes to 0-byte msg 1171 from 2.2.2.2, qs 1

Notice that R4 sent R2 its entire mroute table. Let's check the mroute table on R2:

R2#sho ip mroute 225.0.0.1 | be \(\*
(*, 225.0.0.1), 00:04:59/00:03:27, RP 2.2.2.2, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1/0, Forward/Sparse, 00:04:59/00:03:27

(192.168.56.6, 225.0.0.1), 00:01:47/00:01:12, flags: M
Incoming interface: Serial1/1, RPF nbr 192.168.23.3
Outgoing interface list:
Serial1/0, Forward/Sparse, 00:01:47/00:03:27

R2 now knows about the source of R6 and has even populated its OIL. The M flag tells us this is an MSDP created entry. Let's ping from R6:

R6#ping 225.0.0.1 re 5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 225.0.0.1, timeout is 2 seconds:

Reply to request 0 from 192.168.78.8, 188 ms
Reply to request 0 from 192.168.12.1, 284 ms
Reply to request 0 from 192.168.12.1, 268 ms
Reply to request 1 from 192.168.12.1, 132 ms
Reply to request 1 from 192.168.78.8, 184 ms
Reply to request 2 from 192.168.12.1, 132 ms
Reply to request 2 from 192.168.78.8, 132 ms
Reply to request 3 from 192.168.12.1, 100 ms
Reply to request 3 from 192.168.78.8, 100 ms
Reply to request 4 from 192.168.12.1, 96 ms
Reply to request 4 from 192.168.78.8, 100 ms

Well that's it for now. You can have more complex scenarios with multiple domains (DocCD says MBGP is required for that) but the basics are easy to get down.

STP: UplinkFast and BackBoneFast

This is I lab made to get familiar with the two STP features Uplinkfast and Backbonefast. RSTP (802.1w) includes these features but I don't seem to get the BackboneFast behavior when using "spanning-tree mode rapid-pvst+".

These features are similar but they are used to provide fast convergence in different scenarios depending on where the failure is in the STP toplogy.

Here is Topology #1 with SW1 configured as Root for VLAN13 where R1 and R4 reside. The Red Xes mark where STP is blocking:


Without Uplinkfast or Backbonefast enabled, lets see how long it takes STP to converge if port 13 on SW2 is shut:

R4 starts the ping while we shut the port on SW2

R4#ping 2001:13::1 re 1000000 Type escape sequence to abort. Sending 1000000, 100-byte ICMP Echos to 2001:13::1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!................!!!!!!

We missed about 16 pings and our topology has now converged. Let's enable UplinkFast on SW2, SW3 and SW4 and test again:

SW2(config)#spanning-tree uplinkfast
SW3(config)#spanning-tree uplinkfast
SW4(config)#spanning-tree uplinkfast

When you re-enable Port 13 on SW2, it takes awhile to come back up. It doesn't move through the LIS and LRN states according to the output but it will come up and you will see this message:

02:31:17: %SPANTREE_FAST-7-PORT_FWD_UPLINK: VLAN0013 FastEthernet0/13 moved to Forwarding (UplinkFast)

Now Let's ping from R4 again and the shut port 13 on SW2:

R4#ping 2001:13::1 re 1000000 Type escape sequence to abort. Sending 1000000, 100-byte ICMP Echos to 2001:13::1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!

One ping lost - WOW! Very fast. Let's build upon this failed scenario and look our new topology. Now we have SW2 forwarding through SW4 on it's way to the root SW1.

Let's see how long it takes to converge if we shut port 13 on SW4:

R4#ping 2001:13::1 re 1000000 Type escape sequence to abort. Sending 1000000, 100-byte ICMP Echos to 2001:13::1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.........!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

We miss about 9 pings here. What happened? Well in short, when SW4 path to root went down, it started thinking that it was the new root. This caused a new STP election to occur and SW4 finally had to wait until it heard the new SW1 BPDUs from SW1 > SW3 > SW2 > SW4.

BackboneFast can speed up this process, when SW2 starts hearing this inferior BPDUS from SW4 (who is cliaming to be root when port 13 goes down") and special query process takes place to speed up convergence. Let's enable it and check the pings again. This goes on all switches.

SW1(config)#spann backbonefast
SW2(config)#spann backbonefast
SW3(config)#spann backbonefast
SW4(config)#spann backbonefast

R4#ping 2001:13::1 re 1000000

Type escape sequence to abort.
Sending 1000000, 100-byte ICMP Echos to 2001:13::1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Rapid Spanning Tree Protocol (802.1w) includes these features natively. In failover scenario #2 (shutting port 13 on SW4), only backbonefast provided quick convergence while Rapid-PVST+ did not. If have any ideas why, please let me know.

IPv6 NAT-PT

This is a very simple IPv6 NAT-PT scenario. Here is the topology and addressing:


R1 is an IPv6 only host and R2 is an IPv4 only host.
R1 should use address 2001:23::2 to reach R2.
R2 should use 192.168.13.1 to reach R1.
R3 will be doing NAT-PT

Assign addresses per the diagram. The rest of the configuration is on R3.

R3(config)#int e0/0
R3(config-if)#ipv6 nat
R3(config-if)#int e0/1
R3(config-if)#ipv6 nat
R3(config)#ipv6 nat v4v6 source 192.168.23.2 2001:23::2
R3(config)#ipv6 nat v6v4 source 2001:13::1 192.168.13.1
R3(config)#ipv6 nat prefix 2001:23::/96

Remember to assing default gateways on R1 and R2:

R1(config)#ipv6 route 0::/0 2001:13::3

R2(config)#ip route 0.0.0.0 0.0.0.0 192.168.23.3

Let's ping from R1 while debugging on R3:

R3#debug ipv6 nat
IPv6 NAT-PT debugging is on

R1#ping 2001:23::2 re 1

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

R3#
*Mar 1 13:51:12.323: IPv6 NAT: icmp src (2001:13::1) -> (192.168.13.1), dst (2001:23::2) -> (192.168.23.2)
*Mar 1 13:51:12.327: IPv6 NAT: src (192.168.23.2) -> (2001:23::2), dst (192.168.13.1) -> (2001:13::1)
R3#

Now let's try the other way:

R2#ping 192.168.13.1 re 1

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

R3#
*Mar 1 13:53:00.991: IPv6 NAT: src (192.168.23.2) -> (2001:23::2), dst(192.168.13.1) -> (2001:13::1)
*Mar 1 13:53:00.995: IPv6 NAT: icmp src (2001:13::1) -> (192.168.13.1), dst (2001:23::2) -> (192.168.23.2)
R3#

You can view the translations on R3:

R3#sho ipv6  nat translations
Prot  IPv4 source              IPv6 source
      IPv4 destination         IPv6 destination
---   ---                      ---
      192.168.23.2             2001:23::2

---   192.168.13.1             2001:13::1
      192.168.23.2             2001:23::2

---   192.168.13.1             2001:13::1
      ---                      ---

That's it!