Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

simple, yet FRUSTRATING routing problem

basic config is two locatios, each with two subnets connected with an MPLS.

The remote site routes to the local site just fine, however when doing a tracert from local to remote somthing is not right. The connection does work, however we're getting lots of 1-way audio on VOIP calls.

Local -> Remote

Tracing route to 192.168.3.48 over a maximum of 30 ho

  1    <1 ms    <1 ms    <1 ms  192.168.2.200
  2    27 ms    27 ms    27 ms  999.20.94.29
  3    28 ms    47 ms    28 ms  999.20.94.213
  4    36 ms    35 ms    35 ms  999.20.94.214
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
10    42 ms    41 ms    41 ms  192.168.3.48

Remote -> Local

Tracing route to 192.168.4.48 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.3.1
  2     8 ms     8 ms     8 ms  999.20.94.213
  3     9 ms     9 ms    10 ms  999.20.94.29
  4    36 ms    36 ms    36 ms  999.20.94.30
  5    57 ms    56 ms    60 ms  192.168.4.48

999.20.94.214 is my serial interface from the MPLS. The same router has an interface in at 192.168.3.1. Any ideas why the trace route would do this?

12 REPLIES
New Member

Re: simple, yet FRUSTRATING routing problem

anyone? I'd can't find anything to help explain why a traceroute works in one direction, but chokes in the other.

Re: simple, yet FRUSTRATING routing problem

Try doing an extended ping and record it. See if it's taking the same path to/from the remote and local routers.

HTH,

John

HTH, John *** Please rate all useful posts ***
New Member

Re: simple, yet FRUSTRATING routing problem

when I ping from the local router to the remote target it does not respond if I take the default options. HOWEVER in the extended commands, if I specify one of the other ethernet interfaces (not S0) it works. Really odd, because the traffic goes over the S0 interface anyway... yet another thing I can't explain.

E-town#ping
Protocol [ip]:
Target IP address: 192.168.3.49
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.2.200 (******** have to specify, if left to default (S0) it times out)
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: Record
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.3.49, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.200
Packet has IP options:  Total option bytes= 39, padded length=40
Record route: <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)

Reply to request 0 (44 ms).  Received packet has options
Total option bytes= 40, padded length=40
Record route:
   (999.20.94.30)
   (192.168.3.1)
   (192.168.3.49)
   (999.20.94.214)
   (192.168.2.200) <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
End of list

Success rate is 100 percent (1/1), round-trip min/avg/max = 44/44/44 ms
E-town#

Hall of Fame Super Bronze

Re: simple, yet FRUSTRATING routing problem

when I ping from the local router to the remote target it does not respond if I take the default options. HOWEVER in the extended commands, if I specify one of the other ethernet interfaces (not S0) it works.

An indication that the remote target does not have a route back to the Serial 0 interface. It may know how to reach your ethernet interface because the subnet is known.

Advertise your serial 0 interface and let us know if that corrects your problem.

Regards,

Edison

Re: simple, yet FRUSTRATING routing problem

Yeah, if you're having to source from your inside interface, your remote side doesn't know how to get back to your serial side. You could see this in the routing table on the remote side. Do as Edison says and advertise your serial side on this router that you have to provide a source address, and that should solve the problem.

HTH,

John

HTH, John *** Please rate all useful posts ***
New Member

Re: simple, yet FRUSTRATING routing problem

Hey! That seems to have taken care of my trace route problems. That makes total sense now.

Now we'll see if thats had any effect on my VOIP problesm????

Hall of Fame Super Bronze

Re: simple, yet FRUSTRATING routing problem

VoIP problems could be QoS related. Have you implemented QOS in your network and have QOS services with the MPLS provider?

Please remember to rate helpful posts.

Regards,

Edison

New Member

Re: simple, yet FRUSTRATING routing problem

Crap... still problems with One-way VOIP.

Yea, I have a QOS policy in place, and there is QOS on the MPLS. All has been fine for 3-4 years... but suddly this became an issue.

Back to the drawing board I guess.

Re: simple, yet FRUSTRATING routing problem

Which side is experiencing one way audio? Has anything changed recently in configs, added any new equipment, etc? Is the one way problem internal to extensions or external out your PRI? Usually it comes down to a routing issue though. What routing protocol are you using for your IGP and to your provider? Can you post the routing table from the router that's having the problem?

HTH, John *** Please rate all useful posts ***
New Member

Re: simple, yet FRUSTRATING routing problem

One-way audio is at the remote side. THey can't hear the caller, caller can hear them. The trunks are at the local site, so its happening with both internal and outside callers.

Nothing has really changed on my end. A few days ago the circuit went down for an hour or so, its seems to be fussy since. I checked with the Telco, they say they do not see the outage, I also had them verify that the config did not change.

The QOS for voice-signaling below is not catching any traffic.. I could fix that. However its been this way for 4-5 years without issue.

Thanks so much for your willingness to help.

REMOTE

Gateway of last resort is 192.168.1.2 to network 0.0.0.0

     999.20.0.0/30 is subnetted, 2 subnets
C       999.20.94.212 is directly connected, Serial0/0/0
S       999.20.94.28 [1/0] via 172.20.94.213
S    192.168.4.0/24 [1/0] via 172.20.94.213
S    192.168.5.0/24 [1/0] via 172.20.94.213
C    192.168.1.0/24 is directly connected, FastEthernet0/0
S    192.168.2.0/24 [1/0] via 172.20.94.213
C    192.168.3.0/24 is directly connected, FastEthernet0/1
S*   0.0.0.0/0 [1/0] via 192.168.1.2

LOCAL

Gateway of last resort is 10.1.10.1 to network 0.0.0.0

     99.20.0.0/30 is subnetted, 2 subnets
S       999.20.94.212 [1/0] via 172.20.94.29
C       999.20.94.28 is directly connected, Serial0/0/0
C    192.168.4.0/24 is directly connected, FastEthernet0/0.2
S    192.168.5.0/24 [1/0] via 192.168.2.7
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.10.0 is directly connected, FastEthernet0/1
S    192.168.1.0/24 [1/0] via 172.20.94.29
C    192.168.2.0/24 is directly connected, FastEthernet0/0.1
S    192.168.3.0/24 [1/0] via 172.20.94.29
S*   0.0.0.0/0 [1/0] via 10.1.10.1

Local#show policy-map int s0/0/0
Serial0/0/0

  Service-policy output: voice-qos

    Class-map: voice (match-any)
      24479015 packets, 1667205726 bytes
      5 minute offered rate 75000 bps, drop rate 0 bps
      Match: ip dscp ef (46)
        24479016 packets, 1667205790 bytes
        5 minute rate 75000 bps
      Match: ip precedence 5
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 20 (%)
        Bandwidth 308 (kbps) Burst 7700 (Bytes)
        (pkts matched/bytes matched) 3821703/263582400
        (total drops/bytes drops) 0/0

    Class-map: voice-signaling (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp cs3 (24)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: ip dscp af31 (26)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing
        Output Queue: Conversation 265
        Bandwidth 5 (%)
        Bandwidth 77 (kbps) Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: class-default (match-any)
      23585969 packets, 30837445126 bytes
      5 minute offered rate 25000 bps, drop rate 0 bps
      Match: any
      Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 256
        (total queued/total drops/no-buffer drops) 0/2341/0

New Member

Re: simple, yet FRUSTRATING routing problem

I was missing a DSCP value in the signaling QOS. It was on the config at the remote site... so I fixed it at the local. Thought that may do it, but alas... it did not.

Hall of Fame Super Bronze

Re: simple, yet FRUSTRATING routing problem

The packets could be dropped within the provider network. You need to open a trouble ticket with them.

387
Views
5
Helpful
12
Replies
CreatePlease login to create content