[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OSPF] Unnumbered PtoP router LSA question.
On Tue, 2009-01-06 at 16:34 -0700, Dave Katz wrote:
> On Jan 6, 2009, at 2:19 PM, Joakim Tjernlund wrote:
>
> >>
> >> The footnote is sort of bogus on three counts. First of all, a
> >> router
> >> *must* have an address somewhere, or it has nothing to put in the IP
> >> source address field, can't be managed, and is an incredibly
> >> expensive
> >> door stop. So that bit is redundant.
> >
> > Obviously an IP address is needed, the key part is that the IP address
> > should be announced as an host route in the router LSA.
> >
> >> Secondly, there is no explicit
> >> mechanism in the spec for advertising that host route, unless this
> >> sentence is intended to be normative (in which case the "will" should
> >> be a "SHALL".)
> >
> > What mechanism do you need? It is an impl. detail how you specify
> > that IP address, if you need one. Will vs. shall is perhaps an
> > error, I can't
> > say, but I don't think the language in Option 1 or Option 2 is any
> > stronger.
> >
> >> Thirdly, if implementations were to actually follow
> >> the other section you mention and do option 1, advertising that host
> >> route is unnecessary because all of the OSPF neighbors will know the
> >> address and advertise it themselves (roundabout, as mentioned
> >> earlier,
> >> but it works.) And that footnote is much narrower than the case we
> >> are talking about, which is that of *any* unnumbered interface,
> >> regardless of whether there are other numbered interfaces or not.
> >
> > You only have do this iff you just have unnumbered interfaces, no need
> > to add an extra host route if you already announce one.
>
> I think we've gone in circles here.
>
> If I understood your original posting, you were asking about the
> meaning/value of the options listed as part of 12.4.1.1. The reason
> that they are there is to ensure reachability to the remote router
> itself, if it implements exactly what the spec says to do. If the
> local router doesn't do Option 1, and the remote router only does
> exactly what the spec says to do, you will not be able to route to the
> remote router because nobody will announce reachability to its address.
>
> One can look at the spec and say, "of course I should announce host
> routes for addresses I think the world might be interested in", and it
> will work, but the spec never actually says to do that, *except* in
> the case of a router with no numbered interfaces at all (and burying
> it in a footnote at the very end of the spec is not a terribly good
> thing even in that case.)
>
> So a naïve implementor will still have a functional, reachable,
> manageable network if he implements Option 1 and doesn't advertise any
> host routes otherwise. This is why Option 1 exists, and why it is
> normative. If my box is neighbor to the the naïve implementor's box,
> and I don't do Option 1, and he doesn't have his loopback address or
> some other address outside of OSPF in a host route (perfectly in-
> spec), his box is going to be unreachable for management purposes.
I would not say that it is "perfectly in spec" as the spec actually
mentions this case explicitly in that footnote. I guess that the spec
assumes that it is very uncommon to just have unnumbered links is the
domain and that is perhaps why it is in a footnote.
Also I can can't find a reference in the spec that states that
the purpose of Option 1 is reachability, in [15] one can read:
[15]This is the way RFC 1583 specified point-to-point
representation. It has three advantages: a) it does not require
allocating a subnet to the point-to-point link, b) it tends to bias
the routing so that packets destined for the point-to-point
interface will actually be received over the interface (which is
useful for diagnostic purposes) and c) it allows network
bootstrapping of a neighbor, without requiring that the bootstrap
program contain an OSPF implementation.
Further, looking into RFC 1583 one can see that Option 1 isn't used for
unnumbered links.
Also, there would be no need for footnote [2] if Option 1 is required
so why have in the first place?
Actully, the only thing that might suggest that Option 1 should be
used in 2328 is the text i Option 1 and that text is a bit "fuzzy".
Everything else suggests that Option 1 should not be used(in my reading)
>
> Maybe I'm missing something here?
>
> >
> >
> >>
> >>>
> >>>
> >>> An related question: what to do with an interface that is UP but not
> >>> RUNNING?
> >>
> >> Given that these terms are not well-defined, it's not possible to
> >> answer in a normative way. Even in a non-normative, casual way, it's
> >> not clear to me what the actual difference is. If the link does not
> >> pass packets, for whatever reason, OSPF will not come up, and traffic
> >> will not be passed to the nonfunctional link. Whether that interface
> >> address is advertised by the offending router is an implementation
> >> decision, as it has no functional use other than as a management
> >> address. For that matter, it is then immaterial as to whether the
> >> interface is "up" in any way or not, since there's no traffic going
> >> to
> >> that interface anyhow. One could choose to advertise *all* interface
> >> addresses as host routes whether the interface is up or not, in case
> >> anybody is sending packets to those addresses from afar. But this is
> >> usually done with loopback addresses, which become the "router
> >> address" for management purposes and are independent of any physical
> >> hardware.
> >
> > The IP address on that link is still reachable through other
> > interfaces. If you
> > have a connection to the router using its IP address, you can still
> > use it
> > even if the interface isn't RUNNING(i.e someone pulled the cable for
> > that interface).
> > So instead of removing the whole interface and its subnet from the
> > OSPF domain, one
> > should change the router LSA to announce a host route with that
> > interface's IP address.
>
> I guess I still don't understand the distinction between UP and
> RUNNING, but that's OK.
Sorry, I should have explained this better. I refering to the
status of the interface as returned by ifconfig:
# > ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:06:9C:00:20:02
inet addr:10.0.1.1 Bcast:10.0.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
If I disconnect the ethernet cable, the RUNNING status goes away since
the interface cannot pass traffic on the ethernet, but the interface is
still UP.
What does Juniper do in this case for an interface that is part
of a OSPF area? I really like to find out how other routers handle
this case.
> The point is (and I think we're in violent
> agreement) that if you want a router address to be reachable, it
> either has to be announced as a host route or as part of a subnet
> route. If the interface isn't passing traffic, announcing a subnet
> route would be an exceedingly poor idea, so the host route is the way
> to go. The spec is properly (IMHO) silent on when to send host routes
> in this case, as it is purely an implementation decision and is not
> subject to standardization.
I think this is implicit in the spec. One can ask OSPF to announce
some subnets and all matching interfaces are then announced, if you pull
the cable, the IP address still matches and is reachable so it
should still be announced as a host route.
Jocke
_______________________________________________
OSPF mailing list
OSPF at ietf.org
https://www.ietf.org/mailman/listinfo/ospf