[Xorp-users] Fwd: Questions on OSPF
Atanu Ghosh
atanu at ICSI.Berkeley.EDU
Wed Sep 19 08:44:35 PDT 2007
Hi,
If you want to announce static routes then you need to use
policy. Connected routes that not already being advertised due to OSPF
being configured on the interface can be advertised using
policy. Another strategy for connected routes for interfaces that are
not configured for OSPF is to configure the interface but mark it as
passive, if an interface is marked as passive then no protocol
interactions will be attempted but the subnet will be announced. There
was a bug that marking an interface as passive only advertised the host
route, but I think that this was fixed.
Atanu.
>>>>> "Hansi" == Hansi <hantongs at gmail.com> writes:
Hansi> Hello Atanu, How about static routes and connected routes?
Hansi> Do I still need to explicitly use policies in order for them
Hansi> to be announced? What I'm seeing on a network dump is only
Hansi> indeed the subnet for the interfaces on w/c OSPF is
Hansi> configured. I also want OSPF to announce static and connected
Hansi> routes just like what is done w/ RIP when policy static and
Hansi> connected is exported, can this be possible? Thanks Hansi.
Hansi> On 9/19/07, Atanu Ghosh <atanu at icsi.berkeley.edu> wrote:
Hansi> Hi, OSPF will advertise the the subnets for the
Hansi> interfaces on which it is configured. In the case of OSPFv2
Hansi> one subnet has to be explicitly configured in the config, for
Hansi> OSPFv3 just specifying the interface will advertise all
Hansi> associated subnets (the subnets can also be explicitly
Hansi> configured). Routes from other protocols must be explicity
Hansi> exported using policy. Atanu.
>>>>>> "Hansi" == Hansi < hantongs at gmail.com> writes:
Hansi> looping in the mailing list. Thank you. One more question
Hansi> though.. I noticed that before RIP can be configured, the
Hansi> policy parameter must be set first in order for RIP to either
Hansi> advertise static and/or connected routes. Although RIP
Hansi> already sends out udp packets once you configure it, it does
Hansi> not send out its routing table entries not until after a
Hansi> policy is either imported/exported to it. Does this also
Hansi> apply to OSPF? Thanks. Hansi. On 9/14/07, Kristian Larsson
Hansi> < kristian at spritelink.net> wrote: Hansi wrote:
>>> Hello Kristian, Atanu,
>>>
>>> Thank you answering for my queries. Let me see if I
Hansi> understood it clearly.
>>> For link-types: p2p or p2m, it is necessary to explicitly
Hansi> set
>>> the neighbor parameter in order for the router running OSPF
Hansi> to establish
>>> adjacency with another router. Broadcast link-types on the
Hansi> other hand
>>> does not require the neighbor parameter to be explicitly
Hansi> set, am I
>>> correct? :)
>>>
>>> I concur with Atanu that p2p link-types requires the
Hansi> neighbor statement
>>> to be explicitly stated. My initial configuration does not
Hansi> include
>>> setting the neighbor parameter, upon invoking "show ospf4
Hansi> neighbor",
>>> nothing comes up even though dumps from the network shows
Hansi> OSPF hello
>>> packets have been multicast already.. The neighbor router
Hansi> only displays
>>> [upon invoking show ospf4 neighbor] after setting the
Hansi> neighbor parameter
>>> on both routers.
Hansi> Yepp, I was simply wrong. I expected XORP to work like Cisco
Hansi> or Juniper.
>>> Regarding setting router-ID parameters to loopback 127.0.0.1
Hansi> <
>>> http://127.0.0.1>, would it be possible for two routers
Hansi> running OSPF to
>>> use the same router-ID? that is both of them are configured
Hansi> to 127.0.0.1
>>> < http://127.0.0.1>? Since conventionally the router-ID is
Hansi> usually set to
>>> the loopback, would it be possible to configure all routers
Hansi> in an OSPF
>>> network to have the same router-ID of 127.0.0.1
Hansi> <http://127.0.0.1>? No, you cannot use 127.0.0.1, at least
Hansi> not on both routers. Router-id have to be unique within your
Hansi> OSPF domain, one common way of ensuring this is to use the
Hansi> loopback address that you assign to a router. Although you
Hansi> are correct that 127.0.0.1 is a loopback adress, routes
Hansi> normally get one assigned from your address pool. iBGP
Hansi> session for example are normally established between loopback
Hansi> addresses to not be dependant upon a specific interface being
Hansi> up. So assign 172.16.0.1-254 (if your are using private
Hansi> addressing) or something to your loopbacks as well and you
Hansi> can use those. -K
>>> On 9/14/07, * kristian at spritelink.net <mailto:
Hansi> kristian at spritelink.net>* <
>>> kristian at spritelink.net <mailto:kristian at spritelink.net>>
Hansi> wrote:
>>> On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh <
>>> atanu at icsi.berkeley.edu <mailto:atanu at icsi.berkeley.edu >>
Hansi> wrote:
>>> >>>>>> "kristian" == kristian < kristian at spritelink.net <mailto:
>>> kristian at spritelink.net>> writes:
>>> >
>>> > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu
Hansi> Ghosh
>>> > kristian> < atanu at icsi.berkeley.edu <mailto:
>>> atanu at icsi.berkeley.edu>> wrote: > >>>>>>> "kristian" ==
Hansi> kristian
>>> <
Hansi> kristian at spritelink.net
>>> <mailto: kristian at spritelink.net>> writes:
>>> > >>
>>> > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu
Hansi> Ghosh
>>> > kristian> < atanu at icsi.berkeley.edu <mailto:
>>> atanu at icsi.berkeley.edu>> wrote: > >> >>>>>>> "Kristian" ==
>>> Kristian Larsson < kristian at spritelink.net <mailto:
>>> kristian at spritelink.net>> > >> >>>>>>> writes:
>>> > >> >>
>>> > Kristian> Hansi wrote: > >> >> >> Hello All,
>>> > >> >> >>
>>> > >> >> >> I'm currently learning how to configure
Hansi> OSPFv2 on
>>> two XORP > >> >> >> machines just to establish adjacency
Hansi> with one
>>> another. In a > >> p2p >> >> link type, is it still
Hansi> necessary to explicitly
>>> set the > >> >> 'neighbor' >> parameter of each machine
Hansi> before
>>> adjacency is >> > >> established? >> Furthermore, would it
Hansi> be
>>> possible
Hansi> to set
>>> the >> > >> router-id to its >> loopback address? instead of
Hansi> say.. the
>>> ip >> > >> address of the >> interface on which ospf will be
Hansi> used?
>>> > >> >> > Kristian> The neighbor command is only useful if
Hansi> you are using a
>>> > Kristian> medium on which the routers cannot broadcast
Hansi> and thus
>>> > Kristian> cannot discover each other. If you're using
Hansi> ethernet
>>> > Kristian> (which I presume from your NIC names) you do
Hansi> not
>>> have to > Kristian> use the neighbor statements. I would
Hansi> advice configuring
>>> > Kristian> the interfaces as link-type p2p as this
Hansi> avoids DR
>>> election > Kristian> and unnecessary CPU load. > >> >> I am
>>> fairly sure that it is necessary to use
Hansi> the
>>> neighbour >> > >> statements.
>>> > >>
>>> > kristian> Are you serious? I haven't used the XORP
Hansi> code in
>>> quite > kristian> some time now.. but at least I thought
Hansi> XORP implemented
>>> > kristian> the OSPF standard. AFAIK, that includes
Hansi> being able to
>>> > kristian> discover neighbors and turn up adjacencies
Hansi> to them. Is
>>> > kristian> this not the case? Observe that he is
Hansi> running an
>>> Ethernet > kristian> point-to-point link, ie, it is not a
Hansi> non-broadcast
>>> medium. > kristian> Or are you saying that you can't do
Hansi> link-type p2p
>>> without > kristian> configuring neighbours ?
>>> >
>>> > >> If the link-type is set to "broadcast" then the
Hansi> neighbours
>>> will > >> be correctly discovered. If the link-type is set
Hansi> to "p2p"
>>> > >> (Point-to-point) or "p2m" (Point-to-multipoint)
Hansi> then it is
>>> > >> necessary to configure the neighbours. It has been
Hansi> argued
>>> that it > >> should not be necessary to configure the
Hansi> neighbours if the
>>> > >> routers are connected via a true Point-to-point
Hansi> link, but
>>> > >> unfortunately even in this case it is necessary to
Hansi> configure
>>> the > >> neighbour.
>>> >
>>> > kristian> Okey, that "kinda" makes sense. I apparently
Hansi> forgot or
>>> > kristian> missed the conversation on this. What I
Hansi> want to
>>> configure > kristian> with link-type p2p is not whether or
Hansi> not
>>> the
Hansi> router
>>> should > kristian> try to broadcast but if it should setup
Hansi> one of those
>>> > kristian> virtual router thingys, hehe. I'm not very
Hansi> familiar
>>> with > kristian> the terminology but (as you know) on a
Hansi> broadcast medium
>>> > kristian> you first have a DR selection and all that
Hansi> and then
>>> you're > kristian> gonna run your SPF. Since SPF can't
Hansi> handle the
>>> concept of > kristian> a broadcast medium it creates a
Hansi> "virtual router" to
>>> > kristian> represent the broadcast medium and connects
Hansi> all
>>> routers in > kristian> that broadcast domain as adjacencies
Hansi> to
>>> the
Hansi> virtual
>>> > kristian> router. When I configure 'isis network
>>> point-to-point' on > kristian> a Cisco router I expect it to
Hansi> not
>>> setup one
Hansi> of these
>>> > kristian> "virtual routers" in it's SPF topology. And
Hansi> this is
>>> > kristian> different with XORP?
>>> >
>>> > Setting the link type to "broadcast" or "p2p" will both
Hansi> result in
>>> the > hello packets being broadcast, the distinction is that
Hansi> if the
>>> link-type > is set to "p2p" no DR election will be
Hansi> attempted.
>>> Alright, just as I expected.
>>>
>>> > The XORP OSPF behaves > as specified in the relevant RFCs
Hansi> and
>>> interoperates with
Hansi> other OSPF
>>> > implementations, the only difference is in configuration
Hansi> of a "p2p"
>>> > where we require the neighbour to be specified, which as I
Hansi> mentioned
>>> > before should not strictly be necessary.
>>>
>>> Okey, not what I expected. Why is it so? Just lack of time
Hansi> to do the
>>> actual implementation (although I don't see how it would
Hansi> actually
>>> be
Hansi> more code
>>> than it is today) or has there been a policy decision
Hansi> against it?
>>> -K
>>>
>>>
Hansi> _______________________________________________ Xorp-users
Hansi> mailing list Xorp-users at xorp.org
Hansi>
Hansi>
Hansi> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
More information about the Xorp-users
mailing list