What is the difference between these two.

redistribute connected metric 10000 100 255 1 1500 route-map CONNECTED->EIGRP

redistribute connected route-map CONNECTED->EIGRP metric 10000 100 255 1 1500

========================================================

Nothing, both will do the samething,=.

EIGRP Queries and Stuck-In-Active

• With EIGRP, if a router loses a route and it does not have an FS in the topology table, it sends out queries to neighboring routers to recompute a new route. This process puts the route in what is termed active state.
  • A route is considered passive when a router is not recomputing a new route.
• To recompute a new route, the router sends out queries to all neighbors on interfaces other than the one used to reach the previous successor (a function of split horizon). The query inquires the other routers whether they have a route to a given destination.
  • If the receiving router has an alternative route, it replies back to the sending router letting it know about the alternative route and the query ends there.
  • If the receiving neighbor does not have a route, it queries all of its own neighbors asking for an alternative route.
  • The queries propagate through the network creating an expanding tree of queries.
  • When a router responds to the query, it stops propagating on that portion of the network. However, the query can still propagate in other portions of the network as the other routers attempt to find alternative paths.
• When a route goes active, a reply must be received for every generated queries, otherwise it stay active the whole time.
• Stuck-in-Active
  • If the router does not receive a reply to all outstanding queries within 3 minutes (default setting), the route goes on stuck-in-active (SIA) state.
  • To change the limit limit before an outstanding query is stuck in active state use the router configuration command:
    • timers active-time [time-limit | disabled], where time-limit is in minutes.
  • When a route goes on SIA state, the neighbor relationship between the router and the neighbors that failed to reply resets. This action causes a recomputation of all routes known from that neighbor and to re-advertise all the routes it knows about to that neighbor.
  • Common causes of SIAs
    • Router has high CPU usage or memory problems that results in the router being too busy to respond or unable to allocate enough memory to process the query or build the reply packet.
    • Bad link between the router routers, which allows the two routers just enough to keep the route connected and receiving packets, but not enough that some packets or lost therefore some queries and replies are lost.
    • Unidirectional link, which results with traffic only flowing in one direction.
  • Many networks have implemented an erroneous approach of using multiple EIGRP autonomous systems in hopes of decreasing the chances of stuck-in-active route. This approach is somewhat simulating the effect of using OSPF areas.
    • There is an unintended result for doing this: If a query reaches the edge of the autonomous system, the original query is answered. However, the edge router then initiates a new query in the other autonomous system where the route can potentially go in stuck-in-active state.
    • Another misconception about autonomous system boundaries is that implementing multiple autonomous systems protects one AS from route flaps in another AS. However, if routes are redistributed between AS, route transitions form one AS are detected in another.

Preventing SIA Connections

• Cisco IOS Software Release 12.1(5) introduced a new feature called Active Process Enhancement.
  • This feature enables an EIGRP router to monitor the progression of the search for a successor route and ensure that the neighbor is still reachable by using two new addition to the EIGRP packet header:
    • SIA – Query
    • SIA – Reply
  • The result is improved network reliability by reducing unintended termination of neighbor adjacency.

The following diagram illustrates how the process works before and after the addition of the Active Process Enhancement:

Before

• Router A sends a query for network 10.1.1.0/24 to Router B
• Router B has no entry for this network, so it queries Router C
• If problem exists beween router B and C, the reply packet from Router C to Router B might be delayed or lost.
• Router A has no visibility of downstream progress and assumes that no response indicates problems with Router B
• After Router A’s 3-minute active timer expires, the neighbor relationship with Router B is reset, along with all known routes from Router B.

After

• With the Active Process Enhancement feature, Router A queries downstream Router B (with an SIA-Query) at the midway point of the active timer (one and a half minutes by default) about the status of the route.
• Router B responds (with an SIA-Reply) that it is searching for a replacement route.
• Upon receiving this SIA-Reply response packet, Router A validates the status of Router B and does not terminate the neighbor relationship.
• Meanwhile, Router B will send up to three SIA-Queries to Router C. If they go unanswered, Router B will terminate the neighbor relationship with Router C.
• Router B will then update Router A with an SIA-Reply indicating that the network 10.1.1.0/24 is unreachable.
• Routers A and B will remove the active route from their topology tables.
• The neighbor relationship between Routers A and B remains intact.

EIGRP Query Range

• Query Scoping - limiting the scope of query propagation through the network (the query range) – helps reduce incidences of SIA.
• Keeping the query packets close to the source reduces the chance that an isolated failure in another part of the network will restrict the convergence (query/reply) process.
• Note that remote routers seldom needs to know advertised routes across and entire network. Consider using default routes.

Consider the following example:

• In the figure above Router B notices the loss of network 10.1.8.0 and sends a query to Routers A, C, D, E.
• These routers, in turn, send queries to their neighbors, requesting an FS for 10.1.8.0.
• The redundant topology causes each path to receive duplicate queries as the process starts.
• As a result, not only do the remote routers have to respond to queries form the regional offices, but they also continue the search by reflecting the queries back toward the other regional office router, which makes the convergence process even more complicated.

Examining the Query Process

• Refer to the above figure. Assume that the EIGRP metric for the Ethernet link is 1000 and the serial link is 100,000
• Router B advertises 10.1.8.1/24 to all other routers
• Router A’s best route to get to the 10.1.8.0/24 network is through the Ethernet link to Router B.
• Remote routers C, D, and E prefer the serial link through B as the best path to 10.1.8.0/24.
• Here’s how the Toplogy table for 10.1.8.1/24 for Routers C, D, E would look like.

• Router A’s topology table for 10.1.8.0/24:

• With the information above, Routers C, D, and E determine that router B is the successor and Router A is the FS to reach network 10.1.8.0/24 – because it meets the feasibility conditon that the AD through router A (which is 2000) be less than the FD through Router B (101,000).
• Note also that router A does not have an FS because none of other routes meet that feasiblity condition (i.e. all the other routes have ADs higher (101,000) than the FD of the current successor (B = 2000).

Assume that Router B loses the path to network 10.1.8.0/24:

• Router B, then sends queries out to all its four neighbors.
• When the remote sites receive this query, they automatically install the path through their FS, which is Router A, in their routing table and sends a response to Router B with their supposedly good path through Router A. They also remove the path through Router B from their topology tables.
• Router B receives the responses from the remote routers and waits for a response from Router A.
• Because Router A only has one successor and no FS, it takes a little bit longer because it knows from its topology table that Routers C, D, and E each has a path to the lost network so it builds and sends it’s own query to Routers C, D, and E.
• At this point Router B is still waiting for a response from Router A.
• When the remote routers receive the query from Router A, they now learn that their path through A is not good. So they check their topology tables for alternative routes. This time there is none. Router B has already informed them that its path to 10.1.8.0/24 is gone.
• Because the remote routers don’t have anything to give to Router A as a response, they build a query and send it to all their neighbors; it is not sent to Router A because the message came from A (split horizon) which leaves B as the only choice to send the query to.
• Remember Router B is still waiting for a response from Router A.
  • Router B receives the query from the remote routers but it cannot respond to them because it still has not received a response from A.
  • Router A on the other hand is waiting for a response from either C, D, or E.
  • Routers C, D, and E are waiting for Router B to respond to their queries.
• Router B then goes to SIA state first because it is the router that sent the first query and whose SIA timer expired first.
• Router B then resets its neighbor relationship with A.
• As soon as the neighbor relationship goes down, Router B can immediately respond to Router C, D, and E, saying that router B does not have a path to 10.1.8.0/24.
• Routers C, D, and E can then respond to Router A that they do not have a path.

• After Router B and Router A resets their neighbor relationship, adjacency is restored. Router B does not pass the 10.1.8.0/24 network to Router A because it no longer exist.
• Router A learns that the remote side do not have a path to 10.1.8.0/24 so it removes the 10.1.8.0 network form its topology table.

Limiting the EIGRP Query Range

• Trying to determine the amount of information necessary to properly route traffic to the correct destination requires some business decision to weigh what is appropriate. Oftentimes the network manager must analyze the amount of information passed through the remote routers and the capacity and bandwidth that it can handle.
• A properly designed network would have each remote site with redundant WAN links to separate distribution sites. If both distribution sites pass a default route to the remote sites, the remote sites load balance to all networks behind the distribution site routers. This means maximum bandwidth utilization and less CPU and memory usage, which also means smaller and less expensive router required.
• It is optimal for all remote site to see all available routes so it can select the best path. However it must be taken into consideration the amount of bandwidth a larger internetwork would require in order to achieve this.

Two options for making EIGRP more scalable are:

1. Use of Route Summarization
2. Configuring Stub Routers

Limiting Query Range with Summarization

• Summarization minimizes the size of routing tables which means less CPU and memory usage and less bandwidth to transmit.
• Summarization reduces the chance of networks becoming stuck-in-active, because it reduces the number of routers the see each query. Therefore the chances of a query encountering issues is reduced.
• NOTE: A router extends the query about a network only if it has an exact match in the routing table.

Consider the following figure for example:

• Router B sends a summary route of 172.30.0.0/16 to Router A.
• When network 172.30.1.0/24 goes down, Router B sends a query to Router A asking for an alternative path to 172.30.1.0/24.
• Becuase Router A only received a summarized route 172.30.0.0/16, the network 172.30.1.0/24 is nowhere to be found on Router A’s routing table. Router A replies with a “network 172.30.1.0/24 unreachabel” message.
• The message does not extend the query any further.

Another Example, recall back to the earlier figure:

• Going back to a familiar scenario, the figure above has the ip summary-address eigrp command configured on the outbound interfaces of Routers A and B so that Routers A and B advertises the 10.0.0.0/8 summary to remote Routers C, D, and E.
• The 10.1.8.0/24 network is not advertised to the remote routers.
• When the network 10.1.8.0/24 goes down and Routers A and B sends queries to Routers C, D, and E, the routers immediately reply to Routers A and B that the destination is unreachable because that specific route is not in any of the Remote sites’ routing tables. The remote routers therefore don’t extend the queries back to Routers A and B which prevents Routers A and B from becoming SIA waiting for the query process to receive all the replies.

Limiting Query Range Using a Stub

• Hub-and-spoke network topologies commonly use stub routing.
• In a hub-and-spoke topology the remote router forwards all traffic that is not local to a hub router; the remote router does not need to keep a complete routing table. Generally, hub routers need to send only a default route to the remote routers.
• There is no advantage for a hub-and-spoke topology to have full routing table on the remote routers because everything goes through the hub router anyway. Besides, a full routing table on the spoke routers only increases the amount of memory required.
• Route summarization and route filtering can also be used to conserve bandwidth and memory requirements on the spoke routers.
• Traffic from a hub router should not use a remote router as a transit path.
• In order to prevent this, EIGRP stub routing can restrict the remote router from advertising the hub router’s routes back to other hub routers.
  • For example, going back to the figure above, if a remote router receives routes from hub Router A, the remote routers don’t advertise it back to Router B.
  • And because the remote router does not advertise the hub routes back to other hub routers, the hub routers do not use the remote routers as a transit path.
• EIGRP Stub
  • Only remote routers are configured as stubs. The stub feature does not prevent routes from being advertised to the remote router.
  • Stub routers are not queried. Instead, hub routers connect to the stub router answer the query on behalf of the stub router.
  • A hello packet carries the information about a router being a stub router.
    • Any neighbor that receives a packet informing it of the stub status does not query the stub router for any routes. Therefore, a router that has a stub peer does not query the peer.
  • When stub routing is enabled in dual-homed remote configurations, you do not have to configure filtering on remote routers to prevent them from appearing as transit paths to the hub routers.
  • EIGRP stub routing should be used on stub routers only. A stub router is defined as a router connected to the network core or hub layer, and through which core transit traffic should not flow.
  • A stud router should have only hub routers for EIGRP neighbors.
• Configuring an EIGRP stub
  • use the router configuration command:

eigrp stub [receive-only | connected | static | summary]

eigrp stub Command Parameters:

• Any combinations can be used with the exception of receive-only keyword.
• If any of the keywords (except receive-only) is used individually, the connected and summary routes are not sent automatically.

The following example configuration configures a stub that advertises connected and summary routes:

Router(config)#router eigrp 1
Router(config-router)#network 10.0.0.0
Router(config-router)#eigrp stub

The following configuration does not send connected, summary, or static routes:

Router(config)#router eigrp 1
Router(config-router)#network 10.0.0.0 eigrp
Router(config-router)#eigrp stub receive-only

• The EIGRP stub feature does not automatically enable route summarization on the hub router. If desired, the network administrator can configure route summarization.
• If a true stub network is required, the hub router can be configured to send a default route to the spoke routers. This approach is the most simple and conserves the most bandwidth and memory on the spoke routers.
• NOTE: Although EIGRP is a classless routing protocol, it behaves like a classful protocol, such as having automatic summarization on by default. When configuring the hub router to send a default route to the remote router, configure the ip classless command. By default, the ip classless command is enabled in all Cisco IOS images that support EIGRP stub routing.

• Without the stub feature, if a route is lost EIGRP sends a query to the spoke routers. The EIGRP stub route feature allows a network professional to prevent sending queries to the spoke router under any conditions.

The following is an example of how a stub feature would work on a network:

• In the above figure, Routers C, D, and E are configured as stub routers, therefor queries for 10.1.8.0/24 network are not sent to these routers.
• In addition, hub sites are able to immediately answer queries without propagating queries to the remote sites, saving CPU and bandwidth. Convergence time is also improved even when the remote sites are dual-homes to the two hub sites.

The figure below shows another example with the configurations following that:

RouterB#show running-config
<output omitted>
ip route 10.1.4.0 255.255.255.0 10.1.3.10
!
interface ethernet 0
ip address 10.1.2.1 255.255.255.0
!
interface serial 0
ip address 10.2.2.3 255.255.255.254
ip summary-address eigrp 100 10.1.2.0 255.255.254.0
!
interface serial 1
ip address 10.1.3.1 255.255.255.0
!
router eigrp 100
redistribute static 1000 1 255 1 1500
network 10.2.2.2 0.0.0.1
network 10.1.2.0 0.0.0.255
<output omitted>

Using the above figure and configuration, the network behaves differently with various eigrp stub configurations as follows:

• eigrp stub connected
  • Router B will advertise only 10.1.2.0/24 to Router A. Even though 10.1.3.0/24 is a connected network as well, it is not advertised to Router A because it is not configured in a network command, and connected routes are not redistributed
• eigrp stub summary
  • Router B will advertise only 10.1.2.0/23 (the summary route configured on the router) to Router A.
• eigrp sub static
  • Router B advertises only 10.1.4.0/24 (the configured static route on the router) to Router A.
• eigrp stub receive-only
  • Router B does not advertise anything to Router A.

Graceful Shutdown

• A graceful shutdown is a feature that would allow an EIGRP routing process that is about to shut down to broadcast a goodbye message to inform adjacent peers about the topology change that is about to occur.
  • This feature allows other EIGRP peers to synchornize and recalculate neighbor relationships more efficiently than would occur if the peers had to rely on the hold timer expiring.
  • Without it, a neigbor wouldn’t normally warn a peer that it was about to go down. The other router would have to wait for the hold timer to expire and packets could be lost in the process.
• Goodbye Messages
  • The goodbye message is supported in Cisco IOS Software Release 12.3(2), 12.3(3)B, and 12.3(2)T and later.
  • They are sent in Hello packets
  • EIGRP sends and interface goodbye messages with all K values set to 255 when taking down all peers on an interface.
• If a router IOS does not support goodbye messages, it will misinterpret the message as K-value mismatch and display the following:

*Apr 26 13:48:41.811: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down: K-value mismatch

• For supported software releases, the following message is displayed by routers when goodbye messages are received:

*Apr 26 13:48:42.523: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down: Interface Goodbye received

Note: Goodbye messages recieved by a nonsupporting router does not disrupt the network operation. It will use the hold timer to determine a down peer.

• An EIGRP router will send a goodbye message on an interface if:
  • The EIGRP network command is removed.
  • The EIGRP process is shut down (using no router eigrp).
• But it wont send goodbye messages if:
  • An interface is shut down
  • Or the router is reloaded

  reference: http://routemyworld.com/2008/07/23/bsci-eigrp-queries-stuck-in-active-route-summarization-and-stub-routers/

Switch:

05:04:04: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.1.105.5 (FastEthernet0/18) is up: new adjacency
–More–
05:05:23: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.1.105.5 (FastEthernet0/18) is down: K-value mismatch
–More–
05:05:26: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.1.105.5 (FastEthernet0/18) is up: new adjacency

router eigrp 100
network 183.1.105.10 0.0.0.0
network 183.1.107.10 0.0.0.0
no auto-summary
eigrp router-id 150.1.10.10

interface FastEthernet0/18
no switchport
ip address 183.1.105.10 255.255.255.0

Routing Protocol is “eigrp 100″
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
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
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 100
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
183.1.105.10/32
183.1.107.10/32
Routing Information Sources:
Gateway         Distance      Last Update
183.1.107.7 90      00:07:43
Distance: internal 90 external 170

router:
*Nov  2 13:55:54.926: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.1.105.10 (FastEthernet0/0) is down: retry limit exceeded
RSRack1R5(config-router)#
*Nov  2 13:55:57.322: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.1.105.10 (FastEthernet0/0) is up: new adjacency
RSRack1R5(config-router)#
*Nov  2 13:57:16.834: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.1.105.10 (FastEthernet0/0) is down: retry limit exceeded
RSRack1R5(config-router)#
*Nov  2 13:57:20.290: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.1.105.10 (FastEthernet0/0) is up: new adjacency

router eigrp 100
network 183.1.105.5 0.0.0.0
no auto-summary
eigrp router-id 150.1.5.5

interface FastEthernet0/0
ip address 183.1.105.5 255.255.255.0
duplex auto
speed auto

Routing Protocol is “eigrp 100″
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
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
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 100
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
183.1.105.5/32
Routing Information Sources:
Gateway         Distance      Last Update
183.1.105.10 90      00:09:49
Distance: internal 90 external 170

**********************************************************solved*************************************************

I recreated the issue in dynamips.
As suspected it was a layer 2 problem.
dynamips:
SW2 Fa1/15 SW4 Fa1/12 105 VLAN_105 < —- I was missing access vlan 105 on f1/15
actual rack:
SW2 Fa1/21 SW4 Fa1/18105 VLAN_105 < —- I can only assume I was missing access vlan 105 on f1/21 or I screwed up the port/trunk assignments.

How