Pete's Packet

Limitless

Archive for November 2nd, 2008

EIGRP Queries and Stuck-In-Active

Posted by Peter Kurdziel on November 2, 2008

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.

Neighbor

FD

AD

Router A 102,000 2000
Router B 101,000 1000
  • Router A’s topology table for 10.1.8.0/24:

Neighbor

FD

AD

Router B 2,000 1,000
Router C 201,000 101,000
Router D 201,000 101,000
Router E 201,000 101,000
  • 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:

Parameter

Description

receive-only The receive-only keyword restricts the router from sharing any of its routes with any other router within an EIGRP autonomous system. This keyword does not permit any other keyword to be specified, because it prevents any type of route from being sent. Use this option if there is a single interface on the router.
connected The connected keyword permits the EIGRP stub routing feature to send connected routes. If a network command does not include the connected routes, it might be necessary to redistribute connected routes with the redistribute connected command under the EIGRP process. This option is enabled by default and is the most widely practical stub option.
static The static keyword permits the EIGRP stub routing feature to send static routes. Redistributing static routes with the redistribute static command is still necessary.
summary The summary keyword permits the EIGRP stub routing feature to send summary routes. You can create summary routes manually with the ip summary-address eigrp command or automatically at a major network border router with the autosummary command enabled. This option is enabled by default.
  • 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/

Posted in EIGRP, Routing & Switching Lab | 1 Comment »

Working on IE II lab 1

Posted by Peter Kurdziel on November 2, 2008

I drew out my topology map with the routing protocols and my layer 2 map. I also wrote out my task tracker.

Loops = 2 but they are contained in a single routing protocol so I do not need to worry about them.

Spotting the issues:

Right off the bat I know there will be some sort of OSPF network type issue between R3-5 and a split an EIGRP split horizon issue on R2.

I started with Cat and moved on to FR. Then I skipped to RIP since it has the least amount of work to do. Then I moved on to EIGRP also since it does not have a lot of tasks.

I had company so I had to waste 6 hrs of my rack time.

I ran into a weird issue with EIGRP and got stuck.

I am getting a K-value mismatch & retry limit exceeded messages
25 messages


Piotr <usaccie@gmail.com> Sun, Nov 2, 2008 at 2:10 PM

To: ccielab@groupstudy.com

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


Jason Madsen <madsen.jason@gmail.com> Sun, Nov 2, 2008 at 2:21 PM

To: Piotr <usaccie@gmail.com>

strange…you don’t have a BW or timer mismatch do you?  your K values used seems to be the default on both ends at least.  i don’t think MTU has to match for EIGRP like it does with OSPF or i’d consider it as well.

Jason

[Quoted text hidden]
[Quoted text hidden]

Blogs and organic groups at http://www.ccie.net

_______________________________________________________________________
Subscription information may be found at:
http://www.groupstudy.com/list/CCIELab.html


Narbik Kocharians <narbikk@gmail.com> Sun, Nov 2, 2008 at 2:24 PM

To: Piotr <usaccie@gmail.com>
Cc: ccielab@groupstudy.com

Make sure that the interfaces are in the correct VLANs, do not put all interfaces of all routers in the same VLAN. If you are doing it in Frame-relay, you should ensure that there are no other frame mapping that ones desired.

[Quoted text hidden]
[Quoted text hidden]

Blogs and organic groups at http://www.ccie.net

_______________________________________________________________________
Subscription information may be found at:
http://www.groupstudy.com/list/CCIELab.html


Narbik Kocharians
CCSI#30832, CCIE# 12410 (R&S, SP, Security)
www.MicronicsTraining
www.Net-Workbooks.com
Sr. Technical Instructor


Bob Sinclair <bob@bobsinclair.net> Sun, Nov 2, 2008 at 3:02 PM

To: Piotr <usaccie@gmail.com>
Cc: ccielab@groupstudy.com

Piotr,

Check that the MTUs match on both devices.  I notice one is a switch.  Though the specs do  not require equal MTU (like OSPF does) Cisco routers have been known to drop EIGRP packets over MTU mismatch issues.
The K-value mismatch error can be caused when the near side router does not support the “goodbye” message, added around 12.2(3), but the far side does.

HTH,

Bob Sinclair  CCIE 10427  CCSI 30427
www.netmasterclass.net

Piotr wrote:

[Quoted text hidden]

Blogs and organic groups at http://www.ccie.net

_______________________________________________________________________
Subscription information may be found at: http://www.groupstudy.com/list/CCIELab.html



Piotr <usaccie@gmail.com> Sun, Nov 2, 2008 at 6:16 PM

To: Narbik Kocharians <narbikk@gmail.com>
Cc: ccielab@groupstudy.com

The interfaces appear to be in the correct vlans as per the solution.

[Quoted text hidden]


Piotr <usaccie@gmail.com> Sun, Nov 2, 2008 at 6:16 PM

To: ccielab@groupstudy.com

I am working on IE II lab 1 task 3.6. I started with the cat then frame, rip and I am on eigrp (switch to router). I’ll do eigrp router to router next then move on to OSPF.

[Quoted text hidden]


Piotr <usaccie@gmail.com> Sun, Nov 2, 2008 at 6:22 PM

To: Bob Sinclair <bob@bobsinclair.net>
Cc: ccielab@groupstudy.com

On the routers I left the MTU at default,m 1500. On the switches (3550/3560) I set the system MTU to 1500 (system MTU 1500 or system MTU routing 1500. Where allowed on the interface I set ip mtu 1500).

Debugs don’t show me anything. I was looking to shut the messages off with a command similar to ip ospf mtu-ignore but I don’t see one under the interface.

I can try and set the metric for all devices in the AS and see what happens.

[Quoted text hidden]


Piotr <usaccie@gmail.com> Sun, Nov 2, 2008 at 6:35 PM

To: Bob Sinclair <bob@bobsinclair.net>
Cc: ccielab@groupstudy.com

Nov  2 18:34:24.797: EIGRP: Sending HELLO on FastEthernet0/0
*Nov  2 18:34:24.797:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
RSRack1R5#
*Nov  2 18:34:28.593: EIGRP: Sending UPDATE on FastEthernet0/0 nbr 183.1.105.10, retry 16, RTO 5000
*Nov  2 18:34:28.593:   AS 100, Flags 0×1, Seq 435/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/2
*Nov  2 18:34:29.557: EIGRP: Sending HELLO on FastEthernet0/0
*Nov  2 18:34:29.557:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
RSRack1R5#
*Nov  2 18:34:33.593: EIGRP: Retransmission retry limit exceeded
*Nov  2 18:34:33.593: EIGRP: Sending HELLO on FastEthernet0/0
*Nov  2 18:34:33.593:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Nov  2 18:34:33.597: EIGRP: Holdtime expired
*Nov  2 18:34:33.597: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.1.105.10 (FastEthernet0/0) is down: retry limit exceeded
RSRack1R5#
*Nov  2 18:34:33.597: Going down: Peer 183.1.105.10 total=0 stub 0 template=0, iidb-stub=0 iid-all=0
*Nov  2 18:34:33.597: EIGRP: FastEthernet0/0 multicast flow blocking cleared
*Nov  2 18:34:33.597: EIGRP: Neighbor 183.1.105.10 went down on FastEthernet0/0
RSRack1R5#
*Nov  2 18:34:38.069: EIGRP: Sending HELLO on FastEthernet0/0
*Nov  2 18:34:38.069:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
RSRack1R5#
*Nov  2 18:34:42.633: EIGRP: Sending HELLO on FastEthernet0/0
*Nov  2 18:34:42.633:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
RSRack1R5#
*Nov  2 18:34:47.289: EIGRP: Sending HELLO on FastEthernet0/0
*Nov  2 18:34:47.289:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
RSRack1R5#
*Nov  2 18:34:51.765: EIGRP: Sending HELLO on FastEthernet0/0
*Nov  2 18:34:51.765:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
RSRack1R5#
*Nov  2 18:34:56.377: EIGRP: Sending HELLO on FastEthernet0/0
*Nov  2 18:34:56.377:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
RSRack1R5#ping
*Nov  2 18:35:01.265: EIGRP: Sending HELLO on FastEthernet0/0
*Nov  2 18:35:01.265:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
RSRack1R5#ping 183.1.105.10

04:03:06: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:03:06:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
04:03:07: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:03:07:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
04:03:07:        K-value mismatch
RSRack1SW4(config-router)#
04:03:07: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.1.105.5 (FastEthernet0/18) is down: K-value mismatch
RSRack1SW4(config-router)#
04:03:10: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:03:10:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0
04:03:10: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.1.105.5 (FastEthernet0/18) is up: new adjacency
04:03:10: EIGRP: Enqueueing UPDATE on FastEthernet0/18 nbr 183.1.105.5 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 1-6
04:03:10: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5
04:03:10:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 sernRSRack1SW4(config-router)#
04:03:10: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:03:10:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
04:03:10: EIGRP: Received Sequence TLV from 183.1.105.5
04:03:10:        183.1.105.10
04:03:10:        clearing CR-mode
04:03:10: EIGRP: Received CR sequence TLV from 183.1.105.5, sequence 436
04:03:10: EIGRP: Received UPDATE on FastEthernet0/18 nbr 183.1.105.5
04:03:10:   AS 100, Flags 0xA, Seq 436/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1, n
RSRack1SW4(config-router)#ot in CR-mode, packet discarded
RSRack1SW4(config-router)#
04:03:12: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5, retry 1, RTO 3000
04:03:12:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
RSRack1SW4(config-router)#
04:03:15: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:03:15:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
04:03:15: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5, retry 2, RTO 4500
04:03:15:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
RSRack1SW4(config-router)#
04:03:19: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:03:19:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
04:03:19: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5, retry 3, RTO 5000
04:03:19:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
RSRack1SW4(config-router)#
04:03:24: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:03:24:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
04:03:24: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5, retry 4, RTO 5000
04:03:24:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
RSRack1SW4(config-router)#
04:03:28: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:03:28:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
RSRack1SW4(config-router)#
04:03:29: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5, retry 5, RTO 5000
04:03:29:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
RSRack1SW4(config-router)#
04:03:33: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:03:33:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
RSRack1SW4(config-router)#
04:03:34: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5, retry 6, RTO 5000
04:03:34:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
RSRack1SW4(config-router)#
04:03:38: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:03:38:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
RSRack1SW4(config-router)#
04:03:39: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5, retry 7, RTO 5000
04:03:39:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
RSRack1SW4(config-router)#
04:03:42: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:03:42:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
RSRack1SW4(config-router)#
04:03:44: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5, retry 8, RTO 5000
04:03:44:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
RSRack1SW4(config-router)#
04:03:47: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:03:47:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
RSRack1SW4(config-router)#
04:03:49: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5, retry 9, RTO 5000
04:03:49:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
RSRack1SW4(config-router)#
04:03:52: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:03:52:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
RSRack1SW4(config-router)#
04:03:54: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5, retry 10, RTO 5000
04:03:54:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
RSRack1SW4(config-router)#
04:03:57: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:03:57:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
RSRack1SW4(config-router)#
04:03:59: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5, retry 11, RTO 5000
04:03:59:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
RSRack1SW4(config-router)#
04:04:01: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:04:01:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
RSRack1SW4(config-router)#
04:04:04: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5, retry 12, RTO 5000
04:04:04:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
RSRack1SW4(config-router)#
04:04:06: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:04:06:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
RSRack1SW4(config-router)#
04:04:09: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5, retry 13, RTO 5000
04:04:09:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
RSRack1SW4(config-router)#
04:04:11: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:04:11:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
RSRack1SW4(config-router)#
04:04:14: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5, retry 14, RTO 5000
04:04:14:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
RSRack1SW4(config-router)#
04:04:16: EIGRP: Received HELLO on FastEthernet0/18 nbr 183.1.105.5
04:04:16:   AS 100, Flags 0×0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
RSRack1SW4(config-router)#
04:04:19: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5, retry 15, RTO 5000
04:04:19:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6
RSRack1SW4(config-router)#
04:04:24: EIGRP: Sending UPDATE on FastEthernet0/18 nbr 183.1.105.5, retry 16, RTO 5000
04:04:24:   AS 100, Flags 0×9, Seq 180/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 1-6

From R5 I can not ping 183.1.105.10. From SW1 I can ping 183.1.105.10. R5 is connected to SW1.

[Quoted text hidden]

Hobbs <deadheadblues@gmail.com> Sun, Nov 2, 2008 at 6:43 PM

To: Piotr <usaccie@gmail.com>
Cc: Bob Sinclair <bob@bobsinclair.net>, ccielab@groupstudy.com

When does it happen? After you change a parameter? I think I have seen the issue that Bob talked about with the goodbye message causing a K-value mismatch….It looks like you are getting the K-value mismatch, then your adjacency is forming. This means your adjacency was brought down for some reason – maybe you configured a summary or secondary address…

Example: I had an initial config with a mistake (on purpose). One router on a LAN with /24 and the other with /20 mask. After I configured the /20 for a /24, EIGRP sent a goodbye and the other router complained about a K-value mismatch. The adjacency then came up fine.

I wonder if its a code issue…I am always running 12.4…

On Sun, Nov 2, 2008 at 4:22 PM, Piotr <usaccie@gmail.com> wrote:

[Quoted text hidden]


Hobbs <deadheadblues@gmail.com> Sun, Nov 2, 2008 at 6:44 PM

To: Piotr <usaccie@gmail.com>
Cc: Bob Sinclair <bob@bobsinclair.net>, ccielab@groupstudy.com

What is the mask of each interface?

[Quoted text hidden]


Hobbs <deadheadblues@gmail.com> Sun, Nov 2, 2008 at 6:45 PM

To: Piotr <usaccie@gmail.com>

Is the mask 255.255.255.248 on one end and something else on the other?

[Quoted text hidden]


Narbik Kocharians <narbikk@gmail.com> Sun, Nov 2, 2008 at 6:56 PM

To: Hobbs <deadheadblues@gmail.com>
Cc: Piotr <usaccie@gmail.com>, Bob Sinclair <bob@bobsinclair.net>, ccielab@groupstudy.com

Can you show us the configuration of the interfaces.

[Quoted text hidden]
[Quoted text hidden]


Piotr <usaccie@gmail.com> Sun, Nov 2, 2008 at 7:06 PM

To: Narbik Kocharians <narbikk@gmail.com>
Cc: Hobbs <deadheadblues@gmail.com>, Bob Sinclair <bob@bobsinclair.net>, ccielab@groupstudy.com

RSRack1SW1(config-if)#do sho ip route 183.1.105.5
Routing entry for 183.1.105.0/24
Known via “eigrp 100″, distance 90, metric 30720, type internal
Redistributing via eigrp 100
Last update from 183.1.107.10 on FastEthernet0/14, 00:20:27 ago
Routing Descriptor Blocks:
* 183.1.107.10, from 183.1.107.10, 00:20:27 ago, via FastEthernet0/14
Route metric is 30720, traffic share count is 1
Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

RSRack1SW1(config-if)#do sho ip route 183.1.105.10
Routing entry for 183.1.105.0/24
Known via “eigrp 100″, distance 90, metric 30720, type internal
Redistributing via eigrp 100
Last update from 183.1.107.10 on FastEthernet0/14, 00:20:31 ago
Routing Descriptor Blocks:
* 183.1.107.10, from 183.1.107.10, 00:20:31 ago, via FastEthernet0/14
Route metric is 30720, traffic share count is 1
Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

[Quoted text hidden]


Piotr <usaccie@gmail.com> Sun, Nov 2, 2008 at 7:09 PM

To: Narbik Kocharians <narbikk@gmail.com>
Cc: Hobbs <deadheadblues@gmail.com>, Bob Sinclair <bob@bobsinclair.net>, ccielab@groupstudy.com

R5 F0/0 has a physical connection to sw f0/5

RSRack1R5(config-if)#do sri f0/0
Building configuration…

Current configuration : 95 bytes
!
interface FastEthernet0/0
ip address 183.1.105.5 255.255.255.0
duplex full
speed 100
end

RSRack1SW1(config)#do sri f0/5
Building configuration…

Current configuration : 109 bytes
!
interface FastEthernet0/5
switchport access vlan 105
switchport mode access
speed 100
duplex full
end

On the topology map R5 F0/0 connects to sw4 f0/18

SRack1SW4(config-router)#  do sri f0/18
Building configuration…

Current configuration : 88 bytes
!
interface FastEthernet0/18
no switchport
ip address 183.1.105.10 255.255.255.0
end

[Quoted text hidden]

Piotr <usaccie@gmail.com> Sun, Nov 2, 2008 at 7:14 PM

To: Narbik Kocharians <narbikk@gmail.com>
Cc: Hobbs <deadheadblues@gmail.com>, Bob Sinclair <bob@bobsinclair.net>, ccielab@groupstudy.com

RSRack1SW1(config)#do sho int trunk

Port        Mode         Encapsulation  Status        Native vlan
Fa0/13      on           802.1q         trunking      46
Fa0/15      on           802.1q         trunking      46
Fa0/21      on           802.1q         trunking      1

Port        Vlans allowed on trunk
Fa0/13      1-4094
Fa0/15      1-4094
Fa0/21      1-4094

Port        Vlans allowed and active in management domain
Fa0/13      1,6,28,33,45-46,102,105,107
Fa0/15      1,6,28,33,45-46,102,105,107
Fa0/21      1,6,28,33,45-46,102,105,107

Port        Vlans in spanning tree forwarding state and not pruned
Fa0/13      1,6,28,33,45-46,102,105,107
Fa0/15      1,6,28,33,45-46,102,105,107
Fa0/21      1,6,28,33,45-46,102,105,107
RSRack1SW1(config)#

RSRack1SW4(config-if)#do sho int trunk

Port        Mode         Encapsulation  Status        Native vlan
Fa0/15      on           802.1q         trunking      1
Fa0/19      on           802.1q         trunking      46
Fa0/20      on           802.1q         trunking      46

Port        Vlans allowed on trunk
Fa0/15      1-4094
Fa0/19      1-4094
Fa0/20      1-4094

Port        Vlans allowed and active in management domain
Fa0/15      1,6,28,33,45-46,102,105,107
Fa0/19      1,6,28,33,45-46,102,105,107
Fa0/20      1,6,28,33,45-46,102,105,107

Port        Vlans in spanning tree forwarding state and not pruned
Fa0/15      1,6,28,33,45-46,102,105,107
Fa0/19      1,6,28,33,45-46,102,105,107
Fa0/20      1,6,28,33,45-46,102,105,107
RSRack1SW4(config-if)#do sho cdp nei
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
S – Switch, H – Host, I – IGMP, r – Repeater, P – Phone

Device ID            Local Intrfce         Holdtme   Capability    Platform   Port ID
RSRack1SW3          Fas 0/20              132            S I      WS-C3550-2Fas 0/20
RSRack1SW3          Fas 0/19              132            S I      WS-C3550-2Fas 0/19
RSRack1SW3          Fas 0/21              132            S I      WS-C3550-2Fas 0/21
RSRack1SW2          Fas 0/18              157           R S I     WS-C3560-2Fas 0/21
RSRack1SW1          Fas 0/15              158           R S I     WS-C3560-2Fas 0/21
RSRack1R4           Fas 0/4               165           R S I     2811      Fas 0/1
RSRack1R6           Fas 0/6               165           R S I     2811      Fas 0/1

RSRack1SW1(config)#do ping 183.1.105.10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 183.1.105.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
RSRack1SW1(config)#do ping 183.1.105.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 183.1.105.5, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

[Quoted text hidden]


Hobbs <deadheadblues@gmail.com> Sun, Nov 2, 2008 at 7:20 PM

To: Piotr <usaccie@gmail.com>
Cc: Narbik Kocharians <narbikk@gmail.com>, Bob Sinclair <bob@bobsinclair.net>, ccielab@groupstudy.com

Let’s focus on the basics.

You said “From R5 I can not ping 183.1.105.10.”

SW1 as far as I can tell is not routing between SW4 and R5 so we do not care about its routing table or whether it can ping any address. Sw4 and R5 should have a layer 2 path somewhere. What is that path?

Solve this issue first.

[Quoted text hidden]


Bob Sinclair <bob@bobsinclair.net> Sun, Nov 2, 2008 at 7:20 PM

To: Piotr <usaccie@gmail.com>
Cc: ccielab@groupstudy.com

Piotr,

Try consistent speed and duplex. Either both sides negotiate or both sides locked down.

-Bob Sinclair

Piotr wrote:

!
interface FastEthernet0/0
ip address 183.1.105.5 255.255.255.0
duplex full
speed 100
end

interface FastEthernet0/18
no switchport
ip address 183.1.105.10 255.255.255.0
end


Piotr <usaccie@gmail.com> Sun, Nov 2, 2008 at 7:29 PM

To: Bob Sinclair <bob@bobsinclair.net>
Cc: ccielab@groupstudy.com

I nailed it down. No luck.

[Quoted text hidden]


Piotr <usaccie@gmail.com> Sun, Nov 2, 2008 at 7:33 PM

To: Hobbs <deadheadblues@gmail.com>
Cc: Narbik Kocharians <narbikk@gmail.com>, Bob Sinclair <bob@bobsinclair.net>, ccielab@groupstudy.com

SW4 > R5 – layer 2 path
sw4 f0/15 > sw1 f0/21 > r5 f0/0

[Quoted text hidden]


amernas <taloust@gmail.com> Sun, Nov 2, 2008 at 7:40 PM

To: Piotr <usaccie@gmail.com>, Bob Sinclair <bob@bobsinclair.net>
Cc: ccielab@groupstudy.com

Piotr,

You can try to hardcode the k vlaues on both neighober

- Hamid

[Quoted text hidden]
[Quoted text hidden]

ZZ <zurabz@gmail.com> Sun, Nov 2, 2008 at 7:42 PM

To: Piotr <usaccie@gmail.com>
Cc: Hobbs <deadheadblues@gmail.com>, Narbik Kocharians <narbikk@gmail.com>, Bob Sinclair <bob@bobsinclair.net>, ccielab@groupstudy.com

Try to change IP mtu on SW4

[Quoted text hidden]


Hobbs <deadheadblues@gmail.com> Sun, Nov 2, 2008 at 7:45 PM

To: Piotr <usaccie@gmail.com>
Cc: Narbik Kocharians <narbikk@gmail.com>, Bob Sinclair <bob@bobsinclair.net>, ccielab@groupstudy.com

Are you sure that SW4 f0/18 is connected to SW1 f0/15…?There seems to be another switch involved because SW1 is trunking on f0/15….show cdp neighbor, something funny’s going on

[Quoted text hidden]


Hobbs <deadheadblues@gmail.com> Sun, Nov 2, 2008 at 7:47 PM

To: Piotr <usaccie@gmail.com>
Cc: Narbik Kocharians <narbikk@gmail.com>, Bob Sinclair <bob@bobsinclair.net>, ccielab@groupstudy.com

As a side note you should have verified that R5 and SW4 could ping each other before moving on to routing. I learn the hard way too :)

[Quoted text hidden]


Piotr <usaccie@gmail.com> Sun, Nov 2, 2008 at 8:30 PM

To: Hobbs <deadheadblues@gmail.com>
Cc: Narbik Kocharians <narbikk@gmail.com>, Bob Sinclair <bob@bobsinclair.net>, ccielab@groupstudy.com

I removed routing and checked my trunks. Everything looks ok.

On sw1 f0/5 I added 183.1.105.55/24 and I could ping that from R5.

I ran out of rack time……

Thanks everyone.

[Quoted text hidden]


Hobbs <deadheadblues@gmail.com> Sun, Nov 2, 2008 at 8:45 PM

To: Piotr <usaccie@gmail.com>

next time you run into issue, let us/me know. i am curious to know what issue was.

[Quoted text hidden]


Posted in Routing & Switching Lab | Leave a Comment »

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 183.1.105.5 (FastEthernet0/18) is down: K-value mismatch

Posted by Peter Kurdziel on November 2, 2008

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

Posted in EIGRP, Routing & Switching Lab | Leave a Comment »

RIP: authenticate rip updates

Posted by Peter Kurdziel on November 2, 2008

key chain RIPUPDATES
key 1
key-string CISCO

interface Vlan102
ip address 192.10.1.10 255.255.255.0
ip rip authentication mode md5
ip rip authentication key-chain RIPUPDATES
!
router rip
version 2
passive-interface default
no passive-interface Vlan102
network 192.10.1.0
no auto-summary <————- enables support for discontinuous networks.

Posted in RIP, Routing & Switching Lab | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.