Cisco ISR4331 eigrp Interface PEER-TERMINATION received issue question

[dae0712]

hello,
I would like to ask a question about Cisco ISR4331 eigrp Interface PEER-TERMINATION received issue.

The interface connected between two different devices had a bandwidth of 100000 for A and a bandwidth of 10 for B.

In conclusion, it was a mistake to use 10 bandwidth, but it was operating normally.

However, the problem is that after rebooting the equipment, Interface PEER-TERMINATION received occurs, and the eigrp neighbor is established and disconnected repeatedly at approximately 70 second intervals.

The problem was resolved by setting the bandwidth to 100000 for the interface where the bandwidth was accidentally set to 10.

However, the question is, when I rebooted the two devices after setting the bandwidth differently with the stock device, I confirmed that the eigrp neighbor was established immediately.

If so, I would like to ask a question because I am curious as to what could be the cause of the symptom.

Could it be that the eigrp neighbor was established immediately in the test environment because the amount of information loaded was different from the actual operating equipment?

In the test environment, only eigrp settings were entered.

However, equipment in actual operation has a huge routing table.

If you know anything about this, please let me know.

[David Ruess · Accepted solution]

Hello,

Given the information I would attribute it to the huge routing table and the low BW on the interface. Here's why: EIGRP (by default) will use 50% of the BW for its updates and such. This value can be configured. Hello packets don't take up that much BW, but then you have a large routing table of updates that needs to be provided to its peer you could run into issues of packets not arriving or being acknowledged. Update packets require an ACK from its peer. This could be the reason the peer sent a termination since it wasn't getting the necessary packets after asking multiple times.

I assume your test environment doesn't have a big routing table, so the neighbor adjacencies came up and exchanged routes just fine. In your live environment the large routing table could not be sent to the neighbor in bulk after your reload. Another issue (assumption) is when the EIGRP peers established in your live environment either the 10 BW command hadn't been applied, or you incrementally added routes to the routing table over time. This would explain why it probably hasn't happened before because it never had to send large amounts of updates at one time. The reboot would have introduced that condition.

Hope this helps

-David

[dae0712]

Thanks for your reply.
Your question has been resolved.

[MHM Cisco World]

I dont think it issue of BW mismatch 

Peer termination is send when one peer admin down eigrp AND/OR we run any change in eigrp

MHM

[David Ruess]

An EIGRP neighbor doesn't necessarily have to be admin down to send a peer termination. A peer termination can also be sent if the EIGRP device doesn't hear from its neighbor with either Hello packets or ACK packets. This can be caused by congestion on the link to include low BW configured. The peers can still be functionally up, but packets may be dropped causing a PEER TERMINATION to be sent.

[MHM Cisco World]

If it not hear why it need to send peer termination?

I am sure' peer termination is happening when admin down or change anything in eigrp config in one side

Hello must be fine when peer termination messages is use.

For BW mismatch I dont think it big issue' in end control plane use 10% by defualt and one side is 1 G BW which is so enough for eigrp.

MHM

[David Ruess]

I don't believe the BW mismatch was the issue either from my original reply. I just noted the low BW and EIGRP using 50% by default means it only had 5 kBits (0.01 megabits (mb)), which is very low to send a huge routing table. As the OP also noted the neighbors successfully established which means peers were sending hellos. Peer termination could have also been sent if one of the peers wasn't able to acknowledge update packets.

It is incorrect to say EIGRP configuration must be changed in EIGRP on one side for peer termination to be sent. If an EIGRP neighbor does NOT receive an ACK for an update it sent due to link issues or congestion it will terminate the neighborship after so many retries, without any config changes made.

[MHM Cisco World]

Yes you are correct I mention peer termination use when hello is OK

If one peer dont see ACK for update for neighbor and have fine hello message from neighbor it will send peer termination. <<- I was correct in my first comment' this statement is wrong' if peer not receive ack the hold-time-expire message send NOT peer-termination.

For BW maybe @dae0712 help us for more details about exact value in both peers

MHM