Web Client 4.5/WIN2003 SP1. Multicast send is slow to non existent 2

[JackOldham]

I have gone over the manuals and seems all settings are fine. We have a correct multicast send and receive address.
I see Multicast coming in to the web server at a normal continuous rate but nothing on the send except every once in a while I will get a burst. 10 minutes or so.(no pattern). Launch agent displays and it hangs for up to ten minutes befor it launches then there in no realtime updates. Client can't launch Rtd. Get the old server unavail or no agents logged in and set for multicast. I do have an agent logged in and see its info coming into the server. All this testing is on the same subnet. Should I not see at least info every 5 seconds, as set in the RTD properties in the server?

 

[rfwhite]

Try modifying the TTL number in your Symposium server using the RSMConfig utility. Ours was 2 and changing it to 6 made ours start working. As I recall you'll need to restart SDP and RSM and that will probably "blow" the current real time displays anyone has running on classic client (and the 24 hour cums if someone is collecting them) so you may want to do it in the wee hours because you'll probably end up restarting IS service as well.

 

[mte0910]

First, check the Multi-Cast Stream Control and be sure that you are sending the reports you want sent. Leave this window open.
Second, check the Multi-Cast Address and Port Configuration. I use a TTL (effectively the hop count) of 64. I am using a Rate of 2000 (2 secs.) on all of the reports I send.
Third, to apply any changes, do the following; click Apply and the OK on the Multi-Cast Address and Port Configuration window, then click Apply and OK on the Multi-Cast Stream Control window.
Fourth, restart the SDP_Service (Statistical Data Propagator), which will restart the IS_Service as well.

 

[JackOldham]

Thankyou rfwhite and mte0910.
I will try these settings tomorrow evening. My TTL is set at 64. I will double check both servers. I wasn't aware of restarting the SDP service after these changes. I'll let you know my findings.

 

[mte0910]

Also, any changes you make, you have to hit the apply button in the Multi-Cast Stream Control window. Nortel doesn't document it well, but changes made in the Address and Port Config are not posted to the Registry unless you hit the apply button in the Stream Control window. That sends the new data to the registry, but you have to reset the SDP (and IS) for the changes to take effect.
This is not horriably service interrupting, I have done it a number of times in the middle of the day when I needed to get something in right then.
Have you used the icertdTrace to track what is leaving your SCCS and what is arriving at your SWC? You can also use it to see what is getting out to the desktops.
On the Network side, we had a lot of issues with IGMP Snooping. Even now, when things get a little screwy, we toggle it on and then back off.

 

[JackOldham]

Well Guess what? I set my IPSend on the Web Client to 7 seconds from 5 and set up the Symposium for 2 from 5 and TTL from 64 to 6. I dissabled some reports like nodal and routes, but did not restart the SDP yet. Started the send trace on WC and every 7 seconds I got multicast. I can now get RTD and ADD. I will restart the SCCS SDP on the weekend.
Thanks for your helpful insights as they all played a part in solving this issue. As per the norm, Nortel plug and play and play and play.

 

[rfwhite]

Or at least in some cases Nortel + Windoze = Plug 'n' pray.
I just finished a 2nd installation of WC. 1st & 2nd Symposium servers appear to be identical- hardware, patches, etc. WC servers are identical, new. Same installation procedures, same TTL and other settings. First one is working like a peach. 2nd one doesn't want to make RTD no how, no way.
I'm still juggling settings on timers but it's a live call center with moderately high traffic so it's a drawn out process...changing/resetting almost anything causes a RTD (Classic Client) reset on the 24 hour cumulative stats and makes the center manager and supervisors 'freak out'.
Even though our network guy says the routers are configured identically at the two centers it's beginning to smell like a network issue. I'm still running some ICE traces but just checking to see if anyone has thoughts or suggestions.

 

[mte0910]

If you are familiar with ICERTDTrace, you can at least figure out where it is dying.
I get tired of typing I-C-E-R-T-D-T-r-a-c-e, and then the switches, so I generally change the .exe name to trace.exe.
you can place it on any machine, so I like to put it on the SCCS, the SWC, and a couple of clients in select spots as it relates to the various VLANs I am going through/to.
This was you can see the traffic leave the SCCS, arrive at the SWC, leave the SWC, and arrive at the workstation.
Simple, but it works.
Most every problem I have had with RTD related back to the network. IGMP Snooping was almost always to blame.

 

[JackOldham]

Better yet, to launch icertdtrace, create a shortcut of it to your desk top. Right click the shortcut, click properties and in the target box after the icertdtrace.exe" enter the switches (-? ipsend)
icertdtrace.exe" -s ipsend

It will launch just nicely with no paths to put in or any command. ( I think I forgot the -? switch. Don't have my book with me tonight.)