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.