ospf over frame relay curious behaviour

marco_fera

Hi, I was playing with ospf network types for frame relay. I noticed a curious thing with non-broadcast type.
I've got three routers as in topology

Tutorial: OSPF Network Types and Frame Relay Part 1 » ardenpackeer.com

Router 1 needs to have neighbor statements for adjacencies to come up, then I can cancel those neighbor statements and my adjacencies will still be up! in fact even if I clear ospf process on r1 I still have adjacencies up as long as r1 receives hellos from r2 and r3. Also, if I configure minimal dead timers (with sub-second hellos), it's practically impossible to tear down adjacencies by clearing ospf process on all 3 routers simply because I'm not fast enough to issue the command: everytime I do the command on one device that device still receives hellos from the others. The result is that theoretically one could find a configuration where there's nbma network types, no neighbours configured on the dr, and still have adjacencies up!
Now I was just wondering if this is the correct behaviour of ospf per rfc, or if it is my dynamips or my image (c3640-jk9o3s-mz.124-12) which are broken.

Awaiting for your opinion gents.


Take a look at my final configs:

R1
interface Serial1/0
ip address 192.168.1.1 255.255.255.0
encapsulation frame-relay
ip ospf hello-interval 5
serial restart-delay 0
end

router ospf 1
log-adjacency-changes
passive-interface FastEthernet0/0
network 0.0.0.0 255.255.255.255 area 0

---

R2
interface Serial1/0
ip address 192.168.1.2 255.255.255.0
encapsulation frame-relay
ip ospf hello-interval 5
ip ospf priority 0
serial restart-delay 0
end

router ospf 1
log-adjacency-changes
passive-interface FastEthernet0/0
network 0.0.0.0 255.255.255.255 area 0

---

R3
interface Serial1/0
ip address 192.168.1.3 255.255.255.0
encapsulation frame-relay
ip ospf hello-interval 5
ip ospf priority 0
serial restart-delay 0
end

router ospf 1
log-adjacency-changes
passive-interface FastEthernet0/0
network 0.0.0.0 255.255.255.255 area 0

---

R1#sh ip ospf nei

Neighbor ID Pri State Dead Time Address Interface
192.168.1.2 0 FULL/DROTHER 00:00:17 192.168.1.2 Serial1/0
192.168.1.3 0 FULL/DROTHER 00:00:15 192.168.1.3 Serial1/0

jason_lunde

just remembered a similiar thread...
http://www.techexams.net/forums/ccie/53459-ospf-over-fr-non-broadcast.html

marco_fera

jason_lunde wrote: »

just remembered a similiar thread...
http://www.techexams.net/forums/ccie/53459-ospf-over-fr-non-broadcast.html

Yep I didn't see it. Well ok, that guy stumbled upon the same thing, but still I don't understand if this is per rfc: it's ok that dead timer does not expire on the hub since the spokes still send hellos, but the spokes are supposed to reply to hellos sent by the hub; however the hub should not be able to send hellos if he doesn't have neighbor statements, while in this case the hub also replies to hellos sent by the spokes. It seems a benign bug.

marco_fera

Another curious thing is with non-broadcast network type: I configured the spokes with priority 0, then I put the neighbor statements on these spokes. Well, due to the priority being 0 the "neighbor" line does not show up in the configuration, as if it was not accepted

R3(config-router)#neighbor 192.168.1.1


router ospf 1
router-id 3.3.3.3
log-adjacency-changes
passive-interface FastEthernet0/0
network 0.0.0.0 255.255.255.255 area 0

As soon as I configure the line I get this message

*Mar 1 00:11:13.123: %OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.0 on Serial1/0 from ATTEMPT to DOWN, Neighbor Down: Dead timer expired

The neighborship stays in that state for some time (a couple of minutes), and then all of a sudden - pouf! - I see hellos sent from the spokes to the hub and neighborships coming up and remaining stable.
It's like the "neighbor" command triggered something, but I can't imagine exactly what. Has anyone else experienced this?

M

marco_fera

Hi, I've noticed another curious thing. Sorry for the long post and the many outputs.

When using broadcast type you have to specify a frame relay map with broadcast keyword, otherwise you get encapsulation failure for multicast address 224.0.0.5
The funny thing is that you can put ANY ip address with broadcast keyword and the ospf will take it for good!

The topology is from this lab

Tutorial: OSPF Network Types and Frame Relay Part 1 » ardenpackeer.com

The initial situation is this on hub R1

interface Serial1/0
ip address 192.168.1.1 255.255.255.0
encapsulation frame-relay
ip ospf network broadcast
ip ospf hello-interval 2
ip ospf priority 255
serial restart-delay 0
no frame-relay inverse-arp
end

and I get this debug

*Mar 1 01:40:43.099: IP: s=192.168.1.1 (local), d=224.0.0.5 (Serial1/0), len 76, encapsulation failed

which is ok.

On R1 I add the fr map statement for R2 without broadcast,

frame-relay map ip 192.168.1.2 102

nothing happens and it's the expected behavior, I still get the same debug output.

If I add this statement

frame-relay map ip 12.34.56.78 102 broadcast

I've got no errors from the debug and the adj comes up!


R1#sh ip ospf nei

Neighbor ID Pri State Dead Time Address Interface
192.168.1.2 0 FULL/DROTHER 00:00:07 192.168.1.2 Serial1/0



Now I still have to bring up adj with R3, I follow another path, first the broadcast statement with a clueless ip and then the normal map statement with the correct ip.

frame-relay map ip 87.65.43.21 103 broadcast

I get the encaps failure output

*Mar 1 01:48:10.419: IP: s=192.168.1.1 (local), d=192.168.1.3 (Serial1/0), len 124, encapsulation failed


but that's because a unicast map is missing, the broadcast is accepted, in fact my adj remains in exchange

192.168.1.3 0 EXCHANGE/DROTHER00:00:06 192.168.1.3 Serial1/0

until the dead timer expires, then the process repeats.
Once I add the unicast map statement the adj comes up

frame-relay map ip 192.168.1.3 103

192.168.1.3 0 FULL/DROTHER 00:00:07 192.168.1.3 Serial1/0


The final config is


interface Serial1/0
ip address 192.168.1.1 255.255.255.0
encapsulation frame-relay
ip ospf network broadcast
ip ospf hello-interval 2
ip ospf priority 255
serial restart-delay 0
frame-relay map ip 87.65.43.21 103 broadcast
frame-relay map ip 192.168.1.2 102
frame-relay map ip 192.168.1.3 103
frame-relay map ip 12.34.56.78 102 broadcast
no frame-relay inverse-arp
end



R1#sh ip ospf nei

Neighbor ID Pri State Dead Time Address Interface
192.168.1.2 0 FULL/DROTHER 00:00:07 192.168.1.2 Serial1/0
192.168.1.3 0 FULL/DROTHER 00:00:07 192.168.1.3 Serial1/0



Every prefix advertised is pingable.

Does anyone have an explanation for this behavior?

Thanks

M

tim100

marco_fera wrote: »

frame-relay map ip 87.65.43.21 103 broadcast

I get the encaps failure output

*Mar 1 01:48:10.419: IP: s=192.168.1.1 (local), d=192.168.1.3 (Serial1/0), len 124, encapsulation failed


but that's because a unicast map is missing, the broadcast is accepted, in fact my adj remains in exchange

192.168.1.3 0 EXCHANGE/DROTHER00:00:06 192.168.1.3 Serial1/0

until the dead timer expires, then the process repeats.
Once I add the unicast map statement the adj comes up

frame-relay map ip 192.168.1.3 103

192.168.1.3 0 FULL/DROTHER 00:00:07 192.168.1.3 Serial1/0


The final config is


interface Serial1/0
ip address 192.168.1.1 255.255.255.0
encapsulation frame-relay
ip ospf network broadcast
ip ospf hello-interval 2
ip ospf priority 255
serial restart-delay 0
frame-relay map ip 87.65.43.21 103 broadcast
frame-relay map ip 192.168.1.2 102
frame-relay map ip 192.168.1.3 103
frame-relay map ip 12.34.56.78 102 broadcast
no frame-relay inverse-arp
end



R1#sh ip ospf nei

Neighbor ID Pri State Dead Time Address Interface
192.168.1.2 0 FULL/DROTHER 00:00:07 192.168.1.2 Serial1/0
192.168.1.3 0 FULL/DROTHER 00:00:07 192.168.1.3 Serial1/0



Every prefix advertised is pingable.

Does anyone have an explanation for this behavior?

Thanks

M

With the dummy IP you specified broadcast on the DLCI so the multicast is in fact being "copied" (unicasted) out of each DLCI with a broadcast statement but the fact that frame-relay inverse arp is disabled and you didn't map the correct IP previously is why you were getting the "encapsulation failed" message because the router can't correctly encapsulate the frame for that IP without knowing the layer 2 address/DLCI.

marco_fera

tim100 wrote: »

With the dummy IP you specified broadcast on the DLCI so the multicast is in fact being "copied" (unicasted) out of each DLCI with a broadcast statement

It makes no sense: a replicated unicast is the way broadcast is simulated on a non-broadcast segment. But in order to work there must be a valid unicast address the fake broadcasts must be replicated to. If I put a dummy ip the unicasts should be sent to a non-existent ip and should have no effect.

tim100 wrote: »

but the fact that frame-relay inverse arp is disabled and you didn't map the correct IP previously is why you were getting the "encapsulation failed" message because the router can't correctly encapsulate the frame for that IP without knowing the layer 2 address/DLCI.

Well, that was my intention...

tim100

marco_fera wrote: »

If I put a dummy ip the unicasts should be sent to a non-existent ip and should have no effect.

But once the exchange state is established the routers will try to exchange DBDs but since IP 192.168.1.3 wasn't mapped to the DLCI that is why you were getting the encapsulation failed message and you were stuck in exchange. After you added the "frame-relay map ip 192.168.1.3 103" statement the routers exchanged DBDs successfully.

marco_fera

tim100 wrote: »

But once the exchange state is established the routers will try to exchange DBDs but since IP 192.168.1.3 wasn't mapped to the DLCI that is why you were getting the encapsulation failed message and you were stuck in exchange. After you added the "frame-relay map ip 192.168.1.3 103" statement the routers exchanged DBDs successfully.

Wait a second, I don't get what you say: I purposedly avoided putting the frame-relay map statements in order to see what would happen.
What I'm saying is: isn't it strange that R1 can reach exchange state with R3? theoretically R1 should reach that state if it can send a first series of packets to R3.
It does so by sending multicasts, but since I've got no broadcast support on the fr segment I must add a fr map with the broadcast keyword.
The broadcast keyword specifies which unicast address should receive the replicated unicasts.
If I put the line

frame-relay map ip 87.65.43.21 103 broadcast

basically I'm saying to the router that when he has to send broadcasts it actually has to send a unicast to ip addres 87.65.43.21. But this address is configured nowhere, so nothing is supposed to happen.

tim100

marco_fera wrote: »

basically I'm saying to the router that when he has to send broadcasts it actually has to send a unicast to ip addres 87.65.43.21. But this address is configured nowhere, so nothing is supposed to happen.

It is unicasting out the DLCI not to the IP. Since it is NBMA what you are really doing is unicasting out each specified DLCI configured with a broadcast statement in order to simulate a broadcast network.

marco_fera

tim100 wrote: »

It is unicasting out the DLCI not to the IP. Since it is NBMA what you are really doing is unicasting out each specified DLCI configured with a broadcast statement in order to simulate a broadcast network.

Excellent, it wasn't clear from the documentation.
Thanks
M