Eigrp strange issue

Discussion in 'Cisco' started by Tosh, Mar 19, 2006.

  1. Tosh

    Tosh Guest

    Hi all,
    I've got a strange issue with a 3620 which is an hub for 25 eigrp peers.
    21 of 25 peers are connected trough gre tunnels, which are working quite
    well, but when the isp connection fails for a few seconds or when the router
    gets reloaded, these peers becomes eigrp neighbours but every 90 seconds
    disappears and reappers until I issue one or more times a "clear ip eigrp
    neighbours", at this time they reach a stable condition until the next
    connectivity issue.
    Here is a "sh ip eigrp neighbours" output when all goes right, the only
    difference in the bad output is the RTO that reaches 5000 for the gre peers
    router#sh ip eigrp ne
    IP-EIGRP neighbors for process 100
    H Address Interface Hold Uptime SRTT RTO Q Seq
    (sec) (ms) Cnt Num
    25 172.19.35.2 Tu35 14 00:25:34 112 672 0
    52601
    24 172.19.40.2 Tu40 11 00:25:35 109 654 0
    19278
    23 172.19.33.2 Tu33 13 00:25:35 122 732 0
    102422
    22 172.16.3.51 Fa0/0 14 00:25:35 22 200 0
    47943
    21 172.19.15.2 Tu15 10 00:25:35 140 840 0
    12300
    20 172.19.27.2 Tu27 12 00:25:35 116 696 0
    12699
    19 172.19.18.2 Tu18 11 00:25:36 122 732 0
    2105
    18 172.16.3.70 Fa0/0 14 00:25:36 23 200 0
    16157
    17 172.17.3.1 Fa0/1 11 00:25:36 12 200 0
    18847
    16 172.19.36.2 Tu36 14 00:25:36 77 462 0
    102707
    15 172.19.30.2 Tu30 14 00:25:36 92 552 0
    10395
    14 172.19.6.2 Tu6 11 00:25:37 112 672 0
    102631
    13 172.19.14.2 Tu14 14 00:25:37 73 438 0
    111574
    12 172.19.29.2 Tu29 14 00:25:37 116 696 0
    62650
    11 172.19.37.2 Tu37 14 00:25:38 128 768 0
    10737
    10 172.19.24.2 Tu24 13 00:25:38 134 804 0
    14061
    9 172.19.38.2 Tu38 14 00:25:38 103 618 0
    76314
    8 172.19.11.2 Tu11 12 00:25:38 116 696 0
    95578
    7 172.16.3.2 Fa0/0 11 00:25:38 24 200 0
    16147
    6 172.19.19.2 Tu19 10 00:25:38 129 774 0
    42264
    5 172.19.4.2 Tu4 14 00:25:39 74 444 0
    7582
    4 172.19.9.2 Tu9 11 00:25:39 133 798 0
    11155
    3 172.19.7.2 Tu7 11 00:25:39 137 822 0
    84534
    2 172.19.34.2 Tu34 13 00:25:39 68 408 0
    44295
    1 172.19.16.2 Tu16 10 00:25:39 145 870 0
    49718
    0 172.19.26.2 Tu26 12 00:25:39 120 720 0
    11303

    The other 4 peers never gets problems, at the remote peers side all seems
    ok.
    I tried 3 ios releases on the 3620 with bad luck, remote peers are a mix of
    1601, 1720 and 1721.
    All releases are 12.3(16) or newer.
    Bye,
    Max.
     
    Tosh, Mar 19, 2006
    #1
    1. Advertising

  2. If you are not using them already, you may try implementing GRE
    keepalives to take those tunnels down hard when the ISP has an issue:
    http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/grekpliv.htm

    Regards,
    Steve
    www.networking-forum.com


    "Tosh" <> wrote in message
    news:441d831c$-privat.org...
    > Hi all,
    > I've got a strange issue with a 3620 which is an hub for 25 eigrp peers.
    > 21 of 25 peers are connected trough gre tunnels, which are working quite
    > well, but when the isp connection fails for a few seconds or when the
    > router gets reloaded, these peers becomes eigrp neighbours but every 90
    > seconds disappears and reappers until I issue one or more times a "clear
    > ip eigrp neighbours", at this time they reach a stable condition until the
    > next connectivity issue.
    > Here is a "sh ip eigrp neighbours" output when all goes right, the only
    > difference in the bad output is the RTO that reaches 5000 for the gre
    > peers
    > router#sh ip eigrp ne
    > IP-EIGRP neighbors for process 100
    > H Address Interface Hold Uptime SRTT RTO Q
    > Seq
    > (sec) (ms) Cnt
    > Num
    > 25 172.19.35.2 Tu35 14 00:25:34 112 672 0
    > 52601
    > 24 172.19.40.2 Tu40 11 00:25:35 109 654 0
    > 19278
    > 23 172.19.33.2 Tu33 13 00:25:35 122 732 0
    > 102422
    > 22 172.16.3.51 Fa0/0 14 00:25:35 22 200 0
    > 47943
    > 21 172.19.15.2 Tu15 10 00:25:35 140 840 0
    > 12300
    > 20 172.19.27.2 Tu27 12 00:25:35 116 696 0
    > 12699
    > 19 172.19.18.2 Tu18 11 00:25:36 122 732 0
    > 2105
    > 18 172.16.3.70 Fa0/0 14 00:25:36 23 200 0
    > 16157
    > 17 172.17.3.1 Fa0/1 11 00:25:36 12 200 0
    > 18847
    > 16 172.19.36.2 Tu36 14 00:25:36 77 462 0
    > 102707
    > 15 172.19.30.2 Tu30 14 00:25:36 92 552 0
    > 10395
    > 14 172.19.6.2 Tu6 11 00:25:37 112 672 0
    > 102631
    > 13 172.19.14.2 Tu14 14 00:25:37 73 438 0
    > 111574
    > 12 172.19.29.2 Tu29 14 00:25:37 116 696 0
    > 62650
    > 11 172.19.37.2 Tu37 14 00:25:38 128 768 0
    > 10737
    > 10 172.19.24.2 Tu24 13 00:25:38 134 804 0
    > 14061
    > 9 172.19.38.2 Tu38 14 00:25:38 103 618 0
    > 76314
    > 8 172.19.11.2 Tu11 12 00:25:38 116 696 0
    > 95578
    > 7 172.16.3.2 Fa0/0 11 00:25:38 24 200 0
    > 16147
    > 6 172.19.19.2 Tu19 10 00:25:38 129 774 0
    > 42264
    > 5 172.19.4.2 Tu4 14 00:25:39 74 444 0
    > 7582
    > 4 172.19.9.2 Tu9 11 00:25:39 133 798 0
    > 11155
    > 3 172.19.7.2 Tu7 11 00:25:39 137 822 0
    > 84534
    > 2 172.19.34.2 Tu34 13 00:25:39 68 408 0
    > 44295
    > 1 172.19.16.2 Tu16 10 00:25:39 145 870 0
    > 49718
    > 0 172.19.26.2 Tu26 12 00:25:39 120 720 0
    > 11303
    >
    > The other 4 peers never gets problems, at the remote peers side all seems
    > ok.
    > I tried 3 ios releases on the 3620 with bad luck, remote peers are a mix
    > of 1601, 1720 and 1721.
    > All releases are 12.3(16) or newer.
    > Bye,
    > Max.
    >
     
    www.networking-forum.com, Mar 19, 2006
    #2
    1. Advertising

  3. Tosh

    Tosh Guest

    > If you are not using them already, you may try implementing GRE
    > keepalives to take those tunnels down hard when the ISP has an issue:
    >


    This seems to me an eigrp issue, tunnel interfaces works well, since I can
    regularly ping each side of the tunnel, but eigrp seems to have some
    difficulty to make adjiacencies with peer after an isp issue or a reload?
    Do you think that keeping gre tunnels down until isp line comes up may solve
    the issue?
    Tnx,
    Tosh.
     
    Tosh, Mar 19, 2006
    #3
  4. Tosh

    Merv Guest

    1 Are you having Stuck-In-Active (SIA) events ?

    2. Are the remote singled-homed to the one hub?

    3. Are you using the EIGRP stub feature on the remotes?

    4. Do you have internal logging configured on hub?
    logging buffer 10000 debug
    no logging console

    Please post
    sh ip eigrp traffic
    sh ip eigrp nei detail
     
    Merv, Mar 19, 2006
    #4
  5. Tosh

    thrill5 Guest

    If your remotes are not configured as stub, this could be part of your
    problem. A 3620 doesn't really have that much horsepower and EIGRP is very
    CPU intensive during convergence. Using stub will make that much better.
    For example a 7200 can only have about 150 EIGRP neighbors when not using
    stub, but can support well over 800 stub neighbors. 25 non-stub routers on a
    3620 is probably near the edge, but other factors do apply. How big are the
    circuits between the routers and how many routes do you have? Are the other
    peers connected to any of the other peers?

    Scott


    "Merv" <> wrote in message
    news:...
    >1 Are you having Stuck-In-Active (SIA) events ?
    >
    > 2. Are the remote singled-homed to the one hub?
    >
    > 3. Are you using the EIGRP stub feature on the remotes?
    >
    > 4. Do you have internal logging configured on hub?
    > logging buffer 10000 debug
    > no logging console
    >
    > Please post
    > sh ip eigrp traffic
    > sh ip eigrp nei detail
    >
     
    thrill5, Mar 19, 2006
    #5
  6. Tosh

    Maxximo Guest

    Hi Merv,
    in response to your questions I give you some outputs, some complete, some
    with only relevant parts.
    At the time these outputs were capured the peer 172.19.9.2 was the only that
    showed the issue.

    3620 outputs:

    interface Tunnel19
    bandwidth 4000
    ip address 172.19.19.1 255.255.255.252
    keepalive 10 3
    tunnel source Loopback0
    tunnel destination x.x.x.x
    tunnel key 3061963
    ..
    ..
    router eigrp 100
    redistribute static route-map redistat
    passive-interface ATM1/IMA1
    passive-interface ATM1/IMA1.1
    network 172.16.0.0
    network 172.17.3.0 0.0.0.3
    network 172.19.0.0
    distribute-list 2 out FastEthernet0/0
    distribute-list 1 out FastEthernet0/1
    distribute-list 3 in FastEthernet0/1
    distance eigrp 80 80
    no auto-summary
    no eigrp log-neighbor-changes
    ..
    ..
    logging trap debugging
    logging facility local5
    logging 172.16.3.40
    logging 172.16.3.35

    hub#sh ip eigrp ne det
    IP-EIGRP neighbors for process 100
    H Address Interface Hold Uptime SRTT RTO Q Seq
    (sec) (ms) Cnt Num
    4 172.19.9.2 Tu9 12 00:00:39 1 5000 4 118
    Last startup serial 42362
    Version 12.3/1.2, Retrans: 8, Retries: 6
    Stub Peer Advertising ( CONNECTED ) Routes
    Suppressing queries
    UPDATE seq 179192 ser 40856-40885 Sent 34096 Sequenced
    UPDATE seq 179193 ser 40886-40915 Sequenced
    UPDATE seq 179194 ser 40916-42362 Sequenced
    UPDATE seq 179196 ser 42363-42363 Sequenced

    hub#sh ip eigrp top det
    IP-EIGRP Topology Table for AS(100)/ID(85.44.245.129)

    Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
    r - reply Status, s - sia Status
    ..
    ..
    P 172.16.9.0/24, 1 successors, FD is 13465600, U, serno 42363, refcount 1,
    anchored
    via 172.19.9.2 (13465600/281600), Tunnel9
    P 172.17.8.0/30, 1 successors, FD is 307200, tag is 1, serno 40905
    via 172.17.3.1 (307200/281600), FastEthernet0/1
    P 172.19.9.0/30, 1 successors, FD is 13440000, serno 40997
    via Connected, Tunnel9

    Note: 172.16.9.0 is the network announced by 172.19.9.2 peer

    hub#sh ip eigrp ne
    IP-EIGRP neighbors for process 100
    H Address Interface Hold Uptime SRTT RTO Q Seq
    (sec) (ms) Cnt Num
    4 172.19.9.2 Tu9 14 00:00:14 1 5000 4 140
    25 172.19.35.2 Tu35 13 16:25:58 110 660 0
    52744
    24 172.19.40.2 Tu40 14 16:25:58 115 690 0
    19421
    23 172.19.33.2 Tu33 10 16:25:58 93 558 0
    102565
    22 172.16.3.51 Fa0/0 14 16:25:58 107 642 0
    48363
    21 172.19.15.2 Tu15 14 16:25:58 137 822 0
    12443
    20 172.19.27.2 Tu27 13 16:25:59 96 576 0
    12842
    19 172.19.18.2 Tu18 11 16:25:59 144 864 0
    2248
    18 172.16.3.70 Fa0/0 14 16:25:59 105 630 0
    16299
    17 172.17.3.1 Fa0/1 13 16:25:59 106 636 0
    18990
    16 172.19.36.2 Tu36 11 16:25:59 110 660 0
    102850
    15 172.19.30.2 Tu30 10 16:26:00 100 600 0
    10538
    14 172.19.6.2 Tu6 11 16:26:00 103 618 0
    102774
    13 172.19.14.2 Tu14 14 16:26:00 101 606 0
    111717
    12 172.19.29.2 Tu29 12 16:26:01 116 696 0
    62793
    11 172.19.37.2 Tu37 12 16:26:01 118 708 0
    10880
    10 172.19.24.2 Tu24 12 16:26:01 112 672 0
    14204
    9 172.19.38.2 Tu38 14 16:26:01 112 672 0
    76457
    8 172.19.11.2 Tu11 10 16:26:01 113 678 0
    95721
    7 172.16.3.2 Fa0/0 11 16:26:01 105 630 0
    16289
    6 172.19.19.2 Tu19 10 16:26:02 143 858 0
    42407
    5 172.19.4.2 Tu4 14 16:26:02 102 612 0
    7725
    3 172.19.7.2 Tu7 11 16:26:02 167 1002 0
    85035
    2 172.19.34.2 Tu34 11 16:26:02 115 690 0
    44814
    1 172.19.16.2 Tu16 12 16:26:02 131 786 0
    49861
    0 172.19.26.2 Tu26 14 16:26:02 121 726 0
    11446

    1601 remote peer outputs:

    interface Tunnel9
    bandwidth 4000
    ip address 172.19.9.2 255.255.255.252
    keepalive 10 3
    tunnel source Loopback0
    tunnel destination y.y.y.y
    tunnel key 3061963
    ..
    ..
    router eigrp 100
    passive-interface Serial0.1
    network 172.16.0.0
    network 172.19.0.0
    distribute-list 1 out Tunnel9
    no auto-summary
    eigrp stub connected

    remote#sh ip eigrp ne
    IP-EIGRP neighbors for process 100
    H Address Interface Hold Uptime SRTT RTO Q Seq
    (sec) (ms) Cnt Num
    0 172.19.9.1 Tu9 13 00:00:10 479 2874 0
    180317

    Strange enough are the SRTT and RTO values, since I can ping both peers with
    an rtt of approx.60ms.
    I noted that the bandwidth value in the tunnel interfaces was quite high, so
    I adjusted the values from 4000 to 1000 and the issue disappeared, does it
    make some sense or is it only fate?
    Tnx,
    Tosh.



    "Merv" <> ha scritto nel messaggio
    news:...
    >1 Are you having Stuck-In-Active (SIA) events ?
    >
    > 2. Are the remote singled-homed to the one hub?
    >
    > 3. Are you using the EIGRP stub feature on the remotes?
    >
    > 4. Do you have internal logging configured on hub?
    > logging buffer 10000 debug
    > no logging console
    >
    > Please post
    > sh ip eigrp traffic
    > sh ip eigrp nei detail
    >
     
    Maxximo, Mar 20, 2006
    #6
  7. Tosh

    Maxximo Guest

    > If your remotes are not configured as stub, this could be part of your
    > problem. A 3620 doesn't really have that much horsepower and EIGRP is
    > very CPU intensive during convergence. Using stub will make that much
    > better. For example a 7200 can only have about 150 EIGRP neighbors when
    > not using stub, but can support well over 800 stub neighbors. 25 non-stub
    > routers on a 3620 is probably near the edge, but other factors do apply.
    > How big are the circuits between the routers and how many routes do you
    > have? Are the other peers connected to any of the other peers?
    >


    Hi Scott,
    as you can see in the reply I sent to Merv, all the gre peers are configured
    as stub, only the remaining 3 peers are not configured as stub because is
    not applicable (2 of them are transit peers and the last is redistributed by
    bgp so the stub info is lost).
    Tnx,
    Tosh.
     
    Maxximo, Mar 20, 2006
    #7
  8. Tosh

    Merv Guest


    > I adjusted the values from 4000 to 1000 and the issue disappeared, does it
    > make some sense or is it only fate?


    The interface bandwidth setting is actually quite important.

    EIGRP will use up to 50 percent of the bandwidth of a link,
    as defined by the bandwidth interface configuration command.

    see the interface command "ip bandwidth-percent eigrp "


    BTW It is good that you are using EIGRP stub feature in your network
     
    Merv, Mar 20, 2006
    #8
  9. Tosh

    Merv Guest


    > > I adjusted the values from 4000 to 1000 and the issue disappeared, does it
    > > make some sense or is it only fate?



    Also did you adjust the tunnel bandwidth on each of the remote routers ?
     
    Merv, Mar 20, 2006
    #9
  10. Tosh

    Tosh Guest

    > Also did you adjust the tunnel bandwidth on each of the remote routers ?
    >


    Actually I've adjusted the bandwidth value only on the router that had the
    issue this morning, I've planned to do it on the other remotes asap.
    It's a little too early to say that, but the situation seems to be stable
    now, I'm confident for the issue to be solved this way,
    Can you think of any other cause for this issue?
    Thanks a lot,
    Tosh.
     
    Tosh, Mar 20, 2006
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Smythe
    Replies:
    3
    Views:
    692
    John Agosta
    Nov 29, 2003
  2. yepp

    Strange EIGRP/GRE issue !!

    yepp, Jun 1, 2005, in forum: Cisco
    Replies:
    4
    Views:
    3,728
    shivlu
    Oct 7, 2009
  3. BG
    Replies:
    3
    Views:
    7,013
  4. Darren Green
    Replies:
    2
    Views:
    810
    Darren Green
    May 14, 2006
  5. kevin

    a Strange Problem of EIGRP

    kevin, Jun 19, 2006, in forum: Cisco
    Replies:
    1
    Views:
    7,383
    kevin
    Jun 21, 2006
Loading...

Share This Page