OSPF P2M non-broadcast interface issues

From: Radoslav Vasilev (deckland@gmail.com)
Date: Sat Jul 15 2006 - 10:36:28 ART


Hi Group,

This is mostly for the IEWB Team to check, but any other opinion
appreciated.

Currnetly working on IEWB Lab 16, task 5.1 which is BGP configurations.
One of my adjacency woldn't come up (eBGP session over FR cloud), due to TTL
expiration (no ebgp-multihop configured as the neighbors are directly
connected).
Starting from this issue, i went back to my OSPF configuration. First the
setup:

R3, R4 and R5 in a hub-and-spoke toplogy with R3 being the hub. All devices
use physical interfaces and the requirenments say no broadcast for the
frame-relay maps(no inverse arp as well). Common IP subnet over this
toplogy. My configuration:

R3, the hub:
interface Serial1/0
 ip address 154.1.0.3 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint non-broadcast
 clock rate 64000
 frame-relay map ip 154.1.0.4 304
 frame-relay map ip 154.1.0.5 305
 no frame-relay inverse-arp

R4, a spoke:

interface Serial0/0
 ip address 154.1.0.4 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint non-broadcast
 clock rate 64000
 frame-relay map ip 154.1.0.3 403
 frame-relay map ip 154.1.0.5 403
 no frame-relay inverse-arp

R5, a spoke:
interface Serial0/0
 ip address 154.1.0.5 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint non-broadcast
 clock rate 64000
 frame-relay map ip 154.1.0.3 503
 frame-relay map ip 154.1.0.4 503
 no frame-relay inverse-arp

I have connectivity between the devices and now i need to configure OSPF
adjacencie. Pasting only the configuration of R3:

router ospf 100
 router-id 150.1.3.3
 log-adjacency-changes
 area 3457 filter-list prefix area3457in in
 timers throttle spf 4000 10000 90000
 network 150.1.3.3 0.0.0.0 area 3457
 network 154.1.0.3 0.0.0.0 area 3457
 network 154.1.38.3 0.0.0.0 area 38
 network 0.0.0.0 255.255.255.255 area 0
 neighbor 154.1.0.4 cost 97
 neighbor 154.1.0.5 cost 195

As shown above, R3 is manually configured with R4 and R5 as OSPF neighbors
over what is configured as P2M non-broadcast network (because of another lab
requrement the cost to the two neighbors are not equal).

My troubles begin when i configure the two neighbors on R3 with different
costs, as then the FR interface address of R5 (154.1.0.5) starts to be seen
through R4 (from R3 perspective). This is because R4 and R5 have another
OSPF link, over which R4 learns about R5's FR interface. Because now R3
routes through R4 for the R5's address:

Rack1R3#sh ip route 154.1.0.5
Routing entry for 154.1.0.5/32
  Known via "ospf 100", distance 110, metric 98, type intra area
  Last update from 154.1.0.4 on Serial1/0, 00:07:06 ago
  Routing Descriptor Blocks:
  * 154.1.0.4, from 150.1.5.5, 00:07:06 ago, via Serial1/0
      Route metric is 98, traffic share count is 1

the eBGP won't come up.

At the same time I don't see anything in the solultion that would overcome
this.

Rado



This archive was generated by hypermail 2.1.4 : Tue Aug 01 2006 - 07:13:47 ART