[Xorp-users] Re: help establishing OSPF adjacencies

Atanu Ghosh atanu@ICSI.Berkeley.EDU
Mon, 17 Oct 2005 14:11:25 -0700


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.

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.

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.

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?

	Atanu.

>>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:

    Nick> Just to follow up with some more information: I see messages
    Nick> such as: [ 4251 +430 xrl_io.cc join_multicast_group ] Join
    Nick> Interface eth0 Vif eth0 mcast 224.0.0.5 ]

    Nick> in the logs.  I don't understand what's going on here, but I
    Nick> can't help but wonder if this has anything to do with these
    Nick> messages: [ 4251 +92 xrl_io.cc send ] send(interface = eth0,
    Nick> vif = eth0, src = 128.31.1.14, dst = 224.0.0.5, payload_size =
    Nick> 44

    Nick> I'm puzzled, since I didn't configure anything having to do
    Nick> with multicast.  Since these messages seem to disappear when I
    Nick> disable OSPF, I'm wondering if XORP's OSPF somehow relies on
    Nick> multicast to distribute LSAs, and, if so, how I should be
    Nick> configuring multicast to get these adjacencies exchanged
    Nick> properly?

    Nick> The only other clue I see in the logs is: [ 2005/10/17
    Nick> 16:20:52 TRACE xorp_ospfv2 OSPF ] Event(InterfaceUp)
    Nick> Interface(eth0/eth0) State(Down)

    Nick> which I'm not certain how to interpret.  Could "State(Down)"
    Nick> be the reason I don't see anything in other OSPF LSA
    Nick> databases, for example?

    Nick> thanks, Nick

    Nick> p.s. I also see the following error message when starting up:
    Nick> [ 2005/10/17 16:20:37 INFO xorp_rtrmgr:20946 RTRMGR +485
    Nick> module_manager.cc run ] Running module: fea
    Nick> (/usr/local/xorp/fea/xorp_fea) c user_click_command_done_cb ]
    Nick> User-level Click command (~/demo/click) failed.

    Nick> I did not see this problem when running XORP 1.1, but now it
    Nick> seems I'm having to start click manually because XORP does not
    Nick> fire it up properly.  Has the mechanism for starting up click
    Nick> in XORP changed since version 1.1?


    Nick> On Mon, Oct 17, 2005 at 01:43:26PM -0400, Nick Feamster wrote:
    >> Hi,
    >> 
    >> I can't seem to find much documentation on configuring OSPF in
    >> XORP, which is understandable since it is quite new.  btw, thanks
    >> for implementing this!
    >> 
    >> I am trying to get an adjacency established between two nodes.
    >> Standard error/xorpsh shows me this on the two machines.  Both of
    >> the eth0 interfaces below are configured with a prefix-length of
    >> /24 so they should, in theory, be in the same subnet.
    >> 
    >> I'm wondering why the LSA databases below don't show the
    >> adjacency.  Any potential hangups I should know about?
    >> 
    >> Thanks, Nick
    >> 
    >> 
    >> Machine 1:
    >> ----------
    >> Standard error (LSA announcements) ...  [ 22201 +92 xrl_io.cc
    >> send ] send(interface = eth0, vif = eth0, src = 128.31.1.14, dst
    >> = 224.0.0.5, payload_size = 44 ...
    >> 
    >> 
    >> xorpsh
    Xorp> show ospf4 database 0.0.0.0
    >> Type ID Adv Rtr Seq Age Opt Cksum Len Router *128.31.1.14
    >> 128.31.1.14 0x80000001 326 0x2 0x3e12 36
    >> 
    >> interface eth0 { description "ethernet adapter" disable: false
    >> discard: true vif eth0 { disable: false address 128.31.1.14 {
    >> prefix-length: 24 disable: false } } }
    >> 
    >> ....
    >> 
    >> ospf4 { router-id: 128.31.1.14
    >> 
    >> area 0.0.0.0 { interface eth0 { vif eth0 { address 128.31.1.14 {
    >> interface-cost: 5 } } } } }
    >> 
    >> 
    >> Machine 2:
    >> ----------
    >> [ 18333 +92 xrl_io.cc send ] send(interface = eth0, vif = eth0,
    >> src = 128.31.1.15, dst = 224.0.0.5, payload_size = 44
    >> 
    >> xorpsh
    Xorp> show ospf4 database 0.0.0.0
    >> Type ID Adv Rtr Seq Age Opt Cksum Len Router *128.31.1.15
    >> 128.31.1.15 0x80000001 326 0x2 0x3e12 36
    >> 
    >> 
    >> 
    Nick> _______________________________________________ Xorp-users
    Nick> mailing list Xorp-users@xorp.org
    Nick> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users