Routing propagation problem over frame relay..

pogue

I know this is just a tad bit out of the scope of the CCNA, but I came upon this problem while working through some frame relay labs..

Scenario:

I have three routers in a full mesh configuration, all can ping each other, and after a great struggle, I have gotten EIGRP tables to propogate, to a certain extent. Weird thing is...One of the routers in my mesh is not getting EIGRP updates from one of the others..

RouterA


interface Ethernet0
ip address 172.16.9.1 255.255.255.0
no ip directed-broadcast
!
interface Serial0
ip address 10.10.2.1 255.255.255.0
no ip directed-broadcast
no ip mroute-cache
no fair-queue
clockrate 4000000
!
interface Serial1
ip address 172.16.2.1 255.255.255.0
ip directed-broadcast
encapsulation frame-relay
frame-relay lmi-type ansi


router eigrp 1
network 10.0.0.0
network 172.16.0.0
no auto-summary

Note that RouterA is only getting routing updates from the third router, but not RouterB

Russ#sho ip rou

172.16.0.0/24 is subnetted, 3 subnets
D 172.16.8.0 [90/2172416] via 172.16.2.3, 00:36:39, Serial1
C 172.16.1.0 is directly connected, Loopback1
C 172.16.2.0 is directly connected, Serial1

RouterB


interface Ethernet0
ip address 172.16.9.1 255.255.255.0
no ip directed-broadcast
!
interface Serial0
ip address 10.10.2.1 255.255.255.0
no ip directed-broadcast
no ip mroute-cache
no fair-queue
clockrate 4000000
!
interface Serial1
ip address 172.16.2.1 255.255.255.0
ip directed-broadcast
encapsulation frame-relay
frame-relay lmi-type ansi
!
interface TokenRing0
no ip address
no ip directed-broadcast
shutdown
!
router eigrp 1
network 10.0.0.0
network 172.16.0.0
no auto-summary

RouterB#sho ip rou

(The two bolded routes are not showing up in RouterA's routing table.)

172.16.0.0/24 is subnetted, 4 subnets
D 172.16.8.0 [90/2172416] via 172.16.2.3, 00:28:38, Serial1
C 172.16.9.0 is directly connected, Ethernet0
D 172.16.1.0 [90/2297856] via 172.16.2.2, 00:28:40, Serial1
C 172.16.2.0 is directly connected, Serial1

Notice that RouterB IS learning routes from RouterA, though!

So, in essence, all the router are playing nicely, except one router is not taking updates from one other router, and otherwise, everyone is exchanging info.

Any ideas? Like I said, I know it's not really within the scope of the CCNA, but it is driving me crazy.

All 6 PVCs are up and running. PVC status ACTIVE.

I am so confused...

Russ

jovan88

i see you're not using sub interfaces so i would turn off split horizon, also take a look if your frame relay mappings have the broadcast keyword

kryolla

he has a full mesh so split horizon should be enabled

(The two bolded routes are not showing up in RouterA's routing table.)

172.16.0.0/24 is subnetted, 4 subnets
D 172.16.8.0 [90/2172416] via 172.16.2.3, 00:28:38, Serial1
C 172.16.9.0 is directly connected, Ethernet0
D 172.16.1.0 [90/2297856] via 172.16.2.2, 00:28:40, Serial1
C 172.16.2.0 is directly connected, Serial1

Router A has those 2 routes as directly connected but when you sh ip route e0 is not in there so troubleshoot that but it should be there as directly connected

interface Ethernet0
ip address 172.16.9.1 255.255.255.0
no ip directed-broadcast

interface Serial1
ip address 172.16.2.1 255.255.255.0
ip directed-broadcast
encapsulation frame-relay
frame-relay lmi-type ansi

pogue

jovan88 wrote: »

also take a look if your frame relay mappings have the broadcast keyword

????

Both of the shown routing tables have a "D" in them, so broadcast must be enabled on both, otherwise no EIGRP routes would have propagated...

Russ

pogue

kryolla wrote: »

Router A has those 2 routes as directly connected

Oooooppps.

That is most likely the reason.

Of course, RouterA will not accept a routing update for a route it is directly connected to. D'oh.

I was REALLY tired last night whilst working this frame relay lab, as I am trying to push through and possibly take the ICND2 tommorrow. I don't have anything hooked up to RouterA's E0 port, so I will hook it up to a switch to get it up/up, change the ip address to a class C not currently being used in my network, and see if it propogates.

I was struggling mightily with frame relay concepts until the wee hours of the morn today, and I just kept hammering away at it until it "clicked", and then I missed something silly because I'd been up for 20 hours.

Thanks for the fresh set of eyes.

I do have one more question, though. Is there some general rule to know when you have to use the distant DLCI in your command, (frame-relay map or frame-relay interface) and when you have to use your own DLCI? I am just not getting the concept from either one of my books, and I KNOW it is gonna come up in the exam.

Russ

luke_bibby

LAPF headers only have a single DLCI address field which, when it leaves the source host, indicates the other end of the PVC. So the DLCI configured on the subinterfaces will indicate the OTHER end of the PVC

jovan88

kryolla wrote: »

he has a full mesh so split horizon should be enabled

You're right I just skimmed thru it and thought he was using a hub and spoke design, apologies!