Subject: [OSPF] Neighbour processing

From: Joakim Tjernlund <[email-masked]>
Date: Tue, 17 Nov 2009 13:19:47 +0100

I OSPF RFC 2328, chap 10.5 one can read:
        o   If the neighbor is both declaring itself to be Designated
            Router (Hello Packet's Designated Router field = Neighbor IP
            address) and the Backup Designated Router field in the
            packet is equal to 0.0.0.0 and the receiving interface is in
            state Waiting, the receiving interface's state machine is
            scheduled with the event BackupSeen.  Otherwise, if the
            neighbor is declaring itself to be Designated Router and it
            had not previously, or the neighbor is not declaring itself
            Designated Router where it had previously, the receiving
            interface's state machine is scheduled with the event
            NeighborChange.

        o   If the neighbor is declaring itself to be Backup Designated
            Router (Hello Packet's Backup Designated Router field =
            Neighbor IP address) and the receiving interface is in state
            Waiting, the receiving interface's state machine is
            scheduled with the event BackupSeen.  Otherwise, if the
            neighbor is declaring itself to be Backup Designated Router
            and it had not previously, or the neighbor is not declaring
            itself Backup Designated Router where it had previously, the
            receiving interface's state machine is scheduled with the
            event NeighborChange.

I wonder about the Otherwise, .. part in these two bullets: Should
this be read as iff the first part before the "Otherwise, .." is false only
the the otherwise part should be performed? in other words, can
each bullet generate a BackupSeen AND NeighborChange or only
one of them?

Does the order matter, i.e is it valid to schedule two BackupSeen then
two NeighborChange?
Or should/must it be in order?

           Jocke

---

From: Acee Lindem <[email-masked]>
Date: Tue, 17 Nov 2009 08:36:10 -0500

Hi Joakim,
If the inteface state is Waiting, then the BackupSeen event is scheduled. For more advanced interface states, the NeighborChange event is scheduled. You would never schedule both of them.  
Hope this Helps,
Acee 

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of Joakim Tjernlund
|Sent: Tuesday, November 17, 2009 7:20 AM
|To: [email-masked]
|Subject: [OSPF] Neighbour processing
|
|
|I OSPF RFC 2328, chap 10.5 one can read:
|        o   If the neighbor is both declaring itself to be Designated
|            Router (Hello Packet's Designated Router field = 
|Neighbor IP
|            address) and the Backup Designated Router field in the
|            packet is equal to 0.0.0.0 and the receiving 
|interface is in
|            state Waiting, the receiving interface's state machine is
|            scheduled with the event BackupSeen.  Otherwise, if the
|            neighbor is declaring itself to be Designated Router and it
|            had not previously, or the neighbor is not declaring itself
|            Designated Router where it had previously, the receiving
|            interface's state machine is scheduled with the event
|            NeighborChange.
|
|        o   If the neighbor is declaring itself to be Backup Designated
|            Router (Hello Packet's Backup Designated Router field =
|            Neighbor IP address) and the receiving interface 
|is in state
|            Waiting, the receiving interface's state machine is
|            scheduled with the event BackupSeen.  Otherwise, if the
|            neighbor is declaring itself to be Backup Designated Router
|            and it had not previously, or the neighbor is not declaring
|            itself Backup Designated Router where it had 
|previously, the
|            receiving interface's state machine is scheduled with the
|            event NeighborChange.
|
|I wonder about the Otherwise, .. part in these two bullets: 
|Should this be read as iff the first part before the 
|"Otherwise, .." is false only the the otherwise part should be 
|performed? in other words, can each bullet generate a 
|BackupSeen AND NeighborChange or only one of them?
|
|Does the order matter, i.e is it valid to schedule two 
|BackupSeen then two NeighborChange?
|Or should/must it be in order?
|
|           Jocke
|
|_______________________________________________
|OSPF mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/ospf
|

---

From: Joakim Tjernlund <[email-masked]>
Date: Tue, 17 Nov 2009 16:23:56 +0100

Acee Lindem <[email-masked]> wrote on 17/11/2009 14:36:10:
>
> Hi Joakim,
> If the inteface state is Waiting, then the BackupSeen event is scheduled. For
> more advanced interface states, the NeighborChange event is scheduled. You
> would never schedule both of them.
> Hope this Helps,

Yes it does, thanks.
Clarification though: "never schedule both of them" is that
per bullet?
If the first bullet schedules either a BackupSeen or NeighborChange should
the next bullet be skipped?

New question same chaper(10.5) there is:
        When receiving an Hello Packet from a neighbor on a broadcast,
        Point-to-MultiPoint or NBMA network, set the neighbor
        structure's Neighbor ID equal to the Router ID found in the
        packet's OSPF header.  For these network types, the neighbor
        structure's Router Priority field, Neighbor's Designated Router
        field, and Neighbor's Backup Designated Router field are also
        set equal to the corresponding fields found in the received
        Hello Packet; changes in these fields should be noted for
        possible use in the steps below.  When receiving an Hello on a
        point-to-point network (but not on a virtual link) set the
        neighbor structure's Neighbor IP address to the packet's IP
        source address.

I don't understand how virtual link fits. Should a Vlink
be considered to be in the same group as
"broadcast, Point-to-MultiPoint or NBMA network" or is
it its own group? If so what should be for vlinks?

  Jocke

---

From: Acee Lindem <[email-masked]>
Date: Tue, 17 Nov 2009 10:40:10 -0500

Hi Joakim,  

|-----Original Message-----
|From: Joakim Tjernlund [mailto:[email-masked]] 
|Sent: Tuesday, November 17, 2009 10:24 AM
|To: Acee Lindem
|Cc: [email-masked]
|Subject: RE: [OSPF] Neighbour processing
|
|Acee Lindem <[email-masked]> wrote on 17/11/2009 14:36:10:
|>
|> Hi Joakim,
|> If the inteface state is Waiting, then the BackupSeen event is 
|> scheduled. For more advanced interface states, the NeighborChange 
|> event is scheduled. You would never schedule both of them.
|> Hope this Helps,
|
|Yes it does, thanks.
|Clarification though: "never schedule both of them" is that per bullet?
|If the first bullet schedules either a BackupSeen or 
|NeighborChange should the next bullet be skipped?

Yes. Only one bullet is applicable and the conditions predicating each bullet should be mutually exclusive. 

|
|New question same chaper(10.5) there is:
|        When receiving an Hello Packet from a neighbor on a broadcast,
|        Point-to-MultiPoint or NBMA network, set the neighbor
|        structure's Neighbor ID equal to the Router ID found in the
|        packet's OSPF header.  For these network types, the neighbor
|        structure's Router Priority field, Neighbor's Designated Router
|        field, and Neighbor's Backup Designated Router field are also
|        set equal to the corresponding fields found in the received
|        Hello Packet; changes in these fields should be noted for
|        possible use in the steps below.  When receiving an Hello on a
|        point-to-point network (but not on a virtual link) set the
|        neighbor structure's Neighbor IP address to the packet's IP
|        source address.
|
|I don't understand how virtual link fits. Should a Vlink be 
|considered to be in the same group as "broadcast, 
|Point-to-MultiPoint or NBMA network" or is it its own group? 
|If so what should be for vlinks?

A virtual link will have the same interface states as a point-to-point interface except the Loopback state isn't applicable. Also, the InterfaceUp event only occurs when the virtual link endpoint is reachable across the transit area.  

Thanks,
Acee 

|
|  Jocke
|
|> Acee
|>
|> |-----Original Message-----
|> |From: [email-masked] [mailto:[email-masked]] 
|On Behalf 
|> |Of Joakim Tjernlund
|> |Sent: Tuesday, November 17, 2009 7:20 AM
|> |To: [email-masked]
|> |Subject: [OSPF] Neighbour processing
|> |
|> |
|> |I OSPF RFC 2328, chap 10.5 one can read:
|> |        o   If the neighbor is both declaring itself to be 
|Designated
|> |            Router (Hello Packet's Designated Router field 
|= Neighbor 
|> |IP
|> |            address) and the Backup Designated Router field in the
|> |            packet is equal to 0.0.0.0 and the receiving 
|interface is 
|> |in
|> |            state Waiting, the receiving interface's state 
|machine is
|> |            scheduled with the event BackupSeen.  Otherwise, if the
|> |            neighbor is declaring itself to be Designated 
|Router and it
|> |            had not previously, or the neighbor is not 
|declaring itself
|> |            Designated Router where it had previously, the receiving
|> |            interface's state machine is scheduled with the event
|> |            NeighborChange.
|> |
|> |        o   If the neighbor is declaring itself to be 
|Backup Designated
|> |            Router (Hello Packet's Backup Designated Router field =
|> |            Neighbor IP address) and the receiving interface is in 
|> |state
|> |            Waiting, the receiving interface's state machine is
|> |            scheduled with the event BackupSeen.  Otherwise, if the
|> |            neighbor is declaring itself to be Backup 
|Designated Router
|> |            and it had not previously, or the neighbor is 
|not declaring
|> |            itself Backup Designated Router where it had 
|previously, 
|> |the
|> |            receiving interface's state machine is 
|scheduled with the
|> |            event NeighborChange.
|> |
|> |I wonder about the Otherwise, .. part in these two bullets:
|> |Should this be read as iff the first part before the 
|"Otherwise, .." 
|> |is false only the the otherwise part should be performed? in other 
|> |words, can each bullet generate a BackupSeen AND NeighborChange or 
|> |only one of them?
|> |
|> |Does the order matter, i.e is it valid to schedule two BackupSeen 
|> |then two NeighborChange?
|> |Or should/must it be in order?
|> |
|> |           Jocke
|> |
|> |_______________________________________________
|> |OSPF mailing list
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/ospf
|> |
|>
|
|

---

From: Joakim Tjernlund <[email-masked]>
Date: Tue, 17 Nov 2009 16:50:29 +0100

> should be mutually exclusive.

Thanks, this makes sense.

> A virtual link will have the same interface states as a point-to-point
> interface except the Loopback state isn't applicable. Also, the InterfaceUp
> event only occurs when the virtual link endpoint is reachable across the transit area.

This seems to indicate that I should treat a Vlink the same as a p2p link above,
however the paragraph explicitly say I should not so now I am confused :)
Exactly what should be done to a Vlink in the above context?

---

From: Acee Lindem <[email-masked]>
Date: Tue, 17 Nov 2009 17:52:42 -0500

Hi Joakim,
See inline.  

|-----Original Message-----
|From: Joakim Tjernlund [mailto:[email-masked]] 
|Sent: Tuesday, November 17, 2009 10:50 AM
|To: Acee Lindem
|Cc: [email-masked]
|Subject: RE: [OSPF] Neighbour processing
|
|Acee Lindem <[email-masked]> wrote on 17/11/2009 16:40:10:
|>
|> |-----Original Message-----
|> |From: Joakim Tjernlund [mailto:[email-masked]]
|> |Sent: Tuesday, November 17, 2009 10:24 AM
|> |To: Acee Lindem
|> |Cc: [email-masked]
|> |Subject: RE: [OSPF] Neighbour processing
|> |
|> |Acee Lindem <[email-masked]> wrote on 17/11/2009 14:36:10:
|> |>
|> |> Hi Joakim,
|> |> If the inteface state is Waiting, then the BackupSeen event is 
|> |> scheduled. For more advanced interface states, the NeighborChange 
|> |> event is scheduled. You would never schedule both of them.
|> |> Hope this Helps,
|> |
|> |Yes it does, thanks.
|> |Clarification though: "never schedule both of them" is that 
|per bullet?
|> |If the first bullet schedules either a BackupSeen or NeighborChange 
|> |should the next bullet be skipped?
|>
|> Yes. Only one bullet is applicable and the conditions 
|predicating each 
|> bullet should be mutually exclusive.
|
|Thanks, this makes sense.
|
|>
|> |
|> |New question same chaper(10.5) there is:
|> |        When receiving an Hello Packet from a neighbor on a 
|broadcast,
|> |        Point-to-MultiPoint or NBMA network, set the neighbor
|> |        structure's Neighbor ID equal to the Router ID found in the
|> |        packet's OSPF header.  For these network types, the neighbor
|> |        structure's Router Priority field, Neighbor's 
|Designated Router
|> |        field, and Neighbor's Backup Designated Router 
|field are also
|> |        set equal to the corresponding fields found in the received
|> |        Hello Packet; changes in these fields should be noted for
|> |        possible use in the steps below.  When receiving an 
|Hello on a
|> |        point-to-point network (but not on a virtual link) set the
|> |        neighbor structure's Neighbor IP address to the packet's IP
|> |        source address.
|> |
|> |I don't understand how virtual link fits. Should a Vlink be 
|> |considered to be in the same group as "broadcast, 
|Point-to-MultiPoint 
|> |or NBMA network" or is it its own group?
|> |If so what should be for vlinks?
|>
|> A virtual link will have the same interface states as a 
|point-to-point 
|> interface except the Loopback state isn't applicable. Also, the 
|> InterfaceUp event only occurs when the virtual link endpoint 
|is reachable across the transit area.
|
|This seems to indicate that I should treat a Vlink the same as 
|a p2p link above, however the paragraph explicitly say I 
|should not so now I am confused :) Exactly what should be done 
|to a Vlink in the above context?

This statement only refers to the setting of the Neighbor IP address in the RFC's reference Neighbor data structure. For virtual links, this address should be as described in the second full bullet on page 159 (Section 15) in RFC 2328. 

Hope this helps,
Acee  

|
|

---

From: Joakim Tjernlund <[email-masked]>
Date: Wed, 18 Nov 2009 11:54:16 +0100

Acee Lindem <[email-masked]> wrote on 17/11/2009 23:52:42:
> This statement only refers to the setting of the Neighbor IP address in the
> RFC's reference Neighbor data structure. For virtual links, this address

Yes and that was what I wondered about. The stmt does not cover Vlinks I think
so what should one do with Neighbour data when the link in question is a Vlink?

Why should one only set the Neighbor IP address for a PtoP link?
What should Neighbor IP address be for the other link types?

> should be as described in the second full bullet on page 159 (Section 15) in RFC 2328.

---

From: Acee Lindem <[email-masked]>
Date: Wed, 18 Nov 2009 12:35:40 -0500

Joakim - see inline. 

|-----Original Message-----
|From: Joakim Tjernlund [mailto:[email-masked]] 
|Sent: Wednesday, November 18, 2009 5:54 AM
|To: Acee Lindem
|Cc: [email-masked]
|Subject: RE: [OSPF] Neighbour processing
|
|Acee Lindem <[email-masked]> wrote on 17/11/2009 23:52:42:
|>
|> Hi Joakim,
|> See inline.
|>
|> |-----Original Message-----
|> |From: Joakim Tjernlund [mailto:[email-masked]]
|> |Sent: Tuesday, November 17, 2009 10:50 AM
|> |To: Acee Lindem
|> |Cc: [email-masked]
|> |Subject: RE: [OSPF] Neighbour processing
|> |
|> |Acee Lindem <[email-masked]> wrote on 17/11/2009 16:40:10:
|> |>
|> |> |-----Original Message-----
|> |> |From: Joakim Tjernlund [mailto:[email-masked]]
|> |> |Sent: Tuesday, November 17, 2009 10:24 AM
|> |> |To: Acee Lindem
|> |> |Cc: [email-masked]
|> |> |Subject: RE: [OSPF] Neighbour processing
|> |> |
|> |> |Acee Lindem <[email-masked]> wrote on 
|17/11/2009 14:36:10:
|> |> |>
|> |> |> Hi Joakim,
|> |> |> If the inteface state is Waiting, then the BackupSeen event is 
|> |> |> scheduled. For more advanced interface states, the 
|> |> |> NeighborChange event is scheduled. You would never 
|schedule both of them.
|> |> |> Hope this Helps,
|> |> |
|> |> |Yes it does, thanks.
|> |> |Clarification though: "never schedule both of them" is that
|> |per bullet?
|> |> |If the first bullet schedules either a BackupSeen or 
|> |> |NeighborChange should the next bullet be skipped?
|> |>
|> |> Yes. Only one bullet is applicable and the conditions
|> |predicating each
|> |> bullet should be mutually exclusive.
|> |
|> |Thanks, this makes sense.
|> |
|> |>
|> |> |
|> |> |New question same chaper(10.5) there is:
|> |> |        When receiving an Hello Packet from a neighbor on a
|> |broadcast,
|> |> |        Point-to-MultiPoint or NBMA network, set the neighbor
|> |> |        structure's Neighbor ID equal to the Router ID 
|found in the
|> |> |        packet's OSPF header.  For these network types, 
|the neighbor
|> |> |        structure's Router Priority field, Neighbor's
|> |Designated Router
|> |> |        field, and Neighbor's Backup Designated Router
|> |field are also
|> |> |        set equal to the corresponding fields found in 
|the received
|> |> |        Hello Packet; changes in these fields should be noted for
|> |> |        possible use in the steps below.  When receiving an
|> |Hello on a
|> |> |        point-to-point network (but not on a virtual 
|link) set the
|> |> |        neighbor structure's Neighbor IP address to the 
|packet's IP
|> |> |        source address.
|> |> |
|> |> |I don't understand how virtual link fits. Should a Vlink be 
|> |> |considered to be in the same group as "broadcast,
|> |Point-to-MultiPoint
|> |> |or NBMA network" or is it its own group?
|> |> |If so what should be for vlinks?
|> |>
|> |> A virtual link will have the same interface states as a
|> |point-to-point
|> |> interface except the Loopback state isn't applicable. Also, the 
|> |> InterfaceUp event only occurs when the virtual link endpoint
|> |is reachable across the transit area.
|> |
|> |This seems to indicate that I should treat a Vlink the same 
|as a p2p 
|> |link above, however the paragraph explicitly say I should 
|not so now 
|> |I am confused :) Exactly what should be done to a Vlink in 
|the above 
|> |context?
|>
|> This statement only refers to the setting of the Neighbor IP address 
|> in the RFC's reference Neighbor data structure. For virtual links, 
|> this address
|
|Yes and that was what I wondered about. The stmt does not 
|cover Vlinks I think so what should one do with Neighbour data 
|when the link in question is a Vlink?

For virtual links, this clearly described in section 15 of RFC 2328:

    o   Just as the virtual link's cost and viability are determined by
        the routing table build process (through construction of the
        routing table entry for the other endpoint), so are the IP
        interface address for the virtual interface and the virtual
        neighbor's IP address.  These are used when sending OSPF
        protocol packets over the virtual link. Note that when one (or
        both) of the virtual link endpoints connect to the Transit area
        via an unnumbered point-to-point link, it may be impossible to
        calculate either the virtual interface's IP address and/or the
        virtual neighbor's IP address, thereby causing the virtual link
        to fail. 

|
|Why should one only set the Neighbor IP address for a PtoP link?
|What should Neighbor IP address be for the other link types?

In the paragraph preceding the one in question, it clearly states that the source for broadcast, P2MP, and NBMA networks is identified by the IP source address. It doesn't state explicitly that you should save it in the RFC's reference neighbor data structure but this is implied. 

        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.

Hope this Helps, 
Acee 

|
|> should be as described in the second full bullet on page 159 
|(Section 15) in RFC 2328.
|
|
|

---

From: Joakim Tjernlund <[email-masked]>
Date: Wed, 18 Nov 2009 19:46:09 +0100

Acee Lindem <[email-masked]> wrote on 18/11/2009 18:35:40:
> In the paragraph preceding the one in question, it clearly states that the
> source for broadcast, P2MP, and NBMA networks is identified by the IP source
> address. It doesn't state explicitly that you should save it in the RFC's
> reference neighbor data structure but this is implied.
>

OK, this helps a lot. There is just one thing I don't get:
Why can you not use the packet IP src address for Vlinks?
It must have one, right?
When would this src address differ from the address calculated at route time?
Suppose one uses packet IP src address anyway, what would
the down side be?

       Jocke

---

From: Acee Lindem <[email-masked]>
Date: Wed, 18 Nov 2009 14:45:13 -0500

See inline. 

|-----Original Message-----
|From: Joakim Tjernlund [mailto:[email-masked]] 
|Sent: Wednesday, November 18, 2009 1:46 PM
|To: Acee Lindem
|Cc: [email-masked]
|Subject: RE: [OSPF] Neighbour processing
|
|Acee Lindem <[email-masked]> wrote on 18/11/2009 18:35:40:
|>
|> Joakim - see inline.
|>
|> |-----Original Message-----
|> |From: Joakim Tjernlund [mailto:[email-masked]]
|> |Sent: Wednesday, November 18, 2009 5:54 AM
|> |To: Acee Lindem
|> |Cc: [email-masked]
|> |Subject: RE: [OSPF] Neighbour processing
|> |
|> |Acee Lindem <[email-masked]> wrote on 17/11/2009 23:52:42:
|> |>
|> |> Hi Joakim,
|> |> See inline.
|> |>
|> |> |-----Original Message-----
|> |> |From: Joakim Tjernlund [mailto:[email-masked]]
|> |> |Sent: Tuesday, November 17, 2009 10:50 AM
|> |> |To: Acee Lindem
|> |> |Cc: [email-masked]
|> |> |Subject: RE: [OSPF] Neighbour processing
|> |> |
|> |> |Acee Lindem <[email-masked]> wrote on 
|17/11/2009 16:40:10:
|> |> |>
|> |> |> |-----Original Message-----
|> |> |> |From: Joakim Tjernlund [mailto:[email-masked]]
|> |> |> |Sent: Tuesday, November 17, 2009 10:24 AM
|> |> |> |To: Acee Lindem
|> |> |> |Cc: [email-masked]
|> |> |> |Subject: RE: [OSPF] Neighbour processing
|> |> |> |
|> |> |> |Acee Lindem <[email-masked]> wrote on
|> |17/11/2009 14:36:10:
|> |> |> |>
|> |> |> |> Hi Joakim,
|> |> |> |> If the inteface state is Waiting, then the BackupSeen event 
|> |> |> |> is scheduled. For more advanced interface states, the 
|> |> |> |> NeighborChange event is scheduled. You would never
|> |schedule both of them.
|> |> |> |> Hope this Helps,
|> |> |> |
|> |> |> |Yes it does, thanks.
|> |> |> |Clarification though: "never schedule both of them" is that
|> |> |per bullet?
|> |> |> |If the first bullet schedules either a BackupSeen or 
|> |> |> |NeighborChange should the next bullet be skipped?
|> |> |>
|> |> |> Yes. Only one bullet is applicable and the conditions
|> |> |predicating each
|> |> |> bullet should be mutually exclusive.
|> |> |
|> |> |Thanks, this makes sense.
|> |> |
|> |> |>
|> |> |> |
|> |> |> |New question same chaper(10.5) there is:
|> |> |> |        When receiving an Hello Packet from a neighbor on a
|> |> |broadcast,
|> |> |> |        Point-to-MultiPoint or NBMA network, set the neighbor
|> |> |> |        structure's Neighbor ID equal to the Router ID
|> |found in the
|> |> |> |        packet's OSPF header.  For these network types,
|> |the neighbor
|> |> |> |        structure's Router Priority field, Neighbor's
|> |> |Designated Router
|> |> |> |        field, and Neighbor's Backup Designated Router
|> |> |field are also
|> |> |> |        set equal to the corresponding fields found in
|> |the received
|> |> |> |        Hello Packet; changes in these fields should 
|be noted for
|> |> |> |        possible use in the steps below.  When receiving an
|> |> |Hello on a
|> |> |> |        point-to-point network (but not on a virtual
|> |link) set the
|> |> |> |        neighbor structure's Neighbor IP address to the
|> |packet's IP
|> |> |> |        source address.
|> |> |> |
|> |> |> |I don't understand how virtual link fits. Should a Vlink be 
|> |> |> |considered to be in the same group as "broadcast,
|> |> |Point-to-MultiPoint
|> |> |> |or NBMA network" or is it its own group?
|> |> |> |If so what should be for vlinks?
|> |> |>
|> |> |> A virtual link will have the same interface states as a
|> |> |point-to-point
|> |> |> interface except the Loopback state isn't applicable. 
|Also, the 
|> |> |> InterfaceUp event only occurs when the virtual link endpoint
|> |> |is reachable across the transit area.
|> |> |
|> |> |This seems to indicate that I should treat a Vlink the same
|> |as a p2p
|> |> |link above, however the paragraph explicitly say I should
|> |not so now
|> |> |I am confused :) Exactly what should be done to a Vlink in
|> |the above
|> |> |context?
|> |>
|> |> This statement only refers to the setting of the Neighbor IP 
|> |> address in the RFC's reference Neighbor data structure. 
|For virtual 
|> |> links, this address
|> |
|> |Yes and that was what I wondered about. The stmt does not cover 
|> |Vlinks I think so what should one do with Neighbour data when the 
|> |link in question is a Vlink?
|>
|> For virtual links, this clearly described in section 15 of RFC 2328:
|>
|>     o   Just as the virtual link's cost and viability are 
|determined by
|>         the routing table build process (through construction of the
|>         routing table entry for the other endpoint), so are the IP
|>         interface address for the virtual interface and the virtual
|>         neighbor's IP address.  These are used when sending OSPF
|>         protocol packets over the virtual link. Note that 
|when one (or
|>         both) of the virtual link endpoints connect to the 
|Transit area
|>         via an unnumbered point-to-point link, it may be 
|impossible to
|>         calculate either the virtual interface's IP address 
|and/or the
|>         virtual neighbor's IP address, thereby causing the 
|virtual link
|>         to fail.
|>
|>
|> |
|> |Why should one only set the Neighbor IP address for a PtoP link?
|> |What should Neighbor IP address be for the other link types?
|>
|>
|> In the paragraph preceding the one in question, it clearly 
|states that 
|> the source for broadcast, P2MP, and NBMA networks is 
|identified by the 
|> IP source address. It doesn't state explicitly that you 
|should save it 
|> in the RFC's reference neighbor data structure but this is implied.
|>
|>         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.
|>
|> Hope this Helps,
|> Acee
|
|OK, this helps a lot. There is just one thing I don't get:
|Why can you not use the packet IP src address for Vlinks?
|It must have one, right?

I'm sure some implementations do just that :^) However, the intent of the protocol is that the control packets take the same path as OSPF computes across the transit area. 

|When would this src address differ from the address calculated 
|at route time?

When the routing across the transit area is asymetric. 

|Suppose one uses packet IP src address anyway, what would the 
|down side be?

If the routing asymetric, there could possibly be inconsistencies between the data plane and control plane. 

Hope this helps,
Acee

|
|       Jocke
|
|

---

From: Joakim Tjernlund <[email-masked]>
Date: Thu, 19 Nov 2009 09:15:00 +0100

Acee Lindem <[email-masked]> wrote on 18/11/2009 20:45:13:
> I'm sure some implementations do just that :^) However, the intent of the
> protocol is that the control packets take the same path as OSPF computes
> across the transit area.
>
>

Is there any case where using IP src is better? I am thinking about this
stmt in section 15:
        Note that when one (or

Would using IP src help when one fails to calculate neighbor's IP address?

 Jocke

---

From: Acee Lindem <[email-masked]>
Date: Thu, 19 Nov 2009 09:02:04 -0500

|-----Original Message-----
|From: Joakim Tjernlund [mailto:[email-masked]] 
|Sent: Thursday, November 19, 2009 3:15 AM
|To: Acee Lindem
|Cc: [email-masked]
|Subject: RE: [OSPF] Neighbour processing
|
|Acee Lindem <[email-masked]> wrote on 18/11/2009 20:45:13:
|> See inline.
|>
|> |OK, this helps a lot. There is just one thing I don't get:
|> |Why can you not use the packet IP src address for Vlinks?
|> |It must have one, right?
|>
|> I'm sure some implementations do just that :^) However, the 
|intent of 
|> the protocol is that the control packets take the same path as OSPF 
|> computes across the transit area.
|>
|>
|> |When would this src address differ from the address calculated at 
|> |route time?
|>
|> When the routing across the transit area is asymetric.
|>
|>
|> |Suppose one uses packet IP src address anyway, what would the down 
|> |side be?
|>
|> If the routing asymetric, there could possibly be inconsistencies 
|> between the data plane and control plane.
|
|Is there any case where using IP src is better? I am thinking 
|about this stmt in section 15:
|        Note that when one (or
|        both) of the virtual link endpoints connect to the Transit area
|        via an unnumbered point-to-point link, it may be impossible to
|        calculate either the virtual interface's IP address and/or the
|        virtual neighbor's IP address, thereby causing the virtual link
|        to fail.
|
|Would using IP src help when one fails to calculate neighbor's 
|IP address?

I don't see a requirement for this. OSPFv2 has been deployed in the largest networks since the mid-90s and this restriction hasn't been a concern. 
Thanks,
Acee

|
| Jocke
|
|