cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1087
Views
0
Helpful
18
Replies

Packet drops on Next hop Serial IP

vsraghav123
Level 1
Level 1

Hello all,

I have a problem with one of my frame relay circuit.

Im not seeing any errors on the physical link , Im getting gud response when i ping the LAN ip ranges on both the side.But my question here is when I ping the Serial Ip's of this Frame relay circuit Im getting packetdrops for every single response , like below

Sending 10, 100-byte ICMP Echos to 172.25.160.85, timeout is 3 seconds:

!.!.!.!.!.

Success rate is 50 percent (5/10), round-trip min/avg/max = 8/18/44 ms

Any clue ??

18 Replies 18

a.alekseev
Level 7
Level 7

show the configuration

Raghavan,

Typically, every other packet drop could be a result of a bad link when traffic is load balanced across multiple paths. Can you post the output of 'show ip route 172.25.160.85' from the router that you were pinging. As far as you being able to the LAN IP without packet drop is it using the same path? It would help if you can describe your network setup.

HTH

Sundar

Thanks for the reply..

We have only single link connected between these 2 sites ..one end is the framerelay and the otherend is ATM. As i mentioned earlier when i ping the LAN IP range the response is gud and it takes the same WAN path to reach it ...below is the config for your view.....

interface ATM4/0.51 point-to-point

bandwidth 1024

ip address 172.25.160.85 255.255.255.252

ip mtu 1500

ip pim sparse-mode

ip multicast ttl-threshold 16

ip multicast boundary MC_Med

no snmp trap link-status

pvc 1/51

vbr-nrt 1272 636

oam-pvc manage

max-reserved-bandwidth 100

service-policy output Q-ATMsi

!

interface Serial0.51 point-to-point

bandwidth 1024

ip address 172.25.160.86 255.255.255.252

ip accounting output-packets

ip pim sparse-mode

ip multicast ttl-threshold 16

ip multicast boundary MC_Med

no ip mroute-cache

frame-relay interface-dlci 51 IETF

class QPM_Q-FRsi-1024-512

sh ip route 172.25.160.85

Routing entry for 172.25.160.84/30

Known via "connected", distance 0, metric 0 (connected, via interface)

Redistributing via eigrp 200

Routing Descriptor Blocks:

* directly connected, via Serial0.51

Route metric is 0, traffic share count is 1

please let me knwo if you need more info ..

"service-policy output Q-ATMs" - Are you doing any strict policing under the policy map? Can you remove the service policy and try the pings or post the QOS configuration.

class-map match-any Q1

match ip precedence 1

class-map match-any Q3

match ip precedence 3

class-map match-any Q5

match ip precedence 5

class-map match-any Q6

match ip precedence 6

!

policy-map Q-ATMsi

class Q6

bandwidth percent 4

random-detect

class Q5

priority percent 30

class Q3

bandwidth percent 35

random-detect

class Q1

bandwidth percent 1

random-detect

class class-default

bandwidth percent 30

random-detect

yes we do removed the QOS .. but still the same .. and we didnt noticed any drops in the policy map.

What does 'show ip route 172.25.160.86' show from the ATM router.

Also can you post the configuration of class QPM_Q-FRsi-1024-512 from the Serial side.

sure ...here it is ...

sh ip route 172.25.160.86

Routing entry for 172.25.160.84/30

Known via "connected", distance 0, metric 0 (connected, via interface)

Redistributing via eigrp 200

Routing Descriptor Blocks:

* directly connected, via ATM4/0.51

Route metric is 0, traffic share count is 1

QOS on Frame relay end

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

policy-map QPM_Q-FRsi-1024-512

class QPM_Q6

bandwidth percent 4

random-detect

class QPM_Q5

priority 153

class QPM_Q3

bandwidth percent 35

random-detect

class QPM_Q1

bandwidth percent 1

random-detect

class class-default

bandwidth percent 30

random-detect

map-class frame-relay QPM_Q-FRsi-1024-512

frame-relay cir 1021000

frame-relay bc 10300

frame-relay mincir 512000

frame-relay adaptive-shaping becn

service-policy output QPM_Q-FRsi-1024-512

Interesting.. If you aren't seeing drops on the policy map and have already tried testing without QOS configuration on both ends then can you enable 'debug ip icmp' on the ATM router and do the ping from the far end and see if all the packets make it across the FRASI circuit. This should help narrow the problem to the circuit.

Okies , I wil try debugging sometime in the late nite after business hours .... do we have any other option to check in the meantime

Everything looks good on your side. Have seen issues similar to this on frasi circuits. It's possible telco may be load balancing (layer 2) on their backbone. Ask them to bounce the PVC during the maintenance window and see if that makes difference. You may want to do the testing I had suggested earlier before you do that.

HTH

Sundar

a.alekseev
Level 7
Level 7

Sending 10, 100-byte ICMP Echos to 172.25.160.85, timeout is 3 seconds:

!.!.!.!.!.

Success rate is 50 percent (5/10), round-trip min/avg/max = 8/18/44 ms

do you have the same on both sides?

did you try to ping with different source ip address?

yes ..im getting this packet drops on both ends ... I did a extended ping with source as the WAN IP ..

CEF issue perhaps?

I dont see it to be a problem with IP CEF , Since by LAN packets hit my router and take the same path and moreover its my directly connected interface where im seeing this drop ...

Is there any thing we need to look more on the ATM-Frame Internetwork connection , but i do have same kind of configuration to some other sites which are running fine.

And due to this Im not seeing any impact in my network , but still wanted to know what exactly causing this packet drop.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco