CCIE Pursuit Blog

March 9, 2008

Internetwork Expert Volume III: Lab 1 – Section 4

Interior Gateway Routing – 24 Points

4.1 OSPF over NBMA

Nothing new here.  Simple hub-and-spoke OSPF network.  You cannot change the default network type (NBMA on the physical interfaces) so just set the spokes to OSPF priority 0 and configure neighbor statements on the hub.

4.2 OSPF

Very simple OSPF task.  The only issue I ran across was an MTU mismatch between r2 and sw2: 

r2(config-router)#do sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.10.5.5        1   FULL/DR         00:01:34    140.10.245.5    Serial0/0
150.10.8.8        1   DOWN/DROTHER       –        140.10.28.8     FastEthernet0/0
*Jun 11 12:01:07.591: %OSPF-5-ADJCHG: Process 100, Nbr 150.10.8.8 on FastEthernet0/0 from DOWN to DOWN, Neighbor Down: Ignore timer expired

sw2(config-router)#do sh system mtu

System MTU size is 1504 bytes
System Jumbo MTU size is 1504 bytes
Routing MTU size is 1504 bytes

r2(config-router)#int fa0/0
r2(config-if)#ip os mtu-ignore

*Jun 11 12:01:57.753: %OSPF-5-ADJCHG: Process 100, Nbr 150.10.8.8 on FastEtherne
t0/0 from LOADING to FULL, Loading Done

r2(config-if)#do sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.10.5.5        1   FULL/DR         00:01:54    140.10.245.5    Serial0/0
150.10.8.8        1   FULL/DR         00:00:39    140.10.28.8     FastEthernet0/0

You can also change the system MTU back to 1500 bytes on sw2, but that requires a reload.

4.3 OSPF Stub Area

Easy OSPF stub network task.  There is no ambiguity over what type of OSPF stub to configure.

area stub

Before stub:

sw1(config-router)#do sh ip route os
     140.10.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    140.10.0.128/25 [110/68] via 140.10.57.5, 00:00:13, FastEthernet0/21
O IA    140.10.245.0/24 [110/65] via 140.10.57.5, 00:00:13, FastEthernet0/21
O IA    140.10.0.0/25 [110/67] via 140.10.57.5, 00:00:13, FastEthernet0/21
O IA    140.10.28.0/24 [110/66] via 140.10.57.5, 00:00:13, FastEthernet0/21
O IA    140.10.100.0/24 [110/11] via 140.10.57.5, 00:00:13, FastEthernet0/21

After stub:

sw1#sh ip route os
     140.10.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    140.10.0.128/25 [110/68] via 140.10.57.5, 00:00:04, FastEthernet0/21
O IA    140.10.245.0/24 [110/65] via 140.10.57.5, 00:00:04, FastEthernet0/21
O IA    140.10.0.0/25 [110/67] via 140.10.57.5, 00:00:04, FastEthernet0/21
O IA    140.10.28.0/24 [110/66] via 140.10.57.5, 00:00:04, FastEthernet0/21
O IA    140.10.100.0/24 [110/11] via 140.10.57.5, 00:00:04, FastEthernet0/21
O*IA 0.0.0.0/0 [110/2] via 140.10.57.5, 00:00:04, FastEthernet0/21

4.4 OSPF

Another easy task.  You need to advertise some loopbacks, but the network mask should be /24 not /32.  You’ll need to change the OSPF network type on the loopbacks to point-to-point to accomplish this.  You should see all the loop nets on r5:

r5#sh ip route os | i 150.
     150.10.0.0/24 is subnetted, 9 subnets
O IA    150.10.8.0 [110/66] via 140.10.245.2, 00:01:02, Serial0/0
O IA    150.10.9.0 [110/67] via 140.10.245.2, 00:00:34, Serial0/0
O IA    150.10.10.0 [110/68] via 140.10.245.2, 00:00:18, Serial0/0
O       150.10.4.0 [110/65] via 140.10.245.4, 00:02:31, Serial0/0
O       150.10.6.0 [110/11] via 140.10.100.6, 00:02:57, Ethernet0/0
O       150.10.7.0 [110/11] via 140.10.57.7, 00:01:55, Ethernet0/1
O IA    150.10.2.0 [110/65] via 140.10.245.2, 00:01:22, Serial0/0
O       150.10.3.0 [110/11] via 140.10.100.3, 00:02:57, Ethernet0/0

r5#sh ip route 150.10.10.10
Routing entry for 150.10.10.0/24

4.5 RIP

Very easy RIP configuration.  Just remember to use passive interfaces on devices that have multiple interfaces in the same classful network: 

r4#sh ip int br | e ass
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            140.1.14.4      YES NVRAM  up                    up
Serial0/0                  140.1.245.4     YES NVRAM  up                    up
Serial0/1                  140.1.45.4      YES NVRAM  up                    up
Loopback0                  150.1.4.4       YES NVRAM  up                    up

r4#sh run | sec router rip
router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface Serial0/1

 network 140.1.0.0
 no auto-summary

r4#sh ip proto | sec rip
    rip, includes subnets in redistribution
Routing Protocol is “rip”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 18 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: ospf 100, rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       2     2
    Serial0/1             2     2

  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    140.1.0.0
  Passive Interface(s):
    Serial0/0
    FastEthernet0/1
    Loopback0
    VoIP-Null0

  Routing Information Sources:
    Gateway         Distance      Last Update
    140.1.14.1           120      00:00:14
    Gateway         Distance      Last Update
    140.1.45.5           120      00:00:14
  Distance: (default is 120)  

4.6 RIP

You’ll need to use an offset-list to make the metric (hop count) of 150.1.1.0 on r4 equal 10.  Remember this as it will come back in the redistribution scenario.

4.7 Redistribution

I wish all redistribution were this easy.  You simply need to set the metric-type to type-1 in your route-map and redistribute some connected networks into OSPF.

4.8 Advanced Redistribution

You need to do mutual redistribution between RIP and OSPF on three routers.  As with most of the Volume III labs, you can complete this task with the knowledge that any redistribution issues will most likely be the focus of the next task.

4.9 Advanced Redistribution

“Ensure that reachability to r1’s loopback 0 interface is maintained.”

Before redistribution:

r5(config-route-map)#do sh ip route rip | i 150
     150.1.0.0/24 is subnetted, 10 subnets
      150.1.1.0 [120/11] via 140.1.45.4, 00:00:19, Serial0/1

r4(config-route-map)#do sh ip route rip | i 150.
     150.1.0.0/24 is subnetted, 10 subnets
R       150.1.1.0 [120/10] via 140.1.14.1, 00:00:21, Ethernet0/0

r1’s lo0 interface is advertised to r4 via RIP with a metric of 10 (we changed the metric in task 4.6).  r4 advertises that route to r5 via the point-to-point serial connection.  r5 adds the route to its routing table with a metric of 11. 

After redistribution:

r4#sh ip route rip  <-no RIP routes on r4

r4#

r4#sh ip route 150.1.1.0
Routing entry for 150.1.1.0/24
  Known via “ospf 100“, distance 110, metric 20
  Tag 5120, type extern 2, forward metric 64 
  Redistributing via rip
  Advertised by rip metric 1 route-map OSPF->RIP
  Last update from 140.1.245.5 on Serial0/0, 00:00:18 ago
  Routing Descriptor Blocks:
  * 140.1.245.5, from 150.1.5.5, 00:00:18 ago, via Serial0/0
      Route metric is 20, traffic share count is 1
      Route tag 5120 <-5120 = RIP route redistributed on r5

r5#sh ip route rip | sec 150.1.1.0
     150.1.0.0/24 is subnetted, 10 subnets
R       150.1.1.0 [120/1] via 140.1.45.4, 00:00:04, Serial0/1

r5#sh ip route 150.1.1.0
Routing entry for 150.10.1.0/24
  Known via “rip”, distance 120, metric 1
  Tag 4110 <-5120 = RIP route redistributed on r5
  Redistributing via ospf 100, rip
  Advertised by ospf 100 subnets route-map RIP->OSPF
  Last update from 140.1.45.4 on Serial0/1, 00:00:11 ago
  Routing Descriptor Blocks:
  * 140.1.45.4, from 140.1.45.4, 00:00:11 ago, via Serial0/1
      Route metric is 1, traffic share count is 1
      Route tag 4110

Once we do mutual redistribution on r4 and r5, we end up with a routing loop for the 150.1.1.0/24 network:

sw2#trace 150.1.1.1

Type escape sequence to abort.
Tracing the route to 150.1.1.1

  1 140.1.28.2 9 msec 0 msec 0 msec
  2 140.1.245.525 msec 33 msec 26 msec
  3 140.1.45.450 msec 50 msec 51 msec
  4 140.1.245.541 msec 51 msec 42 msec
  5 140.1.45.4 67 msec 59 msec 59 msec
  6 140.1.245.5 58 msec 59 msec 59 msec
  7 140.1.45.4 84 msec 75 msec 75 msec
  8 140.1.245.5 76 msec 75 msec 76 msec
  9 140.1.45.4 92 msec 92 msec 11 msec
 1 140.1.245.5 84 msec 92 msec 84 msec
 11 140.1.45.4 19 msec 19 msec 19 msec
 12 140.1.245.5 19 msec 11 msec 19 msec
 13 140.1.45.4 118 msec 134 msec 117 msec
 14 140.1.245.5 117 msec 118 msec 117 msec
 15 140.1.45.4 143 msec 134 msec 142 msec
 16 140.1.245.5 135 msec 134 msec 134 msec
 17 140.1.45.4 151 msec 159 msec 151 msec
 18 140.1.245.5 151 msec 151 msec 143 msec
 19 140.1.45.4 176 msec 168 msec 168 msec
 20 140.1.245.5 167 msec 160 msec 168 msec
 21 140.1.45.4 184 msec 185 msec 184 msec
 22 140.1.245.5 176 msec 177 msec 184 msec
 23 140.1.45.4 201 msec 202 msec 201 msec
 24 140.1.245.5 193 msec 193 msec 193 msec
 25 140.1.45.4 218 msec 21 msec 218 msec
 26 140.1.245.5 21 msec 209 msec 21 msec
 27 140.1.45.4 227 msec 234 msec 227 msec
 28 140.1.245.5 226 msec 227 msec 218 msec
 29 140.1.45.4 243 msec 252 msec 243 msec
 30 140.1.245.5 235 msec 243 msec 235 msec

So initially we have:

r4 – R [120/10] from r1 via fa0/0
r5 – R [120/11] from r4 via s0/1

r4 and r5 will each redistribute their RIP routes for 150.1.1.0/24 into OSPF.  That means that r4 and r5 will hear about the 150.1.1.0/24 route from each other via OSPF.  Since OSPF has a lower metric, those routes will be installed:

r4 – R [110/20] from r5 via s0/0
r5 – R [110/20] from r4 via s0/0

This gets even uglier because the RIP route on r4 will is replaced by the OSPF route.  Now the RIP route is no longer advertised to r5 via RIP from r4 nor is it redistributed into OSPF on r4 or r5.  So the route should disappear only to reappear again once the original RIP route is restored to r4’s routing table…which will start the whole process over again.  So we should have a “blinking route”, right?

Not really.  To add to this mindfuck, we need to consider that OSPF is being redistributed into RIP.  I did this with a seed metric of 1.  So the OSPF route to 150.1.1.0/24 advertised to r4 and then redistributed into RIP has a better (lower) metric than 10, so it will be installed instead of the original RIP route with a metric of 10.  Does your head hurt yet?

Here’s how it breaks down:

1) r4 gets RIP route from r1 [120/10] and advertises it to r5 [120/11] via RIP.
2) r4 and r5 redistribute the route into OSPF.  Each installs this route (pointing to each other) in their routing tables based on a lower AD (110 vs 120).
3) These OSPF routes are redistributed into RIP as well [120/1] (note that the metric is better than our original RIP routes) but are not installed on r4 or r5 because the OSPF routes have a lower AD.
4) The original RIP route is removed from r4’s routing table.  This means that neither r4 nor r5 can advertise it into OSPF so the 150.1.1.0/24 route should drop from OSPF.
5) The original RIP route on r4 [120/10] reappears and the whole process begins again…OR due to the slow RIP route removal process, the OSPF route from r5 gets redistributed into RIP on r4 and is installed because of the lower metric (1 vs 10).  Either way, we end up with either a “blinking loop” or a “stable loop.

To stop this we need to make sure that the 150.1.1.0/24 network is not redistributed back into RIP on r5.  This means that we’ll route over the Frame cloud to reach 150.1.1.1 on r5 instead of the serial link, but we won’t get a loop.

I filtered r1 lo0 from getting redistributed into from OSPF back into RIP on r5:

router ospf 100
 redistribute ospf 100 metric 1 route-map OSPF->RIP
!
access-list 69 deny   150.1.1.0
access-list 69 permit any
!
route-map OSPF->RIP permit 10
 match ip address 69
 set tag 5110

sw2#p 150.1.1.1

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

sw2#trace 150.1.1.1

Type escape sequence to abort.
Tracing the route to 150.1.1.1

  1 140.1.28.2 0 msec 0 msec 8 msec
  2 140.1.245.525 msec 25 msec 34 msec
  3 140.1.245.450 msec 50 msec 59 msec
  4 140.1.14.150 msec *  59 msec

Whew!!!

February 10, 2008

Simulated Lab #1: Internetwork Expert Volume II – Lab 1

Volume II Lab 1 Score Report

Section Task

  Points

  Earned

  Time (min)

Bridging and Switching 1.1 2

?

*69

Bridging and Switching 1.2

2

?

8

Bridging and Switching 1.3

2

2

8

Bridging and Switching 1.4

2

0

3

Bridging and Switching 1.5

2

2

25

Bridging and Switching 1.6

2

DNC

Total

12

4 – 8

113

Frame Relay 2.1

2

2

7

Frame Relay 2.2

2

2

5

Frame Relay 2.3

2

2

3

Total

6

6

15

Interior Gateway Routing    3.1

3

3

8

Interior Gateway Routing 3.2

3

3

11

Interior Gateway Routing 3.3

2

2

6

Interior Gateway Routing 3.4

2

2

5

Interior Gateway Routing 3.5

2

2

12

Interior Gateway Routing 3.6

3

3

19

Interior Gateway Routing 3.7

2

2

3

Interior Gateway Routing 3.8

2

2

5

Interior Gateway Routing 3.9

2

2

4

Interior Gateway Routing 3.10

1

1

7

Interior Gateway Routing 3.11

2

2

**42

Total

24

24

122

Exterior Gateway Routing 4.1

3

3

65

Exterior Gateway Routing 4.2

3

3

4

Exterior Gateway Routing 4.3

3

DNC

Total

9

6

69

IP Multicast 5.1

2

2

10

IP Multicast 5.2

2

0

2

IP Multicast 5.3

3

DNC

IP Multicast 5.4

2

DNC

Total

9

2

12

IPv6 6.1

3

3

8

IPv6 6.2

3

3

5

IPv6 6.3

3

0

6

Total

9

6

19

QoS 7.1

3

0

19

QoS 7.2

3

?

10

Total

6

3 – 6

29

Security 8.1

2

DNC

Security 8.2

2

DNC

Total

5

0

0

System Management 9.1

3

3

12

System Management 9.2

3

?

10

System Management 9.3

3

?

16

System Management 9.4

2

2

12

Total

11

5 – 11

50

IP Services 10.1

3

DNC

IP Services 10.2

3

3

15

IP Services 10.3

3

DNC

Total

9

3

15

 

 

Grand Totals

100

 

444

Best Case

 

69

Worst Case

 

56

DNC = Did not complete.
* Includes reading the exam, creating L2 diagram, and initial troubleshooting. 
** Includes creation of TCL scripts and macros.

Notes on specific tasks:

1.1 – I did not put sw1 and sw2 into vtp transparent mode because I never attempted task 1.6 (private VLAN).  I’m not sure if I would lose points for this or not.

1.4 – Stupid mistake #1.  I did not read this question closely.  I would have configured it correctly if I had paid attention to “[ports] will be shut down”.

1.6 – I recognized that this task required private VLANs, but I couldn’t get my head around exactly what the configuration should look like.  I skipped this task rather than risk breaking my network.

5.2 – Stupid mistake #2.  I configured the same router instead two separate routers.  I had the right configuration, but I didn’t switch from r2 to r3 so I ended up putting the entire configuration on r2.

6.3 – Stupid mistake #3.  I forgot to configure the IPv6 hostnames on the routers.

7.1 – Stupid mistake #4.  I configured DLCI 513’s be value on DLCI 504 and vice versa.

7.2 – I used CAR instead of MQC.  I can’t find anything in the question that requires MQC.

9.2 – The task states to “configure all devices in the network” and gives specific ‘logging facility’ values for all devices except sw2 and sw3.  I configured the defaults on those two devices, but the solution guide seems to skip them altogether.

9.3 -I configured ‘ntp peer’ on both r3 and r6.  It is only needed on r3.  Not sure if I would lose points for this or not.

This was my first simulated mock lab.  I limited myself to 8 hours (with a 30 minute “lunch” break).  I have mixed feelings about my experience.  One one hand, I did very well on the core topics.  I aced the IGP and Frame Relay sections.  I nailed the IGP route redistribution (albeit a pretty simple scenario).  I was done with everything up to BGP with the exception of two layer 2 tasks (I completed one of them later) before lunch.  I ran my TCL scripts and ping macros before lunch and then reloaded the routers.

After lunch it was a different story.  I spent over an hour on the first BGP task.  This was a very simple peering task.  For the first time in any lab I had to create a BGP map.  It really helped me out, especially with placing route reflectors.  I spent a ton of time troubleshooting a single peering that would not come up.  It turned out to be a boneheaded mistake.  I configured a neighbor address of 181.13.125.x instead of 181.13.123.x.  ARRGGHHH!!!

I knew that I was not likely to get 80 points as there were a number of tasks which I had no clue as to how to complete.  By the time I was done with BGP, I had about 2.5 hours to complete the remaining 49 points (plus 4 points I skipped in Bridging and Switching).  I knew after reading the lab that I was only going to be able to count on getting about half of those points.  I missed some of these points because of stupid mistakes, but I also picked up some points by mining the DOC.  But in the end, I left 20 points on the table by not attempting/completing the tasks.  While I rocked the core routing section I failed miserably down the stretch.  This is not a surprise as I have been doing a lot of core routing work and only scratching the surface of the non-core tasks. 

I felt pretty good about my time-management skills other then the hour I spent on BGP peering.  It is VERY different trying to complete a lab in 8 hours.  I felt the tyranny of the clock.  Also, I really haven’t logged eight uninterupted, consecutive hours on a rack before.  I was a little punch drunk by the end.  I only missed a couple of (dumb!!!) points due to question interpretation. 

This was IE’s easiest lab and I failed it, so I don’t feel great about that.  On the other hand, I nailed the core tasks and did a pretty good job of managing my time.  As usual, I feel like I’m taking one step forward and 0.99999 steps backward.  🙂

January 6, 2008

Internetwork Expert Volume III: Lab 1 – Section 3

3 WAN Technologies

3.1 Hub and Spoke

This was an easy Hub and Spoke configuration.  The only gotcha is that the initial configurations have some of the FR ports configured with an IP address and opened up.  That means that FR Inverse-ARP is in play:

Before configuration:

r5(config)#do sh run int s0/0
interface Serial0/0
 ip address 140.1.245.5 255.255.255.0
 encapsulation frame-relay
end

r5(config)#do sh frame map
Serial0/0 (up): ip140.1.245.2 dlci 502(0x1F6,0x7C60), dynamic,
              broadcast,, status defined, active
Serial0/0 (up): ip 140.1.245.4 dlci 504(0x1F8,0x7C80), dynamic,
              broadcast,, status defined, active 

3.2 Point-To-Point

This was a very basic point-to-point Frame Relay configuration.

3.3 PPP Authentication

PPP is usually a time-waster for me.  I have boned up on the topic a bit and this task was very basic, so I had little trouble except for my own undoing: 

r5:
username r4 password 0 CISCO
!
interface Serial0/1
 description ->r4 PTP DTE PPP
 ip address 140.1.45.5 255.255.255.0
 encapsulation ppp
 ppp authentication chap

Debugging ppp authentication:
*Mar  1 04:14:18.396: Se0/1 PPP: Authorization required
*Mar  1 04:14:18.400: Se0/1 CHAP: O CHALLENGE id 13 len 23 from “r5”
*Mar  1 04:14:18.400: Se0/1 CHAP: I CHALLENGE id 19 len 23 from “r4”
*Mar  1 04:14:18.404: Se0/1 CHAP: Using hostname from unknown source
*Mar  1 04:14:18.404: Se0/1 CHAP: Using password from AAA 
*Mar  1 04:14:18.404: Se0/1 CHAP: O RESPONSE id 19 len 23 from “r5”

The link would not come up.  The fact that it was trying to use an AAA password made me suspect that I had misconfigured the password.  Close, I actually mucked up the username on r4:

r4(config-if)#do sh run | i username
username r4
password 0 CISCO

r4(config-if)#no username r4 password 0 CISCO
r4(config)#user r5pass CISCO
r4(config)#
*Mar  1 04:15:26.552: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up

This is what the debug looks like when PPP CHAP authentication is successful:

Se0/1 PPP: Using default call direction
Se0/1 PPP: Treating connection as a dedicated line
Se0/1 PPP: Session handle[C1000004] Session id[62]
Se0/1 PPP: Authorization required
Se0/1 CHAP: O CHALLENGE id 56 len 23 from “r5”
Se0/1 CHAP: I CHALLENGE id 62 len 23 from “r4”
%LINK-3-UPDOWN: Interface Serial0/1, changed state to up
Se0/1 CHAP: Using hostname from unknown source
Se0/1 CHAP: Using password from AAA
Se0/1 CHAP: O RESPONSE id 62 len 23 from “r5”
Se0/1 CHAP: I RESPONSE id 56 len 23 from “r4”
Se0/1 PPP: Sent CHAP LOGIN Request
Se0/1 PPP: Received LOGIN Response PASS
Se0/1 PPP: Sent LCP AUTHOR Request
Se0/1 PPP: Sent IPCP AUTHOR Request
Se0/1 LCP: Received AAA AUTHOR Response PASS
Se0/1 IPCP: Received AAA AUTHOR Response PASS
Se0/1 CHAP: O SUCCESS id 56 len 4
Se0/1 CHAP: I SUCCESS id 62 len 4
Se0/1 PPP: Sent CDPCP AUTHOR Request
Se0/1 PPP: Sent IPCP AUTHOR Request
Se0/1 CDPCP: Received AAA AUTHOR Response PASS
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up

Internetwork Expert Volume III: Lab 1 – Section 2

2 Bridging and Switching

2.1 VLAN Assignments

This is a pretty easy task.  You need to set up sw1 as a VTP server and the remaining switches as VTP clients.  You are then given a list of named VLANs to configure as well as a list of ports with VLAN assignments.

IE refers to the VLANs by VLAN name (i.e. VLAN_B) instead of the VLAN number.  You need to use the number when assigning a port to a VLAN:

sw1(config-if)#swit acc vla ?
  <1-4094>  VLAN ID of the VLAN when this port is in access mode
  dynamic   When in access mode, this interfaces VLAN is controlled by VMPS

sw1(config-if)#swit acc vla VLAN_B
                                                ^
% Invalid input detected at ‘^’ marker.

The initial configurations have shut down most of the ports so there are no trunks negotiated by default, so if you do these tasks in order, be sure to come back and verify VTP and access ports after your trunks are up and VTP has propagated the VLANs.

The IE solution guide shows that they are using “switchport mode access” under the ports.  I don’t see anything in the task that requires this.

My solution:

interface FastEthernet0/1
 switchport access vlan 14

sw1#sh int fa0/1 switch
Name: Fa0/1
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: On
Access Mode VLAN: 14 (VLAN_A)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
—output truncated—

IE answer:

interface FastEthernet0/1
 switchport access vlan 14
 switchport mode access

sw1(config-if)#do sh int fa0/1 swit
Name: Fa0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 14 (VLAN_A)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
—output truncated—

2.3 Etherchannel

Simple Etherchannel task.  This subtask is a red herring:

“Use the default native VLAN for this connection.”

Dot1q trunking uses VLAN 1 as the native VLAN by default, so no additional configuration is necessary:

sw1(config)#do sh int po1 trunk

Port        Mode         Encapsulation  Status        Native vlan
Po1         on               802.1q                   trunking      1

Since no channel-group protocol or number was specified in the task,  I used “on” and “1” respectively:

interface FastEthernet0/13
 switchport trunk encapsulation dot1q
 switchport mode trunk
 channel-group 1 mode on

2.3 Trunking

Be careful on this task.  They are asking for two distinct, non-contiguous dot1q trunks.  You can still use “interface range” to shave a little time off of this task though:

sw2(config)#int rang fa0/19,fa0/21
sw2(config-if-range)#swit tru en dot
sw2(config-if-range)#swit mod tru
sw2(config-if-range)#no shut

2.4 Etherchannel

Mind the order of operations for Layer 3 Etherchannels during this task.  The IE solution guide has a nice example of the correct order of operations.  Also, this task asks you to “use all remaining directly connected inter-switch links” between sw2 and sw3 as well as sw2 and sw4.  This gets a little difficult due to the initial configurations setting some of the connected ports in shutdown.  Unless you are given a layer 2 map with all of the inter-switch connections listed in the actual lab, this would be a pain in the ass as you would need to do a “no shut” ports on sw2, sw3, and sw4 to see the connections via “show cdp neighbor”.  Also note that both Layer 3 Etherchannels use a /25 (255.255.255.128) mask.  You’ll discover one of the two initial configuration errors during this task.

Internetwork Expert Volume III: Lab 1 – Section 1

1 Troubleshooting

First error:

I initially missed this error on my fly-by at the beginning of the lab, but caught it later on.  It was an SVI that had been configured with an incorrect second octet:

sw2(config)#do sh run int vlan82
interface Vlan82
 ip address 192.1.1.8 255.255.255.0
end

sw2(config)#int vlan82
sw2(config-if)#ip add 192.10.1.8 255.255.255.0

Second error:

The second error was a little more complicated, but easier to spot as you won’t be able to build your Layer 3 Etherchannels until you fix it.

As you try to configure a Layer 3 Etherchannel with the IP address and mask listed on the topology, you’ll encounter the following error:

sw2(config-if)#ip add 140.1.0.8 255.255.255.128
Bad mask /25 for address 140.1.0.8

If you take a look at the final octet of the address and the mask, you’ll find that the address is in the zero (140.1.0.0) subnet:

Address  .8    0|0001000
Mask     .128  1|0000000

This should not be a problem as “ip subnet-zero” is enabled by default:

ip subnet-zero

But, IE turned it off in the initial configuration:

sw2(config-if)#do sh run | i subnet-zero
no ip subnet-zero

sw2(config-if)#ip subnet-zero
sw2(config)#int po23
sw2(config-if)#ip add 140.1.0.8 255.255.255.128

Blog at WordPress.com.