| LSA TYPE | Name | Description |
| 1 | Router LSA | A Router-LSA includes information about the link states of all of a router's interfaces. These LSAs are flooded throughout the area, but not into adjacent areas. |
| 2 | Network LSA | On NBMA and broadcast capable network segments, the DR originates Network-LSAs. The Network-LSA describes the routers that are connected to this broadcast or NBMA segment. Network-LSAs are flooded throughout the area, but not into adjacent areas. |
| 3 | Summary LSA ABR | ABR routers originate Summary-LSAs to describe interarea routes to networks that are outside of the area but inside of the AS. They are flooded throughout an area. Type 3 LSAs are used for routes to networks. |
| 4 | Summary LSA ASBR | Type 4 LSAs are similar to Type 3 LSAs, except that they are used for routes to ASBR routers. |
| 5 | AS-external-LSA | ASBR routers originate Type 5 LSAs to describe routes to networks that are external to the AS. Type 5 LSAs are flooded throughout the AS. |
| 6 | MOSPF-LSA | Type 6 LSAs are used for carrying multicast routing information with MOSPF. Cisco routers do not currently support Type 6 LSAs. |
| 7 | NSSA-External-LSA | Type 7 LSAs are originated by ASBRs in an NSSA area. They are similar to Type 5 LSAs, except that they are only flooded throughout the NSSA area. When Type 7 LSAs reach the ABR, it translates them into Type 5 LSAs and distributes them to the rest of the AS |
Monday, 23 August 2010
OSPF LSA Types
Sunday, 22 August 2010
Adjusting OSPF Timers
You can improve the convergence time of OSPF on a particular interface by reducing the hello and dead timers:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#interface Serial0/1
Router1(config-if)#ip ospf hello-interval 5
Router1(config-if)#ip ospf dead-interval 20
Router1(config-if)#exit
Router1(config)#end
Router1#
If you make this change on one router, you must make it on all of the other routers sharing the same network segment:
Router2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#interface Serial0/0
Router2(config-if)#ip ospf hello-interval 5
Router2(config-if)#ip ospf dead-interval 20
Router2(config-if)#exit
Router2(config)#end
Router2#
OSPF uses two timers. The hello timer controls how often the router sends routine messages to its neighbors simply by indicating that it is still up. If the neighbors don't hear any hello messages for a length of time defined by the dead-interval, they assume that the router is no longer reachable and drop it from the adjacency table.
The default values are 10 seconds for the hello time, and 40 seconds for the dead time. The usual rule of thumb with OSPF is to keep the dead time value four times the hello interval. However, this is not a strict rule. EIGRP, for example, uses a dead time that is only three times its hello interval. So if you wanted OSPF to have convergence times that more closely matched those of EIGRP, you could set the OSPF hello time to 5 seconds, and the dead interval to 15 seconds. Bear in mind that shortening the hello timer will increase the amount of traffic on the link. And shortening the dead interval increases the chances of losing adjacency just because of network congestion or link errors.
It is important to adjust the timers on all routers on the network segment together. Unlike EIGRP, which allows every router to use a different set of timers, in OSPF, the routers cannot establish adjacencies if their timers do not match exactly. But you can adjust the timers separately on different interfaces on a router. So you can use slower timers on low bandwidth links, and faster timers on faster links. In general, we don't recommend increasing the timers from their default values, but it can be useful to decrease them to improve convergence on important high-speed segments.
You can see the new timers with the show ip ospf interface command:
Router2#show ip ospf interface Serial0/0
Serial0/0 is up, line protocol is up
Internet Address 10.1.1.1/30, Area 2
Process ID 12, Router ID 192.168.30.1, Network Type POINT_TO_POINT, Cost: 130
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 5, Dead 20, Wait 20, Retransmit 5
Hello due in 00:00:04
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 172.25.25.1
Suppress hello for 0 neighbor(s)
Simple password authentication enabled
Router2#
Looking at the neighbor table, you can see that the dead time reflects the configuration change. Note that the time indicated in this output is the actual time remaining before OSPF declares this neighbor invalid. So if everything is working properly, this value show count down from the configured dead time value until the hello interval expires. Then another hello packet will be sent, and the dead timer will start over at its maximum value:
Router2#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface
172.25.25.1 1 FULL/ - 00:00:19 10.1.1.2 Serial0/0
Router2#
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#interface Serial0/1
Router1(config-if)#ip ospf hello-interval 5
Router1(config-if)#ip ospf dead-interval 20
Router1(config-if)#exit
Router1(config)#end
Router1#
If you make this change on one router, you must make it on all of the other routers sharing the same network segment:
Router2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#interface Serial0/0
Router2(config-if)#ip ospf hello-interval 5
Router2(config-if)#ip ospf dead-interval 20
Router2(config-if)#exit
Router2(config)#end
Router2#
OSPF uses two timers. The hello timer controls how often the router sends routine messages to its neighbors simply by indicating that it is still up. If the neighbors don't hear any hello messages for a length of time defined by the dead-interval, they assume that the router is no longer reachable and drop it from the adjacency table.
The default values are 10 seconds for the hello time, and 40 seconds for the dead time. The usual rule of thumb with OSPF is to keep the dead time value four times the hello interval. However, this is not a strict rule. EIGRP, for example, uses a dead time that is only three times its hello interval. So if you wanted OSPF to have convergence times that more closely matched those of EIGRP, you could set the OSPF hello time to 5 seconds, and the dead interval to 15 seconds. Bear in mind that shortening the hello timer will increase the amount of traffic on the link. And shortening the dead interval increases the chances of losing adjacency just because of network congestion or link errors.
It is important to adjust the timers on all routers on the network segment together. Unlike EIGRP, which allows every router to use a different set of timers, in OSPF, the routers cannot establish adjacencies if their timers do not match exactly. But you can adjust the timers separately on different interfaces on a router. So you can use slower timers on low bandwidth links, and faster timers on faster links. In general, we don't recommend increasing the timers from their default values, but it can be useful to decrease them to improve convergence on important high-speed segments.
You can see the new timers with the show ip ospf interface command:
Router2#show ip ospf interface Serial0/0
Serial0/0 is up, line protocol is up
Internet Address 10.1.1.1/30, Area 2
Process ID 12, Router ID 192.168.30.1, Network Type POINT_TO_POINT, Cost: 130
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 5, Dead 20, Wait 20, Retransmit 5
Hello due in 00:00:04
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 172.25.25.1
Suppress hello for 0 neighbor(s)
Simple password authentication enabled
Router2#
Looking at the neighbor table, you can see that the dead time reflects the configuration change. Note that the time indicated in this output is the actual time remaining before OSPF declares this neighbor invalid. So if everything is working properly, this value show count down from the configured dead time value until the hello interval expires. Then another hello packet will be sent, and the dead timer will start over at its maximum value:
Router2#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface
172.25.25.1 1 FULL/ - 00:00:19 10.1.1.2 Serial0/0
Router2#
BGP Route Selection
Unlike the various interior routing protocols that we discussed in the preceding chapters, BGP doesn't support multipath routing by default. So if there are two or more paths to a destination, BGP will go to great extremes to ensure that only one of them is actually used.
BGP decides which route to use by applying a series of tests in order. It is important to understand these tests and the order that the router looks at them, particularly when you are trying to influence which routes are used. Otherwise you might end up wasting a lot of time trying to adjust your routing tables by using one method, while the router is making the actual decision at some earlier step, and never seeing your adjustments.
1 , The first test is whether the next hop router is accessible. By default, routers do not update the next-hop attribute when exchanging routes by iBGP. So it is possible to receive a route whose next hop router is actually several hops away, and perhaps unreachable. BGP will not pass these routes to the main routing table, but it will keep them in its own route database.
2 , If synchronization is enabled, the router will ignore any iBGP routes that are not synchronized.
3, The third test uses the Cisco proprietary weight parameter, selecting the route with the largest weight value. This parameter is not part of the routing protocol. Adjusting the weight of a particular route on a router will only affect route selection on this router. It is a purely local concept. The default weight value is zero, except for locally sourced routes, which get a default weight of 32,768. The maximum possible weight is 65,535.
4, If the weights are the same, BGP then selects the route with the highest Local Preference value, from the LOCAL_PREF attribute. Routers only include this attribute when communicating within an AS (iBGP). For external routes, the router that receives a particular route via eBGP sets the Local Preference value. For internal routes, it is set by the router that introduced the route into BGP. This allows you to force every router in your AS to preferentially send traffic for a particular destination through a particular eBGP link.
5, Next, the router looks to see if any of the equivalent routes were originated locally on this router by either a network or an aggregate command, with those originated locally by a network command being preferred.
6, If two or more routes to the same destination network are still equal, the router moves on to look at the AS_PATH. This is the path vector that gives BGP its essential character. It is a set of AS numbers that describes the path to the destination network.
7, A BGP router will prefer any routes that originate inside its own AS.
8, For routes that originate outside of the AS, BGP will prefer the one with the shortest path (i.e., the one with the fewest ASNs). This is a simple indication of the most direct path.
9, BGP then looks at the ORIGIN attribute if the AS Path lengths are the same, and selects IGP routes in preference to EGP, and EGP in preference to INCOMPLETE routes. An INCOMPLETE route is one that is injected into BGP via redistribution, so BGP isn't able to vouch for its validity
.
10, The next test looks at the Multiple Exit Discriminator (MED) and selects route with the lowest value. The MED is only used if both routes are received from the same AS, or if the command bgp always-compare-med has been enabled. With this command enabled, BGP will compare MED values even if they come from different ASs, although to reach this step the AS_PATHs must have the same length. Note that if you use this command at all, you should use it throughout the AS or you risk creating routing loops. MED values are only propagated to adjacent ASs, so routers that are further downstream don't see them at all.
11, BGP will prefer eBGP to iBGP paths. This helps to eliminate loops by ensuring that the route selected is the one that leads out of the AS most directly. Note that the iBGP routes don't include internal routes that are sourced from within your AS because they are selected at step number 5 above. So this test looks only at routes to external destinations.
12, The next test compares the IGP costs of the paths to the next hop routers and selects the closest one. This helps to ensure that faster links and shorter paths are used when possible.
13, Next, BGP will look at the ages of the routes and use the oldest route to a particular destination. This is an indication of stability. If two routes are otherwise equivalent, it is best to use the one that appears to be the most stable.
14, And finally, if the routes are still equivalent, BGP resorts to the router IDs of the next hop routers to break any ties, selecting the next hop router with the lowest router ID. Since router IDs are unique, this is guaranteed to eliminate any remaining duplicate route problems.
BGP decides which route to use by applying a series of tests in order. It is important to understand these tests and the order that the router looks at them, particularly when you are trying to influence which routes are used. Otherwise you might end up wasting a lot of time trying to adjust your routing tables by using one method, while the router is making the actual decision at some earlier step, and never seeing your adjustments.
1 , The first test is whether the next hop router is accessible. By default, routers do not update the next-hop attribute when exchanging routes by iBGP. So it is possible to receive a route whose next hop router is actually several hops away, and perhaps unreachable. BGP will not pass these routes to the main routing table, but it will keep them in its own route database.
2 , If synchronization is enabled, the router will ignore any iBGP routes that are not synchronized.
3, The third test uses the Cisco proprietary weight parameter, selecting the route with the largest weight value. This parameter is not part of the routing protocol. Adjusting the weight of a particular route on a router will only affect route selection on this router. It is a purely local concept. The default weight value is zero, except for locally sourced routes, which get a default weight of 32,768. The maximum possible weight is 65,535.
4, If the weights are the same, BGP then selects the route with the highest Local Preference value, from the LOCAL_PREF attribute. Routers only include this attribute when communicating within an AS (iBGP). For external routes, the router that receives a particular route via eBGP sets the Local Preference value. For internal routes, it is set by the router that introduced the route into BGP. This allows you to force every router in your AS to preferentially send traffic for a particular destination through a particular eBGP link.
5, Next, the router looks to see if any of the equivalent routes were originated locally on this router by either a network or an aggregate command, with those originated locally by a network command being preferred.
6, If two or more routes to the same destination network are still equal, the router moves on to look at the AS_PATH. This is the path vector that gives BGP its essential character. It is a set of AS numbers that describes the path to the destination network.
7, A BGP router will prefer any routes that originate inside its own AS.
8, For routes that originate outside of the AS, BGP will prefer the one with the shortest path (i.e., the one with the fewest ASNs). This is a simple indication of the most direct path.
9, BGP then looks at the ORIGIN attribute if the AS Path lengths are the same, and selects IGP routes in preference to EGP, and EGP in preference to INCOMPLETE routes. An INCOMPLETE route is one that is injected into BGP via redistribution, so BGP isn't able to vouch for its validity
.
10, The next test looks at the Multiple Exit Discriminator (MED) and selects route with the lowest value. The MED is only used if both routes are received from the same AS, or if the command bgp always-compare-med has been enabled. With this command enabled, BGP will compare MED values even if they come from different ASs, although to reach this step the AS_PATHs must have the same length. Note that if you use this command at all, you should use it throughout the AS or you risk creating routing loops. MED values are only propagated to adjacent ASs, so routers that are further downstream don't see them at all.
11, BGP will prefer eBGP to iBGP paths. This helps to eliminate loops by ensuring that the route selected is the one that leads out of the AS most directly. Note that the iBGP routes don't include internal routes that are sourced from within your AS because they are selected at step number 5 above. So this test looks only at routes to external destinations.
12, The next test compares the IGP costs of the paths to the next hop routers and selects the closest one. This helps to ensure that faster links and shorter paths are used when possible.
13, Next, BGP will look at the ages of the routes and use the oldest route to a particular destination. This is an indication of stability. If two routes are otherwise equivalent, it is best to use the one that appears to be the most stable.
14, And finally, if the routes are still equivalent, BGP resorts to the router IDs of the next hop routers to break any ties, selecting the next hop router with the lowest router ID. Since router IDs are unique, this is guaranteed to eliminate any remaining duplicate route problems.
BGP Attributes
BGP associates several different basic attributes with each route prefix. These attributes include useful pieces of information about the route, where it came from, and how to reach it. Well known attributes must be supported by every BGP implementation. Some well known attributes are mandatory. All of the mandatory attributes must be included with every route entry. A BGP router will generate an error message if it receives a route that is missing one or more well known mandatory attributes.
There are also well known discretionary attributes, which every BGP router must recognize and support, but that don't have to be present with every route entry. Whenever a router passes along a route that it has learned via BGP to another BGP peer, it must include all of the well known attributes that came with this route, including any discretionary attributes. Of course, the router may need to update some of these attributes before passing them along, to include itself in the path, for example.
BGP routes can also include one or more optional attributes. These are not necessarily supported by all BGP implementations. Optional attributes can be either transitive or nontransitive, which is specified by a special flag in the attribute type field. If a router receives a route with a transitive optional attribute, it will pass this information along intact to other BGP routers, even if it doesn't understand the option. The router will mark the Partial bit in the attribute flags to indicate that it was unable to handle this attribute, however.
The router will quietly drop any unrecognized nontransitive optional attributes from the route information without taking any action.
We will now describe several of the most common BGP attributes.
ORIGIN Well known, Mandatory
---------------------------------------------
This attribute can have one of three different values, reflecting how the BGP router that was responsible for originating the route first learned it. The possible values are:
IGP: the route came from an IGP interior to the originating AS.
EGP: the route came from an EGP other than BGP.
Incomplete: any other method.
AS_PATH Well known, Mandatory
-----------------------------------------------
The AS_PATH is a list of ASNs, which show the path taken to reach the destination network. There are actually two types of AS_PATHs. An AS_SEQUENCE describes the literal path taken to reach the destination, while an AS_SET is an unordered list of ASNs along the path. Each time a BGP router passes a route update to an eBGP peer, it updates the AS_PATH variable to include its own ASN.
NEXT_HOP Well known, Mandatory
-------------------------------------------
This attribute carries the IP address of the first BGP router along the path to the destination network. When the router installs the route for the associated prefix in its routing table, it will use this attribute for the next hop router. This is where the router will forward its packets for this destination network.
By default, the NEXT_HOP router will be the router that announced this route to the AS. For routes learned from an external AS via eBGP, the NEXT_HOP router will be the first router in the neighboring AS. This information is passed intact throughout the AS by using iBGP, so all routers in the AS see the same NEXT_HOP router.
MULTI_EXIT_DISC Optional, Nontransitive
---------------------------------------------------------
The Multiple Exit Discriminatory (MED) option is also often called the BGP Metric. Because this 32-bit value is non-transitive, it is only propagated to adjacent ASs. Routers can use the MED to help differentiate between two or more equivalent paths between these ASs.
LOCAL_PREF Well known, Discretionary
---------------------------------------------------
BGP only distributes Local Preference information with routes inside of an AS. Routers can use this number to allow the network to favor a particular exit point to reach a destination network. This information is not included with eBGP route updates.
ATOMIC_AGGREGATE Well known, Discretionary
----------------------------------------------------------
When a BGP router aggregates several route prefixes to simplify the routing tables that it passes to its peers, it usually sets the ATOMIC_AGGREGATE attribute to indicate that some information has been lost. It doesn't set this attribute, however, in cases in which it uses an AS_SET in its AS_PATH to show the ASNs of all of the different prefixes being summarized.
AGGREGATOR Optional, Transitive
-------------------------------------------
The AGGREGATOR attribute indicates that a router has summarized a range of prefixes. The router doing the route aggregation can include this attribute, which will include its own ASN and IP address or Router ID.
COMMUNITY Optional, Transitive
------------------------------------------
A COMMUNITY is a logical grouping of networks. This attribute is defined in RFC 1997, and RFC 1998 describes a useful application of the concept to ISP networks.
MP_REACH_NLRI Optional, Nontransitive
--------------------------------------------------
This attribute carries information about reachable multiprotocol destinations and next-hop routers. Multiprotocol in this context could refer to any foreign protocol, such as IPv6, although it is most commonly used with IP multicast, as we will discuss in Chapter 23. Multiprotocol Label Switching (MPLS) also uses MBGP for per-VPN routing tables.
MP_UNREACH_NLRIOptional, Nontransitive
-----------------------------------------------------
The MP_UNREACH_NLRI attribute is similar to the MP_REACH_NLRI, except that it carries information about unreachable multiprotocol destinations.
There are also well known discretionary attributes, which every BGP router must recognize and support, but that don't have to be present with every route entry. Whenever a router passes along a route that it has learned via BGP to another BGP peer, it must include all of the well known attributes that came with this route, including any discretionary attributes. Of course, the router may need to update some of these attributes before passing them along, to include itself in the path, for example.
BGP routes can also include one or more optional attributes. These are not necessarily supported by all BGP implementations. Optional attributes can be either transitive or nontransitive, which is specified by a special flag in the attribute type field. If a router receives a route with a transitive optional attribute, it will pass this information along intact to other BGP routers, even if it doesn't understand the option. The router will mark the Partial bit in the attribute flags to indicate that it was unable to handle this attribute, however.
The router will quietly drop any unrecognized nontransitive optional attributes from the route information without taking any action.
We will now describe several of the most common BGP attributes.
ORIGIN Well known, Mandatory
---------------------------------------------
This attribute can have one of three different values, reflecting how the BGP router that was responsible for originating the route first learned it. The possible values are:
IGP: the route came from an IGP interior to the originating AS.
EGP: the route came from an EGP other than BGP.
Incomplete: any other method.
AS_PATH Well known, Mandatory
-----------------------------------------------
The AS_PATH is a list of ASNs, which show the path taken to reach the destination network. There are actually two types of AS_PATHs. An AS_SEQUENCE describes the literal path taken to reach the destination, while an AS_SET is an unordered list of ASNs along the path. Each time a BGP router passes a route update to an eBGP peer, it updates the AS_PATH variable to include its own ASN.
NEXT_HOP Well known, Mandatory
-------------------------------------------
This attribute carries the IP address of the first BGP router along the path to the destination network. When the router installs the route for the associated prefix in its routing table, it will use this attribute for the next hop router. This is where the router will forward its packets for this destination network.
By default, the NEXT_HOP router will be the router that announced this route to the AS. For routes learned from an external AS via eBGP, the NEXT_HOP router will be the first router in the neighboring AS. This information is passed intact throughout the AS by using iBGP, so all routers in the AS see the same NEXT_HOP router.
MULTI_EXIT_DISC Optional, Nontransitive
---------------------------------------------------------
The Multiple Exit Discriminatory (MED) option is also often called the BGP Metric. Because this 32-bit value is non-transitive, it is only propagated to adjacent ASs. Routers can use the MED to help differentiate between two or more equivalent paths between these ASs.
LOCAL_PREF Well known, Discretionary
---------------------------------------------------
BGP only distributes Local Preference information with routes inside of an AS. Routers can use this number to allow the network to favor a particular exit point to reach a destination network. This information is not included with eBGP route updates.
ATOMIC_AGGREGATE Well known, Discretionary
----------------------------------------------------------
When a BGP router aggregates several route prefixes to simplify the routing tables that it passes to its peers, it usually sets the ATOMIC_AGGREGATE attribute to indicate that some information has been lost. It doesn't set this attribute, however, in cases in which it uses an AS_SET in its AS_PATH to show the ASNs of all of the different prefixes being summarized.
AGGREGATOR Optional, Transitive
-------------------------------------------
The AGGREGATOR attribute indicates that a router has summarized a range of prefixes. The router doing the route aggregation can include this attribute, which will include its own ASN and IP address or Router ID.
COMMUNITY Optional, Transitive
------------------------------------------
A COMMUNITY is a logical grouping of networks. This attribute is defined in RFC 1997, and RFC 1998 describes a useful application of the concept to ISP networks.
MP_REACH_NLRI Optional, Nontransitive
--------------------------------------------------
This attribute carries information about reachable multiprotocol destinations and next-hop routers. Multiprotocol in this context could refer to any foreign protocol, such as IPv6, although it is most commonly used with IP multicast, as we will discuss in Chapter 23. Multiprotocol Label Switching (MPLS) also uses MBGP for per-VPN routing tables.
MP_UNREACH_NLRIOptional, Nontransitive
-----------------------------------------------------
The MP_UNREACH_NLRI attribute is similar to the MP_REACH_NLRI, except that it carries information about unreachable multiprotocol destinations.
Manipulating DR Selection
Some case administrator want to manipulate the Designated Router (DR) selection process on a particular subnet.The ip ospf priority configuration command allows you to weight the Designated Router (DR) selection process on a network segment. The following configuration examples are for three different routers that all share the same Ethernet segment. Router5 has the highest OSPF priority, so it will become the DR. RTR1 has the second highest priority because we want it to be the Backup Designated Router (BDR).
Router1 is connected to this network segment through a VLAN trunk:
RTR1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
RTR1(config)#interface FastEthernet0/0.1
RTR1(config-subif)#ip ospf priority 2
RTR1(config-subif)#exit
RTR1(config)#endRouter1#
We will configure RTR3 with a priority of 0. The default priority is 1. A router with priority 0 will never become the DR or BDR:
RTR3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
RTR3(config)#interface FastEthernet0/0.1
RTR3(config-subif)#ip ospf priority 0
RTR3(config-subif)#exit
RTR3(config)#end
RTR3#
RTR5 has the highest priority, so it will become the DR for the segment:
RTR5#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
RTR5(config)#interface Ethernet0
RTR5(config-if)#ip ospf priority 10
RTR5(config-if)#exit
RTR5(config)#end
RTR5#
There are several reasons for rigging the DR election process, as we have done in this recipe. The most common reason is simply to ensure that the router closest to the network core is responsible for distributing routing information. This is actually a somewhat aesthetic requirement, because all of the routers in an area see all of the LSAs for that area, so nobody's routing table is more accurate than anybody else's. But it can result in faster convergence in some network configurations.
But there are two times when it is critical to force a particular router to become the DR. The first is when you are using MOSPF to handle multicast routing. MOSPF uses the same DR as regular OSPF. So if you have a mix of MOSPF and regular OSPF on the same segment, it is critical that an MOSPF router be the DR, or no multicast routes will be distributed. Because Cisco routers do not support MOSPF, this means that you must set the priority to 0 for all Cisco routers on such a segment.
The second place where DR selection is critical is in Nonbroadcast Multiple Access (NBMA) networks. A typical example of this would be a Frame Relay WAN that uses multipoint subinterfaces, as described in Recipe 10.4. In this case, all of the routers are members of the same subnet, but only the central hub router can talk directly to the branch devices. A branch router should never act as DR because it can't talk directly to any of the other branches. The central router is the only device that can be the DR, or the routing updates will not work.
If you don't adjust the priorities to help force a particular winner to the DR election, the DR will be the router with the highest Router ID (RID) value.
It is important to note that setting a higher priority can help to rig the DR election process, but it doesn't guarantee that another lower priority router device won't become DR if it happens to be there first. And if a higher priority router comes up on a segment that already has a DR, it will not preempt either the DR or the BDR. If the higher priority router isn't available when a lower priority router joins the segment, then the lower priority router will become DR. Once a router is DR, it will remain DR until you either manually reset the neighbor relationships or until there is a network failure on the segment that forces the change.
The exception to this rule is when you configure a router with a priority of 0. In this case, the router will never become DR, even if it is the only router on the segment.
You can see the state of all of the neighboring routers on a segment with the show ip ospf neighbor command:
Router5#show ip ospf neighbor Ethernet0
Neighbor ID Pri State Dead Time Address Interface
Router1 2 FULL/BDR 00:00:31 172.25.1.5 Ethernet0
Router3 0 FULL/DROTHER 00:00:31 172.25.1.3 Ethernet0
Router4 1 FULL/DROTHER 00:00:39 172.25.1.1 Ethernet0
Router5#
In this output, we have asked the router to only show the neighbors on the Ethernet0 interface. You can see that Router1 is the BDR, and the other two routers on the segment have a state of DROTHER. This means that they are neither DR nor BDR, but are neighbors. Notice that none of the routers listed is the DR. This is because the router we typed this on was the DR itself.
You can verify that this router is the DR, and that it has a priority of 10 with the show ip ospf interface command:
Router5#show ip ospf interface
Ethernet0 is up, line protocol is up
Internet Address 172.25.1.7/24, Area 0
Process ID 87, Router ID 172.25.1.7, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DR, Priority 10
Designated Router (ID) 172.25.25.6, Interface address 172.25.1.7
Backup Designated router (ID) Router1, Interface address 172.25.1.3
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:03
Neighbor Count is 3, Adjacent neighbor count is 3
Adjacent with neighbor Router3
Adjacent with neighbor Router1 (Backup Designated Router)
Adjacent with neighbor Router4
Suppress hello for 0 neighbor(s)
Router5#
In the following example, we have increased the priority of Router4 to 10, as well. However, as you can see, not only does it not pre-empt the DR, it doesn't even pre-empt the BDR:
Router5#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
Router4 10 FULL/DROTHER 00:00:30 172.25.1.5 Ethernet0
Router1 2 FULL/BDR 00:00:38 172.25.1.3 Ethernet0
Router3 0 FULL/DROTHER 00:00:30 172.25.1.1 Ethernet0
Router5#
Because higher priority routers will not pre-empt existing DR and BDR routers, if there are routers that should not become DR for any reason, you should be careful to set their priorities to 0. Otherwise, you may find that the DR is simply the router that has been active for the longest time, instead of the one that you actually wanted.
Router1 is connected to this network segment through a VLAN trunk:
RTR1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
RTR1(config)#interface FastEthernet0/0.1
RTR1(config-subif)#ip ospf priority 2
RTR1(config-subif)#exit
RTR1(config)#endRouter1#
We will configure RTR3 with a priority of 0. The default priority is 1. A router with priority 0 will never become the DR or BDR:
RTR3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
RTR3(config)#interface FastEthernet0/0.1
RTR3(config-subif)#ip ospf priority 0
RTR3(config-subif)#exit
RTR3(config)#end
RTR3#
RTR5 has the highest priority, so it will become the DR for the segment:
RTR5#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
RTR5(config)#interface Ethernet0
RTR5(config-if)#ip ospf priority 10
RTR5(config-if)#exit
RTR5(config)#end
RTR5#
There are several reasons for rigging the DR election process, as we have done in this recipe. The most common reason is simply to ensure that the router closest to the network core is responsible for distributing routing information. This is actually a somewhat aesthetic requirement, because all of the routers in an area see all of the LSAs for that area, so nobody's routing table is more accurate than anybody else's. But it can result in faster convergence in some network configurations.
But there are two times when it is critical to force a particular router to become the DR. The first is when you are using MOSPF to handle multicast routing. MOSPF uses the same DR as regular OSPF. So if you have a mix of MOSPF and regular OSPF on the same segment, it is critical that an MOSPF router be the DR, or no multicast routes will be distributed. Because Cisco routers do not support MOSPF, this means that you must set the priority to 0 for all Cisco routers on such a segment.
The second place where DR selection is critical is in Nonbroadcast Multiple Access (NBMA) networks. A typical example of this would be a Frame Relay WAN that uses multipoint subinterfaces, as described in Recipe 10.4. In this case, all of the routers are members of the same subnet, but only the central hub router can talk directly to the branch devices. A branch router should never act as DR because it can't talk directly to any of the other branches. The central router is the only device that can be the DR, or the routing updates will not work.
If you don't adjust the priorities to help force a particular winner to the DR election, the DR will be the router with the highest Router ID (RID) value.
It is important to note that setting a higher priority can help to rig the DR election process, but it doesn't guarantee that another lower priority router device won't become DR if it happens to be there first. And if a higher priority router comes up on a segment that already has a DR, it will not preempt either the DR or the BDR. If the higher priority router isn't available when a lower priority router joins the segment, then the lower priority router will become DR. Once a router is DR, it will remain DR until you either manually reset the neighbor relationships or until there is a network failure on the segment that forces the change.
The exception to this rule is when you configure a router with a priority of 0. In this case, the router will never become DR, even if it is the only router on the segment.
You can see the state of all of the neighboring routers on a segment with the show ip ospf neighbor command:
Router5#show ip ospf neighbor Ethernet0
Neighbor ID Pri State Dead Time Address Interface
Router1 2 FULL/BDR 00:00:31 172.25.1.5 Ethernet0
Router3 0 FULL/DROTHER 00:00:31 172.25.1.3 Ethernet0
Router4 1 FULL/DROTHER 00:00:39 172.25.1.1 Ethernet0
Router5#
In this output, we have asked the router to only show the neighbors on the Ethernet0 interface. You can see that Router1 is the BDR, and the other two routers on the segment have a state of DROTHER. This means that they are neither DR nor BDR, but are neighbors. Notice that none of the routers listed is the DR. This is because the router we typed this on was the DR itself.
You can verify that this router is the DR, and that it has a priority of 10 with the show ip ospf interface command:
Router5#show ip ospf interface
Ethernet0 is up, line protocol is up
Internet Address 172.25.1.7/24, Area 0
Process ID 87, Router ID 172.25.1.7, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DR, Priority 10
Designated Router (ID) 172.25.25.6, Interface address 172.25.1.7
Backup Designated router (ID) Router1, Interface address 172.25.1.3
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:03
Neighbor Count is 3, Adjacent neighbor count is 3
Adjacent with neighbor Router3
Adjacent with neighbor Router1 (Backup Designated Router)
Adjacent with neighbor Router4
Suppress hello for 0 neighbor(s)
Router5#
In the following example, we have increased the priority of Router4 to 10, as well. However, as you can see, not only does it not pre-empt the DR, it doesn't even pre-empt the BDR:
Router5#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
Router4 10 FULL/DROTHER 00:00:30 172.25.1.5 Ethernet0
Router1 2 FULL/BDR 00:00:38 172.25.1.3 Ethernet0
Router3 0 FULL/DROTHER 00:00:30 172.25.1.1 Ethernet0
Router5#
Because higher priority routers will not pre-empt existing DR and BDR routers, if there are routers that should not become DR for any reason, you should be careful to set their priorities to 0. Otherwise, you may find that the DR is simply the router that has been active for the longest time, instead of the one that you actually wanted.
Changing Administrative Distances
Sometimes Administrator need to change the administrative distance for an external network.use the distance command to adjust the administrative distance for a particular routing protocol. The precise syntax depends on the routing protocol.
This example uses RIP:
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#router rip
Router(config-route)#network 192.168.15.0
Router(config-route)#distance 15 192.168.15.1 0.0.0.0
Router(config-route)#distance 200 192.168.15.0 0.0.0.255
Router(config-route)#distance 255
Router(config-route)#end
Router#
For EIGRP, you can specify the distance for routes learned from both internal and external neighbors:
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#router eigrp 111
Router(config-route)#network 192.168.16.0
Router(config-route)#distance eigrp 55 200
Router(config-route)#end
Router#
With OSPF, you can also control the distance, depending on whether the neighboring router is in the same area:
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#router ospf 66
Router(config-route)#distance ospf inter-area 115
Router(config-route)#distance ospf intra-area 105
Router(config-route)#distance ospf external 125
Router(config-route)#end
Router#
And you can configure BGP distances for internal, external, and local routes:
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#router bgp 65520
Router(config-route)#distance bgp 115 220 50
Router(config-route)#end
Router#
When dealing with administrative distances, always bear in mind that they only affect route selection on this particular router. Administrative distances are not distributed by the routing protocols. However, they can affect the routing protocols. Distance vector algorithms in particular only distribute the routes that are used locally. Adjusting the administrative distance could change which routes are used. So you should always be extremely careful when adjusting administrative distances.
In fact, the main place where it makes sense to consider changing the administrative distance for a routing protocol is when the same route is distributed by two different protocols. For example, suppose you have an OSPF network that uses EIGRP to distribute routes for dial backup links. When both the primary OSPF link and backup EIGRP link are active, the router will prefer the routes it learns via EIGRP by default because of the lower administrative distance values. This will cause performance problems, since the backup link most likely has lower bandwidth, and it will probably also interfere with dropping the dialup connection because it is actively passing traffic. Changing the administrative distance can be an effective way of resolving this kind of conflict.
You can adjust these values to force the router to prefer routes learned by one protocol over those learned from another.
In the RIP example, shown in the Solution section above, the last distance command overrides the default administrative distance for RIP routes and sets it to 255:
Router(config)#router rip
Router(config-route)#distance 255
This is the worst possible administrative distance value. Any route with an administrative distance of 255 is considered infinitely far away and will never be used. You could also configure a lower administrative distance value for this protocol. If we gave it a value of 105, for example, then by default RIP routes would be better than OSPF, but worse than IGRP.
The second distance command line overrides the new default value for routes received from one particular router, 192.168.15.1. These routes will have a distance value of 15:
Router(config-route)#distance 15 192.168.15.1 0.0.0.0
The last field in this line is an address wildcard pattern. In the binary representation of this number, the 0s represent values in the address that are important and 1s represent values that can be ignored. In this case, the wildcard is 0.0.0.0, which means that every bit is important. So this refers to a single specific device, which is a router whose RIP routes we want to treat differently.
The third distance command line in the RIP changes the administrative distance value to 200 for routes learned from devices in the 192.168.15.0 subnet:
Router(config-route)#distance 200 192.168.15.0 0.0.0.255
The last field, 0.0.0.255, includes every device in the subnet.
Note the router processes these commands sequentially and stops as soon as it gets a match. So although the device 192.168.15.1 is also a member of the 192.168.15.0 subnet, its routes receive an administrative distance of 15. However, if the two commands were set in the opposite order, the more specific one would never be invoked.
This example represents another interesting use for administrative distances. You can use them as we have in this RIP example to ensure that you favor routes learned from particular routers over other less reliable devices. Note that this is only possible with distance vector protocols.
The EIGRP and OSPF configurations are similar, except that they include different options. The EIGRP example uses the distance eigrp command:
Router(config)#router eigrp 111
Router(config-route)#distance eigrp 55 200
This sets the administrative distance for routes learned by EIGRP to 55 if they are from the same EIGRP network, or 200 if they are external routes that have been redistributed into EIGRP.
OSPF also allows you to set a different administrative distance for external routes. And for internal routes, you can specify different administrative distances, depending on whether the route destination is internal or external to the area. This might be useful in certain cases in which you want to connect to another area through an external network rather than through the OSPF core. However, in most cases you do not need to treat intra-area and inter-area OSPF routes differently.
When setting distances for use with BGP, the syntax is distance bgp :
Router(config-route)#distance bgp 115 220 50
The external and internal distances are used for routes learned through eBGP and iBGP protocols, respectively. Local routes in this context are routes to destinations inside of this Autonomous System. Adjusting BGP administrative distances is relatively rare and frequently dangerous. The default value of 20 for eBGP and 200 for iBGP means that the router generally will prefer external BGP routes, but prefer any internal routing protocol to iBGP. This is almost always the required behavior. If you want to change the way the router handles BGP routes, we don't recommend using administrative distance.
This example uses RIP:
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#router rip
Router(config-route)#network 192.168.15.0
Router(config-route)#distance 15 192.168.15.1 0.0.0.0
Router(config-route)#distance 200 192.168.15.0 0.0.0.255
Router(config-route)#distance 255
Router(config-route)#end
Router#
For EIGRP, you can specify the distance for routes learned from both internal and external neighbors:
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#router eigrp 111
Router(config-route)#network 192.168.16.0
Router(config-route)#distance eigrp 55 200
Router(config-route)#end
Router#
With OSPF, you can also control the distance, depending on whether the neighboring router is in the same area:
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#router ospf 66
Router(config-route)#distance ospf inter-area 115
Router(config-route)#distance ospf intra-area 105
Router(config-route)#distance ospf external 125
Router(config-route)#end
Router#
And you can configure BGP distances for internal, external, and local routes:
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#router bgp 65520
Router(config-route)#distance bgp 115 220 50
Router(config-route)#end
Router#
When dealing with administrative distances, always bear in mind that they only affect route selection on this particular router. Administrative distances are not distributed by the routing protocols. However, they can affect the routing protocols. Distance vector algorithms in particular only distribute the routes that are used locally. Adjusting the administrative distance could change which routes are used. So you should always be extremely careful when adjusting administrative distances.
In fact, the main place where it makes sense to consider changing the administrative distance for a routing protocol is when the same route is distributed by two different protocols. For example, suppose you have an OSPF network that uses EIGRP to distribute routes for dial backup links. When both the primary OSPF link and backup EIGRP link are active, the router will prefer the routes it learns via EIGRP by default because of the lower administrative distance values. This will cause performance problems, since the backup link most likely has lower bandwidth, and it will probably also interfere with dropping the dialup connection because it is actively passing traffic. Changing the administrative distance can be an effective way of resolving this kind of conflict.
You can adjust these values to force the router to prefer routes learned by one protocol over those learned from another.
In the RIP example, shown in the Solution section above, the last distance command overrides the default administrative distance for RIP routes and sets it to 255:
Router(config)#router rip
Router(config-route)#distance 255
This is the worst possible administrative distance value. Any route with an administrative distance of 255 is considered infinitely far away and will never be used. You could also configure a lower administrative distance value for this protocol. If we gave it a value of 105, for example, then by default RIP routes would be better than OSPF, but worse than IGRP.
The second distance command line overrides the new default value for routes received from one particular router, 192.168.15.1. These routes will have a distance value of 15:
Router(config-route)#distance 15 192.168.15.1 0.0.0.0
The last field in this line is an address wildcard pattern. In the binary representation of this number, the 0s represent values in the address that are important and 1s represent values that can be ignored. In this case, the wildcard is 0.0.0.0, which means that every bit is important. So this refers to a single specific device, which is a router whose RIP routes we want to treat differently.
The third distance command line in the RIP changes the administrative distance value to 200 for routes learned from devices in the 192.168.15.0 subnet:
Router(config-route)#distance 200 192.168.15.0 0.0.0.255
The last field, 0.0.0.255, includes every device in the subnet.
Note the router processes these commands sequentially and stops as soon as it gets a match. So although the device 192.168.15.1 is also a member of the 192.168.15.0 subnet, its routes receive an administrative distance of 15. However, if the two commands were set in the opposite order, the more specific one would never be invoked.
This example represents another interesting use for administrative distances. You can use them as we have in this RIP example to ensure that you favor routes learned from particular routers over other less reliable devices. Note that this is only possible with distance vector protocols.
The EIGRP and OSPF configurations are similar, except that they include different options. The EIGRP example uses the distance eigrp command:
Router(config)#router eigrp 111
Router(config-route)#distance eigrp 55 200
This sets the administrative distance for routes learned by EIGRP to 55 if they are from the same EIGRP network, or 200 if they are external routes that have been redistributed into EIGRP.
OSPF also allows you to set a different administrative distance for external routes. And for internal routes, you can specify different administrative distances, depending on whether the route destination is internal or external to the area. This might be useful in certain cases in which you want to connect to another area through an external network rather than through the OSPF core. However, in most cases you do not need to treat intra-area and inter-area OSPF routes differently.
When setting distances for use with BGP, the syntax is distance bgp :
Router(config-route)#distance bgp 115 220 50
The external and internal distances are used for routes learned through eBGP and iBGP protocols, respectively. Local routes in this context are routes to destinations inside of this Autonomous System. Adjusting BGP administrative distances is relatively rare and frequently dangerous. The default value of 20 for eBGP and 200 for iBGP means that the router generally will prefer external BGP routes, but prefer any internal routing protocol to iBGP. This is almost always the required behavior. If you want to change the way the router handles BGP routes, we don't recommend using administrative distance.
Using SSH for Secure Access
SSH became available in Cisco's IOS, starting with release 12.1(1)T. However, only versions of IOS that support IPSec (DES or 3DES) encryption include SSH support.
Beginning with IOS Version 12.3(4)T, Cisco introduced support for SSH Version 2. The configuration is identical. However, only IOS versions that support 3DES encryption will support SSH Version 2. Also, the RSA key-pair size must be greater than or equal to 768.
Configuring SSH for secure encrypted remote access to your router
RTR1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
RTR1(config)#hostname Router1
RTR1(config)#ip domain-name oreilly.com
RTR1(config)#crypto key generate rsa
The name for the keys will be: Router1.oreilly.com
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes.
How many bits in the modulus [512]: 1024
Generating RSA keys ...
[OK]
RTR1(config)#ip ssh time-out 120
RTR1(config)#ip ssh authentication-retries 4
RTR1(config)#line vty 0 4
RTR1(config-line)#transport input ssh
RTR1#
Beginning with IOS Version 12.3(4)T, Cisco introduced support for SSH Version 2. The configuration is identical. However, only IOS versions that support 3DES encryption will support SSH Version 2. Also, the RSA key-pair size must be greater than or equal to 768.
Configuring SSH for secure encrypted remote access to your router
RTR1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
RTR1(config)#hostname Router1
RTR1(config)#ip domain-name oreilly.com
RTR1(config)#crypto key generate rsa
The name for the keys will be: Router1.oreilly.com
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes.
How many bits in the modulus [512]: 1024
Generating RSA keys ...
[OK]
RTR1(config)#ip ssh time-out 120
RTR1(config)#ip ssh authentication-retries 4
RTR1(config)#line vty 0 4
RTR1(config-line)#transport input ssh
RTR1#
Subscribe to:
Posts (Atom)