Re: OSPF Router ID & Network Types

Thank you Petr for the detailed clarification, appreciate it. :)

On Fri, Jan 21, 2011 at 9:00 PM, Petr Lapukhov
<petr_at_internetworkexpert.com>wrote:

> You missed the part
>
> "All other packet types are sent/received only on adjacencies. This means
> that the packet must have been sent by one of the router's active
> neighbors."
>
> Here is the question: when an OSPF packet is received on the interface,
> should it be processed or dropped? What are the rules for distinguishing
> legitimate packets?
>
> Obviously, the packets need to have proper header structure first. Next, if
> the interface is configured for authentication, the authentication
> information in the packet should be verifiable using the interface key
> settings. What next? If the packet is a HELLO packet, it could signal a new
> adjacency establishment or belong to an existing adjacency. If packet is
> anything else but HELLO, there MUST be an adjacency matching this packet -
> otherwise the packet should be dropped.
>
> Now we approach your question: how would OSPF router match a packet to an
> adjacency? OSPF maintains list of neighbor IP addresses, so it can simply
> use the source IP address to find matching neighbor from the list. However,
> there is a problem area here: point-to-point links and virtual-links.
>
> P2P links could be unnumbered. That is, the source IP address used in OSPF
> packets sent over P2P link may actually correspond to MULTIPLE adjacencies.
> Simply imagine two routers connected by two unnumbered point-to-point links.
> For this reason, if a packet is received on a P2P interface, it is matched
> against the neighbor table using the Router-ID found in the OSPF header.
> This resolves the unnumbered problem.
>
> The next problematic link type is virtual link. Virtual link neighbors
> could be separated by multiple hops. The source and destination IP addresses
> in VL packets are calculated dynamically based on the existing topology
> state. When OSPF receives an unicast HELLO packet, it finds out it belongs
> to area 0 and inspects the Router-ID in OSPF header to find a matching
> virtual-link. Obviously, relating on source IP will not help in this case,
> even though it is theoretically possible to scan the LSDB for Type 3 links
> and see what router has the IP address.
>
> HTH,
>
> --
> Petr Lapukhov, petr_at_INE.com
> CCIE #16379 (R&S/Security/SP/Voice)
> CCDE #20100007
>
> Internetwork Expert, Inc.
> http://www.INE.com <http://www.ine.com/>
> Toll Free: 877-224-8987
> Outside US: 775-826-4344
>
> 2011/1/21 Nish Vamadevan <ipnish_at_gmail.com>
>
>> Hi,
>>
>> As I am reading through RFC 2328, Came up with this statement and I can't
>> seem to come up with a logical explanation, why... Maybe someone can help
>> me
>> out?
>>
>> When it comes to the Hello Packet,
>>
>> //
>> If the receiving interface connects to a point-to-point network or a
>> virtual
>> link, the sender is identified by the Router ID (source router) found in
>> the
>> packet's OSPF header.
>> //
>>
>> I can understand the part about the virtual-link because it is created
>> using
>> the Router ID.
>>
>> What I can't understand is why a point-to-point network is identified by
>> the
>> Router ID. And having said that, Point-To-MultiPoint isin't. (It also
>> states
>> that, as we know Point-To-MultiPoint is a collection of point-to-point)
>>
>> I'd appreciate it if anyone can shed some light in this...
>>
>> Thanks,
>>
>> --
>> Regards,
>> Nish
>>
>> www.twitter.com/nish
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>
>

-- 
Regards,
Nish
http://twitter.com/nish
Blogs and organic groups at http://www.ccie.net