| 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#
Restricting VTY Access by Protocol
To restrict what protocols that you can use to access the routers VTY ports, use the transport input configuration command:
RTR1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
RTR1(config)#line vty 0 4
RTR1(config-line)#transport input telnet(for telnet )
RTR1(config-line)#transport input telnet ssh (for both telnet and ssh)
RTR1(config-line)#exit
RTR1(config)#end
RTR1#
Most administrators do not realize that, by default, Cisco routers will allow VTY access via other protocols besides Telnet. In some instances, intruders can bypass security measures that you have in place for Telnet and access your VTYs directly. To be safe, we recommend that you disable all unused protocols from accessing your VTYs. This will prevent anybody from gaining VTY access through one of these other protocols.
RTR1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
RTR1(config)#line vty 0 4
RTR1(config-line)#transport input telnet(for telnet )
RTR1(config-line)#transport input telnet ssh (for both telnet and ssh)
RTR1(config-line)#exit
RTR1(config)#end
RTR1#
Most administrators do not realize that, by default, Cisco routers will allow VTY access via other protocols besides Telnet. In some instances, intruders can bypass security measures that you have in place for Telnet and access your VTYs directly. To be safe, we recommend that you disable all unused protocols from accessing your VTYs. This will prevent anybody from gaining VTY access through one of these other protocols.
Quick Notes – OSPF
• The Neighbor IP used with OSPF distance command is the Neighbors Router-ID.
• “area range” summarize type 3 LSA’.
• “summary-address” summarize type 5 & 7 LSA’s.
• Auto-cost reference BW (Default = 100mb), formula = Ref-BW/Int-Bw.
• Switches do not support the interface command “ip ospf {pid} area {area-id}” .
• OSPF path selection: O > O*IA > O*E1 > O*E2.
• Using E1 metric type : Packets will be routed out the closest exit point of the network. (sum of path cost between router to next hop and next hop to destination)
• Using E2 metric type : If you want packets to exit your network at the closest point to their external destination. (path cost from next hop to destination)
• Don’t forget with hub and spoke topology, “ip ospf priority 0″.
• “no capability transit” – Mimics OSPFv1 behaviour for all data traffic to pass through Area-0.
• “max-metric” – Configures OSPF stub configurations
• “max-lsa” – Limit amount of non-local LSA’s
• “timers throttle lsa all” – Slow down update rate.
• “timers pacing lsa-group” – Group more LSA’s together in updates.
• “no ip ospf flood-reduction” – Disables every 30-min LSA DB refresh.
• “ip ospf database filter all out” – Breaks RFC, Stop sending LSA’s, but still receive LSA’s
• “area range” summarize type 3 LSA’.
• “summary-address” summarize type 5 & 7 LSA’s.
• Auto-cost reference BW (Default = 100mb), formula = Ref-BW/Int-Bw.
• Switches do not support the interface command “ip ospf {pid} area {area-id}” .
• OSPF path selection: O > O*IA > O*E1 > O*E2.
• Using E1 metric type : Packets will be routed out the closest exit point of the network. (sum of path cost between router to next hop and next hop to destination)
• Using E2 metric type : If you want packets to exit your network at the closest point to their external destination. (path cost from next hop to destination)
• Don’t forget with hub and spoke topology, “ip ospf priority 0″.
• “no capability transit” – Mimics OSPFv1 behaviour for all data traffic to pass through Area-0.
• “max-metric” – Configures OSPF stub configurations
• “max-lsa” – Limit amount of non-local LSA’s
• “timers throttle lsa all” – Slow down update rate.
• “timers pacing lsa-group” – Group more LSA’s together in updates.
• “no ip ospf flood-reduction” – Disables every 30-min LSA DB refresh.
• “ip ospf database filter all out” – Breaks RFC, Stop sending LSA’s, but still receive LSA’s
OSPF DR and BDR
A designated router (DR) is a router that has been elected to advertise all the router for a multi-access segment (like a LAN segment). Every time a change occurs in the network, the router that detected it will notify the DR, who will then relay the information to the other routers on that segment. The backup designated router (BDR) takes over that functionality if the DR fails.
OSPF Router ID Calculation
The router ID is discovered just as EIGRP does it. First, it looks for a route-id command. If one does not exist, the highest IP of on a up/up loopback interface is used. If one does not exist, the highest IP of the rest of the up/up interfaces is used
OSPF hello packet
For an OSPF Router Inorder to make a Neighborship with another OSPF Router the below fields in the Hello packet must match on both the side.
Subnet
Area
Hello and dead intervals
Authentication key(Optional)
Stub Area Flag(Optional)
Subnet
Area
Hello and dead intervals
Authentication key(Optional)
Stub Area Flag(Optional)
OSPF Hello and Dead Intervels
The hello intervals is how often a router sends hello messages. The dead interval is how long to wait before considering a neighbor dead from lack of hello messages; this is 4x the hello interval by default.
Broadcast: 10 sec 40 sec
Point to Point: 10 sec 40 sec
NBMA: 30 sec 120 sec
Point to Multipoint: 30 sec 120 sec
Administrator can change the hello intervals with below command.
R1(config-if)#ip ospf hello-interval X
Broadcast: 10 sec 40 sec
Point to Point: 10 sec 40 sec
NBMA: 30 sec 120 sec
Point to Multipoint: 30 sec 120 sec
Administrator can change the hello intervals with below command.
R1(config-if)#ip ospf hello-interval X
OSPF Database Filtering
The command "ip ospf database-filter all out" under interface works like passive interface does in distance vector protocols. When you say 'passive interface' in OSPF, you deny sending any hello packets out an interface, therefore an adjacency cannot be established. With 'ip ospf database-filter' on the other hand, you are only filtering the LSA generation. This means that you can still establish adjacencies (since hellos are still sent), but you won't send your neighboring router any LSA's. Therefore you will receive all the LSA's in their database, but they will not receive any of yours.
Neighbor ip-address database-filter all out-To filter outgoing link-state advertisements (LSAs) to an OSPF neighbor
Ip ospf database-filter all out-To filter outgoing link-state advertisements (LSAs) to an OSPF interface
Neighbor ip-address database-filter all out-To filter outgoing link-state advertisements (LSAs) to an OSPF neighbor
Ip ospf database-filter all out-To filter outgoing link-state advertisements (LSAs) to an OSPF interface
Friday, 20 August 2010
Administrative Distance and Metric
Administrative Distance is known as the Believability of the Routing Protocol.Administrative distance will select the best path when there is multiple path to the same destination from the different protocols. The lowest administrative distance route will placed in to the routing table .
Metric is a Calculation done by the Routing protocol to determine the best path through a network. Metrics are only helpful INSIDE a routing protocol's database (called a RIB - Routing Information Base). Each routing protocol has its own election process to figure out the best unique path. Metrics may be all or part of that decision process (depends on the protocol ). The winners get handed to the routing table.
An administrator can change the values ie, AD and MATRIC but it’s not recommended
Metric is a Calculation done by the Routing protocol to determine the best path through a network. Metrics are only helpful INSIDE a routing protocol's database (called a RIB - Routing Information Base). Each routing protocol has its own election process to figure out the best unique path. Metrics may be all or part of that decision process (depends on the protocol ). The winners get handed to the routing table.
An administrator can change the values ie, AD and MATRIC but it’s not recommended
EIGRP Hello and Dead Intervals.
EIGRP does not form a neighbor relationship with mismatched k values; however, a neighbor can be formed with mismatched hellos and dead timers.An Administrator Can Manipulate both Hello and Dead time Intervells
Router(config-if)ip hello-interval eigrp as_number interval_in_seconds— Use this interfacecommand to change the hello timer for EIGRP. The default value of this command is interface dependant.By default, hello packets are sent every 5 seconds. The exception to this is low-speed,nonbroadcast multiaccess media (NBMA), where it is 60 seconds. Low-speed is defined as rates of T1 (1.544 Mbps) or slower.
Router(config-if)ip hold-time eigrp as_number holdown_timer_in_seconds— Use this command to change the EIGRP hold timer for routes received by this interface. The timer has a default value of 180 seconds for low-speed NBMA networks and 15 seconds for all other networks.
Router(config-if)ip hello-interval eigrp as_number interval_in_seconds— Use this interfacecommand to change the hello timer for EIGRP. The default value of this command is interface dependant.By default, hello packets are sent every 5 seconds. The exception to this is low-speed,nonbroadcast multiaccess media (NBMA), where it is 60 seconds. Low-speed is defined as rates of T1 (1.544 Mbps) or slower.
Router(config-if)ip hold-time eigrp as_number holdown_timer_in_seconds— Use this command to change the EIGRP hold timer for routes received by this interface. The timer has a default value of 180 seconds for low-speed NBMA networks and 15 seconds for all other networks.
The "Big show" and "Big D" for EIGRP
Cisco offers some useful tools for determining how EIGRP is working. Perhaps one of the best and most overlooked commands is show ip eigrp neighbors. This can be one of the most useful commands when verifying the operational status of EIGRP. The show ip eigrp neighbors command shows the status of all EIGRP neighbors. The neighbor should be "up" for as long as EIGRP has been running on the link. EIGRP forms a neighbor relationship with all routers on the same subnet and in the same AS.
EIGRP does not form a neighbor relationship with mismatched k values; however, a neighbor can be formed with mismatched hellos and dead timers.A neighbor with a short uptime is a clear indication of a problem. Another important field is the queue count. This field indicates the number of packets waiting to be transmitted to that neighbor. This value should be 0 or a number under 20.
Consistent Q values in the range of 60 or greater are considered high. A high SRTT number can mean that the packet isexperiencing some type of delay on the link
RTR1 #show ip eigrp neighbors
IP-EIGRP neighbors for process 2001
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 172.16.1.5 Se0.1 136 05:48:23 36 1302 0 15
0 172.16.1.6 Se0.1 131 05:48:24 40 1302 0 17
RTR 1#
Handle (H)— A Cisco IOS internal number used to identify a neighbor. Do not confuse this with hop count.
Neighbor Address— The adjacent neighbor's IP address. A neighbor should be formed between every router on thatsubnet running EIGRP in a common AS.
Interface— The interface that is reporting the neighbor.
HoldTime— The amount of time, which counts down, that EIGRP waits for a hello before tearing down the neighbor.
Uptime— Statement of how long the neighbor has been up. This number should be up for as long as the link has been up.
Smooth Round Trip Timer (SRRT)— The number of milliseconds that it takes for an EIGRP packet to be sent to thisneighbor and for the local router to receive an acknowledgment—hence, a round-trip timer. If this number equals 0, apacket has never made a successful round trip.
Retransmission TimeOut (RTO)— The amount of time, in milliseconds, that the EIGRP waits before retransmitting apacket from the retransmission queue to a neighbor.
Queue count (Q)— The number of packets waiting in the queue to be sent out to this neighbor. This value should be 0 or a very low number. A high queue count indicates that data is having trouble getting through.
Sequence Number (Seq-Num)— Sequence number of the last update, query, or reply that was received from this neighbor. If this number equals 0, it indicates that no reliable packets have ever been received from the neighbor, another clear indication of a problem.
show ip eigrp topology Command
The table lists all routes that EIGRP is aware of and shows whether EIGRP is actively processing information on that route. Under most normal conditions, the routes should all be in a passive state and no EIGRP process are running for that route. If the routes are active, this could indicate the dreaded stuck in active, or SIA, state.
RTR1#show ip eigrp topology
IP-EIGRP Topology Table for process 2001
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status
P 172.16.5.0/24, 1 successors, FD is 23394560
via 172.16.1.5 (23394560/281600), Serial0.1
P 172.16.6.0/24, 1 successors, FD is 23394560
via 172.16.1.6 (23394560/281600), Serial0.1
P 172.16.1.0/24, 1 successors, FD is 23368960
via Connected, Serial0.1
P 172.16.2.0/24, 1 successors, FD is 281600
via Connected, Ethernet1
RTR1#
RTR1#show ip eigrp topology 2001 172.16.5.0 255.255.255.0
IP-EIGRP topology entry for 172.16.5.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 23394560
Routing Descriptor Blocks:
172.16.1.5 (Serial0.1), from 172.16.1.5, Send flag is 0x0
Composite metric is (23394560/281600), Route is Internal
Vector metric:
Minimum bandwidth is 112 Kbit
Total delay is 21000 microseconds
Reliability is 254/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
RTR1#
The fields to note in this output are as follows:
P— Passive; no EIGRP computation is being performed. This is the ideal state.
A— Active; EIGRP computations are "actively" being performed for this destination. Routes constantly appearing in anactive state indicate a neighbor or query problem. Both are symptoms of the SIA problem.
U— Update; an update packet was sent to this destination.
Q— Query; a query packet was sent to this destination.
R— Reply; a reply packet was sent to this destination.
Route information— IP address of the route or network, its subnet mask, and the successor, or next hop to that network, or the feasible successor.
FD— Feasible distance to the destination network.
show ip protocols Command
This command displays all routing protocols, detailed timer and metric information, as well as routing update information.
RTR1#show ip protocols
Routing Protocol is "eigrp 2001" AS system ID
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0 'K' values
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 2001
Automatic network summarization is in effect Auto-summary in effect
Routing for Networks:
172.16.0.0 Networks running EIGRP
Routing Information Sources:
Gateway Distance Last Update
172.16.1.5 90 00:08:48 Routes reported, and administrative
172.16.1.6 90 00:08:52 distance of the route.
Distance: internal 90 external 170 Default admin distance
RTR1#
show ip route Command
This command lists the router's current route or forwarding table. The output lists what routing protocol the route is from—in this case, D for EIGRP internal routes and D EX for routes redistributed into EIGRP. The number behind the route is the administrative distance of the route, followed by the composite metric of the route. The via field explains where the route isfrom, how long ago an update was received, and by what interface it was received.
RTR1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 4 subnets
D 172.16.5.0 [90/23394560] via 172.16.1.5, 00:17:51, Serial0.1
D 172.16.6.0 [90/23394560] via 172.16.1.6, 00:29:06, Serial0.1
C 172.16.1.0 is directly connected, Serial0.1
C 172.16.2.0 is directly connected, Ethernet1
RTR1#
EIGRP does not form a neighbor relationship with mismatched k values; however, a neighbor can be formed with mismatched hellos and dead timers.A neighbor with a short uptime is a clear indication of a problem. Another important field is the queue count. This field indicates the number of packets waiting to be transmitted to that neighbor. This value should be 0 or a number under 20.
Consistent Q values in the range of 60 or greater are considered high. A high SRTT number can mean that the packet isexperiencing some type of delay on the link
RTR1 #show ip eigrp neighbors
IP-EIGRP neighbors for process 2001
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 172.16.1.5 Se0.1 136 05:48:23 36 1302 0 15
0 172.16.1.6 Se0.1 131 05:48:24 40 1302 0 17
RTR 1#
Handle (H)— A Cisco IOS internal number used to identify a neighbor. Do not confuse this with hop count.
Neighbor Address— The adjacent neighbor's IP address. A neighbor should be formed between every router on thatsubnet running EIGRP in a common AS.
Interface— The interface that is reporting the neighbor.
HoldTime— The amount of time, which counts down, that EIGRP waits for a hello before tearing down the neighbor.
Uptime— Statement of how long the neighbor has been up. This number should be up for as long as the link has been up.
Smooth Round Trip Timer (SRRT)— The number of milliseconds that it takes for an EIGRP packet to be sent to thisneighbor and for the local router to receive an acknowledgment—hence, a round-trip timer. If this number equals 0, apacket has never made a successful round trip.
Retransmission TimeOut (RTO)— The amount of time, in milliseconds, that the EIGRP waits before retransmitting apacket from the retransmission queue to a neighbor.
Queue count (Q)— The number of packets waiting in the queue to be sent out to this neighbor. This value should be 0 or a very low number. A high queue count indicates that data is having trouble getting through.
Sequence Number (Seq-Num)— Sequence number of the last update, query, or reply that was received from this neighbor. If this number equals 0, it indicates that no reliable packets have ever been received from the neighbor, another clear indication of a problem.
show ip eigrp topology Command
The table lists all routes that EIGRP is aware of and shows whether EIGRP is actively processing information on that route. Under most normal conditions, the routes should all be in a passive state and no EIGRP process are running for that route. If the routes are active, this could indicate the dreaded stuck in active, or SIA, state.
RTR1#show ip eigrp topology
IP-EIGRP Topology Table for process 2001
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - Reply status
P 172.16.5.0/24, 1 successors, FD is 23394560
via 172.16.1.5 (23394560/281600), Serial0.1
P 172.16.6.0/24, 1 successors, FD is 23394560
via 172.16.1.6 (23394560/281600), Serial0.1
P 172.16.1.0/24, 1 successors, FD is 23368960
via Connected, Serial0.1
P 172.16.2.0/24, 1 successors, FD is 281600
via Connected, Ethernet1
RTR1#
RTR1#show ip eigrp topology 2001 172.16.5.0 255.255.255.0
IP-EIGRP topology entry for 172.16.5.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 23394560
Routing Descriptor Blocks:
172.16.1.5 (Serial0.1), from 172.16.1.5, Send flag is 0x0
Composite metric is (23394560/281600), Route is Internal
Vector metric:
Minimum bandwidth is 112 Kbit
Total delay is 21000 microseconds
Reliability is 254/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
RTR1#
The fields to note in this output are as follows:
P— Passive; no EIGRP computation is being performed. This is the ideal state.
A— Active; EIGRP computations are "actively" being performed for this destination. Routes constantly appearing in anactive state indicate a neighbor or query problem. Both are symptoms of the SIA problem.
U— Update; an update packet was sent to this destination.
Q— Query; a query packet was sent to this destination.
R— Reply; a reply packet was sent to this destination.
Route information— IP address of the route or network, its subnet mask, and the successor, or next hop to that network, or the feasible successor.
FD— Feasible distance to the destination network.
show ip protocols Command
This command displays all routing protocols, detailed timer and metric information, as well as routing update information.
RTR1#show ip protocols
Routing Protocol is "eigrp 2001" AS system ID
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0 'K' values
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 2001
Automatic network summarization is in effect Auto-summary in effect
Routing for Networks:
172.16.0.0 Networks running EIGRP
Routing Information Sources:
Gateway Distance Last Update
172.16.1.5 90 00:08:48 Routes reported, and administrative
172.16.1.6 90 00:08:52 distance of the route.
Distance: internal 90 external 170 Default admin distance
RTR1#
show ip route Command
This command lists the router's current route or forwarding table. The output lists what routing protocol the route is from—in this case, D for EIGRP internal routes and D EX for routes redistributed into EIGRP. The number behind the route is the administrative distance of the route, followed by the composite metric of the route. The via field explains where the route isfrom, how long ago an update was received, and by what interface it was received.
RTR1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 4 subnets
D 172.16.5.0 [90/23394560] via 172.16.1.5, 00:17:51, Serial0.1
D 172.16.6.0 [90/23394560] via 172.16.1.6, 00:29:06, Serial0.1
C 172.16.1.0 is directly connected, Serial0.1
C 172.16.2.0 is directly connected, Ethernet1
RTR1#
EIGRP Successor and Feasible Successor
An Eigrp Successor is a neighboring router that has a least-cost path to a destination (lowest FD) that is guaranteed not to be part of a routing loop. Successors are offered to the routing table to be used for forwarding packets
Feasible Successor is the Next-Hop router for the backup path. To qualify as a feasible successor, a Next-Hop router must have an AD (Administrative Distance) less than the FD of the Current Successor Route. Feasible Successors are kept in Topology Table. Topology Table can maintain multiple FS for a Destination.
“Feasible Distance (FD )is the accumulated cost between the local router to the Next-Hop Router and the Next-Hop Router to the Destination. The Cost between the Next-Hop Router and the Destination is known as Advertised Distance, and the Sum of Advertised Distance and the Cost between Local Router and Next-Hop Router is known as Feasible Distance.”
Feasible Successor is the Next-Hop router for the backup path. To qualify as a feasible successor, a Next-Hop router must have an AD (Administrative Distance) less than the FD of the Current Successor Route. Feasible Successors are kept in Topology Table. Topology Table can maintain multiple FS for a Destination.
“Feasible Distance (FD )is the accumulated cost between the local router to the Next-Hop Router and the Next-Hop Router to the Destination. The Cost between the Next-Hop Router and the Destination is known as Advertised Distance, and the Sum of Advertised Distance and the Cost between Local Router and Next-Hop Router is known as Feasible Distance.”
EIGRP Load Balancing.
One of the main features of Eigrp is, it support both Equal and Unequal Load Balancing, none of the other Routing Protocol have this feature.Load balancing is a Routers Capability to distribute the traffic of over multiple paths to a same destination.
By Default Eigrp Support four Equal Cost paths for IP. A Network Administrator can extend this UP to Sixteen Paths by using Maximum-Paths (No of Max.Path) IOS command.
[“When a packet is process –switched ,load balancing over equal-cost paths occurs on a per-packet basis, where as when a packet is fast-switched ,load balancing over equal-cost path occurs on a per-destination basis.”]
Eigrp can also balance traffic across multiple paths that have different metric; this is called unequal load balancing. EIGRP Perform Unequal load balancing by using Variance multiplier command.The Multiplier is a variance Value between 1 and 128, using for load- balancing. The Default is 1 which means equal load-balancing. Only paths that are FEASIBLE can be used for load balancing.
Two feasibility Conditions are:
A, The local Best metric (Current FD) must be greater than the best metric (AD) learned from the next router.
B, The Variance multiplied by the local Best Metric (Current FD) must be greater than the metric through the next router (alternative FD).
For Example, Router A has 4 paths to network F .
@ Path 1: FD-30 (via B)
@ Path 2: FD-20 (via C)
@ Path 3: FD-45 (via D)
@ Path 4: FD-55(via E)
Router A Choose Router C as the Successor ,because its FD is lowest (20).With Variance 2 command applied on Router A ,the Path through the Router B will meet the Criteria for Load balancing ,as the FD through the Router B will be less than the FD for the Current Successor(C)
By Default Eigrp Support four Equal Cost paths for IP. A Network Administrator can extend this UP to Sixteen Paths by using Maximum-Paths (No of Max.Path) IOS command.
[“When a packet is process –switched ,load balancing over equal-cost paths occurs on a per-packet basis, where as when a packet is fast-switched ,load balancing over equal-cost path occurs on a per-destination basis.”]
Eigrp can also balance traffic across multiple paths that have different metric; this is called unequal load balancing. EIGRP Perform Unequal load balancing by using Variance multiplier command.The Multiplier is a variance Value between 1 and 128, using for load- balancing. The Default is 1 which means equal load-balancing. Only paths that are FEASIBLE can be used for load balancing.
Two feasibility Conditions are:
A, The local Best metric (Current FD) must be greater than the best metric (AD) learned from the next router.
B, The Variance multiplied by the local Best Metric (Current FD) must be greater than the metric through the next router (alternative FD).
For Example, Router A has 4 paths to network F .
@ Path 1: FD-30 (via B)
@ Path 2: FD-20 (via C)
@ Path 3: FD-45 (via D)
@ Path 4: FD-55(via E)
Router A Choose Router C as the Successor ,because its FD is lowest (20).With Variance 2 command applied on Router A ,the Path through the Router B will meet the Criteria for Load balancing ,as the FD through the Router B will be less than the FD for the Current Successor(C)
Thursday, 19 August 2010
Limiting EIGRP Quiery Range.
There are three methods to limiting Eigrp Queries.
1, Design the network with a redundant wan links from remote site to NAP or distribution site. Run Default or Static routes between Remote Sites and Distribution or NAP sites. Run Eigrp between NAP /Distribution Sites and Central Sites or Data Centers. By configuring this we can limit the queries to Distribution sites.
2, Configure Eigrp Summary Routes with ip summary—address eigrp command on interfaces.
For Example, on a typical connectivity of A, B, C Router B send a Summary route of 172.50.0.0/16 to Router A. When Network 172.50.3.0/24 goes down .Router A receives a query from Router B about that Network. Because router A has only a Summary Route, that specified network is not in the routing table. Router A replies to the query with a “network 172.50.30.0/24 unreachable” message, hence the query will stop here.
“A Remote Router extends the query about the network only if it has an exact match in the routing table”
3, Configure remote routers as Eigrp Stub.
Eigrp Stub routers not queried. Instead, hub routers connected to the stub routers answer the query on behalf of the stub router. Eigrp hub routers will not use Stub Routers as a Transit path. Remote Router configured as Stub does not advertise the hub routes back to the hub routers.
1, Design the network with a redundant wan links from remote site to NAP or distribution site. Run Default or Static routes between Remote Sites and Distribution or NAP sites. Run Eigrp between NAP /Distribution Sites and Central Sites or Data Centers. By configuring this we can limit the queries to Distribution sites.
2, Configure Eigrp Summary Routes with ip summary—address eigrp command on interfaces.
For Example, on a typical connectivity of A, B, C Router B send a Summary route of 172.50.0.0/16 to Router A. When Network 172.50.3.0/24 goes down .Router A receives a query from Router B about that Network. Because router A has only a Summary Route, that specified network is not in the routing table. Router A replies to the query with a “network 172.50.30.0/24 unreachable” message, hence the query will stop here.
“A Remote Router extends the query about the network only if it has an exact match in the routing table”
3, Configure remote routers as Eigrp Stub.
Eigrp Stub routers not queried. Instead, hub routers connected to the stub routers answer the query on behalf of the stub router. Eigrp hub routers will not use Stub Routers as a Transit path. Remote Router configured as Stub does not advertise the hub routes back to the hub routers.
Preventing EIGRP SIA Connections.
For preventing SIA (Stuck-in Active) connections in EIGRP, Cisco has introduced a new IOS feature (12.1(5) or later) that will generate 2 packet types SIA-Query and SIA-Reply automatically with no configuration required.
For Example: Router A, B and C are connected each other. Router A Send a Query to Router B for Network 172.10.30.0/24.Router B has no Entry for this Network, so it queries to Router C.But there is a problem in the link between Router B and C, because of this packet might lost or Delayed. Router A has no visibility of downstream progress and assumes it has problem with Router B.in this case after the default period of 3 minutes Router A will reset the neighbour relation with Router B.
But with the Active Enhancement feature of SIA-Query and Reply ,Router A queries down stream Router B (with SIA-Query) at the midway point of the active default timer(one and half minutes) about the status of the route. Router B responds (with SIA-Reply) that it is searching for a replacement route. After receiving this SIA-Reply packet, Router A validates the status of Router B and does not terminate the neighbour relationship.
For Example: Router A, B and C are connected each other. Router A Send a Query to Router B for Network 172.10.30.0/24.Router B has no Entry for this Network, so it queries to Router C.But there is a problem in the link between Router B and C, because of this packet might lost or Delayed. Router A has no visibility of downstream progress and assumes it has problem with Router B.in this case after the default period of 3 minutes Router A will reset the neighbour relation with Router B.
But with the Active Enhancement feature of SIA-Query and Reply ,Router A queries down stream Router B (with SIA-Query) at the midway point of the active default timer(one and half minutes) about the status of the route. Router B responds (with SIA-Reply) that it is searching for a replacement route. After receiving this SIA-Reply packet, Router A validates the status of Router B and does not terminate the neighbour relationship.
Reasons for EIGRP Stuck –in-Active
EIGRP Stuck in Active State is when a router does not receive a reply to all its outstanding queries (i.e. query for alternative route to a destination, after the successor goes down and no feasible successor exist) within 3 minutes (default time) ,the route goes to Stuck-in-Active(SIA) mode.
Most Common reasons for SIA routes are:
A, The router is too busy to answer query-generally because of high cpu or memory utilization.
B, The link between two routers is not good, so some packets are lost between the router.
C, Unidirectional link problem (UDLD).A failure causes traffic on a link to flow in only one direction.
Most Common reasons for SIA routes are:
A, The router is too busy to answer query-generally because of high cpu or memory utilization.
B, The link between two routers is not good, so some packets are lost between the router.
C, Unidirectional link problem (UDLD).A failure causes traffic on a link to flow in only one direction.
EIGRP Summarization and null routes.
When EIGRP summarization configured on a routers interface ,a summary route is added to that routers routing table, with the next-hop interface is set to null 0.Use of null 0 interface prevents the router from trying to forward traffic to other routers in search of more precise ,longer match route ,thus preventing traffic from looping within the network.
RTP and EIGRP
EIGRP is using RTP as a Transport protocaols .Reliable Transport Protocol (RTP) is responsible for guaranteed, ordered delivery of eigrp packets to all neighborss.RTP support an intermixed transmission of multicast or unicast packets.
For Example, on Ethernet network it is not necessary to send hello packets reliably to all neighbours.So eigrp send single multicast hello packet with a flag that informs the receivers that the packet need not be acknowledged. But on other packet types such as query, update and reply indicate in the packet that acknowledgement in required. With both these features RTP ensures that convergence time remains low in the presence of varying speed links.
For Example, on Ethernet network it is not necessary to send hello packets reliably to all neighbours.So eigrp send single multicast hello packet with a flag that informs the receivers that the packet need not be acknowledged. But on other packet types such as query, update and reply indicate in the packet that acknowledgement in required. With both these features RTP ensures that convergence time remains low in the presence of varying speed links.
Routing Protocols and Protocol Numbers
Routing protocols working on differenet layers.IGRP .EIGRP and OSPF are transport layer Protocaols that run directly over IP.where as RIP and BGP are Applicationn Layer Protocols.BGP using TCP as transport Protocols.
Protocol Protocol number
====== ===========
IGRP 9
EIGRP 88
OSPF 99
RIP UDP 520
BGP TCP 179
Eigrp as Hybrid
As a Hybrid protocol Eigrp has featres of both Distance Vector and Link state protocol.Eigrp has the link state feature of Sending Partial Triggered Updates(Changes Updates) ,only to the directly connected neighboring devices(a Distance Vector Feature)
BGP Weight Attribute
The BGP Weight attribute is a Cisco Proprietary attribute that influences a router how to reach a certain prefix. The difference between Local Preference and Weight is that the former is propagated within an AS and the latter is router locally significant. Weight can be used if there is one router connected to two or more AS's or just to just one with two or more eBGP peers. Now, lets configure weight and later use a route-map for more complex use of weight
"Weight is a Cisco Proprietary attribute for BGP that is "locally significant."Local Preference is a Well-known Discretionary attribute, Weight doesn't belong to any category.Default Weight for locally originated routes is 32768.Zero is the default for other routes.Weight is not propagated to other routers within the AS."
"Weight is a Cisco Proprietary attribute for BGP that is "locally significant."Local Preference is a Well-known Discretionary attribute, Weight doesn't belong to any category.Default Weight for locally originated routes is 32768.Zero is the default for other routes.Weight is not propagated to other routers within the AS."
Subscribe to:
Posts (Atom)