Hi Rick i have already enabled debug on both routers:

debug eigrp packets hello

debug ip eigrp notifications

debug eigrp neighbors

I noticed that during the EIGRP Adjacency loss both routers send and receive hello packets. I was wondering if there is a problem with FR configuration, or FR ISP but the relevant PVC never comes down.

Is there any other command i can use to inspect this phenomenon?

Thanks again

Yes I have only 2 routers on a point-to-point format. Just these 2 routers over the FR cloud.

Below you can see the map-classes for

ROUTER_A:

map-class frame-relay

frame-relay adaptive-shaping becn

frame-relay cir 1024000

and for ROUTER_B:

map-class frame-relay

frame-relay cir 1024000

frame-relay adaptive-shaping becn

frame-relay priority-group 2

Do you believe that tha traffic shaping is the reason for that EIGRP Adjacency loss? I could try to remove the relevant entries and observe the router's behavior..

I will keep you informed for the results.

Thanks anyway

Routing protocols rely on the bandwidth statement from the interface to make routing decisions.

Your map-class doesn't match to the bandwidth statement on Router A (768kbps bandwidth statement vs 1024000 cir).

You also have a priority-group on Router B, what kind of traffic are you marking ?

If you are able to remove the traffic-shaping on these routers, it will definitely help us identifying the problem. Make sure you remove the traffic-shaping command from the main interface. If you leave it there while removing the class from the subinterface, the circuits will default to 64kbps CIR.

HTH,

__

Edison.

Hi guys,

Unfortunately it did not work. Basically i removed the relevant traffic-shaping commands from those routers but again after 3 days i had the same log messages:

Mar 20 11:15:00.054: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.230.246 (Serial4/3.100) is down: Interface Goodbye received

Mar 20 11:15:03.238: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.230.246 (Serial4/3.100) is up: new adjacency

Mar 20 11:15:32.139: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.230.246 (Serial4/3.100) is down: Interface Goodbye received

Mar 20 11:15:35.239: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.230.246 (Serial4/3.100) is up: new adjacency

I think it is a bit starnge because the pvc was still up and running. Take a look below from the show frame-relay pvc command output:

FBB-BBN-3662#sh frame-relay pvc

PVC Statistics for interface Serial4/3 (Frame Relay DTE)

Active Inactive Deleted Static

Local 1 0 0 0

Switched 0 0 0 0

Unused 0 0 0 0

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/3.100

input pkts 244416 output pkts 278502 in bytes 44791803

out bytes 225508885 dropped pkts 0 in pkts dropped 0

out pkts dropped 0 out bytes dropped 0

in FECN pkts 0 in BECN pkts 0 out FECN pkts 0

out BECN pkts 0 in DE pkts 18238 out DE pkts 0

out bcast pkts 2647 out bcast bytes 222328

5 minute input rate 9000 bits/sec, 13 packets/sec

5 minute output rate 82000 bits/sec, 13 packets/sec

pvc create time 5w4d, last time pvc status changed 2d16h

Could you please advise me anybody, if there is a way to find out if this phenomenon is a Telco or ISP problem (i do not think because of the output above related to pvc)...

Anyway...any help would be appreciated!!!

Thanks in advance...

John

The fact that the PVC stays up and running is not surprising. As has been mentioned in previous posts I believe that the problem is packet loss, specifically the loss of packets which are EIGRP hello messages. It is possible that the packets are being dropped in the Frame Relay cloud by the provider and it is possible that the packets are being dropped by your router. I note in the output that you posted that "in DE pkts 18238". If there are 18238 Discard Eligible packets it implies that some traffic is exceeding the CIR and leads to the question whether some of the eligible packets being dropped?

Is it consistently the same router that has the Goodby Received message? That might imply that traffic is dropped in one direction but not the other. The router that generates the "holding time expired" message is the one where packets are dropped. This might help us focus on where to look.

In a previous post you indicate that you had run some debugs including a debug that looks at EIGRP hello messages. These should be received on a regular interval (probably every 5 seconds - though if an interface has a low bandwidth configured that might change. In the debugs are there some instances where the interval between receiving hellos changes (implying that some hello messages were dropped)?

HTH

Rick

Hi Rick,

For the time being yes it is consistently the same router that has the Goodby Received message.

Regarding the debugs that i had run some days ago i have noticed that hello packets received on a regular interval on router's interface with this log message. Actually the range is between 4.1 - 4.9 sec.

You can see below the output from the show frame-relay pvc command from both routers.

ROUTER_B

PVC Statistics for interface Serial0/2/0 (Frame Relay DTE)

Active Inactive Deleted Static

Local 1 0 0 0

Switched 0 0 0 0

Unused 0 0 0 0

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/2/0.100

input pkts 498560 output pkts 451474 in bytes 392086869

out bytes 79406319 dropped pkts 0 in pkts dropped 0

out pkts dropped 0 out bytes dropped 0

in FECN pkts 0 in BECN pkts 0 out FECN pkts 0

out BECN pkts 0 in DE pkts 5585 out DE pkts 0

out bcast pkts 5150 out bcast bytes 435952

5 minute input rate 177000 bits/sec, 18 packets/sec

5 minute output rate 11000 bits/sec, 15 packets/sec

pvc create time 6w6d, last time pvc status changed 2d19h

ROUTER_A

PVC Statistics for interface Serial4/3 (Frame Relay DTE)

Active Inactive Deleted Static

Local 1 0 0 0

Switched 0 0 0 0

Unused 0 0 0 0

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/3.100

input pkts 203766 output pkts 223361 in bytes 35892037

out bytes 171905699 dropped pkts 0 in pkts dropped 0

out pkts dropped 0 out bytes dropped 0

in FECN pkts 0 in BECN pkts 0 out FECN pkts 0

out BECN pkts 0 in DE pkts 12834 out DE pkts 0

out bcast pkts 2508 out bcast bytes 210632

5 minute input rate 67000 bits/sec, 21 packets/sec

5 minute output rate 66000 bits/sec, 15 packets/sec

pvc create time 5w5d, last time pvc status changed 2d19h

As you can see there are alot of DE packets. However there is no dropped packet either ROUTER_A or ROUTER_B...

At this time both routers have in their interfaces only the following class:

map-class frame-relay CLASS-ROUTER

frame-relay adaptive-shaping becn

frame-relay cir 1024000

I have already configured the bandwidth to 1024 Kbps to both interfaces...

Thanks for your assistance!!!

Hi all,

After further investigation I found out that you are absolutely right. I turned on the relevant debug commands and I captured the debug messages, which indicate that EIGRP Adjacency Loss is due to missed hello packets. (see attachements, the BRI interface is the backup interface)

The point is that I noticed both log messages on the router:

Mar 21 17:56:41.508: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.230.246 (Serial4/3.100) is down: Interface Goodbye received

Mar 21 17:55:21.129: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.230.246 (Serial4/3.100) is down: holding time expired

I realised tha hello packets are lost somewhere in the middle in Frame-Relay cloud. I do not think that this packet lost is due to traffic congestion. Are you think tha it is?

I do not see any dropped packet in neither serial interface...Is there any way to find out what happen?

Thanks in advance!!!

""I realised tha hello packets are lost somewhere in the middle in Frame-Relay cloud. I do not think that this packet lost is due to traffic congestion. Are you think tha it is?""

Yes, it's being dropped in the frame relay cloud somewhere. It's purely due to oversubscription of circuit on your side (RouterA). Anytime the router marks a packet DE the devices on the frame network are free to discard those packets. No it's not due to congestion on the frame network as that would reflect in FECN/BECNs etc.

""I do not see any dropped packet in neither serial interface...Is there any way to find out what happen?""

Call the frame provider and asked them to a look at the statistics and tell you whether they have been discarding packets. You could also ask them to disable graceful discards and if the problem goes away then you wouldn't know that you've been overutilizing the ciruit.

You may have to fine tune the frame relay map class to restrict the traffic flow to comply with the CIR on the PVC and thus avoid all these problems.

HTH

Sundar