Pat,

It doesn't have to be this complex if you can run OSPF directly
on the subnet corresponding to the secondary address without
using a layer 2 encapsulation.

My apologies in advance for including a vendor specific
configuration....

Anyway, I did a quick configuration on our router for sharing a
single ethernet across 10 areas (backbone and 9 others).

!
  interface ether-two
   ip address 10.1.0.1/24
   ip address 10.1.1.1/24 secondary
   ip address 10.1.2.1/24 secondary
   ip address 10.1.3.1/24 secondary
   ip address 10.1.4.1/24 secondary
   ip address 10.1.5.1/24 secondary
   ip address 10.1.6.1/24 secondary
   ip address 10.1.7.1/24 secondary
   ip address 10.1.8.1/24 secondary
   ip address 10.1.9.1/24 secondary
!
  router ospf 1
   area 0.0.0.0
    interface 10.1.0.1
   area 0.0.0.1
    interface 10.1.1.1
   area 0.0.0.2
    interface 10.1.2.1
   area 0.0.0.3
    interface 10.1.3.1
   area 0.0.0.4
    interface 10.1.4.1
   area 0.0.0.5
    interface 10.1.5.1
   area 0.0.0.6
    interface 10.1.6.1
   area 0.0.0.7
    interface 10.1.7.1
   area 0.0.0.8
    interface 10.1.8.1
   area 0.0.0.9
    interface 10.1.9.1

Note that our implementation supports the concept of a logical interface
that can be bound to a physical port or pvc. So, in a complete
configuration you also have a statement such as:

! Bind ether-two from context local to Ethernet port 4/1
port ethernet 4/2
  no shutdown
  bind interface ether-two local

It works fine...

[local]SE1#show ospf neighbor

   --- OSPF Neighbors for Instance 1/Router ID 10.1.0.1 ---

NeighborID NeighborAddress Pri State DR-State IntfAddress TimeLeft
10.1.0.2 10.1.0.2 1 Full BDR 10.1.0.1 37
10.1.0.2 10.1.1.2 1 Full BDR 10.1.1.1 37
10.1.0.2 10.1.2.2 1 Full BDR 10.1.2.1 36
10.1.0.2 10.1.3.2 1 Full BDR 10.1.3.1 35
10.1.0.2 10.1.4.2 1 Full BDR 10.1.4.1 34
10.1.0.2 10.1.5.2 1 Full BDR 10.1.5.1 32
10.1.0.2 10.1.6.2 1 Full BDR 10.1.6.1 32
10.1.0.2 10.1.7.2 1 Full BDR 10.1.7.1 31
10.1.0.2 10.1.8.2 1 Full BDR 10.1.8.1 40
10.1.0.2 10.1.9.2 1 Full BDR 10.1.9.1 39
[local]SE1#

Again, sorry for the vendor-specific example.

Pat Murphy - (650)329-4044 wrote:
> Acee,
>
>
>>Close - I say it is more a trade-off between extra code and greater
>>complexity versus less code and simplicity.
>>
>
> I trust you mean from an implementation perspective, not from a customer
> perspective. No doubt about it, less code is simpler. From a customer
> perspective, consider the following generic example with cisco-like
> commands using OSPF sub-addressing features:
>
> interface serial 1
> encapsulation frame-relay
> ip address 10.0.1.1/24
> ip address 10.0.1.2/24 secondary
> ip address 10.0.1.3/24 secondary
> ip address 10.0.1.4/24 secondary
> ip ospf network non-broadcast area 10.0.1.0
> ip ospf network non-broadcast area 10.0.2.0
> ip ospf network non-broadcast area 10.0.3.0
> ip ospf network non-broadcast area 10.0.4.0
> neighbor 10.0.1.2 area 10.0.1.0 priority 7
> neighbor 10.0.1.3 area 10.0.1.0 priority 1
> frame-relay map ip 10.0.1.2 2
> frame-relay map ip 10.0.1.3 3
> frame-relay map ip 10.0.1.4 4
> frame-relay map ip 10.0.1.5 1
> neighbor 10.0.2.3 area 10.0.2.0 priority 7
> neighbor 10.0.2.4 area 10.0.2.0 priority 1
> frame-relay map ip 10.0.2.2 2
> frame-relay map ip 10.0.2.3 3
> frame-relay map ip 10.0.2.4 4
> frame-relay map ip 10.0.2.5 1
> neighbor 10.0.3.1 area 10.0.3.0 priority 7
> neighbor 10.0.3.3 area 10.0.3.0 priority 1
> frame-relay map ip 10.0.3.2 2
> frame-relay map ip 10.0.3.3 3
> frame-relay map ip 10.0.3.4 1
> frame-relay map ip 10.0.3.5 4
> neighbor 10.0.4.2 area 10.0.4.0 priority 7
> neighbor 10.0.4.5 area 10.0.4.0 priority 1
> frame-relay map ip 10.0.4.2 2
> frame-relay map ip 10.0.4.3 3
> frame-relay map ip 10.0.4.4 4
> frame-relay map ip 10.0.4.5 1
>
> router ospf 10
> network 10.0.1.0/24 area 10.0.1.0
> network 10.0.2.0/24 area 10.0.2.0
> network 10.0.3.0/24 area 10.0.3.0
> network 10.0.4.0/24 area 10.0.4.0
>
>
> Now consider a configuration of the same example using the features of
> draft-ietf-ospf-mlinks-03.txt:
>
> interface serial 1
> encapsulation frame-relay
> ip address 10.0.1.1/24
> ip ospf network non-broadcast area 10.0.1.0
> neighbor 10.0.1.2 area 10.0.1.0 priority 7
> neighbor 10.0.1.3 area 10.0.1.0 priority 1
> frame-relay map ip 10.0.1.1 1
> frame-relay map ip 10.0.1.2 2
> frame-relay map ip 10.0.1.3 3
> frame-relay map ip 10.0.1.4 4
>
> router ospf 10
> network 10.0.1.0/24 area 10.0.1.0
> network 10.0.1.0/24 area 10.0.2.0
> network 10.0.1.0/24 area 10.0.3.0
> network 10.0.1.0/24 area 10.0.4.0
>
> Note that draft-ietf-ospf-mlinks-03.txt computes NBMA secondary
> neighbors with their DR priorities automatically via the opaque mlink
> LSA, as hinted at in RFC 2326 Appendix C.6. Try extrapolating this
> example to 10 areas and 20 links.
>
> I highly recommend you implementors start approaching specifications
> from a customer perspector. I would be unwise to think your competors
> will continue the current path indefinitely. As for less code being
> simpler, new implementations of OSPF would make this customer happy if
> they would simply drop the sub-addressing capability and implement this
> draft. After all less code is simpler. Why would anyone routinely use
> sub-addressing if they didn't haven't? Don't forget all that in-addr DNS
> maintenance.
>
> Pat
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]