Frame relay and OSPF issues.

AlexMR

I have a hub and two spokes and they are forming adjancencies. The problem is their state keeps going down for a few seconds and then comes back to full after a few sseconds.

I dont have a clue as to what the reason may be.

This is all under GNS3. Something that call my attention was that i had to configure all OSPF interfaces with ip ospf network point-to-multipoint, in order to get connectivy from one spoke to the other. What was even more strange was the fact that I had adjacencies between both spokes and the hub and spokes were receiving routing updates from each other, but were not able to ping beyond the hub.

I am doing the labs in the Chris Bryant study material and he asks to use the ip ospf network non-broadcast interface configuration command in all participating OSPF interfaces. As I said, that way I got the routers to exchange routing information but they couldnt ping beyond the interfaces of the hub.

What could be the cause of the adjacencies going to down and then back to full? I dont have a clue...

Cyclades

I am not an expert but .....

Are you using sub-interface ?

If you are using sub-interfaces also map the DLCI values. " frame-relay map-ip <neighbor ip> <DLCI> non-broadcast " for each neighbor at the interfaces of the Hub.

The " ip ospf network point-to-multipoint non - broadcast " option is only when you are going for SVC's where you don't want the dial-up interfaces to come up unwanted. and when you use non-broadcast you should also specify the neighbors manually.

wirerat

I have noticed before when using GNS3/Dynamips and the cpu is being overworked that you will start to lose adjacency with whichever routing protocol you are using. I would assume it is due to packets not being sent due to no cpu cycles. I don't think this would be your problem if you are only using three routers. Have you put in your idlepc value yet?

pureblue

if the hub is a point-to-multipoint interface,
check frame-relay mappings and make sure they are "broadcast".
If you've done manual mappings, instead of letting inverse-arp do it, I think you might have forgot the "broadcast" on one spoke.

AlexMR

i started watching debugs with debug ip ospf events and it was obvious R1, the hub, was not receiving hellos from the problem spoke, r3. There was no problem with Re, the second spoke so I basically compared both configurations and the only thing different that might have something to do was the frame relay mapping. I remember having read that in frame map ip <remote ip> (local dlci> [broadcast,cisco,etc] interface config command, broadcast was the default option, and i ddint used it in that specific interface. That was the problem. As soon as I used broadcast in the mapping the link remained up and the hellos were received by the hub.

Thanks for your contribution.