From: Edwards, Andrew M (andrew.m.edwards@boeing.com)
Date: Wed Feb 01 2006 - 13:56:28 GMT-3
Nick
In answer to your question, "Where do the spokes find how to make their
adjacency?"
Your answer is in RFC 2328: OSPF v2
The part that's important follows my explaination (suggest you read it),
but basically its this way for non-broadcast networks:
If a router is capable of being a DR/BDR, then it sends packets every
hello interval to the specified unicast neighbor addresses.
If a router is not capable of being a DR/BDR it sends unicast hello
packets to the DR/BDR on the segment (if they exist); and it also must
respond to any hello packets it receives (from either DR/BDR or other
received hellos).
So, basically, the spokes reply to the unicast source address of the hub
hello packet. Or, as the second statement implies, if a spoke is
configured with a unicast neighbor it should be the DR/BDR for the
segment so it can direct its hello packets to them.
Now, we know having partial mesh hub/spoke over frame-relay keep the
spokes from effectively being on the same segment. So, not all OSPF
routers can see all others. The only one that can is the hub that's why
it's made the DR at all times by the engineer (via some method). And,
since none of the spokes can reach the other spokes directly, they
should not be the BDR at any time, so they are configured this way by
the engineer.
Configuration-wise, I know of two methods to achieve these goals with
implied restrictions:
1. spoke interfaces set with priority 0 and hub set with neighbor
unicast address of spokes
2. spoke interfaces set with priority 0. set each spoke with the hub
unicast address as a neighbor (e.g. no hub configuration required)
Anyhow, here's the RFC 2328 stuff that's important:
"9.5.1. Sending Hello packets on NBMA networks
Static configuration information may be necessary in order for the Hello
Protocol to function on non-broadcast networks (see Sections C.5 and
C.6). On NBMA networks, every attached router which is eligible to
become Designated Router becomes aware of all of its neighbors on the
network (either through configuration or by some unspecified mechanism).
Each neighbor is labelled with the neighbor's Designated Router
eligibility.
The interface state must be at least Waiting for any Hello Packets to be
sent out the NBMA interface. Hello Packets are then sent directly (as
unicasts) to some subset of a router's neighbors. Sometimes an Hello
Packet is sent periodically on a timer; at other times it is sent as a
response to a received Hello Packet. A router's hello- sending behavior
varies depending on whether the router itself is eligible to become
Designated Router.
If the router is eligible to become Designated Router, it must
periodically send Hello Packets to all neighbors that are also eligible.
In addition, if the router is itself the Designated Router or Backup
Designated Router, it must also send periodic Hello Packets to all other
neighbors. This means that any two eligible routers are always
exchanging Hello Packets, which is necessary for the correct operation
of the Designated Router election algorithm. To minimize the number of
Hello Packets sent, the number of eligible routers on an NBMA network
should be kept small.
If the router is not eligible to become Designated Router, it must
periodically send Hello Packets to both the Designated Router and the
Backup Designated Router (if they exist). It must also send an Hello
Packet in reply to an Hello Packet received from any eligible neighbor
(other than the current Designated Router and Backup Designated Router).
This is needed to establish an initial bidirectional relationship with
any potential Designated Router.
When sending Hello packets periodically to any neighbor, the interval
between Hello Packets is determined by the neighbor's state. If the
neighbor is in state Down, Hello Packets are sent every PollInterval
seconds. Otherwise, Hello Packets are sent every HelloInterval seconds."
http://www.faqs.org/rfcs/rfc2328.html
HTH,
Andrew M. Edwards
CCIE No. 15334
562-797-4454
800-946-4646 pin 6024349
This archive was generated by hypermail 2.1.4 : Wed Mar 01 2006 - 11:28:17 GMT-3