MCU 4515 too low MTU

[Alexander Belonogov]

     In my VC network I faced with problem: bad picture from participants. I tried to find issue and now I know a maximal packet size to MCU is 104 bytes.

Pinging from Cisco router (default gateway for this MCU):

#ping 10.50.2.8 size 104

Type escape sequence to abort.

Sending 5, 104-byte ICMP Echos to 10.50.2.8, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Increase packet size to 105:

#ping 10.50.2.8 size 105

Type escape sequence to abort.

Sending 5, 105-byte ICMP Echos to 10.50.2.8, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Is it normal MTU size for MCU 4515? Can it be my issue? How I can change this parameter on MCU 4515?

[Tomonori Taniguchi · Accepted solution]

Are you sure you getting ping reply from 4500 series MCU while packet size set to 104 bytes?

Due to kernel limitation (limited to save the box from failing over), the max size of ping response that 4500 series MCU support should be 76 byte payload…

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

~ # ping 172.16.1.90 -s 75

PING 172.16.1.90 (172.16.1.90) 75(103) bytes of data.

83 bytes from 172.16.1.90: icmp_req=1 ttl=255 time=0.936 ms

83 bytes from 172.16.1.90: icmp_req=2 ttl=255 time=1.93 ms

--- 172.16.1.90 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1001ms

rtt min/avg/max/mdev = 0.936/1.434/1.933/0.499 ms

~ # ping 172.16.1.90 -s 76

PING 172.16.1.90 (172.16.1.90) 76(104) bytes of data.

84 bytes from 172.16.1.90: icmp_req=1 ttl=255 time=2.00 ms

84 bytes from 172.16.1.90: icmp_req=2 ttl=255 time=0.905 ms

--- 172.16.1.90 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1001ms

rtt min/avg/max/mdev = 0.905/1.452/2.000/0.548 ms

~ # ping 172.16.1.90 -s 77

PING 172.16.1.90 (172.16.1.90) 77(105) bytes of data.

--- 172.16.1.90 ping statistics ---

6 packets transmitted, 0 received, 100% packet loss, time 4998ms

~ # ping 172.16.1.90 -s 104

PING 172.16.1.90 (172.16.1.90) 104(132) bytes of data.

2 packets transmitted, 0 received, 100% packet loss, time 1000ms

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

This is limitation on ping response so actual MTU size is different.

[Alexander Belonogov]

Tomonori Taniguchi написал(а):
Are you sure you getting ping reply from 4500 series MCU while packet size set to 104 bytes?
Due to kernel limitation (limited to save the box from failing over), the max size of ping response that 4500 series MCU support should be 76 byte payload…
=========================================================

Yes, I am shure. I get ping from Cisco router and its size parameter set full packet size not only payload size. From OS ping is absolutely the same:

WINDOWS>ping 10.50.2.8 -l 76

Pinging 10.50.2.8 with 76 bytes of data:

Reply from 10.50.2.8: bytes=76 time=2ms TTL=255

Reply from 10.50.2.8: bytes=76 time=3ms TTL=255

Reply from 10.50.2.8: bytes=76 time=3ms TTL=255

Reply from 10.50.2.8: bytes=76 time=1ms TTL=255

Ping statistics for 10.50.2.8:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 1ms, Maximum = 3ms, Average = 2ms

>ping 10.50.2.8 -l 77

Pinging 10.50.2.8 with 77 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Ping statistics for 10.50.2.8:

    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

[Tomonori Taniguchi]

> Yes, I am shure. I get ping from Cisco router and its size parameter set full packet size not only payload size.

> From OS ping is absolutely the same:

OK, then it makes sense why you see ping success with size=104.

IOS able to specify data size which include some of overhead packet length not pure ping data length.

Ping from Router/Switch run IOS with size option parameter.

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

Size = 104

Overall frame length: 118 bytes

Ping data length: 76 bytes

Size = 105

Overall frame length: 119 bytes

Ping data length: 77 bytes

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

So overall same result that 4500 series MCU has kernel level limitation for reply the ping request depend on ping data length as I explained above.

[Anthony Thomson]

You can set the maximum transmitted video packet size under Settings --> Conferences --> Advanced settings, but this is not the same thing as setting MTU size.  As far as I know, you cannot change the MTU size on the MCU.

Interestingly enough, I tried this on my own, and ICMP echoes over 76 bytes fail to my 4505 (even smaller than yours!).  I don't know what is causing this behavior.  (Edit: answer to this from Tomonori above!!)

However, I do not have a problem with poor picture.  This is likely a red herring for you.  You probably need to look more at the usual suspects: traffic congestion, and speed/duplex mismatches a long the path that video takes.  With the latter, don't assume that since switches A & B are both configure for Auto negotiation that they have successfully negotiated the same speed/duplex.  All too often they don't, and one side is using half duplex and the other is full duplex, and no one notices its dropping packets until you put video across the connection.

[Alexander Belonogov]

Anthony Thomson написал(а):
Interestingly enough, I tried this on my own, and ICMP echoes over 76 bytes fail to my 4505 (even smaller than yours!).  I don't know what is causing this behavior.  (Edit: answer to this from Tomonori above!!)

See my answer to Tomonori above.

Anthony Thomson написал(а):
You probably need to look more at the usual suspects: traffic congestion, and speed/duplex mismatches a long the path that video takes. 

See my answer to Tomonori below.

[Tomonori Taniguchi]

Regarding to the bad picture, do you see any packet loss on MCU (under each participant statistics)?

If you have seen bad picture on specific location/site, common issue due with the Ethernet speed mismatch (or one of connection in path with 10M/100M half-duplex).

I’d suggest reviewing the call statistic or talking SIP/H323 syslog and look for FUR message volume to narrow down the possible scenario.

[Alexander Belonogov]

Thank you all for answers!

I didn't tell but my participants connect throw WAN links (L2 VPN by ISP network). And I see packet loss on MCU.

I am going to present a complete picture of my issue before I make a request to my ISP.

On MCU I have see Packet errors and Frame errors, what is the difference between them?

FUR message what is it?

[Tomonori Taniguchi]

> On MCU I have see Packet errors and Frame errors, what is the difference between them?

The packet errors are reported when there is a problem with error in receiving packets, for example, a discontinuation of a sequence or incorrect RTP information (e.g. a payload has changed mid-stream but the endpoint hasn't sent a keyframe), etc.

Frame errors are reported when the actual frame is suffering either due to packet loss or actual video errors. So this will most often trigger FURs if MCU is unable to recover.

> FUR message what is it?

FUR is "Fast Video Update". Device sends this message for requesting new key frame from far end device.

When there are number of packet loss on video stream, Endpoint may not decode incoming video payload because of already lose several previous update video payload/frame.

To recover it, Endpoint request new key frame which doesn't require previous video frame to decode the picture.

[Tomonori Taniguchi]

Here is a little more explanation about FUR.

For H.323 call, you should see H.245 Miscellaneous Command message with “videoFastUpdatePicture :” information.

For example:

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

sysl H245LO-1 Incoming MESSAGE START

value MultimediaSystemControlMessage ::= command : miscellaneousCommand :

{

logicalChannelNumber 2,

type videoFastUpdatePicture : NULL

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

For SIP call, you should see SIP INFO message with “picture_fast_update” information.

For example:

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

CSeq: 108 INFO

Contact: <127.0.0.1:5071>

From: <>user1@demo.com>;tag=24a8c7987aeba7c8

To: <>tuser2@demo.com>;tag=a6d6c9c194ed9dc9

Max-Forwards: 68

Content-Type: application/media_control+xml

Content-Length: 168

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

[Alexander Belonogov]

Where you can see this messages? Any log file, from data port, by telnet?

I will try to watch this during the conference.

[Tomonori Taniguchi]

On MCU, you should see the FUR message in Logs > H.323/SIP log (Enable H323/SIP logging).

Please note this log on Web GUI able to display latest 2000 entries.

You may monitor FUR by using VCS diagnostic log as well.

Under Maintenance > Diagnostics > Diagnostic logging, change Network log level to "Debug" and click "Start new log".

After your conference, click "Stop logging" then "Download log" to download log file (text base).

Probably this will be more recommended method as allow to capture log during your conference call.

[Alexander Belonogov]

Thank you Tomonori for your detailed response! Now I know a little more about MCU working.

[Martin Koch]

Can I see the RTCP stats of a call somewhere in the logs / debug info of the MCU?