Download OSPF Network Implementation: Understanding OSPF Packets, LSAs, and Area Types and more Study Guides, Projects, Research Network Theory in PDF only on Docsity!
Open Shortest Path First
Open Shortest Path First (OSPF) is an open-standard Link State routing protocol. Link State
routing protocols advertise the state of their links. When a Link State router begins operating on
a network link, information associated with that logical network is added to its local Link State
Database (LSDB). The local router then sends Hello messages on its operational links to
determine whether other Link State routers are operating on the interfaces as well. OSPF runs
directly over Internet Protocol using IP protocol number 89. The ROUTE exam objective
covered in this chapter is as follows:
Implement a multi-area OSPF network, given a network design and a set of
requirements
This chapter contains the following sections:
OSPF Overview and Fundamentals
OSPF Configuration Fundamentals
OSPF Packet Types
Establishing Adjacencies
OSPF LSAs and the Link State Database (LSDB)
OSPF Areas
Route Metrics and Best Route Selection
OSPF Default Routing
OSPF Virtual Links
OSPF Route Summarization
OSPF Passive Interfaces
Securing OSPF Messages
Configuring OSPF over Non-Broadcast Networks
OSPF Logging and Reporting
OSPF Overview and Fundamentals
Several Requests for Comments (RFCs) have been written for OSPF. In this section, we will
learn about the history of OSPF based on some of the most common RFCs that pertain to OSPF.
The OSPF working group was formed in 1987 and it has since released numerous RFCs. Some
of the most common RFCs on OSPF are listed below:
RFC 1131 - OSPF Specification
RFC 1584 - Multicast Extensions to OSPF
RFC 1587 - The OSPF NSSA Option
RFC 1850 - OSPF Version 2 Management Information Base
RFC 2328 - OSPF Version 2
RFC 2740 - OSPF Version 3
RFC 1131 describes the first iteration of OSPF and it was used in initial tests to determine
whether the protocol worked.
RFC 1584 provides extensions to OSPF for the support of IP Multicast traffic. This is commonly
referred to as Multicast OSPF (MOSPF). However, this standard is seldom used and, most
importantly, it is not supported by Cisco.
RFC 1587 describes the operation of an OSPF Not-So-Stubby Area (NSSA). An NSSA allows for
the injection of external routing knowledge by an ASBR using an NSSA External LSA. NSSAs
are described in detail later in this chapter.
RFC 1850 allows network management of OSPF using the Simple Network Management
Protocol (SNMP). SNMP is used in network management systems to monitor network-attached
devices for conditions that warrant administrative attention. The implementation of this
standard is beyond the scope of the ROUTE exam requirements and is not described in this
guide.
RFC 2328 details the latest update to OSPF version 2 (OSPFv2), which is the default version of
OSPF in use today. OSPFv2 was initially described in RFC 1247, which addressed a number of
issues discovered during the initial rollout of OSPF version 1 (OSPFv1) and modified the
protocol to allow future modifications without generating backward-compatibility issues.
Because of this, OSPFv2 is not compatible with OSPFv1.
Finally, RFC 2740 describes the modifications to OSPF to support version 6 of the Internet
Protocol (IPv6). IPv6 is described in detail later in this guide. It should be assumed that all
references to OSPF in this chapter are for OSPFv2.
Link State Fundamentals
When a Link State routing protocol is enabled for a particular link, information associated with
that network is added to the local Link State Database (LSDB). The local router then sends Hello
messages on its operational links to determine whether other Link State routers are operating
on the interfaces as well. The Hello messages are used for neighbor discovery as well as to
maintain adjacencies between neighbor routers. These messages are described in detail later in
this chapter.
When a neighbor router is located, the local router attempts to establish an adjacency, assuming
both routers share the same common subnet, are in the same area, and that other parameters,
such as authentication and timers, are identical. This adjacency enables the two routers to
Reduces the scope of LSAs flooding throughout the OSPF domain
Hides detailed topology information between areas
Allows for end-to-end connectivity within the OSPF domain
Creates logical boundaries within the OSPF domain
The OSPF backbone area receives summarized routing information from the ABRs. The routing
information is disseminated to all other non-backbone areas within the OSPF network. When a
change to the network topology occurs, this information is disseminated throughout the entire
OSPF domain, allowing all routers in all areas to have a consistent view of the network. The
network topology illustrated in Figure 3-1 below is an example of a multi-area OSPF
implementation:
Area 0 Area 1 Area 2 R R R R R5 R Intra-Area Intra-Area Intra-Area Area 1 Summary: Inter-Area Area 1 Summary: Inter-Area
Fig. 3-1. A Multi-Area OSPF Network
Figure 3-1 illustrates a basic multi-area OSPF network. Areas 1 and 2 are connected to Area 0,
the OSPF backbone. Within Area 1, routers R1, R2, and R3 exchange intra-area routing
information and maintain detailed topology for that area. R3, the ABR, generates an inter-area
summary route and advertises this to the OSPF backbone.
R4, the ABR for Area 2, receives the summary information from Area 0 and floods it into its
adjacent area. This allows routers R5 and R6 to know of the routes that reside outside of their
local area but within the OSPF domain. The same concept would also be applicable to the
routing information within Area 2.
In summation, the ABRs maintain LSDB information for all the areas in which they are
connected. All routers within each area have detailed topology information pertaining to that
specific area. These routers exchange intra-area routing information. The ABRs advertise
summary information from each of their connected areas to other OSPF areas, allowing for
inter-area routing within the domain.
NOTE: OSPF ABRs and other OSPF router types are described in detail later in this chapter. Network Types
OSPF uses different default network types for different media, which are as follows:
Non-Broadcast
Point-to-Point
Broadcast
Point-to-Multipoint
Non-Broadcast networks are network types that do not support natively Broadcast or Multicast
traffic. The most common example of a non-Broadcast network type is Frame Relay. Non-
Broadcast network types require additional configuration to allow for both Broadcast and
Multicast support. On such networks, OSPF elects a Designated Router (DR) and/or a Backup
Designated Router (BDR). These two routers are described later in this chapter.
In Cisco IOS software, OSPF-enabled routers send Hello packets every 30 seconds on non-
Broadcast network types. If a Hello packet is not received in four times the Hello interval, or 120
seconds, the neighbor router is considered ‘dead.’ The following illustrates the output of the
show ip ospf interface command on a Frame Relay Serial interface:
R2# show ip ospf interface Serial0/ Serial0/0 is up, line protocol is up Internet Address 150.1.1.2/24, Area 0 Process ID 2, Router ID 2.2.2.2, Network Type NON_BROADCAST , Cost: 64 Transmit Delay is 1 sec, State DR , Priority 1
FastEthernet0/0 is up, line protocol is up Internet Address 192.168.1.2/24, Area 0 Process ID 2, Router ID 2.2.2.2, Network Type BROADCAST , Cost: 64 Transmit Delay is 1 sec, State BDR , Priority 1 Designated Router (ID) 192.168.1.3, Interface address 192.168.1. Backup Designated router (ID) 2.2.2.2, Interface address 192.168.1. Timer intervals configured, Hello 10, Dead 40 , Wait 40, Retransmit 5 oob-resync timeout 40 Hello due in 00:00: Supports Link-local Signaling (LLS) Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 1 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 192.168.1.3 (Designated Router) Suppress Hello for 0 neighbor(s)
Point-to-multipoint is a non-default OSPF network type. In other words, this network type must
be configured manually using the ip ospf network point-to-multipoint [non-
broadcast] interface configuration command. By default, the command defaults to a
Broadcast point-to-multipoint network type. This default network type allows OSPF to use
Multicast packets to discover dynamically its neighbor routers. In addition, there is no DR/BDR
election held on Broadcast point-to-multipoint network types.
The [non-broadcast] keyword configures the point-to-multipoint network type as a non-
Broadcast point-to-multipoint network. This requires static OSPF neighbor configuration, as
OSPF will not use Multicast to discover dynamically its neighbor routers. Additionally, this
network type does not require the election of a DR and/or a BDR router for the designated
segment. The primary use of this network type is to allow neighbor costs to be assigned to
neighbors instead of using the interface-assigned cost for routes received from all neighbors.
This concept will be described in detail later in this chapter.
The point-to-multipoint network type is typically used in partial-mesh hub-and-spoke NBMA
networks. However, this network type can also be specified for other network types, such as
Broadcast Multi-Access networks (e.g., Ethernet). By default, OSPF sends Hello packets every
30 seconds on point-to-multipoint networks. The default dead interval is four times the Hello
interval, which is 120 seconds.
The following illustrates the output of the show ip ospf interface command on a Frame
Relay Serial interface that has been configured manually as a point-to-multipoint network:
R2# show ip ospf interface Serial0/ Serial0/0 is up, line protocol is up Internet Address 150.1.1.2/24, Area 0 Process ID 2, Router ID 2.2.2.2, Network Type POINT_TO_MULTIPOINT , Cost: 64
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT Timer intervals configured, Hello 30, Dead 120 , Wait 120, Retransmit 5 oob-resync timeout 120 Hello due in 00:00: Supports Link-local Signaling (LLS) Index 2/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 2 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 1.1.1. Suppress Hello for 0 neighbor(s)
The primary reason for the OSPF requirement that the network type be the same on both
routers is because of the timer values. As illustrated in the outputs above, different network
types use different Hello and Dead timer intervals. In order for an OSPF adjacency to be
established successfully, these values must match on both routers.
Cisco IOS software allows the default OSPF Hello and Dead timers to be changed using the ip
ospf hello-interval <1-65535> and the ip ospf dead-interval [<1-
65535>|minimal] interface configuration commands. The ip ospf hello-interval
<1-65535> command is used to specify the Hello interval in seconds. When issued, the
software automatically configures the Dead interval to a value four times the configured Hello
interval. For example, assume that a router was configured as follows:
R2(config)# interface Serial0/ R2(config-if)# ip ospf hello-interval 1 R2(config-if)# exit
By setting the Hello interval to 1 on R2 above, Cisco IOS software automatically adjusts the
default Dead timer to four times the Hello interval, which is 4 seconds. This is illustrated in the
following output:
R2# show ip ospf interface Serial0/ Serial0/0 is up, line protocol is up Internet Address 10.0.2.4/24, Area 2 Process ID 4, Router ID 4.4.4.4, Network Type POINT_TO_POINT, Cost: 64 Transmit Delay is 1 sec, State POINT_TO_POINT Timer intervals configured, Hello 1, Dead 4 , Wait 4, Retransmit 5 oob-resync timeout 40 Hello due in 00:00: ... [Truncated Output]
NOTE: While it is possible technically to establish an adjacency between dissimilar network
types with the same timer values (e.g., between a Broadcast and a point-to-multipoint network
type), for reasons beyond the scope of the ROUTE exam requirements, this is not recommended
because it could result in unexpected behavior within the OSPF network.
In addition to adjusting timer values to allow adjacencies to be established on different network
types, OSPF timers can also be adjusted to reduce protocol convergence time. However, be
cautious when setting aggressive timers, as this may cause more problems than are addressed.
Designated and Backup Designated Routers
As stated in the previous section, OSPF elects a Designated Router and/or a Backup Designated
Router on Broadcast and non-Broadcast network types. It is important to understand that the
BDR is not a mandatory component on these network types. In fact, OSPF will work just as well
when only a DR is elected and there is no BDR; however, there will be no redundancy if the DR
fails and the OSPF routers will need to go through the election process again to elect a new DR.
On the segment, each individual non-DR/BDR router establishes an adjacency with the DR and,
if one has also been elected, the BDR, but not with any other non-DR/BDR routers on the
segment. The DR and BDR routers are fully adjacent with each other and all other routers on the
segment. The non-DR/BDR routers send messages and updates to the AllDRRouters Multicast
group address 224.0.0.6. Only the DR/BDR routers listen to Multicast messages sent to this
group address. The DR then advertises messages to the AllSPFRouters Multicast group address
224.0.0.5. This allows all other OSPF routers on the segment to receive the updates.
It is important to understand the sequence of message exchanges when a DR and/or a BDR
router have been elected. As an example, imagine a Broadcast network with four routers, which
are R1, R2, R3, and R4. Assume that R4 has been elected DR, and R3 has been elected BDR. R
and R1 are neither DR nor BDR and are therefore referred to as DROther routers in Cisco OSPF
terminology. A configuration change is made on R1 and R1 then sends an update to the
AllDRRouters Multicast group address 224.0.0.6. R4, the DR, receives this update and sends an
acknowledgement back to the AllSPFRouters Multicast group address 224.0.0.5. R4 then sends
this update to all other non-DR/BDR routers using the AllSPFRouters Multicast group address.
This update is received by the other DROther router, R2, and R2 sends an acknowledgement to
the AllDRRouters Multicast group 224.0.0.6. This is illustrated in Figure
3-2 below:
R R2 R R Lo0: 1.1.1.1/ Lo0: 4.4.4.4/ Lo0: 3.3.3.3/ Lo0: 2.2.2.2/ Update: AllDRRouters group 224.0.0. 1 ACK: AllSPFRouters group 224.0.0. 2 Update: AllSPFRouters group 224.0.0. ACK: AllDRRouters^3 4 group 224.0.0.
Fig. 3-2. OSPF DR and BDR Advertisements
NOTE: The BDR simply listens to the packets sent to both Multicast groups.
In order for a router to be the DR or the BDR for the segment, the router must be elected. This
election is based on the following:
The highest router priority value
The highest router ID
By default, all routers have a default priority value of 1. This value can be adjusted using the ip
ospf priority <0-255> interface configuration command. The higher the priority, the
greater the likelihood the router will be elected DR for the segment. The router with the second
highest priority will then be elected BDR. If a priority value of 0 is configured, the router will
not participate in the DR/BDR election process.
When determining the OSPF router ID, Cisco IOS selects the highest IP address of configured
Loopback interfaces. If no Loopback interfaces are configured, the software uses the highest IP
address of all configured physical interfaces as the OSPF router ID. Cisco IOS software also
allows administrators to specify the router ID manually using the router-id [address]
router configuration command.
It is important to remember that with OSPF, once the DR and the BDR have been elected, they
will remain as DR/BDR routers until a new election is held. For example, if a DR and a BDR
exist on a multi-access network and a router with a higher priority or IP address is added to the
to establish an adjacency with only these two routers and no other non-DR and BDR routers.
The DR and BDR also establish an adjacency between themselves. This reduces the number of
adjacencies required on the segment and on each individual OSPF router, which in turn reduces
resources consumption (e.g., memory and processor utilization) on the routers.
Regarding the second point, OSPF views a link as a connection between two routers or nodes.
In multi-access networks, such as Ethernet, multiple routers can reside on the same segment, as
illustrated in Figure 3-3. On such networks, OSPF uses the Network Link State Advertisement
(Type 2 LSA) to advertise the routers on the multi-access segment. This LSA is generated by the
DR and is flooded only within the area. Because the other non-DR/BDR routers do not establish
adjacencies with each other, this LSA allows those routers to know about the other routers on
the multi-access segment.
To further clarify this point, referencing Figure 3-3, assuming that all routers on the segment
have the default OSPF priority value of 1, R4 is elected as the Designated Router for the
segment because it has the highest router ID. R3 is elected as Backup Designated Router for the
segment because it has the second highest router ID. Because R2 and R1 are neither the DR nor
the BDR, they are referred to as DROther routers in Cisco terminology. This can be validated
using the show ip ospf neighbor command on all routers as follows:
R1# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 2WAY/DROTHER 00:00:38 192 .168.1.2 Ethernet0/ 3.3.3.3 1 FULL/BDR 00:00:39 192.168.1.3 Ethernet0/ 4.4.4.4 1 FULL/DR 00:00:38 192.168.1.4 Ethernet0/ R2# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 2WAY/DROTHER 00:00:32 192.168.1.1 FastEthernet0/ 3.3.3.3 1 FULL/BDR 00:00:33 192.168.1.3 FastEthernet0/ 4.4.4.4 1 FULL/DR 00:00:32 192.168.1.4 FastEthernet0/ R3# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/DROTHER 00:00:36 192.168.1.1 FastEthernet0/ 2.2.2.2 1 FULL/DROTHER 00:00:36 192.168.1.2 FastEthernet0/ 4.4.4.4 1 FULL/DR 00:00:35 192.168.1.4 FastEthernet0/ R4# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/DROTHER 00:00:39 192.168.1.1 FastEthernet0/ 2.2.2.2 1 FULL/DROTHER 00:00:39 192.168.1.2 FastEthernet0/
3.3.3.3 1 FULL/BDR 00:00:30 192.168.1.3 FastEthernet0/ NOTE: The DROther routers remain in the 2WAY/DROTHER state because they exchange
their databases only with the DR and the BDR routers. Therefore, because there is no full
database exchange between the DROther routers, they will never reach the OSPF Full adjacency
state.
Because R4 has been elected DR, it generates the Network LSA, which advertises the other
routers on the multi-access segment. This LSA advertises the routers on the multi-access
segment. This can be verified using the show ip ospf database network [link state
ID] command on any router on the segment or the show ip ospf database network
self-originate command on the DR only. The following illustrates the output of the show
ip ospf database network self-originate command on the DR (R4):
R4# show ip ospf database network self-originate OSPF Router with ID (4.4.4.4) (Process ID 4) Net Link States (Area 0) Routing Bit Set on this LSA LS age: 429 Options: (No TOS-capability, DC) LS Type: Network Links Link State ID: 192.168.1.4 (address of Designated Router) Advertising Router: 4.4.4. LS Seq Number: 80000006 Checksum: 0x7E Length: 40 Network Mask: / Attached Router: 4.4.4. Attached Router: 1.1.1. Attached Router: 2.2.2. Attached Router: 3.3.3.
Referencing the output above, the DR (R4) originates the Type 2 (Network LSA) representing
the 192.168.1.0/24 subnet. Because multiple routers exist on this subnet, this 192.168.1.0/
subnet is referred to as a transit link in OSPF terminology. The Advertising Router field shows
the router that originated this LSA. The Network Mask field shows the subnet mask of the
transit network, which is 24-bit or 255.255.255.0.
The Attached Router fields list the router IDs of all routers that are on the network segment.
This allows all of the routers on the segment to know what other routers also reside on the
segment. The output of the show ip ospf database network [link state ID]
command on R1, R2, and R3 reflects the same information as illustrated in the following
outputs:
Net Link States (Area 0) Routing Bit Set on this LSA LS age: 988 Options: (No TOS-capability, DC) LS Type: Network Links Link State ID: 192.168.1.4 (address of Designated Router) Advertising Router: 4.4.4. LS Seq Number: 80000006 Checksum: 0x7E Length: 40 Network Mask: / Attached Router: 4.4.4. Attached Router: 1.1.1. Attached Router: 2.2.2. Attached Router: 3.3.3.
The functionality of the Network LSA and how it is correlated to another LSA, specifically the
Router LSA (Type 1), will be described in detail later in this chapter. For this section, primary
emphasis should be placed on understanding that the DR generates and advertises the Network
LSA on the multi-access segment to advertise other routers that reside on the same segment.
This is because routers on the segment establish an adjacency only with the DR and the BDR
routers and not with each other. Without an adjacency with each other, the routers would never
know about other non-DR/BDR routers on the multi-access segment.
Finally, regarding the third point made on DR/BDR routers, the DR/BDR routers ensure that all
routers on the segment have complete databases. Non-DR/BDR routers send updates to the
Multicast group address 224.0.0.6 (AllDRRouters). The DR then advertises these updates to
other non-DR/BDR routers by sending the update to the Multicast group address 224.0.0.
(AllSPFRouters). Figure 3-4 below illustrates an update from R1 (a DROther) to the DR group
address referencing the routers illustrated in Figure 3-3:
Fig. 3-4. DROther Update to DR/BDR Group Address
R4 (DR) receives this update and in turn sends the same to Multicast group address 224.0.0.5.
This group address is used by all OSPF routers, ensuring that all other routers on the segment
receive this update. This update from the DR (R4) is illustrated in Figure 3-5 below:
Fig. 3-5. DR Update to OSPF Group Address
NOTE: We can determine this is the Update from R1 because the Advertising Router field in
both Figures 3-4 and 3-5 contains the router ID (RID) of R1, which is 1.1.1.1.
NOTE: The other LSAs used by OSPF will be described in detail later in this chapter.
An Area Border Router (ABR) is an OSPF router that connects one or more OSPF areas to the
OSPF backbone. This means that it must have at least one interface in Area 0 and another
interface, or interfaces, within a different OSPF area. ABRs are members of all areas to which
they belong and keep a separate Link State Database for every area to which they belong.
Referencing Figure 3-6, R3 would be considered an ABR, as it connects Area 2 to the OSPF
backbone, or Area 0.
An Autonomous System Boundary Router (ASBR), in the traditional sense, resides at the edge
of the routing domain and defines the boundary between the internal and the external
networks. Referencing Figure 3-6, R2 would be considered an ASBR. In addition to injecting
routing information from other protocols (e.g., BGP), a router can also be classified as an ASBR
if it injects static routes or connected subnets into the OSPF domain.
Internal routers maintain all operational interfaces within a single OSPF area. Based on the
network topology illustrated in Figure 3-6, R4 would be considered an internal router because
its only interface resides within a single OSPF area.
Backbone routers are routers that have an interface in the OSPF backbone. Backbone routers can
include routers that have interfaces only in the OSPF backbone area or routers that have an
interface in the OSPF backbone area as well as interfaces in other areas (ABRs). Based on the
topology illustrated in Figure 3-6, both R2 and R3 would be considered backbone routers.
NOTE: OSPF routers can have multiple roles. For example, R2 is both an ASBR and a backbone
router, while R3 is both a backbone router and an ABR. Throughout this chapter, we will take a
detailed look at these types of routers and their roles and functions within the OSPF domain.
OSPF Configuration Fundamentals
This section describes OSPF configuration fundamentals and builds upon the configuration of
OSPF as described in the CCNA certification course.
Enabling OSPF in Cisco IOS Software
OSPF is enabled in Cisco IOS software by issuing the router ospf [process id] global
configuration command. The [process id] is locally significant and does not need to be the
same on all routers in the network in order to establish an adjacency. The use of the locally
significant process ID allows you to configure multiple instances of OSPF on the same router.
The OSPF process ID is an integer between 1 and 65535. Each OSPF process maintains its own
separate Link State Database; however, all routes are entered into the same IP routing table. In
other words, there is no unique IP routing table for each individual OSPF process configured on
the router. A separate routing table is used only when OSPF Virtual Routing and Forwarding or
VPN Routing and Forwarding (VRF) configuration is implemented on the router. VRF will be
described in detail later in this guide.
In earlier versions of Cisco IOS software, OSPF would not be enabled if the router did not have
at least one interface configured with a valid IP address in the up/up state. This restriction has
been removed in current versions of Cisco IOS software. In the event that the router has no
interfaces configured with a valid IP address and in the up/up state, Cisco IOS will create a
Proximity Database (PDB) and allow the process to be created. However, it is important to
remember that the process will be inactive until a router ID is selected, which can be performed
in the following two ways:
1. Configuring a valid IP address on an interface and bringing the interface up
2. Configuring the router ID manually using the router-id command
As an example, consider the following router, which has all interfaces disabled:
R3# show ip interface brief Interface IP-Address OK? Method Status Protocol FastEthernet0/0 unassigned YES manual administratively down down Serial0/0 unassigned YES NVRAM administratively down down Serial0/1 unassigned YES unset administratively down down
Next, OSPF is enabled on the router using the router ospf [process id] global
configuration command as illustrated in the following output:
R3(config)# router ospf 1 R3(config-router)# exit
Based on this configuration, Cisco IOS software assigns the process a default router ID of 0.0.0.
as illustrated in the following output of the show ip protocols command:
R3# show ip protocols Routing Protocol is "ospf 1" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Router ID 0.0.0. Number of areas in this router is 0. 0 normal 0 stub 0 nssa Maximum path: 4 Routing for Networks: Reference bandwidth unit is 100 mbps Routing Information Sources: Gateway Distance Last Update Distance: (default is 110)
