Remote Desktop Not working with EoMPLS

Unanswered Question
Aug 21st, 2007

I am hosting a HVPLS domain on my 7613 Core router where my spokes (6524ME) terminate the port based Pseudowires. All spokes have an MTU size of 1522. The clients are have intermitent problems with Windows Remote Desktop and mail synchronization. This clearly is an indication of an MTU issue. After doing a little bit of research I found, I need to decrease the MTU to make RDP work properly. Is it possible to reduce MTU of an L3 port to less than 1500?. Can i adjust my tcp-mss on the port where my xconnect is originated?

Thanks in advance guys..

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 2 (1 ratings)
swaroop.potdar Thu, 08/23/2007 - 10:16

No you cannot configure tcp mss on the xconnect interface, as if wont be in effect.

Since you have 76xx and 6524ME you can try and configure a higher MTU on the links between then rather than decreasing the MTU at the edges.



dinesh.thathana... Thu, 08/23/2007 - 23:28

Currently MTU is 1600 which should be good enough. Is it possible to configure MTU less than 1500 on Ethernet?.

Will compression on CE devices help?. Apart from tcp header compression, can a stacker be configured on ethernet l3 interface? Apart from RDP, Mail synchronization is a really big issue on an MPLS backbone.

swaroop.potdar Fri, 08/24/2007 - 05:40

When a higher MTU is configured, you should not be running into MTU problems, as the host devices would not be propogating frames larger than 1500.

Can you check from your end CE's whether a extended ping with DF bit set and a payload of 1500 goes through. If it doesnt that means there is some discrepancy in the MTU configuration for the MPLS core.

Also do verify if you have set the (config-if)#mtu 1600, as only the mpls mtu 1600 wont help.

Do get back after you check these points, so we can take it further.



dinesh.thathana... Fri, 08/24/2007 - 22:33

Customer LAN switches are configured with 1500 MTU. We have noticed packets more than 1272 is going through the CE Boxes. MPLS Core MTU is 1700 across. We have verified the "mpls forwarding-table x.x.x.x detail" and it shows the MRU of 1700 and 1704 for POP Labels.

I am planning to mirror ports on multiple sites to see the frame transmitted from Site-A and received at Site-B. Any suggestions/case studies where any customer faced application issues randomnly in MPLS network?.

Thanks for the support Swaroop. I am in touch with TAC too on this.

swaroop.potdar Sun, 08/26/2007 - 08:50

Dinesh, to confirm again, does it mean that you are able to transmit frames across with the DF bit set at 1500.



dinesh.thathana... Mon, 09/03/2007 - 21:35

I am back after a hectic week on this issue...I could find out something very interesting... At times of convergence, the new path takes sometime to calculate the MRU... Mean to say when you issue the command ping mpls pseudowire destn .. The new path has an MRU of 0 for some 5 seconds..After 5-6 seconds MRU comes back with 1700..This screws up the applications like mail synchronization etc.

Apart from this I found a lot of OSPF flapping due to aggresive BFD timers also, which creates issues with remote desktop. I am unable to convince myself on the MRU issue why it happens. IOS issues on 6524??

dinesh.thathana... Sat, 03/08/2008 - 07:02

Well the issue is related to MTU, but this is actually caused by link covergence where for a brief moment, the Maximum Receive Units for the TE Tunnels goes to zero. Seems like a BUG in IOS for 7600 SUP-720.


This Discussion