Routing updates over a Frame-Relay network

[Markfrancis910]

Hi all,

I am trying to configure a Hub and Spoke frame relay network with a mix of the "Frame-Relay map IP" command and the "Frame-Relay interface-dlci" and have a problem sending routing updates. I know that by default a frame-relay network dose not send broadcasts unless specified. I have also been told there is no broadcast command needed with the "Frame-Relay interface-dlci" command.

I have R1 as the hub and R2 and R3 as spokes. I have RIP running with "network 200.0.0.0 and network 200.0.1.0 running on R1+R2 and R1+R3 respectively.

Here is the relevant configs, tidied up for clarity:

R1

interface Serial0/0

no ip address

encapsulation frame-relay

clock rate 2000000

no frame-relay inverse-arp

!

interface Serial0/0.1 point-to-point

ip address 200.0.0.1 255.255.255.252

ip ospf network broadcast

frame-relay interface-dlci 101

!

interface Serial0/0.2 point-to-point

ip address 200.0.1.1 255.255.255.252

ip ospf network broadcast

frame-relay interface-dlci 501

R2

interface Serial0/0

ip address 200.0.0.2 255.255.255.252

encapsulation frame-relay

clock rate 2000000

frame-relay map ip 200.0.0.1 202 broadcast

R3

interface Serial0/0

ip address 200.0.1.2 255.255.255.252

encapsulation frame-relay

clock rate 2000000

frame-relay map ip 200.0.1.1 606 broadcast

[John Blakley]

RIP has a neighbor command too:

router rip

neighbor

Why do you have ospf configurations on your hub? Are you running OSPF?

[Peter Paluch]

Hello Mark,

You should be able to successfully ping R2 and R3 from R1 - have you verified that?

One visible issue here is that on R1, both your subinterfaces are configured with the OSPF Broadcast Multiaccess network type (untypical but otherwise fine by itself), however, on R2 and R3, the corresponding interfaces use the default OSPF network type, which is NonBroadcast Multiaccess on Frame Relay physical interfaces. This causes a discrepancy in two of the mandatory OSPF parameters: Hello timer (BMA=10s, NBMA=30s) and Dead interval (BMA=40s, NBMA=120s). OSPF will therefore refuse to create an adjacency here.

Try using the ip ospf network broadcast on R2 and R3, and the network should come up.

Best regards,

Peter

EDIT: John has a very good question: are you actually trying to run OSPF or RIP here? I thought it is OSPF but you say yourself it is RIP. Hmmm...

[John Blakley]

Peter,

I actually had to go back and reread that because of your response. You're much better at the FR stuff than I am, so I thought I was missing a really big picture

John

[Peter Paluch]

John,

Actually, I have focused on the configuration and didn't pay enough attention to the description of the problem. Thanks for focusing us on the ambiguosity of the original post!

Best regards,

Peter

[Richard Burts]

Mark shows us in the configuration shown in the original post that R1 has 2 point to point subinterfaces while R2 and R3 are running on the physical interface which is multi-point. If the routing protocol were OSPF this would create problems. But in the original post Mark indicates that he is running RIP.

Since we do not know how the Frame Relay network is set up physically, I believe that the question from Peter about whether R1 can ping R2 and R3 is a very good starting point.

HTH

Rick

[cadet alain]

Hi Peter,

if we suppose that the OP is running OSPF and not RIP wouldn't this solution be also viable:

- change the hello-interval on hub to reflect the setting on the spokes ( 30-120)

- and of course put the priority to zero on the spokes so they are not elected DR/BDR

- put a  neighbor command on  each spoke

- let go of the broadcast keyword in the static mappings on the spokes as we are using unicast so they are not necessary

  anymore

Tell me what you think about it.

Regards.

Alain

[Markfrancis910]

Hello all,

I have been trying to get this working all day, so have overlooked some simple things I have not mentioned.

Yes your right there is OSPF commands in there. Originaly I was running OSPF and ran in to the issue with neighbors not forming. Using the usual debug commands I noticed the issue with hello and dead timers not being the same. I hard coded the spokes Hello times and successfully formed the OSPF adjacency. Even with full adjacency the routing tables on each spoke only contained one route, the directly connected network. I then removed OSPF and replaced it with RIP to try to troubleshoot and see if the routes would then be exchanged.

Currently both spokes (R2 and R3) only have the directly connected routes in there routing table. R1 can ping both routers but I cant ping from R2 to R3.

To clarify, I'm currently running RIP, but did have OSPF running and could not get it replicating routes.

[cadet alain]

Hi,

ok so you can't ping from spoke to spoke which seems normal as you have no static mapping for the the other spoke on each one pointing to the hub.

either add this static mapping or just configure a static route on each spoke pointing to other spoke subnet.

R2

interface Serial0/0

ip address 200.0.0.2 255.255.255.252

encapsulation frame-relay

clock rate 2000000

frame-relay map ip 200.0.0.1 202 broadcast

frame-relay map ip 200.0.1.1 202

R3

interface Serial0/0

ip address 200.0.1.2 255.255.255.252

encapsulation frame-relay

clock rate 2000000

frame-relay map ip 200.0.1.1 606 broadcast

frame-relay map ip 200.0.0.2 606

or

R2

ip route 200.0.1.0 255.255.255.252 200.0.0.1

interface Serial0/0

ip address 200.0.0.2 255.255.255.252

encapsulation frame-relay

clock rate 2000000

frame-relay map ip 200.0.0.1 202 broadcast

R3

ip route 200.0.0.0 255.255.255.252 200.0.1.1

interface Serial0/0

ip address 200.0.1.2 255.255.255.252

encapsulation frame-relay

clock rate 2000000

frame-relay map ip 200.0.1.1 606 broadcast

Regards.

Alain

[Markfrancis910]

Hi,

ok so you can't ping from spoke to spoke which seems normal as you have no static mapping for the the other spoke on each one pointing to the hub.

either add this static mapping or just configure a static route on each spoke pointing to other spoke subnet.

R2

interface Serial0/0

ip address 200.0.0.2 255.255.255.252

encapsulation frame-relay

clock rate 2000000

frame-relay map ip 200.0.0.1 202 broadcast

frame-relay map ip 200.0.1.1 202

R3

interface Serial0/0

ip address 200.0.1.2 255.255.255.252

encapsulation frame-relay

clock rate 2000000

frame-relay map ip 200.0.1.1 606 broadcast

frame-relay map ip 200.0.0.2 606

or

R2

ip route 200.0.1.0 255.255.255.252 200.0.0.1

interface Serial0/0

ip address 200.0.0.2 255.255.255.252

encapsulation frame-relay

clock rate 2000000

frame-relay map ip 200.0.0.1 202 broadcast

R3

ip route 200.0.0.0 255.255.255.252 200.0.1.1

interface Serial0/0

ip address 200.0.1.2 255.255.255.252

encapsulation frame-relay

clock rate 2000000

frame-relay map ip 200.0.1.1 606 broadcast

Regards.

Alain

Hello,

I understand that this should work,. It's almost like adding a static route. This is me trying to run a routing protocol that will tell R2 to use R1 to get to R3. This lab is me trying to mix differnt frame-relay commands to try to see if they will work.

[Peter Paluch]

Hi Alain,

This is indeed a CCIE-style combination of different OSPF settings, trying to get it working

- change the hello-interval on hub to reflect the setting on the spokes ( 30-120)

Yes. That would make the OSPF use the same timers, one of the mandatory steps in establishing an adjacency.

- and of course put the priority to zero on the spokes so they are not elected DR/BDR

Not necessary in Mark's case because on the hub, he uses point-to-point subinterfaces, so this is not really a multiaccess network.

- put a  neighbor command on  each spoke

Not necessary in Mark's case because the hub would be capable of successfully delivering its multicast packets to R2 and R3 thanks to the point-to-point subifs, and both R2 and R3 would learn about R1's IP address without needing to have this neighbor configured statically.

- let go of the broadcast keyword in the static mappings on the spokes as we are using unicast so they are not necessary

Yes, it would work - and actually, it would work in Mark's case even without the neighbor commands because R1 would be sending multicasts that would be delivered to R2 and R3 (multicasts are always forwarded on point-to-point FR subifs), and R2/R3 would learn about R1 from these packets and talk back to it via unicast, even without the neighbor command.

Best regards,

Peter

[John Blakley]

Mark,

In addition to what everyone else said, can you post the "sh frame-relay map" information and possibly the "sh frame-relay pvc"? I set this up in a lab and I don't have any issues. I noticed that on your R1, you don't have static mappings for R2 and R3, but I did the same thing and am still getting mappings dynamically.

John

[cadet alain]

Hi Peter,

- and of course put the priority to zero on the spokes so they are not elected DR/BDR

Not  necessary in Mark's case because on the hub, he uses point-to-point  subinterfaces, so this is not really a multiaccess network.

Yes but he has configured the broadcast ospf network type on these P2P subinterfaces  which then require DR/BDR election as well as the physical Frame-relay interfaces ?

- let go of the broadcast keyword in the static mappings on the spokes as we are using unicast so they are not necessary

Yes, it would work - and actually, it would work in Mark's case even without the neighbor commands because R1 would be sending multicasts that would be delivered  to R2 and R3 (multicasts are always forwarded on point-to-point FR  subifs), and R2/R3 would learn about R1 from these packets and talk back  to it via unicast, even without the neighbor command.

Nice info

Regards.

Alain

[Peter Paluch]

Hello Alain,

- and of course put the priority to zero on the spokes so they are not elected DR/BDR
 Not   necessary in Mark's case because on the hub, he uses point-to-point   subinterfaces, so this is not really a multiaccess network.
Yes  but he has configured the broadcast ospf network type on these P2P  subinterfaces  which then require DR/BDR election as well as the  physical Frame-relay interfaces ?

The broadcast network type does lead to DR/BDR elections but it does not require physical FR interfaces. Any interface can be forced to operate in OSPF broadcast network type. The subinterfaces created on R1 do not connect all three routers together into a common multiaccess network, rather, they create two separate segments in the form R2 --- R1 --- R3, virtually identical to point-to-point Ethernet connections between these three routers. Each of the R2/R1 and R1/R3 segments will have a DR/BDR elected here. Because on each of these segments, the two member routers can be considered fully meshed, there is no need to tweak the DR/BDR elections.

Best regards,

Peter