From: Joseph Brunner (joe@affirmedsystems.com)
Date: Mon Nov 19 2007 - 02:46:41 ART
Guys,
I just labbed this up...
-my rack network is 1.1.0.0/16 where lab 11 was 187.x.0.0/16
-I used my r4 to fill in for their R5, but I made fully meshed pvc's on my
Frame switch
IHMO Brian's solution should have been (for task 3.8) to maintain the
requirement from task 3.7
"ensure that connectivity remains throughout the EIGRP domain if one of the
circuits between R2, R3, R5 goes down"
rack1r2#sh run | b router eigrp
router eigrp 1
network 1.1.2.2 0.0.0.0
network 1.1.20.2 0.0.0.0
network 204.12.1.2 0.0.0.0
auto-summary
eigrp stub connected summary
rack1r2#sh run int s0/0.235
Building configuration...
Current configuration : 284 bytes
!
interface Serial0/0.235 multipoint
ip address 1.1.20.2 255.255.255.0
ip summary-address eigrp 1 1.1.0.0 255.255.0.0 5
frame-relay map ip 1.1.20.2 203 broadcast
frame-relay map ip 1.1.20.3 203 broadcast
frame-relay map ip 1.1.20.4 204 broadcast
no frame-relay inverse-arp
end
With the summary in place, I take down the PVC between 4-3, forcing all
traffic for the eigrp domain to use 2 as a hub...
framesw(config)#int s0/1/0
framesw(config-if)#no frame-relay route 403 interface Serial0/2/0 304
framesw(config-if)#int s0/2/0
framesw(config-if)#no frame-relay route 304 interface Serial0/1/0 403
now, watch the action
R2 has the 1.1.24.x/24 subnet from R4
R2 has the 1.1.33.x/24 subnet from R3
rack1r2#sh ip route eigrp
1.0.0.0/8 is variably subnetted, 7 subnets, 3 masks
D 1.1.3.3/32 [90/46354176] via 1.1.20.3, 00:00:19, Serial0/0.235
D 1.1.4.4/32 [90/46354176] via 1.1.20.4, 00:00:39, Serial0/0.235
D 1.1.0.0/16 is a summary, 00:13:39, Null0
D 1.1.24.0/24 [90/46228736] via 1.1.20.4, 00:00:39, Serial0/0.235
D 1.1.33.0/24 [90/46228736] via 1.1.20.3, 00:00:19, Serial0/0.235
R3 & R4 just have the summary generated by R2, the EIGRP STUB Router and
R2's directly connected BB network.
rack1r3#sh ip route eigrp
1.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
D 1.1.0.0/16 [90/46354176] via 1.1.20.2, 00:01:09, Serial0/0.235
D 204.12.1.0/24 [90/46251776] via 1.1.20.2, 00:01:09, Serial0/0.235
So lets see if we can ping R3's lan from R4 and vice versa
rack1r3#ping 1.1.24.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.24.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
No, why?
rack1r4#debug frame packet
Frame Relay packet debugging is on
rack1r4#
1w0d: Serial0/0(i): dlci 402(0x6421), pkt type 0x800, datagramsize 70
rack1r4#
1w0d: Serial0/0(i): dlci 402(0x6421), pkt type 0x800, datagramsize 104
1w0d: DLCI 403 is either deleted or inactive
rack1r4#
1w0d: Serial0/0(i): dlci 402(0x6421), pkt type 0x800, datagramsize 104
1w0d: DLCI 403 is either deleted or inactive
rack1r4#
1w0d: Serial0/0(i): dlci 402(0x6421), pkt type 0x800, datagramsize 104
1w0d: DLCI 403 is either deleted or inactive
rack1r4#
1w0d: Serial0/0(i): dlci 402(0x6421), pkt type 0x800, datagramsize 104
1w0d: DLCI 403 is either deleted or inactive
R4 is still using its frame mapping to R3 via its direct PVC, which is now
DOWN!!!
rack1r4#sh run int s0/0
Building configuration...
Current configuration : 241 bytes
!
interface Serial0/0
ip address 1.1.20.4 255.255.255.0
encapsulation frame-relay
no fair-queue
frame-relay map ip 1.1.20.2 402 broadcast
frame-relay map ip 1.1.20.3 403
frame-relay map ip 1.1.20.4 402
no frame-relay inverse-arp
end
But we still have MET THE requirement (I would say!!!) the LAN's STILL HAVE
REACHIBILITY!!!!
rack1r3#ping 1.1.24.4 source f0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.24.4, timeout is 2 seconds:
Packet sent with a source address of 1.1.33.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 136/136/140 ms
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Gregory Gombas
Sent: Sunday, November 18, 2007 9:29 PM
To: Alex Steer
Cc: Cisco certification
Subject: Re: IE ver 4.1 vol2 lab 11 question 3.7 - 3.8
Hi Alex did you ever find the solution to this? I ran into same
problem, considering R2 is an EIGRP stub it will not re-advertise
routes learned from R5 to R3 and vice versa.
On Nov 17, 2007 9:28 AM, Alex Steer <alex.steer@eison.co.uk> wrote:
> Hi
>
>
>
> Has anyone else done this lab? R2,R3 and R5 are connected via a full
> mesh frame-relay cloud.
>
>
>
> I thought I had done it wrong as my solution to question 3.8
> (configuring r2 with eigrp stub) defeats the last part of question 3.7:-
>
>
>
> "Ensure that connectivity remains throughout the EIGRP domain if one of
> the circuits between r2,r3 and r5 goes down"
>
>
>
> I've checked the solution and it appears to be the same as what I have
> configured (namely eigrp stub on r2).
>
> Connectivity between r3 and r5 is broken if the frame-relay link between
> them is lost.
>
> Can anybody else shed some light on this please?
>
>
>
> Many thanks
>
>
>
> Alex
>
>
>
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Dec 01 2007 - 06:37:30 ART