As per Relevance of the word forwarding, we have this rfc below:
Network Working Group R.
Request for Comments: 1587 RainbowBridge
Category: Standards Track V.
Stanford
March 1994
The OSPF NSSA
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Table Of
1.0 Abstract ................................................. 1
2.0 Overview ................................................. 2
2.1 Motivation ............................................... 2
2.2 Proposed Solution ........................................ 3
3.0 Implementation Details ................................... 5
3.1 The N-bit ................................................ 5
3.2 Type-7 Address Ranges .................................... 5
3.3 Type-7 LSAs .............................................. 5
3.4 Originating Type-7 LSAs .................................. 7
3.5 Calculating Type-7 AS External Routes .................... 8
3.6 Incremental Updates ...................................... 10
4.0 Originating Type-5 LSAs .................................. 10
4.1 Translating Type-7 LSAs .................................. 10
4.2 Flushing Translated Type-7 LSAs .......................... 13
5.0 Acknowledgements ......................................... 13
6.0 References ............................................... 13
7.0 Security Considerations .................................. 13
8.0 Authors' Addresses ....................................... 14
Appendix A: Type-7 LSA Packet Format ......................... 15
Appendix B: The Options Field ................................ 16
Appendix C: Configuration Parameters ......................... 17
1.0
This document describes a new optional type of OSPF area,
humorously referred to as a "not-so-stubby" area (or NSSA).
are similar to the existing OSPF stub area configuration option
have the additional capability of importing AS external routes in
limited fashion
Coltun & Fuller [Page 1]
RFC 1587 OSPF NSSA Option March 1994
2.0
2.1
Wide-area transit networks (such as the NSFNET regionals) often
connections to moderately-complex "leaf" sites. A leaf site may
multiple IP network numbers assigned to it
Typically, one of the leaf site's networks is directly connected to
router provided and administered by the transit network while
others are distributed throughout and administered by the site.
the transit network's perspective, all of the network
associated with the site make up a single "stub" entity.
example, BARRNet has one site composed of a class-B network
130.57.0.0, and a class-C network, 192.31.114.0. From BARRNet'
perspective, this configuration looks something like this
192.31.114
|
(cloud
-------------- 130.57.4
|
|
------ 131.119.13 ------
|BR18|------------|BR10|
------ ------
|
to BARRNet "core" OSPF
where the "cloud" consists of the subnets of 130.57 and
192.31.114, all of which are learned by RIP on router BR18.
Topologically, this cloud looks very much like an OSPF stub area
The advantages of running the cloud as an OSPF stub area are
1. Type-5 routes (OSPF external link-state
(LSAs)) are not advertised beyond the
labeled "BR10". This is advantageous because
link between BR10 and BR18 may be a low-speed
or the router BR18 may have limited resources
2. The transit network is abstracted to the "leaf
router BR18 by advertising only a default
across the link between BR10 and BR18.
3. The cloud becomes a single, manageable "leaf"
respect to the transit network
Coltun & Fuller [Page 2]
RFC 1587 OSPF NSSA Option March 1994
4. The cloud can become, logically, a part of the
network's OSPF routing system
5. Translated type-5 LSAs that are sent into
backbone from the cloud (which is a
stub area) may be considered "leaf"
when performing the Dijkstra calculation
However, the current definition of the OSPF protocol [1]
topological limitations which restrict simple cloud topologies
becoming OSPF stub areas. In particular, it is illegal for a
area to import routes external to OSPF; it is not possible
routers BR18 and BR10 to both be members of the stub area and
import the routes learned from RIP or other IP routing protocols
type-5 (OSPF external LSAs) into the OSPF system. In order to
OSPF out to BR18, BR18 must be a member of a non-stub area or
OSPF backbone to import routes other than its directly-
network(s). Since it is not acceptable for BR18 to maintain all
BARRNet's external (type-5) routes, BARRNet is forced by OSPF'
topological limitations to run OSPF out to BR10 and to run
between BR18 and BR10.
2.2 Proposed
This document describes a new optional type of OSPF area,
humorously referred to as a "not-so-stubby" area (or NSSA) which
the capability of importing external routes in a limited fashion
The OSPF specification defines two general classes of
configuration. The first allows type-5 LSAs to be flooded
the area. In this configuration, type-5 LSAs may be originated
routers internal to the area or flooded into the area by area
routers. These areas, referred to herein as type-5 capable areas (
just plain areas in the OSPF spec), are distinguished by the
that they can carry transit traffic. The backbone is always a type-5
capable area. The second type of area configuration, called stub
allows no type-5 LSAs to be propagated into/throughout the area
instead depends on default routing to external destinations
NSSAs are defined in much the same manner as existing stub areas.
support NSSAs, a new option bit (the "N" bit) and a new type of
(type-7) area defined. The "N" bit ensures that routers belonging
an NSSA agree on its configuration. Similar to the stub area's
of the "E" bit, both NSSA neighbors must agree on the setting of
"N" bit or the OSPF neighbor adjacency will not form
Type-7 LSAs provide for carrying external route information within
NSSA. Type-7 AS External LSAs have virtually the same syntax as
Coltun & Fuller [Page 3]
RFC 1587 OSPF NSSA Option March 1994
Type-5 AS External LSAs with the obvious exception of the link-
type (see section 3.2 for more details). There are two major
differences between type-5 and type-7 LSAs
o Type-7 LSAs may be originated by and
throughout an NSSA; as with stub areas, NSSA's do
receive or originate type-5 LSAs
o Type-7 LSAs are advertised only within a single NSSA
they are not flooded into the backbone area or
other area by border routers, though the
which they contain can be propagated into the
area (see section 3.6).
In order to allow limited exchange of external information across
NSSA area border, NSSA border routers will translate selected type-7
LSAs received from the NSSA into type-5 LSAs. These type-5 LSAs
be flooded to all type-5 capable areas. NSSA area border routers
be configured with address ranges so that several type-7 LSAs may
represented by a single type-5 LSA
In addition, an NSSA area border router can originate a
type-7 LSA (IP address of 0.0.0.0) into the NSSA. Default routes
necessary because NSSAs do not receive full routing information
must have a default route to route to AS-external destinations.
stub areas, NSSAs may be connected to the backbone at more than
area border router, but may not be used as a transit area. Note
the default route originated by an NSSA area border router is
translated into a type-5 LSA, however, a default route originated
an NSSA internal AS boundary router (one that is not also an
border router) may be translated into a type-5 LSA
It should also be noted that unlike stub areas, all OSPF
routes (type-3 LSAs) must be imported into NSSAs. This is to
that OSPF internal routes are always chosen over OSPF
(type-7) routes
In our example topology the subnets of 130.57 and network 192.31.114,
will still be learned by RIP on router BR18 but now both BR10
BR18 can be in an NSSA and all of BARRNets external routes are
from BR18; BR10 becomes an NSSA area border router and BR18
an AS boundary router internal to the NSSA. BR18 will import
subnets of 130.57 and network 192.31.114 as type-7 LSAs into
NSSA. BR10 then translates these routes into type-5 LSAs and
them into BARRNet's backbone
Coltun & Fuller [Page 4]
RFC 1587 OSPF NSSA Option March 1994
3.0 Implementation
3.1 The N-
The N-bit ensures that all members of a NSSA agree on the area'
configuration. Together, the N-bit and E-bit reflect an interface'
(and consequently the interface's associated area's) external
flooding capability. As explained in section 10.5 of the
specification, if type-5 LSAs are not flooded into/throughout
area, the E-bit must be clear in the option field of the
Hello packets. Interfaces associated with an NSSA will not send
receive type-5 LSAs on that interface but may send and receive type-7
LSAs. Therefore, if the N-bit is set in the options field, the E-
must be cleared
To support the NSSA option an additional check must be made in
function that handles receiving Hello packet to verify that both
N-bit and the E-bit found in the Hello packet's option field
the value of the options that have been configured in the
interface. A mismatch in the options causes processing of
received Hello packet to stop and the packet to be dropped
3.2 Type-7 Address
NSSA area border routers may be configured with type-7
ranges. Each address range is defined as an [address,mask] pair
Many separate type-7 networks may then be represented by in a
address range (as advertised by a type-5 LSA), just as a
network is composed of many separate subnets. Area border
may then summarize type-7 routes by advertising a single type-5
for each type-7 address range. The type-5 route, resulting from
type-7 address range match will be distributed to all type-5
areas. Section 4.1 gives the details of generating type-5
from type-7 address ranges
A type-7 address range includes the following configurable items
o An [address,mask] pair
o A status indication of either Advertise
DoNotAdvertise
o External route tag
3.3 Type-7 LSAs: NSSA External Link-State
External routes are imported into NSSAs as type-7 LSAs by the NSSA'
AS boundary routers. An NSSA AS boundary routers is a router
Coltun & Fuller [Page 5]
RFC 1587 OSPF NSSA Option March 1994
has an interface associated with the NSSA and is exchanging
information with routers belonging to another AS. As with type-5
LSAs a separate type-7 LSA is originated for each
network. To support NSSA areas, the link-state database
therefore be expanded to contain a type-7 LSA
Type 7-LSAs are identical to type-5 LSAs except for the
(see section 12.3.4 "AS external links" in the
specification).
1. The type field in the LSA header is 7.
2. Type-7 LSAs are only flooded within the NSSA
The flooding of type-7 LSAs follow the same
as the flooding of type 1-4 LSAs
3. Type-7 LSAs are kept within the NSSA's LSDB (
area specific) whereas because type-5 LSAs
flooded to all type-5 capable areas, type-5
global scope in the router's LSDB
4. At the area border router, selected type-7 LSAs
translated into type 5-LSAs and flooded into
backbone
5. Type 7 LSAs have a propagate (P) bit which
used to flag the area border router to translate
type-7 LSA into a type-5 LSA. Examples of how the P-
is used for loop avoidance are in the following sections
6. Those type-7 LSAs that are to be translated into type-5
LSAs must have their forwarding address set
Type-5 LSAs that have been translated from type-7
for the most part must contain a forwarding address
The execption to this is if the translation to a type-5
LSA is the result of an address range match, in
case the type-5 LSA will not contain a forwarding
(see section 4.1 for details).
The forwarding address contained in type-5 LSAs
result in more efficient routing to the AS
networks when there are multiple NSSA
border routers. Having the forwarding address in
type-7 LSAs will ease the translation of type-7
type-5 LSAs as the NSSA area border router
not be required to compute the forwarding address
If the network between the NSSA AS boundary router and
adjacent AS is advertised into OSPF as an internal
Coltun & Fuller [Page 6]
RFC 1587 OSPF NSSA Option March 1994
route, the forwarding address should be the next
address as is currently done in type-5 LSAs, but
type-5 LSAs if the intervening network is not
into OSPF as an internal OSPF route, the
address should be any one of the router's active
interface addresses
Type-5 and type-7 metrics and path types are directly comparable
3.4 Originating Type-7
NSSA AS boundary routers may originate type-7 LSAs. All NSSA
border routers must also be AS boundary routers since they all
have the capability of translating a type-7 LSAs into a type-5
(see section 3.6 routes for the translation algorithm). NSSA
border routers must set the E-bit (external bit) as well as the B-
(border bit) in its router (type-1) LSAs (both in the backbone and
the NSSA area).
When an NSSA internal AS boundary router originates a type-7 LSA
it wants to be translated into a type-5 LSA by the NSSA area
router (and subsequently flooded into the backbone), it must set
P-bit in the LS header's option field and add a valid
address in the type-7 LSA
If a router is attached to another AS and is also an NSSA area
router, it may originate a both a type-5 and a type-7 LSA for
same network. The type-5 LSA will be flooded to the backbone (
all attached type-5 capable areas) and the type-7 will be
into the NSSA. If this is the case, the P-bit must be reset in
type-7 NSSA so the type-7 LSA isn't again translated into a type-5
LSA by another NSSA area border router
A type-7 default route (network 0.0.0.0) may be originated into
NSSA by an NSSA area border router or by an NSSA AS boundary
which is internal to the NSSA. The type-7 default route
by the NSSA area border router must have the P-bit reset so that
default route originated by the NSSA area border router will not
its way out of the NSSA into the rest of the AS system via
NSSA area border router. The type-7 default route originated by
NSSA AS boundary router which is not an NSSA area border router
have the P-bit set. Type-7 routes which are originated by the
area border router will not get added to other NSSA area
router's routing table
A default route must not be injected into the NSSA as a
(type-3) LSA as in the stub area case. The reason for this is
the preferred summary default route would be chosen over all
Coltun & Fuller [Page 7]
RFC 1587 OSPF NSSA Option March 1994
specific type-7 routes. Because summary routes are preferred
external routes and to ensure that summary routes are chosen
external within the NSSA, all summary routes (unlike stub areas
which this is optional) must be imported into an NSSA
3.5 Calculating Type-7 AS External
This section is very similar to section 16.4 (Calculating AS
routes) in the OSPF specification. An NSSA area border router
examine both type-5 LSAs and type-7 LSAs if either type-5 or type-7
routes need to be updated. Type-7 LSAs should be examined
type-5 LSAs. An NSSA internal router should examine type-7 LSAs
type-7 routes need to be recalculated
In relation to the steps to calculate the routing table as
in the OSPF specification (chapter 16, "Calculation of the
Table"), type-7 LSAs should be examined after step 5 where the
to external destinations are calculated
Type-7 routes are calculated by examining type-7 LSAs. Each of
are considered in turn. Most type-7 LSAs describe routes to
IP destinations. A type-7 LSA can also describe a default route
the NSSA (destination = DefaultDestination). For each type-7 LSA
1. If the metric specified by the LSA is LSInfinity,
age of the LSA equals MaxAge or the advertising
field is equal to this router's router ID, examine
next advertisement
2. Call the destination described by the LSA N. Look up
routing table entry for the AS boundary router (ASBR)
originated the LSA. If no entry exists for the
(i.e., ASBR is unreachable), do nothing with this LSA
consider the next in the list
If the destination is the default route (destination =
DefaultDestination) and if the originator of the LSA
the calculating router are both NSSA area border
do nothing with this LSA and consider the next in the list
Else, this LSA describes an AS external path to
N. If the forwarding address (as specified in the
address field of the LSA) is 0.0.0.0, the packets
to the external destination N will be routed to
originating ASBR. If the forwarding address is not 0.0.0.0,
look up the forwarding address in the routing table.
routed to the external destination N will be routed
the NSSA to this forwarding address. An intra-area
Coltun & Fuller [Page 8]
RFC 1587 OSPF NSSA Option March 1994
must therefore exist to the forwarding address. If no
path exists, do nothing with the LSA and consider the
in the list
Call the routing table distance to the forwarding
(or the distance to the originating ASBR if the
address is 0.0.0.0) X, and the cost specified in the type-7
LSA Y. X is in terms of the link-state metric, and Y is
Type-1 or Type-2 external metric
3. Now, look up the routing table entry for the
N. If no entries exist for N, install the AS external
to N, with the next hop equal to the list of next hops
the forwarding address/ASBR, and the advertising router
to ASBR. If the external metric type is 1, then
path-type is set to Type-1 external and the cost is
to X + Y. If the external metric type is 2, the path-
is set to Type-2 external, the link-state component of
route's cost is X, and the Type-2 cost is Y
4. Else, if the paths present in the table are not Type-1
Type-2 external paths, do nothing (AS external paths
the lowest priority).
5. Otherwise, compare the cost of this new AS external
to the ones present in the table. Note that type-5
type-7 routes are directly comparable. Type-1
paths are always shorter than Type-2 external paths
Type-1 external paths are compared by looking at the
of the distance to the forwarding address/ASBR and
advertised Type-1 paths (X+Y). Type-2 external paths
compared by looking at the advertised Type-2 metrics
and then if necessary, the distance to the
address/ASBR
When a type-5 LSA and a type-7 LSA are found to have
same type and an equal distance, the following
apply (listed from highest to lowest) for breaking the tie
a. Any type 5 LSA
b. A type-7 LSA with the P-bit set and the
address non-zero
c. Any other type-7 LSA
If the new path is shorter, it replaces the present
in the routing table entry. If the new path is the
cost, it is added to the routing table entry's list
paths
Coltun & Fuller [Page 9]
RFC 1587 OSPF NSSA Option March 1994
3.6 Incremental
Incremental updates for type-7 LSAs should be treated the same
incremental updates for type-5 LSAs (see section 16.6 of the
specification). That is, if a new instance of a type-7 LSA
received it is not necessary to recalculate the entire routing table
If there is already an OSPF internal route to the
represented by the type-7 LSA, no recalculation is necessary
Otherwise, the procedure in the proceeding section will have to
performed but only for the external routes (type-5 and type-7)
networks describe the same networks as the newly received LSA
4.0 Originating Type-5
4.1 Translating Type-7 LSAs Into Type-5
This step is performed as part of the NSSA's Dijkstra
after type-5 and type-7 routes have been calculated. If
calculating router is not an area border router this
algorithm should be skipped. All reachable area border routers
the NSSA should now be examined noting the one with the
router ID. If this router has the highest router ID, it will be
one translating type-7 LSAs into type-5 LSAs for the NSSA,
the translation algorithm should not be performed
All type-7 routes that have been added to the routing table should
examined. If the type-7 LSA (associated with the route
examined) has the P-bit set and a non-zero forwarding address,
following steps should be taken
The translation procedure must first check for a configured type-7
address range. Recall that an type-7 address range consists of
[address,mask] pair and a status indication of either Advertise
DoNotAdvertise. At most a single type-5 LSA is made for
range. If the route being examined falls within the type-7
address range, (the [address,mask] pair of the route equal to or
more specific instance of the [address,mask] pair of the type-7
address range), one of following three actions may take place
1. When the range's status indicates Advertise and
route's address and mask are equal to the
and mask of the type-7 range a type-5 LSA should
originated if
o there currently is no type-5 LSA originated
this router corresponding to the type-7 LSA
Coltun & Fuller [Page 10]
RFC 1587 OSPF NSSA Option March 1994
o the path type or the metric in the
type-5 LSA is different from the type-7 LSA
o The forwarding address in the
type-5 LSA is different from the type-7 LSA
The newly originated type-5 LSA will
the same network and have the same network mask
metrics, forwarding address, external route
and path type as the type-7 LSA, however,
advertising router field will be the router
of this area border router
2. When the range's status indicates Advertise and
route's address or mask indicates a more
route (i.e., the route's address is subsumed by
range or the route has a longer mask), a type-5
is generated with link-state ID equal to the range'
address (if necessary, the link-state ID can also
one or more of the range's "host" bits set;
Appendix F of the OSPF specification for details),
the network mask, external route tag
path type will be set to the configured type-7
values. The advertising router field will be
router ID of this area border router
The forwarding address will not be set
The path type should always be set to the
path type that is subsumed by the net range
The metric for the type-5 LSA will be set as follows
o if the path type is externl type 2, the type-5
metric should be set to the largest type-7
subsumed by this net range + 1.
o if the path type is external type 1, the type-5
metric should be set to the largest metric
For example, given a net range of [10.0.0.0, 255.0.0.0]
for an area that has type-7 routes of
10.1.0.0 path type 1, metric 10
10.2.0.0 path type 1, metric 11
10.3.0.0 path type 2, metric 5
a type-5 LSA will be generated with a path type of 2
and a metric of 6.
Coltun & Fuller [Page 11]
RFC 1587 OSPF NSSA Option March 1994
As another example, given a net range
[10.0.0.0, 255.0.0.0] for an area that
type-7 routes of
10.1.0.0 path type 1, metric 10
10.2.0.0 path type 1, metric 11
10.3.0.0 path type 1, metric 5
a type-5 LSA will be generated with a path type of 1
and a metric of 11.
These metric and path type rules will avoid
loops in the event that path type 1 and 2 are
used within the area
3. When the range's status indicates DoNotAdvertise
the type-5 LSA is suppressed and the component
remain hidden from the rest of the AS
By default (given that the P-bit is set and the LSA has
non-zero forwarding address) if a network is not
in any explicitly configured address range, a type-7
type-5 LSA translation will occur
A new instance of a type-5 LSA should be originated
flooded to all attached type-5 capable areas if one of
following is true
1. There currently is no type-5 LSA originated from
router corresponding to the type-7 LSA
2. The path type or the metric in the
type-5 LSA is different from the type-7 LSA
3. The forwarding address in the
type-5 LSA is different from the type-7 LSA
The newly originated type-5 LSAs will describe the
network and have the same network mask, metrics,
address, external route tag and path type as the type-7 LSA
The advertising router field will be the router ID of
area border router
As with all newly originated type-5 LSAs, a type-5 LSA
is the result of a type-7 to type-5 translation (type-7
or default case) is flooded to all attached type-5
areas
Coltun & Fuller [Page 12]
RFC 1587 OSPF NSSA Option March 1994
4.2 Flushing Translated Type-7
If an NSSA area border router has translated a type-7 LSA to a type-5
LSA that should no longer be translated, the type-5 LSA should
flushed (set to MaxAge and flooded). The translated type-5
should be flushed whenever the routing table entry that caused
translation changes so that either the routing table entry
unreachable or the entry's associated LSA is not a type-7 with
P-bit set and a non-zero forwarding address
5.0
This document was produced by the OSPF Working Group, chaired by
Moy
In addition, the comments of the following individuals are
acknowledged
Phani Jajjarvarpu
Dino Farinacci
Jeff Honig Cornell
John Moy Proteon, Inc
Doug Williams
6.0
[1] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994.
[2] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc.,
Proteon, Inc., March 1994.
7.0 Security
Security issues are not discussed in this memo
Coltun & Fuller [Page 13]
RFC 1587 OSPF NSSA Option March 1994
8.0 Authors'
Rob
RainbowBridge
Phone: (301) 340-9416
EMail: rcoltun@rainbow-bridge.
Vince
Stanford
Pine Hall 115
Stanford, CA, 94305-4122
Phone: (415) 723-6860
EMail: vaf@Valinor.Stanford.
Coltun & Fuller [Page 14]
RFC 1587 OSPF NSSA Option March 1994
Appendix A: Type-7 Packet
0 32
-----------------------------------
| | OPTS | 7 |
| ------------------
| Link-State Header |
| |
-----------------------------------
| Network Mask |
----------------------------------- ______
|E| Tos | metric | .
----------------------------------- . repeated for each
| Forwarding Address | .
----------------------------------- .
| External Route Tag | ______
-----------------------------------
The definitions of the link-state ID, network mask, metrics
external route tag are the same as the definitions for the type-5
LSAs (see A.4.5 in the OSPF specification) except for
The Forwarding
If the network between the NSSA AS boundary router and the
AS is advertised into OSPF as an internal OSPF route, the
address should be the next hop address but if the intervening
is not advertised into OSPF as an internal OSPF route, the
address should be any one of the router's active OSPF
addresses
Coltun & Fuller [Page 15]
RFC 1587 OSPF NSSA Option March 1994
Appendix B: The Options
The OSPF options field is present in OSPF Hello packets,
Description packets and all link-state advertisements. See
A.2 in the OSPF specification for a description of option field
------------------------------------
| * | * | * | * | N/P | MC | E | T |
------------------------------------
The Type-7 LSA options
T-bit: The T-bit describes the router's TOS capability
E-bit: Type-5 AS external link advertisements are
flooded into/through OSPF stub and NSSA areas
The E-bit ensures that all members of a stub
agree on that area configuration. The E-bit
meaningful only in OSPF Hello packets. When
E-bit is reset in the Hello packet sent out
particular interface, it means that the
will neither send nor receive type-5 AS
link state advertisements on that interface (
other words, the interface connects to a
area). Two routers will not become
unless they agree on the state of the E-bit
MC-bit: The MC-bit describes the multicast capability
the various pieces of the OSPF routing
[2].
N-bit: The N-bit describes the the router's
capability. The N-bit is used only in
packets and ensures that all members of an
agree on that area's configuration. When
N-bit is reset in the Hello packet sent out
particular interface, it means that the
will neither send nor receive type-7 LSAs on
interface. Two routers will not form an
unless they agree on the state of the N-bit.
the N-bit is set in the options field, the E-
must be reset
P-bit: The P-bit is used only in the type-7 LSA header
It flags the NSSA area border router to
the type-7 LSA into a type-5 LSA
Coltun & Fuller [Page 16]
RFC 1587 OSPF NSSA Option March 1994
Appendix C: Configuration
Appendix C.2 in the OSPF specification lists the area parameters
The area ID, list of address ranges for type-3 summary routes
authentication type remain unchanged. Section 3.2 of this
lists the configuration parameters for type-7 address ranges
For NSSAs the external capabilities of the area must be set to
type-7 external routes. Additionally there must be a way
configuring the NSSA area border router to send a default route
the NSSA using a specific metric (type-1 or type-2 and the
cost).
Coltun & Fuller [Page 17]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
