[Xorp-hackers] OSPF stuck in TwoWay state.

[Atanu Ghosh]

Hi,

This behaviour is correct.

Interfaces of type broadcast and NBMA will elect a DR and BDR if there
are enough neighbours. In this case only the DR and BDR need to form
full adjacencies with all neighbours, the other neighbours will stay in
the 2-Way (TwoWay) state.

---------------------------------------- RFC 2328 Section 10.4
    10.4.  Whether to become adjacent

	Adjacencies are established with some subset of the router's
	neighbors.  Routers connected by point-to-point networks,
	Point-to-MultiPoint networks and virtual links always become
	adjacent.  On broadcast and NBMA networks, all routers become
	adjacent to both the Designated Router and the Backup Designated
	Router.

	The adjacency-forming decision occurs in two places in the
	neighbor state machine.  First, when bidirectional communication
	is initially established with the neighbor, and secondly, when
	the identity of the attached network's (Backup) Designated
	Router changes.  If the decision is made to not attempt an
	adjacency, the state of the neighbor communication stops at 2-
	Way.

	...
----------------------------------------

    Atanu.

>>>>> "Ben" == Ben Greear <greearb at candelatech.com> writes:

    Ben> Is it ever valid for neighbors to be stuck in TwoWay
    Ben> state?

    Ben> I configured a set of 15 virtual routers w/OSPF connected in
    Ben> interesting ways.  Most of the nodes are connected to a bridge
    Ben> object (roughly directly connected), and other connections form
    Ben> a mesh.  Most routers have several redundant paths through the network
    Ben> between any two nodes.

    Ben> Several of the instances connected across the bridge stay in TwoWay
    Ben> state, but some of them work.  As far as I can tell, the hello messages
    Ben> are being send properly even from the guys in TwoWay state.

    Ben> I checked IP connectivity with traceroute, and it all seems to be right
    Ben> (ie, node 99.1.1.6 should be able to talk to 99.1.1.3).

    Ben> [root at lf1016-55 ~]# traceroute -n -i 3.16.3 99.1.1.6
    Ben> traceroute to 99.1.1.6 (99.1.1.6), 30 hops max, 40 byte packets
    Ben> 1  99.1.1.6  2.785 ms  2.768 ms  2.756 ms


    Ben> Assuming its not normal for them to be in this state, can you
    Ben> give me an idea of where to look to start debugging this?

    Ben> root at lf1016-55> show ospf4 neighbor
    Ben> Address         Interface             State      ID              Pri  Dead
    Ben> 99.1.1.9         3.16.3/3.16.3          TwoWay    127.1.0.9        128    33
    Ben> 99.1.1.10        3.16.3/3.16.3          TwoWay    127.1.0.10       128    34
    Ben> 99.1.1.6         3.16.3/3.16.3          TwoWay    127.1.0.6        128    35
    Ben> 99.1.1.2         3.16.3/3.16.3          TwoWay    127.1.0.2        128    35
    Ben> 99.1.1.12        3.16.3/3.16.3          Full      127.1.0.12       128    36
    Ben> 99.1.1.11        3.16.3/3.16.3          Full      127.1.0.11       128    36
    Ben> 10.1.3.1         1.3.3/1.3.3            Full      127.1.0.1        128    30
    Ben> 10.2.3.2         2.3.3/2.3.3            Full      127.1.0.2        128    35
    Ben> 10.3.4.4         3.4.3/3.4.3            Full      127.1.0.4        128    31
    Ben> 10.3.5.5         3.5.3/3.5.3            Full      127.1.0.5        128    33
    Ben> 10.3.9.9         3.9.3/3.9.3            Full      127.1.0.9        128    34
    Ben> root at lf1016-55>

    Ben> Thanks,
    Ben> Ben

    Ben> -- 
    Ben> Ben Greear <greearb at candelatech.com>
    Ben> Candela Technologies Inc  http://www.candelatech.com

    Ben> _______________________________________________
    Ben> Xorp-hackers mailing list
    Ben> Xorp-hackers at icir.org
    Ben> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers