simple, yet FRUSTRATING routing problem

Unanswered Question
Jul 6th, 2010

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?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
neilrmessick Tue, 07/06/2010 - 07:02

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

John Blakley Tue, 07/06/2010 - 07:48

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

neilrmessick Tue, 07/06/2010 - 07:59

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#

Edison Ortiz Tue, 07/06/2010 - 08:08

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

John Blakley Tue, 07/06/2010 - 08:11

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

neilrmessick Tue, 07/06/2010 - 08:36

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????

Edison Ortiz Tue, 07/06/2010 - 08:47

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

neilrmessick Tue, 07/06/2010 - 10:08

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.

John Blakley Tue, 07/06/2010 - 10:11

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?

neilrmessick Tue, 07/06/2010 - 10:39

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

neilrmessick Tue, 07/06/2010 - 11:16

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.

Edison Ortiz Wed, 07/07/2010 - 13:38

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

Actions

This Discussion