[Xorp-users] Fwd: Questions on OSPF
Kristian Larsson
kristian at spritelink.net
Tue Sep 18 00:55:57 PDT 2007
Atanu,
could you perhaps add a note about this on the xorp.org site (under the
Getting started section). Ie, that using a lo is recommended and how to
configure it.
Kristian.
Kristian Larsson wrote:
> Hansi wrote:
>> including the mailing list
>
> Sorry for not replying earlier.
>
>> hmm... seems like after changing my loopback address from 127.0.0.1
>> <http://127.0.0.1> to any private address such as 172.16.0.1
>> <http://172.16.0.1>, this error was encountered:
>
> Yes, XORP uses the loopback interface for IPC communication, it
> therefore by default, binds to 127.0.0.1. You should not replace
> 127.0.0.1 with 172.16.0.1 but rather just add 172.16.0.1
> Can be accomplished with
>
> ip address add 172.16.0.1/32 dev lo
>
> on a Linux machine.
>
> Kristian.
>
>
>>
>> [ 2007/09/17 16:53:31 ERROR xorp_rtrmgr:6201 LIBCOMM +359 comm_sock.c
>> comm_sock_bind4 ] Error binding socket (family = 2, my_addr =
>> 127.0.0.1 <http://127.0.0.1>, my_port = 19999): Cannot assign
>> requested address
>> [ 2007/09/17 16:53:31 ERROR xorp_rtrmgr:6201 RTRMGR +243
>> main_rtrmgr.cc run ] Cannot assign requested address: a finder may
>> already be running.
>>
>> seems like the rtrmgr binds to 127.0.0.1 <http://127.0.0.1> only. is
>> there any way to change this? just in case i want my router-id to bind
>> to a loopback interface with a private assigned IP instead of
>> 127.0.0.1 <http://127.0.0.1>? :)
>>
>>
>> On 9/17/07, * Hansi* <hantongs at gmail.com <mailto:hantongs at gmail.com>>
>> wrote:
>>
>> Thank you Kristian. One more question though.. I noticed that before
>> RIP can be configured, the policy parameter must be set first in
>> order for RIP to either advertise static and/or connected routes.
>> Although RIP already sends out udp packets once you configure it,
>> it does not send out its routing table entries not until after a
>> policy is either imported/exported to it. Does this also apply to
>> OSPF?
>>
>> Thanks.
>> Hansi.
>>
>>
>> On 9/14/07, *Kristian Larsson* < kristian at spritelink.net
>> <mailto:kristian at spritelink.net>> wrote:
>>
>> Hansi wrote:
>> > Hello Kristian, Atanu,
>> >
>> > Thank you answering for my queries. Let me see if I understood
>> it clearly.
>> >
>> > For link-types: p2p or p2m, it is necessary to explicitly
>> set the
>> > neighbor parameter in order for the router running OSPF to
>> establish
>> > adjacency with another router. Broadcast link-types on the
>> other hand
>> > does not require the neighbor parameter to be explicitly
>> set, am I
>> > correct? :)
>> >
>> > I concur with Atanu that p2p link-types requires the neighbor
>> statement
>> > to be explicitly stated. My initial configuration does not
>> include
>> > setting the neighbor parameter, upon invoking "show ospf4
>> neighbor",
>> > nothing comes up even though dumps from the network shows OSPF
>> hello
>> > packets have been multicast already.. The neighbor router only
>> displays
>> > [upon invoking show ospf4 neighbor] after setting the neighbor
>> parameter
>> > on both routers.
>>
>> Yepp, I was simply wrong. I expected XORP to work like Cisco or
>> Juniper.
>>
>>
>> > Regarding setting router-ID parameters to loopback 127.0.0.1
>> <http://127.0.0.1>
>> > < http://127.0.0.1>, would it be possible for two routers
>> running OSPF to
>> > use the same router-ID? that is both of them are configured to
>> 127.0.0.1 <http://127.0.0.1>
>> > < http://127.0.0.1>? Since conventionally the router-ID is
>> usually set to
>> > the loopback, would it be possible to configure all routers in
>> an OSPF
>> > network to have the same router-ID of 127.0.0.1
>> <http://127.0.0.1> <http://127.0.0.1>?
>>
>> No, you cannot use 127.0.0.1 <http://127.0.0.1>, at least not on
>> both routers.
>> Router-id have to be unique within your OSPF domain, one common
>> way of
>> ensuring this is to use the loopback address that you assign to a
>> router. Although you are correct that 127.0.0.1
>> <http://127.0.0.1> is a loopback adress,
>> routes normally get one assigned from your address pool. iBGP
>> session
>> for example are normally established between loopback addresses
>> to not
>> be dependant upon a specific interface being up.
>> So assign 172.16.0.1-254 (if your are using private
>> addressing) or
>> something to your loopbacks as well and you can use those.
>>
>> -K
>>
>> > On 9/14/07, * kristian at spritelink.net
>> <mailto:kristian at spritelink.net> <mailto:
>> kristian at spritelink.net <mailto:kristian at spritelink.net>>* <
>> > kristian at spritelink.net <mailto:kristian at spritelink.net>
>> <mailto:kristian at spritelink.net
>> <mailto:kristian at spritelink.net>>> wrote:
>> >
>> > On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh <
>> > atanu at icsi.berkeley.edu <mailto:atanu at icsi.berkeley.edu>
>> <mailto:atanu at icsi.berkeley.edu
>> <mailto:atanu at icsi.berkeley.edu>>>
>> > wrote:
>> > >>>>>> "kristian" == kristian < kristian at spritelink.net
>> <mailto:kristian at spritelink.net>
>> > <mailto:kristian at spritelink.net
>> <mailto:kristian at spritelink.net>>> writes:
>> > >
>> > > kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu
>> Ghosh
>> > > kristian> <atanu at icsi.berkeley.edu
>> <mailto:atanu at icsi.berkeley.edu>
>> > <mailto: atanu at icsi.berkeley.edu
>> <mailto:atanu at icsi.berkeley.edu>>> wrote:
>> > > >>>>>>> "kristian" == kristian <
>> kristian at spritelink.net <mailto:kristian at spritelink.net>
>> > <mailto: kristian at spritelink.net
>> <mailto:kristian at spritelink.net>>> writes:
>> > > >>
>> > > kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu
>> Ghosh
>> > > kristian> < atanu at icsi.berkeley.edu
>> <mailto:atanu at icsi.berkeley.edu>
>> > <mailto: atanu at icsi.berkeley.edu
>> <mailto:atanu at icsi.berkeley.edu>>> wrote:
>> > > >> >>>>>>> "Kristian" == Kristian Larsson
>> > <kristian at spritelink.net <mailto:kristian at spritelink.net>
>> <mailto: kristian at spritelink.net
>> <mailto:kristian at spritelink.net>>>
>> > > >> >>>>>>> writes:
>> > > >> >>
>> > > Kristian> Hansi wrote:
>> > > >> >> >> Hello All,
>> > > >> >> >>
>> > > >> >> >> I'm currently learning how to configure
>> OSPFv2 on
>> > two XORP
>> > > >> >> >> machines just to establish adjacency
>> with one
>> > another. In a
>> > > >> p2p >> >> link type, is it still necessary to
>> explicitly
>> > set the
>> > > >> >> 'neighbor' >> parameter of each machine before
>> > adjacency is >>
>> > > >> established? >> Furthermore, would it be
>> possible to set
>> > the >>
>> > > >> router-id to its >> loopback address? instead of
>> say.. the
>> > ip >>
>> > > >> address of the >> interface on which ospf will be
>> used?
>> > > >> >>
>> > > Kristian> The neighbor command is only useful if you
>> are using a
>> > > Kristian> medium on which the routers cannot
>> broadcast and thus
>> > > Kristian> cannot discover each other. If you're
>> using ethernet
>> > > Kristian> (which I presume from your NIC names) you
>> do not
>> > have to
>> > > Kristian> use the neighbor statements. I would
>> advice configuring
>> > > Kristian> the interfaces as link-type p2p as this
>> avoids DR
>> > election
>> > > Kristian> and unnecessary CPU load.
>> > > >> >> I am fairly sure that it is necessary to
>> use the
>> > neighbour >>
>> > > >> statements.
>> > > >>
>> > > kristian> Are you serious? I haven't used the XORP
>> code in
>> > quite
>> > > kristian> some time now.. but at least I thought
>> XORP implemented
>> > > kristian> the OSPF standard. AFAIK, that includes
>> being able to
>> > > kristian> discover neighbors and turn up adjacencies
>> to them. Is
>> > > kristian> this not the case? Observe that he is
>> running an
>> > Ethernet
>> > > kristian> point-to-point link, ie, it is not a
>> non-broadcast
>> > medium.
>> > > kristian> Or are you saying that you can't do
>> link-type p2p
>> > without
>> > > kristian> configuring neighbours ?
>> > >
>> > > >> If the link-type is set to "broadcast" then the
>> > neighbours will
>> > > >> be correctly discovered. If the link-type is set
>> to "p2p"
>> > > >> (Point-to-point) or "p2m" (Point-to-multipoint)
>> then it is
>> > > >> necessary to configure the neighbours. It has
>> been argued
>> > that it
>> > > >> should not be necessary to configure the
>> neighbours if the
>> > > >> routers are connected via a true Point-to-point
>> link, but
>> > > >> unfortunately even in this case it is
>> necessary to
>> > configure the
>> > > >> neighbour.
>> > >
>> > > kristian> Okey, that "kinda" makes sense. I
>> apparently forgot or
>> > > kristian> missed the conversation on this. What I
>> want to
>> > configure
>> > > kristian> with link-type p2p is not whether or not
>> the router
>> > should
>> > > kristian> try to broadcast but if it should setup
>> one of those
>> > > kristian> virtual router thingys, hehe. I'm not very
>> familiar
>> > with
>> > > kristian> the terminology but (as you know) on a
>> broadcast medium
>> > > kristian> you first have a DR selection and all that
>> and then
>> > you're
>> > > kristian> gonna run your SPF. Since SPF can't
>> handle the
>> > concept of
>> > > kristian> a broadcast medium it creates a "virtual
>> router" to
>> > > kristian> represent the broadcast medium and
>> connects all
>> > routers in
>> > > kristian> that broadcast domain as adjacencies to
>> the virtual
>> > > kristian> router. When I configure 'isis network
>> > point-to-point' on
>> > > kristian> a Cisco router I expect it to not setup
>> one of these
>> > > kristian> "virtual routers" in it's SPF topology.
>> And this is
>> > > kristian> different with XORP?
>> > >
>> > > Setting the link type to "broadcast" or "p2p" will both
>> result in
>> > the
>> > > hello packets being broadcast, the distinction is that
>> if the
>> > link-type
>> > > is set to "p2p" no DR election will be attempted.
>> >
>> > Alright, just as I expected.
>> >
>> > > The XORP OSPF behaves
>> > > as specified in the relevant RFCs and interoperates with
>> other OSPF
>> > > implementations, the only difference is in configuration
>> of a "p2p"
>> > > where we require the neighbour to be specified, which as
>> I mentioned
>> > > before should not strictly be necessary.
>> >
>> > Okey, not what I expected. Why is it so? Just lack of time
>> to do the
>> > actual
>> > implementation (although I don't see how it would actually
>> be more code
>> > than it is today) or has there been a policy decision
>> against it?
>> >
>> > -K
>> >
>> >
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
>
More information about the Xorp-users
mailing list