«

Hello all.

I'm trying to use Cisco IOS udp-small-servers to measure round-trip
latency and packet loss. I'm sending the echo's from WAN-link (another
site) and using the LAN address as a destination address. As we are
running the voip from the far end I'm trying to measure, I need to get
the UDP Echo-traffic also to the same policy map as the voip traffic.

Now it seems to work so, that the destination router is sending the
answer packets (echoing them) right from the link interface and not
routing them through the LAN-interface and VLAN's/policy maps as we
would like to.

I cannot find ANY documentation regarding this kind of configuration,
only a basic enable/disable the echo service.

Thank's,

Jannar.

Jannar,

If you want to use routers as sources/sinks of test data, then you
should put them outboard of your systems-under-test.

i.e. do this:

[source]-{network-under-test}-[sink]

not this

{[some router [source]]-{cloud}-[[sink] some router]}
|<------------- network under test ---------------->|

For using a router as a source/sink of data packets, one option
is to use ttcp which is built into some feature sets.
http://www.cisco.com/warp/public/471/ttcp.html

(This example violates my advice above, as it has the router
under test act as a source of test data ... but that's OK because
I wasn't testing the router's internal queueing technique.)

Cheers,

Aaron

---

~ Hello all.
~
~ I'm trying to use Cisco IOS udp-small-servers to measure round-trip
~ latency and packet loss. I'm sending the echo's from WAN-link (another
~ site) and using the LAN address as a destination address. As we are
~ running the voip from the far end I'm trying to measure, I need to get
~ the UDP Echo-traffic also to the same policy map as the voip traffic.
~
~ Now it seems to work so, that the destination router is sending the
~ answer packets (echoing them) right from the link interface and not
~ routing them through the LAN-interface and VLAN's/policy maps as we
~ would like to.
~
~ I cannot find ANY documentation regarding this kind of configuration,
~ only a basic enable/disable the echo service.
~
~ Thank's,
~
~ Jannar.

>should put them outboard of your systems-under-test.

Yes, I have a separate hardware sending those UDP echo packets
(source). My problem is how to manage the routing at the far end
(Cisco IOS small-server as a destination). Now the destination IOS
seems to reply directly from the WAN interface and I cannot do any
policing/queuging for the reply traffic.

So my setup is like this:

[UDP echo src] ---- [WAN] ---- [IOS router with UDP echo server] ----
[VoIP VLAN and Data-VLAN]

I need to use IP DSCP 56 for those echo replies. My source is sending
DSCP 56 just fine, and it's working across the WAN just fine.

Any hints?

I'm sorry, you've lost me.

My point was that you should not expect to use one and the
same IOS router simultaneously act as the source/sink of
your test data and also to run data policing/queueing of
that data.

Aaron

---


~
~ >should put them outboard of your systems-under-test.
~
~ Yes, I have a separate hardware sending those UDP echo packets
~ (source). My problem is how to manage the routing at the far end
~ (Cisco IOS small-server as a destination). Now the destination IOS
~ seems to reply directly from the WAN interface and I cannot do any
~ policing/queuging for the reply traffic.
~
~ So my setup is like this:
~
~ [UDP echo src] ---- [WAN] ---- [IOS router with UDP echo server] ----
~ [VoIP VLAN and Data-VLAN]
~
~ I need to use IP DSCP 56 for those echo replies. My source is sending
~ DSCP 56 just fine, and it's working across the WAN just fine.
~
~ Any hints?

>My point was that you should not expect to use one and the
>same IOS router

Do you mean, that I should not try to use it or it's impossible?

On Mon, 07 Nov 2005 10:06:50 +0200, Jannar Molden <> wrote:

~ >My point was that you should not expect to use one and the
~ >same IOS router
~
~ Do you mean, that I should not try to use it or it's impossible?

Well, by all means try it, but if it doesn't produce the expected results,
then you should question the expected results.

In article <>,
Aaron Leonard <> wrote:
>On Mon, 07 Nov 2005 10:06:50 +0200, Jannar Molden <> wrote:
>
>~ >My point was that you should not expect to use one and the
>~ >same IOS router
>~
>~ Do you mean, that I should not try to use it or it's impossible?
>
>Well, by all means try it, but if it doesn't produce the expected results,
>then you should question the expected results.

Perhaps just as important, even if it does produce the expected results,
you should _still_ question the results.

Good luck and have fun!
--
Vincent C Jones, Consultant Expert advice and a helping hand
Networking Unlimited, Inc. for those who want to manage and
Tenafly, NJ Phone: 201 568-7810 control their networking destiny
http://www.networkingunlimited.com