Subject: Re: Identification of neighbors in PTP links

From: "Balaji R (Networking) - CTD, Chennai." <[email-masked]>
Date: Sun, 2 Jun 2002 18:58:36 +0530

Hello,

Thanks for your inputs Acee and Venkata.

----------------------------------------------------------------------------
-------------------------------------------
In ptp links, if the two sides have dissimilar IP subnets assigned, then I
guess option 2 of 12.4.1.1 can't be applied. So, we would have to go with
option 1. Since Link ID contains the neighbor's IP address in this case, we
would have re-originate the LSA when the neigbor's IP address changes, or
else the interface for which IP address has changed will not be reachable.

To exemplify, Let us say that routers R1 and R2 are connected to each other
through a numbered ptp link. R1's IP address is 192.168.232.1/16 and R2's is
193.168.232.1/16. Now, R1 would advertise an LSA with Link ID set to
193.168.232.1/16 and R2 would advertise 192.168.232.1/16. So, 193.168.232.1
is reachable through R1 only (same is the case for 192.168.232.1 advertised
by R2).

At this stage, if R2's IP address changes to, say, 194.168.232.1/16, it
would not be reachable unless and until R1 began to advertise this. This is
why I thought change in neighbor's IP adderss has to be detected.

Correct me if I am wrong.
----------------------------------------------------------------------------
-------------------------------------------

I would be more interested in knowing the implications of identifying
neighbors based on source IP address as against the router ID as mentioned
in the RFC 2328 in section 10.5.
----------------------------------------------------------------------------
--------------------------------------------

Thanks,
Balaji.R.

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]]
Sent: Friday, May 31, 2002 7:13 PM
To: [email-masked]
Subject: Re: Identification of neighbors in PTP links

Naidu, Venkata wrote:
> Balaji, Acee,
>
> -> (Actually, on numbered ptp links, we would have to check if the
> -> source IP address has
> -> > changed every time we receive a packet, since we originate
> -> router LSA with
> -> > the neighbor's IP address. I guess we would have to
> -> re-originate a new LSA
> -> > if the neighbor's IP address changed. So, I thought
> -> locating the neighbor
> -> > based on source IP address would hanlde this case more easily.)
> ->
> -> For P2P links, the link data in your router link contains
> -> your interface IP
> -> address - not your neighbors. You should not have to
> -> originate a new router
> -> LSA if your neighbor's IP address changes.
>
>   In Option 1, P2P stub link represents neighbor IP address
>   and not local interface IP address.

I guess I didn't even support this option this time around
since option 2 results in fewer routes in the OSPF routing
domain.

>
>   More over, the neighbor IP address is used as the next
>   hop for all the SPF routes through the neighbor router.
>   Though, next hop IP address is not required for P2P links
>   (numbered or unnumbered) - because the L3->L2 address
>   resolution won't arise when forwarding packets in case of
>   P2P links, most of the implementations still uses neighbor
>   IP address as the next hop for all those routes.
>
>   For all the above reason, the neighbor IP address change
>   might results in re-originating and/or re-computing SPF.

The router whose IP address changes should be responsible for
re-originating their LSA. This will result in SPF computations on
other routers in the OSPF area. If you perform an SPF when the
IP source address changes you'll end doing another one when you
receive the changed LSA.

> --
> Venkata.

--
Acee

---

From: Alex Zinin <[email-masked]>
Date: Wed, 12 Jun 2002 18:26:55 -0700

Balaji:

> guess option 2 of 12.4.1.1 can't be applied.

It still can be. Each side will announce its own subnet and both will
be reachable.

[...]

> in the RFC 2328 in section 10.5.

Identifying neighbors by the IP address has the drawback of a flapping
adjacency when the interface address on the router is changed. This
does not have to happen, as the topology has not changed. Besides,
the router-ID is considered to be a more stable entity.

Identifying neighbors by their router IDs is the "clean" method, as
the network's topological model will not depend on any IP address
info in this case. The difference in neighbor identification in p2p
and multiaccess case in OSPFv2 has to do with support of multiple interfaces
to the same subnet and is something that you just have to live with.
Note that in OSPFv3, neighbors are always identified by their router IDs
and the case of multiple interfaces to the same link is addressed by
allowing only a single interface to send and receive OSPF control packets.

Alex