[Xorp-hackers] OSPF & migrating remote routers.

[Ben Greear]

Atanu Ghosh wrote:
> Hi,
>
>   
>>>>>> "Ben" == Ben Greear <greearb at candelatech.com> writes:
>>>>>>             
>
>     Ben> The current implementation of OSPF, if the remote router-id
>     Ben> changes, but the remote interface IP doesn't change, then OSPF
>     Ben> doesn't notice that there is a new peer because it searches
>     Ben> on the interface IPs instead of the router-id.
>
>     Ben> With the patch below, it searches by router-id on broadcast
>     Ben> interfaces too, and then it works in my case (I'm using
>     Ben> ethernet-like interfaces.)
>
>     Ben> What is the reason for searching by anything other than router-id,
>     Ben> regardless of the interface type?
>
> The specification RFC 2328:
> ----------------------------------------
> 	At this point, an attempt is made to match the source of the
> 	Hello Packet to one of the receiving interface's neighbors.  If
> 	the receiving interface connects to a broadcast, Point-to-
> 	MultiPoint or NBMA network the source is identified by the IP
> 	source address found in the Hello's IP header.	If the receiving
> 	interface connects to a point-to-point link or a virtual link,
> 	the source is identified by the Router ID found in the Hello's
> 	OSPF packet header.  The interface's current list of neighbors
> 	is contained in the interface's data structure.  If a matching
> 	neighbor structure cannot be found, (i.e., this is the first
> 	time the neighbor has been detected), one is created.  The
> 	initial state of a newly created neighbor is set to Down.
> ----------------------------------------
>   

The next paragraph down talks about setting the neighbor's id to that of 
the router-id
found in the hello packet.  If the new ID is different from the old ID, 
surely you have to go back to initial
state, even though the RFC doesn't say anything about this.  Otherwise, 
it seems like you could
be using stale state for a new router that just came up with the old IP 
address (this is indeed
what I see).

Can you think of any positive reason to use the interface's IP as 
opposed to the
router-id, other than that is what the RFC suggests?

If you don't want to change the code, I can just use my private build, 
but perhaps
it might be worth thinking about fudging the RFC in this case, or at 
least allowing
one to configure this new behaviour in the config file.

Thanks,
Ben

> 	Atanu.
>
>     Ben> Thanks,
>     Ben> Ben
>
>     Ben> RCS file: /cvs/xorp/ospf/peer.cc,v
>     Ben> retrieving revision 1.289
>     Ben> diff -u -r1.289 peer.cc
>     Ben> --- peer.cc     5 Oct 2007 00:06:59 -0000       1.289
>     Ben> +++ peer.cc     5 Oct 2007 00:58:56 -0000
>     Ben> @@ -1487,13 +1487,13 @@
>     Ben>   {
>     Ben>       typename list<Neighbour<A> *>::iterator n;
>     Ben>       switch(get_linktype()) {
>     Ben> -    case OspfTypes::BROADCAST:
>     Ben>       case OspfTypes::NBMA:
>     Ben>       case OspfTypes::PointToMultiPoint:
>     Ben>          for(n = _neighbours.begin(); n != _neighbours.end(); n++)
>     Ben>              if ((*n)->get_neighbour_address() == src)
>     Ben>                  return *n;
>     Ben>          break;
>     Ben> +    case OspfTypes::BROADCAST:
>     Ben>       case OspfTypes::VirtualLink:
>     Ben>       case OspfTypes::PointToPoint:
>     Ben>          for(n = _neighbours.begin(); n != _neighbours.end(); n++)
>
>     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
>   


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