CCIE Pursuit Blog

April 12, 2008

Internetwork Expert Volume III: Lab 5 – Section 5

Exterior Gateway Routing – 7 Points

5.1 BGP Peerings

IE solution is missing the peerings r4-sw3 and r4-sw4.

5.2 BGP Path Manipulation

“Using local-preference within AS 200, ensure that r4 is used as the exit point for all BGP prefixes learned from AS 100.”

To affect OUTBOUND routing (weight and local_pref) we will create a route-map and apply it INBOUND.

r4:
route-map LOCAL_PREF permit 10
 set local-preference 1000
!
router bgp 200
 neighbor 128.1.14.1 route-map LOCAL_PREF in

“AS 100 should use r5 as the entyr point for any routes advertised by AS 200.”

Basically the same thing as the first task, but configured on the peering between r1 (AS 100) and r5 (AS 200):

r1(config)#route-map LOCAL_PREF perm 10
r1(config-route-map)#set local-pre 1000
r1(config-route-map)#router bgp 100
r1(config-router)#neigh 128.1.125.5 route-map LOCAL_PREF in

5.3 Redistribution

“Redistribute sw2’s lo0 network (150.1.8.0/24) into EIGRP on r4.”
“Do not redistribute any other BGP routes into EIGRP.”

Yuck.

I really screwed this task up.  Here’s the IE solution:

ip prefix-list SW2_LOOPBACK seq 5 permit 150.1.8.0/24
!
route-map BGP->EIGRP permit 10
 match ip address prefix-list SW2_LOOPBACK
!
router eigrp 10
 redistribute bgp 200 metric 1 1 1 1 1 route-map BGP->EIGRP
!
router bgp 200
 bgp redistribute-internal

I did everything except “bgp redistribute-internal”

bgp redistribute-internal

Usage Guidelines
The bgp redistribute-internal command is used to configure iBGP redistribution into an IGP. The clear ip bgp command must be entered to reset BGP connections after this command is configured.

When redistributing BGP into any IGP, be sure to use IP prefix-list and route-map statements to limit the number of prefixes that are redistributed.

 

Internetwork Expert Volume III: Lab 5 – Section 4

Interior Gateway Routing – 25 Points

4.1 EIGRP

“Do not send multicast EIGRP updates within VLAN 14″

neighbor (EIGRP)

Remember that you need to configure this on both routers (unlike OSPF):

r1
router eigrp 10
 network 128.1.14.1 0.0.0.0
 no auto-summary
 eigrp router-id 150.1.1.1
 neighbor 128.1.14.4 FastEthernet0/0.2

r4
router eigrp 10
 network 128.1.14.4 0.0.0.0
 no auto-summary
 eigrp router-id 150.1.4.4
 neighbor 128.1.14.1 FastEthernet0/0

4.2 OSPF

Configure OSPF area 0.0.0.0.  This is just the dotted decimal equivalent of area 0.

r1(config-router)#do sh run | sec router os
router ospf 100
 router-id 150.1.1.1
 log-adjacency-changes
 network 128.1.136.1 0.0.0.0 area 0.0.0.0

r1(config-router)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/0.1      100   0.0.0.0        128.1.136.1/24     1     WAIT  0/0

4.3 OSPF

“Without enabling OSPF on r3’s interface fa0/0.2 or r6’s interface fa0/0.2, ensure that they will still receive OSPF routers from each other in the event that they lose their connectivity with r1.”

Basically, we need to make sure that r3 and r6 can communicate over their redundant LAN connection if the primary one fails.

I’m thinking that we can tunnel over that second LAN.  The only problem is that you’d need to an a new subnet to do this.  I peeked the solution guide and that exactly what they did, so I guess that it’s alright.

r6(config-router)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/0.1      100   0.0.0.0         128.1.136.6/24     1     DROTH 2/2
Tu0          100   0.0.0.0         128.1.63.6/24      11111 P2P   1/1

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.1.1         1   FULL/DR         00:00:31    128.1.136.1     FastEthernet0/0.1
150.1.3.3         1   FULL/BDR        00:00:32    128.1.136.3     FastEthernet0/0.1
150.1.3.3         0   FULL/  –        00:00:34    128.1.63.3      Tunnel0

r6(config)#int fa0/0.1
r6(config-subif)#shut
r6(config-subif)#do sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.3.3         0   FULL/  –        00:00:34    128.1.63.3      Tunnel0

4.4 OSPF

Configure OSPF on the PPPoFR network.

The current OPSF network type is point-to-point, which makes sense considering we’re running PPP.  :-)

r5(config-router)#do sh ip os int | i proto|Type
Virtual-Access2 is up, line protocol is up
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 1
Virtual-Template1 is down, line protocol is down
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 1
Virtual-Access1 is up, line protocol is up
  Process ID 100, Router ID 150.1.5.5, Network Type POINT_TO_POINT, Cost: 1

I’m going to need to change the network type because this is a hub-and-spoke network.  Let’s use point-to-multipoint:

r2(config)#int virtual-template 1
r2(config-if)#ip os net non-broadcast

After all is said and done:

r2#sh ip route os
     128.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    128.1.136.0/24 [110/3] via 128.1.125.5, 00:00:58, Virtual-Access1
O IA    128.1.63.0/24 [110/11114] via 128.1.125.5, 00:00:58, Virtual-Access1
O       128.1.125.1/32 [110/2] via 128.1.125.5, 00:00:58, Virtual-Access1

4.5 OSPF

Configure an OSPF stub area.  You’re also going to need a virtual-link as this new stub area is not connected to area 0 (or area 0.0.0.0 in this case :-) ).

r2(config-router)#area 125 virtual-link 150.1.1.1

r2(config-router)#do sh ip os int br
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
VL0          100   0               128.1.125.2/24     2     P2P   1/1
Gi0/0        100   12              128.1.27.2/24      1     BDR   1/1
Vi1          100   125             128.1.125.2/24     1     P2MP  1/1
Vt1          100   125             128.1.125.2/24     1     DOWN  0/0

sw1#sh ip route os
     128.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    128.1.136.0/24 [110/4] via 128.1.27.2, 00:00:40, Vlan72
O IA    128.1.63.0/24 [110/11115] via 128.1.27.2, 00:00:40, Vlan72
O IA    128.1.125.5/32 [110/2] via 128.1.27.2, 00:01:08, Vlan72
O IA    128.1.125.1/32 [110/3] via 128.1.27.2, 00:01:08, Vlan72
O IA    128.1.125.2/32 [110/1] via 128.1.27.2, 00:01:08, Vlan72
O*IA 0.0.0.0/0 [110/2] via 128.1.27.2, 00:01:08, Vlan72

Why all of the virtual-links in the IE solution guide?:

Task 4.5

4.6 OSPF

You’re asked to configure area 51 (hehe) between sw1 and bb2.  The problem is that this new area is non connected to area 0 and you cannot use a virtual-link because area 12 is a stub area.

Another tunnel?  Yup.

Steps:
1) Create tunnel through area 12.
2) Enable OSPF on the tunnel interfaces.  Place them in area 0 (0.0.0.0).

I had to ‘ip os mtu-ignore’ on tu0 on r2.

4.7 OSPF Loopback Advertisements

Advertise a bunch of loopbacks into a couple of non-existant areas.  If everything is configured correctly you should see all of the loopbacks on sw1:

sw1(config-router)#do sh ip route os | i 150.1.
     150.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
O IA    150.1.6.6/32 [110/11115] via 128.1.72.2, 00:00:09, Tunnel0
O IA    150.1.5.5/32 [110/11113] via 128.1.72.2, 00:00:09, Tunnel0
O IA    150.1.3.3/32 [110/11115] via 128.1.72.2, 00:00:09, Tunnel0
O IA    150.1.2.2/32 [110/11112] via 128.1.72.2, 00:00:09, Tunnel0
O IA    150.1.1.1/32 [110/11114] via 128.1.72.2, 00:00:09, Tunnel0

4.8 RIPv2

A straight-forward, easy task.  Thankfully!  :-)

4.9 Default Routing

Configure r4 to generate a default router to sw2 but not to r5.  Don’t use a distribute-list.

We can add a route-map to the ‘default-information-originate’ under the RIP process:

r4(config-router)#default-information originate ?
  route-map  Route-map reference
  <cr>

default-information originate (RIP)

So how do I write a route-map to only advertise to sw2?

r4(config-router)#do sh ip proto | sec Default version
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/1       2     2
    Dialer0               2     2

I want to send the default out fa0/1 and not dialer0 interface.

r4(config-route-map)#set ?
  interface         Output interface

route-map RIP_DEFAULT permit 10
 set interface FastEthernet0/1
!
router rip
 default-information originate route-map RIP_DEFAULT

sw2#sh ip route rip | i 0.0.0.0
R*   0.0.0.0/0
[120/1] via 128.1.48.4, 00:00:06, Vlan48

r5#sh ip route rip | i 0.0.0.0
r5# <-no default route on r5

4.10 Route Filtering

“Configure sw2 so that it will use the default route advertised by r4 to reach the 128.1.14.0/24 network.”
“Use an offset-list on sw2 to accomplish this task.”

This is just a wordy way of telling you to bitbucket the existing route to 128.1.14.0:

Before:
sw2#sh ip route 128.1.14.0
Routing entry for 128.1.14.0/24
  Known via “rip”, distance 120, metric 1
  Redistributing via rip
  Last update from 128.1.48.4 on Vlan48, 00:00:21 ago
  Routing Descriptor Blocks:
  * 128.1.48.4, from 128.1.48.4, 00:00:21 ago, via Vlan48
      Route metric is 1, traffic share count is 1

After:
access-list 71 permit 128.1.14.0 0.0.0.255
!
router rip
  offset-list 71 in 16 vlan48

sw2#sh ip route 128.1.14.0
% Subnet not in table
sw2#p 128.1.14.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 128.1.14.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

4.11 IGP Redistribution

Perform mutual redistribution on three different devices.  As with most of the Volume III labs, you may as well do the next task (the redistribution ‘gotcha’) at the same time.

4.12 Redistribution Loop Prevention

“Ensure that the RIP routes redistributed into EIGRP on r4 do not get passed back into RIP from OSPF on r5.”
“Use route tagging to accomplish this task.”

Sweet.  Route tagging is my preferred method.

So I’m going to tag RIP routes on r4 and then filter those same routes with r5:

r4#sh run | sec route-map RIP->EIGRP
 redistribute rip metric 1 1 1 1 1 route-map RIP->EIGRP
route-map RIP->EIGRP permit 10
 set tag 4120

r5#sh run | sec route-map RIP->OSPF
 redistribute ospf 100 metric 1 route-map RIP->OSPF
route-map RIP->OSPF deny 10
 match tag 4120
route-map RIP->OSPF permit 20

Everything was working fine except for 128.1.14.4 (f0/0 on r1).  I finally had to filter this route from passing to OSPF on r1 and everything was fine.

r1#sh run | sec 128_|EIGRP->OSPF
 redistribute eigrp 10 subnets route-map EIGRP->OSPF
ip prefix-list 128_1_14_0 seq 5 permit 128.1.14.0/24
route-map EIGRP->OSPF deny 10
 match ip address prefix-list 128_1_14_0
route-map EIGRP->OSPF permit 20

This didn’t break the requirements of the task, but I still bothered that I couldn’t figure out why this address was unreachable.

The IE solution guide is a mess for these tasks:

Task 4.13

The task asks you to use route tags to accomplish this task but the IE solution shows r5 changing the AD for OSPF external routes???

r5:
router ospf 1
 distance ospf external 121

 

April 9, 2008

Status Update: 31 March – 06 April

I guess that it was to be expected, but I fell off of the wagon a bit this week.  Spring rolled into Minnesota this weekend (and it seems to have rolled right back out again).  Not only was I burned out by the hours that I had put in the last two weeks, but the weather and housework conspired against me.

I didn’t have enough time on Sunday to complete a full Volume II lab, so decided to do Volume III lab 5.  I usually fly through these labs (except for IGP redistribution) so I figured that I would limit myself to 4 hours and knock this sucker out.  Let’s just say that lab 5 wasn’t the sucker that got knocked out.  :-)

After 4 hours I had just reached IGP redistribution.  Ouch!!!  There wasn’t anything that I hadn’t seen before, just a lot of ‘unique’ tasks and more of them.  It was a humbling experience.

Here are my goals from last week: Review the IEATC IPv6 and BGP videos.  Redo Volume II lab 9.  Do Volume III lab 6.

I did manage to redo most of Volume II lab 9.  I found this to be a pretty tough lab as well.  I completed the IPv6 videos (I feel a lot better about my IPv6 skills now) and did (most of) Volume III lab 5, not lab 6.

Here are my goals this week: Review BGP videos.  Finish Volume III lab 5.  Redo Volume II lab 10.  Start redoing the Volume I BGP labs.

Days Until Lab: 103
Days Until Mock Lab 2: 14
Days Until Mock Lab Workshop: 68
Readiness (1 to 10): 6
Lab Hours This Week 10
Study Hours This Week (estimate): 12

Internetwork Expert Volume III: Lab 5 – Section 3

WAN Technologies – 9 Points

3.1 Hub and Spoke

Strange task:

“Configure a Frame Relay connection between r1, r2, and r5 using multipoint subinterfaces on each router.”
“Do not use Inverse-ARP or more than on frame-relay map command on each router.”

I’m having trouble with only using one frame map statement on r5 (hub).  Can I use PPPoFR?

Hellz yeah I can!!!

I eventually got this correct, but I spent a ton of time running through all of the different varations of Frame Relay in my head and I couldn’t produce on that only used one frame-relay map statement on the hub.  This is a case of me reading too little into the question (it never stated that you needed to use exacly one map, just one or less) as well as not being confident of my PPPoFR implementation.  In the end, you won’t use any frame-relay map statements on any of the routers.

3.2 PPPoFR

More fun with PPPoFR.  Much easier than the last task though.  :-) 

Your connection will not come up until you configure PPP authentication so you may as well skip ahead to task 3.4 right away.

3.3 PPP

“Configure PPP on the Serial connection between r4 and r5 using dialer interfaces.”

Wow.  I had to peek the solution on this one as I haven’t done anything with dialers for ages.

r4(config-if)#do sh run | sec l0/1|Dialer
interface Serial0/1
 no ip address
 shutdown
 dialer in-band
 dialer pool-member 1

 pulse-time 1 <-IOS throws this on by default
interface Dialer0
 ip address 128.1.45.4 255.255.255.0
 encapsulation ppp
 dialer pool 1
 dialer idle-timeout 0
 dialer persistent

In the lab I would have just used PPP encapsution on the links and moved on.  I would have tried to get the points at the end of the lab if I had time.

dialer pool

dialer persistent

dialer pool-member

dialer in-band

r5#sh dialer

Se0/1 – dialer type = IN-BAND SYNC NO-PARITY
Dialer pool 1, priority 0
Idle timer (never), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is data link layer up
Interface bound to profile Di0
Time until disconnect never

Connected to <unknown phone number>

Di0 – dialer type = DIALER PROFILE
Idle timer (never), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dialer state is data link layer up
Number of active calls = 1

Dial String      Successes   Failures    Last DNIS   Last status
r5#

3.4 PPP Authentication

Authenticate the PPPoFR connection we configured in task 3.2 using PAP.  r6 should not authenticate BB1.

interface Serial0/0
 no ip address
 encapsulation frame-relay
 frame-relay interface-dlci 301 ppp Virtual-Template1
!
interface Virtual-Template1
 ip address 54.1.8.6 255.255.255.0
 ppp authentication pap
 ppp pap sent-username ROUTER6 password 0 CISCO

That’s not working:

*Mar  8 03:56:12.058: Vi1 PAP: Using hostname from interface PAP
*Mar  8 03:56:12.058: Vi1 PAP: Using password from interface PAP
*Mar  8 03:56:12.058: Vi1 PAP: O AUTH-REQ id 11 len 18 from “ROUTER6″
*Mar  8 03:56:12.062: Vi1 PAP: I AUTH-REQ id 11 len 14 from “BB1″
*Mar  8 03:56:12.062: Vi1 PAP: Authenticating peer BB1
*Mar  8 03:56:12.062: Vi1 PPP: Sent PAP LOGIN Request
*Mar  8 03:56:12.062: Vi1 PPP: Received LOGIN Response FAIL
*Mar  8 03:56:12.062: Vi1 PAP: O AUTH-NAK id 11 len 26 msg is “Authentication failed”

No clue.  I looked at the solution guide and the only difference was that IE did not use ‘ppp authentication pap’

r6(config)#int virtual-tem 1
r6(config-if)#no ppp authen pap
r6(config-if)#
*Mar  8 04:28:40.518: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up

*Mar  8 04:29:28.846: Vi1 PPP: Using default call direction
*Mar  8 04:29:28.846: Vi1 PPP: Treating connection as a dedicated line
*Mar  8 04:29:28.846: Vi1 PPP: Session handle[BA0003AB] Session id[934]
*Mar  8 04:29:28.846: Vi1 PPP: Authorization required
*Mar  8 04:29:44.958: Vi1 PPP: No authorization without authentication
*Mar  8 04:29:44.958: Vi1 PAP: Using hostname from interface PAP
*Mar  8 04:29:44.958: Vi1 PAP: Using password from interface PAP
*Mar  8 04:29:44.958: Vi1 PAP: O AUTH-REQ id 166 len 18 from “ROUTER6″
*Mar  8 04:29:44.962: Vi1 PAP: I AUTH-ACK id 166 len 5
*Mar  8 04:29:45.962: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up

Really??? That was the issue?

Ummm….of course it was.  DOH!!!  I can’t believe that I fucked this up.  One of the requirements is that r6 should not authenticate BB1.  By configuring ‘ppp authentication pap’ on r6 that is exactly what I was trying to do.  Another time-wasting task.  This one was my fault though. 

 

Internetwork Expert Volume III: Lab 5 – Section 2

Bridging and Switching – 9 Points

2.1 Trunking

Very easy trunking task.  You just need to make sure at least one side of each trunk link is in dynamic desirable mode.

The eternal question: What to do about all of the other dynamically created trunks?

In the solution guide the other trunks (negotiated via DTP on the connections between the 3560s and the 3550s) do not appear in the verification commands.  For this lab, I went ahead and shut them all down.

2.2 VLAN Assignment

VTP is already configured (all switches are in VTP server mode in the vtp domain ‘CCIE’).  You are tasked to build all of the VLANs from the diagram.

Weird:

sw1(config-if)#do sh cdp nei f0/3
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
                  S – Switch, H – Host, I – IGMP, r – Repeater, P – Phone

Device ID            Local Intrfce         Holdtme   Capability    Platform   Port ID
r3                  Fas 0/3               120           R S I     2651XM    Fas0/0
r3                  Fas 0/3               10            R S I     2651XM    Fas0/0.1

This occured soon after I configured router-on-a-stick on r3.  I’ve never seen CDP use a subinterface as a neighbor interface.  Time to clear the cdp table:

clear cdp table

sw1(config-if)#do sh cdp nei f0/3
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
                  S – Switch, H – Host, I – IGMP, r – Repeater, P – Phone

Device ID            Local Intrfce         Holdtme   Capability    Platform   Port ID
r3                  Fas 0/3               178           R S I     2651XM    Fas0/0

Ah.  Much better.

The lab diagram does not show which ethernet port on r2 is connected to VLAN 72.  It must be 0/0 as that interface is already configured with an IP address in VLAN 72.

Weird.  All of the switches are int vtp domain CCIE and all are VTP servers.  Trunking is established between all of the switches.  Yet I am not seeing VLANs propagating via VTP:

sw1:
sw1(config-if)#do sh vtp status
VTP Version                     : 2
Configuration Revision          : 3
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 11
VTP Operating Mode              : Server
VTP Domain Name                 : CCIE

VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Disabled
VTP Traps Generation            : Disabled
MD5 digest                      : 0x4E 0xE7 0xBF 0xB8 0x71 0x10 0xF6 0xB4
Configuration last modified by 128.1.27.7 at 3-1-93 15:57:04
Local updater ID is 128.1.27.7 on interface Vl27 (lowest numbered VLAN interface found)

sw2:
sw2(config-if)#do sh vtp status
VTP Version                     : 2
Configuration Revision          : 3
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 8
VTP Operating Mode              : Server
VTP Domain Name                 : CCIE

VTP Pruning Mode                : Disabled
VTP V2 Mode                     : Disabled
VTP Traps Generation            : Disabled
MD5 digest                      : 0x9C 0x35 0x84 0x20 0x54 0x5D 0x0C 0xEB
Configuration last modified by 128.1.48.8 at 3-1-93 16:03:37 <-Interface on sw2
Local updater ID is 128.1.48.8 on interface Vl48 (lowest numbered VLAN interface found) 

sw1(config-if)#do sh vtp pass
VTP Password: CISCO

sw2(config-if)#do sh vtp pass
VTP Password: CISC0

Sneaky IE bastards.  I looks like sw2’s password ends with a zero.  I went to each switch and set the vtp password to ‘CISCO’ and vlans started flowing again.

This lab has three “router-on-a-stick” setups to configure.

The IE solution guide shows VLAN 10 configured for some reason.  It’s not in this network though.

I later found vlan 10.  It’s on sw4.  It was not included in my initial config for sw4.  I should have caught this during my intial troubleshooting.

I am also not sure that we need to create VLAN 109 and apply it to the L2 ends of the routed links because in the next task we are using L2 tunneling to make those links think that they are directly connected.  I have full connectivity without VLAN 109, but we’ll see if that gives me issues later.

If this were the real lab, I’d just go ahead and configure VLAN 109 as there is no “minimum number of VLANs” requirement for this task.

2.3 Layer 2 Tunneling

“Configure sw2 so that sw3 and sw4 see each other as CDP neighbors across the routed link that connects them.”

I need to tunnel interfaces fa0/16 and fa0/19

Before:
sw3#sh cdp nei fa0/16
| b Dev
Device ID            Local Intrfce         Holdtme   Capability    Platform   Port ID
sw2                 Fas 0/16              178            S I      WS-C3560-4 Fas0/16

sw4#sh cdp neigh fa0/16 | b De
Device ID            Local Intrfce         Holdtme   Capability    Platform   Port ID
sw2                 Fas 0/16              151            S I      WS-C3560-4 Fas0/19

After:
sw3#sh cdp neigh fa0/16
| b De
Device ID            Local Intrfce         Holdtme   Capability    Platform   Port ID
sw4                 Fas 0/16              151            S I      WS-C3550-2 Fas0/16

sw4#sh cdp nei fa0/16 | b De
Device ID            Local Intrfce         Holdtme   Capability    Platform   Port ID
sw3                 Fas 0/16              170            S I      WS-C3550-2 Fas0/16

sw4#p 128.1.109.9

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

 

Internetwork Expert Volume III: Lab 5 – Section 1

Troubleshooting – 2 Points

There are two faults in the initial configurations.  I actually found three and the one that was not listed in the IE Solution Guide was the most devious of the three.

1)  sw3 and sw4 both have an intitial configuration error on their fa0/16 interfaces:

interface FastEthernet0/16
 ip address 128.1.109.9 255.255.255.0

The “no switchport” command for is needed for these routed interfaces.  Without this command, IOS chokes on the ‘ip address’ command and you’re left with an ordinary L2 interface.

2)  Incorrect IP addresses on SVIs on sw1:

sw1(config)#do sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
Vlan27                 128.1.27.7      YES manual up                    up
Vlan72                 192.10.1.7      YES manual up                    up
Loopback0              150.1.7.7       YES manual up                    up

You just need to swap the IP addresses.

3)  VTP password on sw2 is CISC0 (last character is a zero) rather than CISCO.  This is the fault that is not listed in the solution guide.  I occurs on only one switch, and that switch is the only one that has trunking to the other three switches, so if this was an unintended fault, it was a doozy.   :-)

 

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!!!

March 6, 2008

Status Update: 11 February – 02 March

It’s been a long time since I have penned a status update.  I’ve been absolutely overwhelmed at work.  We have an annual “freeze period” that coincides with our company’s busiest time of the year (I have no idea what we’re so busy doing, I just push ones and zeros).  This means that at the end of the calendar year we have a nice 4 – 6 week period in which only emergency changes can be made.  The bad part is that as soon as the freeze is done we get bombarded with work.  I’m just starting to dig out of that mess.

My lab time has dropped off over the last couple of weeks for two reasons: I am exhausted after long hours in the office, and I have decided to make another pass through the IEATC lessons.  I really need to solidify my understanding of the technologies on the lab.  So far I’ve gone over stuff that I’m really good at (Frame Relay and Switching).  Even though these are the technologies that I am strongest in, I still (re)discover bits and pieces in the IEATC videos.  I will try to get through most of OSPF this week.  Next week will be the technologies that I am weakest in (BGP, Multicast, and IPv6).

I’m getting “lab withdrawal” symptoms, so I will be interspersing some of the Volume III labs with the IEATC this weekend.  I hope to complete all of the IEATC lessons by the end of next week.  The week after that (17 – 23 March) I have dubbed “Labapalooza”.  I am taking the week off from work and will be attempting to complete as many of the Volume II and III labs as I can during that week.

My lab date has changed yet again.  I will be attending the Internetwork Expert Mock Lab Workshop in Reno from 16 – 20 June.  As I mentioned in this post, I will schedule my lab date 28 days past the end of the workshop.  My new target date is 21 July.  While I am bummed that this new dates means that I am going to lose a good chunk of my summer to my CCIE pursuit, it does mean that I get more time to study. 

Scheduling the Mock Lab Workshop has left my “CCIE Wish List” nearly empty.  The only thing that I will definitely be purchasing between now and my exam is the Cisco Assessor labs.  Other than that, I may try to pick up a lab book from another vendor (just to get the experience of a different topology/testing style).  I may also pick up a mock lab from another vendor for the same reasons.  Those two things will depend on my funds and perceived necessity at the time.

I’m disappointed that I dropped the ball on posting weekly status updates for the last couple of weeks.  I use these updates to motivate/guide myself.  If I take the time to write them up and post them, then it makes me that more inclined to do what I’ve laid out.

Anyhoo…here are my goals for the remainder of this week: Finish up (at least) the first week OSPF videos.  Redo the first 3 Volume III labs.

Days Until Lab: 137
Days Until Mock Lab 1: 20
Days Until Mock Lab Workshop: 102
Readiness (1 to 10): 2
Lab Hours This Week 0
Study Hours This Week (estimate): 15

February 11, 2008

Status Update: 04 – 10 February

Last week started out pretty well, but I had to write off my second weekend in a row.  This time it was because the temperature here was barely above absolute zero (at least it felt that way).  I spent one day mucking with our cars.  One day after bragging that my car ALWAYS starts, I spent a good chunk of time trying to get it to start.  I didn’t park in the garage and the next morning it was around -40 degrees and my car would not start.  My wife’s car also had a cold-induced flat tire.  So I got to change her tire as well.  On Sunday we had friends over so that day was scratched as well.

I still got 12 hours on the rack during the week, so I still felt pretty good about my progress.

Here are my goals from last week: 

Do Volume II lab 1.  Read OSPF chapter in Routing TCP/IP.  Redo Volume III lab 1.

I finished all of my goals this week.  I did Volume II lab 1 as a simulated lab.

Goals for this week:  Do Volume II lab 12.  Redo Volume II lab3.  Do Volume III lab 5. 

Days Until Lab: 117
Readiness (1 to 10): 2
Lab Hours This Week 12
Study Hours This Week (estimate): 3

January 27, 2008

Internetwork Expert Volume III: Lab 4 – Section 5

Exterior Gateway Routing – 6 Points

5.1 BGP Peerings

This was a pretty easy BGP peering task.  You need to set up a confederation, so you’ll need to be familiar with:

bgp confederation identifier

bgp confederation peers

I did mess up a little bit. I configured “neighbor 150.1.5.5 ebgp-multihop” on r4.

r4 (AS 100) <— r6 (no BGP) —> bb1 (AS 54)

It turns out that I don’t need this command because r6 is bridging, not routing.

neighbor ebgp-multihop

I also missed “neighbor 152.1.37.3 next-hop-self” on sw1, but I did eventually catch that error when I found that I was not installing the bb2 routes on r3:

Without “neighbor 152.1.37.3 next-hop-self” on sw1:

r3#sh ip route bgp
B    119.0.0.0/8 [200/0] via 152.1.125.5, 00:28:44
B    118.0.0.0/8 [200/0] via 152.1.125.5, 00:28:44
B    117.0.0.0/8 [200/0] via 152.1.125.5, 00:28:44
B    116.0.0.0/8 [200/0] via 152.1.125.5, 00:28:44
B    115.0.0.0/8 [200/0] via 152.1.125.5, 00:28:44
B    114.0.0.0/8 [200/0] via 152.1.125.5, 00:28:44
B    113.0.0.0/8 [200/0] via 152.1.125.5, 00:28:44
B    112.0.0.0/8 [200/0] via 152.1.125.5, 00:28:44

r3#sh ip bgp | i Network|192.10.1.254
   Network          Next Hop            Metric LocPrf Weight Path
*  205.90.31.0      192.10.1.254             0    100      0 (7000) 254 ?
220.20.3.0       192.10.1.254             0    100      0 (7000) 254 ?
*  222.22.2.0       192.10.1.254             0    100      0 (7000) 254 ?

r3#sh ip route 192.10.1.254
% Network not in table

With “neighbor 152.1.37.3 next-hop-self” on sw1:

r3#sh ip route bgp
B    119.0.0.0/8 [200/0] via 152.1.125.5, 00:30:15
B    118.0.0.0/8 [200/0] via 152.1.125.5, 00:30:15
B    222.22.2.0/24 [200/0] via 152.1.37.7, 00:00:15
B    117.0.0.0/8 [200/0] via 152.1.125.5, 00:30:15
B    220.20.3.0/24 [200/0] via 152.1.37.7, 00:00:15
B    116.0.0.0/8 [200/0] via 152.1.125.5, 00:30:15
B    115.0.0.0/8 [200/0] via 152.1.125.5, 00:30:15
B    114.0.0.0/8 [200/0] via 152.1.125.5, 00:30:15
B    113.0.0.0/8 [200/0] via 152.1.125.5, 00:30:15
B    112.0.0.0/8 [200/0] via 152.1.125.5, 00:30:15
B    205.90.31.0/24 [200/0] via 152.1.37.7, 00:00:15

r3#sh ip bgp | i Network|152.1.37.7
   Network          Next Hop            Metric LocPrf Weight Path
*> 205.90.31.0      152.1.37.7               0    100      0 (7000) 254 ?
*> 220.20.3.0       152.1.37.7               0    100      0 (7000) 254 ?
*> 222.22.2.0       152.1.37.7               0    100      0 (7000) 254 ?

r3#sh ip route 152.1.37.7
Routing entry for 152.1.37.0/24
  Known via “connected”, distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via FastEthernet0/0
      Route metric is 0, traffic share count is 1

5.2 BGP Bestpath Selection

“Configure the network so that AS 100 routes through r1 to reach prefixes originated in AS 254.”
“Use MED to accomplish this.”

set metric (BGP, OSPF, RIP)

I had the right idea for this task, but I boned it up.  IE used an aggregate-address on sw1 to ensure reachability to all networks advertised by the backbone routers.  They have a short writeup to explain their method.

aggregate-address

I REALLY need to study BGP some more.

Next Page »

The Rubric Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 113 other followers