Brian,

Good points.  See inline.  Plus a new point below.

In message <54f8ae20.5030...@gmail.com>
Brian E Carpenter writes:
> 
> Hi,
>  
> > 8.  Support for Stub Networks and Stub Routers
> ...
> >    IS-IS supports stub-networks as defined above
> >    simply by advertising the prefix associated with a link, but not the
> >    link itself.  This is sometimes referred to as a "passive link".
> > 
> >    Further an IS-IS router has the ability to set a bit (the overload
> >    bit) to indicate that it should not be used for any transit traffic,
> >    and that it will only be considered a destination for the prefixes it
> >    has advertised, i.e., it is a stub router as defined above.

In both ISIS and OSPF is an neighbor adjacency is formed with another
router, the adjacency to a network pseudonode is advertised.  If no
other router is found, then no pseudonode is formed and just the
prefix is announced as a stub.

> ...
> >    As all distance vector protocols, Babel supports fairly arbitrary
> >    route filtering.  Designating a stub network is done with two
> >    statements in the current implementation's filtering language.
>  
> In a homenet, there must be no manual config. In both cases, how does
> this work automatically? How does IS-IS know not to advertise the link
> and set the overload bit, and how does Babel know to include those
> filtering rules? Or more generally, how does a stub router know that
> it's a stub router, when there is no human to tell it so?
>  
> Regards
>    Brian

Another topic comes to mind.  The topic is the partitioned bridged
network.  It looks like this.

  +-------+                                  +-------+
  | Rtr#1 |------------- Link#1 -------------| Rtr#2 |
  +-------+                                  +-------+
      |                                          |
    ... other links                            ... other links
      |                                          |
  +-------+                                  +-------+
  | Rtr#3 |------------- Link#2 -------------| Rtr#4 |
  +-------+                                  +-------+
      | I#3                                      | I#4
      |                                          |
  +-------+                                  +-------+
  |  Sw#1 |-----------/  broken  /-----------|  Sw#2 |
  +-------+       same subnet numbering      +-------+
      |                                          |
      |                                          |
   +--/--- ... ---/--+            +--/--- ... ---/--+
      |           |                  |           |
      |           |                  |           |
  +-------+     more               more      +-------+
  | host1 |     subnet             subnet    | host2 |
  +-------+     drops              drops     +-------+

    legend:  Rtr# = a router; I# = an interface

    example:  I#3= 192.0.2.1; I#4= 192.0.2.2; subnet= 192.0.2/24
              In IPv6, make that 2001:db8:fff0::/64

In this example all of the host and router interfaces are up.  This is
not a misconfiguration.  Some bridging was used and a link between
bridges is down.

In ISIS and OSPF both the interface on the router and the prefix is
advertised.  In ISIS and OSPF sometimes just the prefix is advertised
to save on /32 (/128) prefixes floating about, but that affects some
reachability to router interface addresses (but never to the loopback
if numbered, which is why they are always numbered in ISP networks).
That makes two ways to reach the subnet, and therefore to reach host1
and host2 when bridging is working.

In ISIS and OSPF when this link between bridges goes down, the routers
are always reachable through their loopback addresses.  If pinging the
interface is desireable, mostly just so as not to confuse operators
doing manual ping, the router interfaces can be advertised and they
are always reachable.  The hosts, in this example, host1 and host2,
but potentially quite a few more, are only reachable from parts of the
network.  Any router closer in the topology to Rtr#3 including Rtr#3
can't reach host2.  Any router closer in the topology to Rtr#4
including Rtr#4 can't reach host1.

One solution for an ISP where host1 and host2 are important (for
example NMS data collection nodes), is to run ISIS or OSPF on the host
and make them stub routers if they are multihomed (the old way before
stub router support was set cost to a very high number).  This was
done in the gated days (gated is an older routing daemon) but is
doable with Bird or Quagga.  This yielded a slow switchover, but a
reliable one.

Mostly reliable.  Some routers didn't install the interface addresses
in the FIB (falsely assuming that the subnet address was plenty) but
they were beat up about it, so maybe that problem is gone.

BTW- If there were other routers still connected to Rtr#3 or Rtr#4,
then a DR and BDR was elected and the network pseudonode with save
prefix was advertised from more than one router.

This is why ISPs don't particularly care for switched networks.

Even if an address is configured on the host loopback and advertise it
as a /32 or /128 stub from the routers on that subnet, it doesn't
help.  Reachability to the host has to be determined somehow.

I don't see how this can be fixed without some change to the host to
establish liveness wrt the indiviual routers on the subnet.

Given a means to determine liveness to hosts, the hosts can be
advetised as stubs with zero configuration.  Otherwise just the subnet
is advertised from two places and this situation isn't fixable.

Curtis

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to