[Xorp-users] Re: help establishing OSPF adjacencies
Atanu Ghosh
atanu@ICSI.Berkeley.EDU
Wed, 19 Oct 2005 15:27:03 -0700
Nick> Hi Atanu, What does this error message mean?
Nick> [ 2005/10/19 17:05:51 FATAL xorp_ospfv2:10666 OSPF +914
Nick> peer.cc is_neighbour_DR_or_BDR ] Assertion (do_dr_or_bdr())
Nick> failed
The method is_neighbour_DR_or_BDR() has been called to determine if any
of the routers neighbours are the designated router or backup designated
router. This method should only be called if the the link type is
Broadcast or NBMA, as these are the only link types that perform DR
election. I assume that the link-type is set to point-to-multipoint
(p2m), in when case the assert is signalling a programming error. The
OSPF process will have exited. A stack backtrace might yield some clues.
If the problem is reproducible with the latest code from CVS then the
configuration files and some information about the topology would be useful.
Nick> I see adjacencies in my ospf database, but nothing in the RIB,
Nick> and I suspect this error may have something to do with it?
Nick> Thanks a lot!
If an attempt was made to add a route to the RIB and it failed you
should error messages in the log.
Xorp> show ospf4 database 0.0.0.0
Nick> Type ID Adv Rtr Seq Age Opt Cksum Len Router *128.31.1.13
Nick> 128.31.1.13 0x80000003 68 0x2 0x6771 48 Router 128.31.1.14
Nick> 128.31.1.14 0x80000002 700 0x2 0x9341 48 Router 128.31.1.15
Nick> 128.31.1.15 0x80000002 860 0x2 0x9140 48
Xorp> show route table ipv4 unicast ospf
Xorp>
Nick> -Nick
Nick> On Mon, Oct 17, 2005 at 05:22:21PM -0700, Atanu Ghosh wrote:
>> Hi,
>>
>> Responses inline.
>>
Nick> On Mon, Oct 17, 2005 at 02:11:25PM -0700, Atanu Ghosh wrote:
>> >> Hi,
>> >>
>> >> The messages of the form '[ 4251 +430 xrl_io.cc ...' are >>
>> debugging output from OSPF. One of the things that they show are
>> >> packets being sent and received by OSPF.
>> >>
>> >> OSPF uses multicast on broadcast media to distribute LSAs
>> (with a >> TTL of 1), so this behaviour is correct.
>>
Nick> OK. Thanks for the clarification.
>> >> The TRACE messages are typically at the top of methods so
>> they >> show the state on entry to the method. It is therefore
>> correct >> that when a InterFaceUp event occurs that the state of
>> the >> interface was down.
>> >>
>> >> Could you try disabling Click and see if an adjacency is still
>> >> not formed.
>>
Nick> Yes, I think I did actually try that. I removed it from the
Nick> XORP configuration, at least. What should I configure in the
Nick> FEA instead? Do I need to configure multicast? Also, when
Nick> you say "broadcast media", what do you mean? I'd think that
Nick> would mean the broadcast address of the subnet, 128.31.1.255.
Nick> What's this 224... multicast address, and do I need to
Nick> configure something in XORP to make certain it's reachable?
>> OSPF supports a number of different network types one of them is
>> Broadcast the definition from the RFC is below. The XORP
>> configuration defaults to broadcast (point-2-point and
>> point-to-multipoint are also supported). You shouldn't need to
>> configure anything in order to support the sending of the
>> multicast packets. I have included a complete config that I am
>> using below.
>>
>> ---------------------------------------- RFC 2328 Broadcast
>> networks Networks supporting many (more than two) attached
>> routers, together with the capability to address a single
>> physical message to all of the attached routers (broadcast).
>> Neighboring routers are discovered dynamically on these nets
>> using OSPF's Hello Protocol. The Hello Protocol itself takes
>> advantage of the broadcast capability. The OSPF protocol makes
>> further use of multicast capabilities, if they exist. Each pair
>> of routers on a broadcast network is assumed to be able to
>> communicate directly. An ethernet is an example of a broadcast
>> network.
>> ----------------------------------------
>>
>> ----------------------------------------
>> interfaces { interface en1 { vif en1 { address 10.0.1.6 {
>> prefix-length: 16 } } } }
>>
>> protocols { ospf4 { router-id: 10.0.1.6
>>
>> area 0.0.0.0 { interface en1 { vif en1 { address 10.0.1.6 { } } }
>> } } }
>> ----------------------------------------
>>
>> >> In order for an adjacency to be formed routers have to see
>> each >> others hello packets. A hello packet contains a hello
>> interval, a >> router dead interval and a list of other routers
>> that have been >> seen on this interface. The hello interval and
>> router dead >> interval have to match for an adjacency attempt to
>> be made. As an >> optimisation on broadcast networks rather than
>> forming an >> adjacency with every other router on the subnet a
>> designated >> router and backup designated router are elected.
>> The DR and BDR >> routers form adjacencies with all the routers
>> and the routers in >> the other set form only two adjacencies.
>> >>
>> >> Two routers with the default configuration should try and form
>> an >> adjacency. You should see TRACE messages of this form:
>> >>
>> >> [ . TRACE .] Event(HelloReceived) I.(fxp0/fxp0)
>> N.(128.31.1.14) >> State(Full) [ . TRACE .] Event(2-WayReceived)
>> I.(fxp0/fxp0) >> N.(128.31.1.14) State(Full)
>> >>
>> >> I have replaced some of the output with '.'s.
>> >>
>> >> If you are not seeing Event(HelloReceived) then they are not
>> >> seeing each others hello messages. Note the state is Full in
>> this >> example.
>>
Nick> I definitely don't see these.
>> Then the routers are not seeing each others packets.
>>
>> >> After I saw you original message I went back and checked that
>> >> adjancencies are still being formed and they are.
>> >>
>> >> I found one thing a little puzzling the checksum for both
>> routers >> for different LSAs is the same, is this the actual
>> output?
>>
Nick> No, I had a copy/paste error. The checksums are different.
>> Good - thats what I guessed:-).
>>
>> Atanu.