Question about OSPF stub networks...

Discussion in 'Cisco' started by Stefan Sybydlo, Feb 8, 2004.

  1. Hello Everyone.

    I need to know if the following OSPF configuration is good/bad,
    wanted/unwanted.

    The basic question is as such (I will omit describing the larger part of the
    network). I have two routers, both running OSPF. Between these two routers
    I have two network connections. One is a network connection where IP is
    configured, a single port on each router is used, and the routers have full
    adjacency where one is DR and the other is BDR. In the OSPF database this
    shows up as a transit link.

    The other network is as follows. Both routers are using a single port to
    connect to the network, IP is configured, both interfaces are configured
    with the passive-interface command. There is NO adjacency between the
    routers on this network. Both interfaces show up as stub networks in the
    database. If you look at the interfaces, because of the passive-interface
    command, both say they are the DR for that network. Connected to this
    network is two switches used for user access.

    In terms of OSPF routing, the routing table seems to show the correct
    routes, and the network seems to function as desired.

    I want to know if this is a legal (according to the OSPF RFC and general
    common sense) configuration. Can one have the same network connected to two
    routers as stub networks, where both act as DR. Are they both advertising
    the network in LSAs? Can OSPF cope with this?


    The CISCO OSPF design guide says the following:
    Stub network links: This term has nothing to do with stub areas. A stub
    segment is a segment that has one router only attached to it.


    Cisco says only one router attached only is allowed, but it seems that the
    OSPF RFC has provisions for this type config(?).

    Does anyone see any obvious problems with this set up? Or is this just an
    academic question and both setups are OK.

    Another what if: What if the two switches attached to this netwrok were
    split so that one was attached to one router and the other switch to the
    second router, so that the network was effectively "split" in half?

    One last question. What, in this case, would be considered best practice?
    The routers involved do not have a problem with memory or CPU capacity.

    Thanks in advance,

    Stefan
    Stefan Sybydlo, Feb 8, 2004
    #1
    1. Advertising

  2. Stefan Sybydlo

    shope Guest

    "Stefan Sybydlo" <> wrote in message
    news:wMnVb.84075$...
    > Hello Everyone.
    >
    > I need to know if the following OSPF configuration is good/bad,
    > wanted/unwanted.
    >
    > The basic question is as such (I will omit describing the larger part of

    the
    > network). I have two routers, both running OSPF. Between these two

    routers
    > I have two network connections. One is a network connection where IP is
    > configured, a single port on each router is used, and the routers have

    full
    > adjacency where one is DR and the other is BDR. In the OSPF database this
    > shows up as a transit link.
    >
    > The other network is as follows. Both routers are using a single port to
    > connect to the network, IP is configured, both interfaces are configured
    > with the passive-interface command. There is NO adjacency between the
    > routers on this network. Both interfaces show up as stub networks in the
    > database. If you look at the interfaces, because of the passive-interface
    > command, both say they are the DR for that network. Connected to this
    > network is two switches used for user access.
    >
    > In terms of OSPF routing, the routing table seems to show the correct
    > routes, and the network seems to function as desired.
    >
    > I want to know if this is a legal (according to the OSPF RFC and general
    > common sense) configuration.


    not sure - last time i read the RFCs there was no mention of "passive"
    interfaces.

    however i use this a lot (mainly where dual layer 3 switches connect to lots
    of networks) - the main reasons are to reduce the number of adjacencies, but
    not use external routes to describe the user subnets.

    Can one have the same network connected to two
    > routers as stub networks, where both act as DR. Are they both advertising
    > the network in LSAs? Can OSPF cope with this?


    if you didnt use passive, and didnt configure the interfaces with OSPF, then
    the subnets would be described as external in the database, and that is
    supported in the standards and in widely used practice.

    "passive" is preferred over external as you can summarise passives at ABRs
    (so end up with a block containing passive and other OSPF internal routes).
    externals get flooded throughout the AS, apart from in stub networks.
    ASBRs cause other LSDB entries to get flooded, so increase overhead in
    database size.
    both types of setup prevent transit traffic across the subnet, so give you
    more control over which way router to router flows go across your network.
    >
    >
    > The CISCO OSPF design guide says the following:
    > Stub network links: This term has nothing to do with stub areas. A stub
    > segment is a segment that has one router only attached to it.
    >
    >
    > Cisco says only one router attached only is allowed, but it seems that the
    > OSPF RFC has provisions for this type config(?).


    i think this is backwards - a stub occurs when there is only 1 attached
    router - "stub" means "no path crosses this subnet to another router in
    OSPF" - so the stub network should not carry traffic in transit.
    >
    > Does anyone see any obvious problems with this set up? Or is this just an
    > academic question and both setups are OK.
    >
    > Another what if: What if the two switches attached to this netwrok were
    > split so that one was attached to one router and the other switch to the
    > second router, so that the network was effectively "split" in half?


    split subnet - any flows that get delivered to the "wrong" part of the
    subnet cannot be delivered, so end up in a black hole.

    again, the way to think of this is that you really dont want this kind of
    fault, so thedesign should make it unlikely in practice.
    2 possibilities are with resilience within the subnet (which may need
    spanning tree), or by having each switch in a separate subnet, so the layer
    3 devices can "see" a connection break to the subnet and adjust routing to
    work around it.
    >
    > One last question. What, in this case, would be considered best practice?
    > The routers involved do not have a problem with memory or CPU capacity.


    i prefer that the layer 3 topology maps directly to the physical switch
    connections.

    One way is a separate subnet per layer 2 switch or stack (real resilient
    stacks, with 3750s or nortel stacking, not just gigabit between separate
    2950s). If you need multiple subnets - eg. for voip and data, then multiple
    subnets.

    this has a further advantage - it is much easier to understand - and a lot
    of "faults" are people breaking things by accident, so KISS is a good design
    principle all on its own.
    >
    > Thanks in advance,
    >
    > Stefan

    --
    Regards

    Stephen Hope - remove xx from email to reply
    shope, Feb 8, 2004
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. a_bleem_user

    Stub Zone vs. Delegation (70-291)

    a_bleem_user, Apr 23, 2005, in forum: Microsoft Certification
    Replies:
    2
    Views:
    3,564
  2. E.Finlayson
    Replies:
    0
    Views:
    1,585
    E.Finlayson
    Sep 10, 2004
  3. noname
    Replies:
    4
    Views:
    4,215
    mcaissie
    Dec 21, 2004
  4. jimbo
    Replies:
    2
    Views:
    828
    jimbo
    Jun 20, 2005
  5. Replies:
    4
    Views:
    801
Loading...

Share This Page