Problem: EIGRP advertisements over Frame Relay

Hey all--

I'm hoping to get another set of eyes on this. Staring at my laptop has me going cross-eyed! I have set up a hub-and-spoke frame relay topology with EIGRP as my routing protocol. I am able to ping between the routers at layer 3. Each router has a loopback interface configured and the spokes are advertising to the hub just fine - But the hub isn't forwarding those advertisements back out to the spokes! I have disabled split horizon and used the 'broadcast' declaration on my frame relay mappings. I'm sure I'm missing something fundamental but I'm feeling burnt out at the moment. R1 is my hub, and R2 and R3 are the spokes - When I run "show ip route eigrp" one one spoke I don't see the other spoke's loopback interface. I'm mainly confused because the spoke routers are receiving advertisements for each others frame relay interfaces, just not their loopback interfaces.

I appreciate any help I can get - Thank you!

hostname R1 (hub)
!
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
shutdown
!
interface Serial0/0
ip address 10.1.1.1 255.255.255.0
no ip split-horizon
encapsulation frame-relay
frame-relay map ip 10.1.1.2 100 broadcast
frame-relay map ip 10.1.1.3 150 broadcast
!
router eigrp 1
network 1.1.1.1 0.0.0.0
network 10.1.1.1 0.0.0.0
no auto-summary
!
ip classless
!
!
line con 0
logging synchronous
line vty 0 4
login
!
!
!
end

Router 2 (Spoke)

hostname R2

!
!
interface Loopback2
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
shutdown
!
interface Serial0/0
ip address 10.1.1.2 255.255.255.0
no ip split-horizon
encapsulation frame-relay
frame-relay map ip 10.1.1.1 200 broadcast
frame-relay map ip 10.1.1.3 200 broadcast
!
router eigrp 1
network 2.2.2.2 0.0.0.0
network 10.1.1.2 0.0.0.0
no auto-summary
!
ip classless
!
line con 0
logging synchronous
line vty 0 4
login

!
end

R3 (Spoke)

hostname R3
!
interface Loopback3
ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
shutdown
!
interface Serial0/0
ip address 10.1.1.3 255.255.255.0
no ip split-horizon
encapsulation frame-relay
frame-relay map ip 10.1.1.1 300 broadcast
frame-relay map ip 10.1.1.2 300 broadcast
!
router eigrp 1
network 3.3.3.3 0.0.0.0
network 10.1.1.3 0.0.0.0
no auto-summary
!
ip classless
!
line con 0
logging synchronous
line vty 0 4
login
!
!
!
end

Topology.png

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

dead_p00l

I'm no frame relay or eigrp expert but i found this link that might be helpful.

Troubleshooting EIGRP Route Advertisement > Troubleshooting EIGRP

YFZblu

Thanks for the reply - I did enter "no ip split-horizon eigrp 1" on my hub serial interface - Still, no dice. I'll continue to check that document for something I missed.

YFZblu

I might be wrong, but if something like this popped up in a production environment they'd probably say "screw it" and implement subinterface point-to-point connections, and the split horizon issue would dissolve. That being said, I'm also wondering if this issue is just one of the joys of using Packet Tracer instead of actual hradware. I have hardware, but not enough T1 Serial ports to simulate frame relay...I might have to buy a 4 port serial module and hash this out with the real stuff...

spd3432

Getting out of packet tracer, how would you simulate the cloud? Not sure I've enough matching WICs to attempt this with my gear, but the cloud piece is going to be the stopper.

YFZblu

I've seen people here using routers to simulate the frame relay cloud - I haven't looked into the cloud config myself because I don't have a serial module with 4 or 5 serial interfaces to plug into the cloud router.

spd3432

Hmmm.... So a cloud router with 3 serial interfaces and 3 connected routers. I might be able to do that with a WIC-2T and WIC-1DSU-T1 for the cloud. Something to try later if I get a chance. Don't have enough WIC-1T / WIC-2T cards to bypass using the T1.

CodeBlox

Did you actually set up frame relay on the cloud in PT? You MUST do this in order for this to work. It's a little confusing at first to configure the FR cloud in PT but not extremely difficult.

Zartanasaurus

Couple quick things before I get to the answer.

1) You only need the broadcast keyword once per DLCI. On your spoke routers, the IPs are mapped to the same DLCI, so you only need the keyword once. On the hub router, since you're mapping to two DLCIs, you use broadcast twice.
2) Only the hub router is going to advertise updates out of the same interface they were received in. Therefore, you only need to disable split horizon on the hub's interface, not on the spokes also like you have.
3) The reason this isn't working is because split horizon wasn't disabled properly. For EIGRP, it's no ip split-horizon eigrp AS#. Your config would work fine for RIP, but it has to be disabled specifically for eigrp.

For verification, leave your config as is and do a debup ip eigrp on the hub router. Then clear ip eigrp neighbor on one of the spokes. On the hub you should see something like Int - 1.1.1.1/32 metric xxxxxx. The hub's loopback is being advertised to the neighbor that is reestablishing the adjacency. What you won't see is the other spoke router's loopback. Now disable split-horizon properly on the hub's interface and clear the neighbor from the spoke again. This time you'll see 1.1.1.1/32 and the other spoke's loopback being advertised with a metric.

Zartanasaurus

CodeBlox wrote: »

Did you actually set up frame relay on the cloud in PT? You MUST do this in order for this to work. It's a little confusing at first to configure the FR cloud in PT but not extremely difficult.

If his cloud wasn't set up properly, he wouldn't have anything under show ip route eigrp. He didn't state it specifically, but implied that he was seeing the hub's loopback on each spoke.

Zartanasaurus

YFZblu wrote: »

Thanks for the reply - I did enter "no ip split-horizon eigrp 1" on my hub serial interface - Still, no dice. I'll continue to check that document for something I missed.

It's not showing on your config. Maybe it's a quirk of PT?

YFZblu

Zartanasaurus --- I really appreciate your response. I went ahead and created the topology from scratch with your suggestions: One 'broadcast' declaration per DLCI, and I used the 'no ip split-horizon eigrp 1' on the hub router serial interface. Much to my frustration when I do a 'show run' on the hub router, it only shows "no ip split-horizon", when I didn't issue that command at all; I issued 'no ip split-horizon eigrp 1'. This is getting a little ridiculous...I'm starting to think this is a limitation of PT.

I'm using PT version 5.3.3.0019 for the record, in case anyone has experienced this type of thing before.

YFZblu

Zartanasaurus wrote: »

If his cloud wasn't set up properly, he wouldn't have anything under show ip route eigrp. He didn't state it specifically, but implied that he was seeing the hub's loopback on each spoke.

Correct

YFZblu

I went ahead and killed EIGRP, and implemented RIP2 - Success! Every network is being advertised successfully, and connectivity was tested.

I think I can conclude PT has issues using the 'no ip split-horizon eigrp [AS]' command.

Thank you for your help!

CodeBlox

I haven't done much Frame Relay configuration but are we sure these map statements are correct??

frame-relay map ip 10.1.1.1 300 broadcast
frame-relay map ip 10.1.1.2 300 broadcast

Shouldn't that be:

frame-relay map ip 10.1.1.1 100 broadcast
frame-relay map ip 10.1.1.2 200 broadcast

I suppose this would be dependent of how he set up the cloud but for some reason, it just doesn't "look right" to me.

When I use a global DLCI scheme in my configs, for something like this, I would only have 3 DLCIs, not 4 like in his. I understand that they are locally significant but I think the fourth (150) just makes things confusing.

One more thing, I've set up EIGRP over frame relay using PT without issues. I can make a topology in a bit if you'd like.

CodeBlox

I would say your mapping statements are wrong, some of them at least. I just made a eigrp over frame relay config in PT without issues. See below for config and take a look.

http://www4.zippyshare.com/v/85757801/file.html

Man, i was hard pressed to find a means of uploading surprisingly...

take a look at my routing/frame relay mappings for r1, both loopbacks show. Same case for the other two routers.

frame relay.jpg

YFZblu

That picture is pretty small, and when I enlarge it it becomes all pixels. I was able to get the topology to share all routes successfully by switching to RIPv2, so I hesitate to blame the map statements - Wouldn't I have issues with all routing protocols if my map statements were incorrect?

It is my understanding that when using Global DLCIs one is to map the remote IP address with the remote DLCI - But when using local DLCI's one is to map the remote IP address with the local DLCI.

CodeBlox

I'm reluctant to blame it on a flaw in PT(as I got this to work in my uploaded config), just throwing that out there. How is your cloud configured? Can you take snapshots of the interfaces as well as frame relay config? Did you download my config?

I sent you an email with my PT file.

Zartanasaurus

CodeBlox wrote: »

I'm reluctant to blame it on a flaw in PT(as I got this to work in my uploaded config), just throwing that out there. How is your cloud configured? Can you take snapshots of the interfaces as well as frame relay config? Did you download my config?

I sent you an email with my PT file.

You're doing something completely different than him. You have a full mesh design where R2 and R3 are directly connected via the Frame Relay switch. Change the config on the FR switch so there's only a 1-2 and 1-3 mapping and try again.

YFZblu

It turns out CodeBlox was using global DLCIs and was mapping remote IP's to remote DLCI numbers with the spokes. I went back and confirmed with CBTnuggets and Train Signal that in my topology I should be using remote IP's and local DLCI's - I understand DLCI's are always considered local, so I guess I'm using non-global DLCI's if that makes any sense...

Now that it works with RIPv2 configured, I think the problem comes down to 'no ip split-horizon eigrp 1' not showing in my "show run". Just a quirk in PT it seems.

CodeBlox

Zartanasaurus wrote: »

You're doing something completely different than him. You have a full mesh design where R2 and R3 are directly connected via the Frame Relay switch. Change the config on the FR switch so there's only a 1-2 and 1-3 mapping and try again.

If it's done like that, then shouldn't these be point-to-point interfaces? I was under the impression that since these all three were on the same subnet that it should be full mesh.

Zartanasaurus

CodeBlox wrote: »

If it's done like that, then shouldn't these be point-to-point interfaces? I was under the impression that since these all three were on the same subnet that it should be full mesh.

I'm guessing the point of the exercise was to teach him about split-horizon. In an ideal world you could design it without the need to disable it. But what could be and what you're handed aren't always the same.