07-16-2008 11:33 AM - edited 03-03-2019 10:45 PM
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 ??
07-16-2008 11:58 AM
show the configuration
07-16-2008 12:00 PM
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
07-16-2008 12:26 PM
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 ..
07-16-2008 12:31 PM
"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.
07-16-2008 12:35 PM
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.
07-16-2008 12:45 PM
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.
07-16-2008 12:51 PM
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
07-16-2008 01:05 PM
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.
07-16-2008 01:13 PM
Okies , I wil try debugging sometime in the late nite after business hours .... do we have any other option to check in the meantime
07-16-2008 02:00 PM
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
07-16-2008 02:19 PM
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?
07-16-2008 02:23 PM
yes ..im getting this packet drops on both ends ... I did a extended ping with source as the WAN IP ..
07-16-2008 03:06 PM
CEF issue perhaps?
07-16-2008 03:31 PM
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.
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: