VCS ExpressWay and Control on Different Versions

[Mark H]

Hi everyone,

Can the VCS ExpressWay run on a newer version then the VCS Control?

Currently we have a VCS ExpressWay and a VCS Control appliance running X6.1. I am planning to upgrade them to X7.2.1 and will temporarily have the ExpressWay running the new version with the control running the old version.

I can't see any documentation that says this can't be completed. Especially since X7.2.1 has had interop testing completed with X6.x.

Mark

[Nick Halbert-Lillyman]

While I can understand that new features wouldn't be available unless all VCS-Cs and VCS-Es are on X8.1, I would have hoped we could upgrade our VCS-Es and keep existing functionality without having to get external organisations to upgrade their VCS-Cs at the same time.

[Martin Koch]

Yes, I also see the need of having a backwards compatibility for traversal zones!

Please remember to rate helpful responses and identify helpful or correct answers.

[Alok Jaiswal]

Wayne,

unfortunately the traversal zone is not backward  compatible, because the media multiplexing ports utilized for x7.x and x8.1  version has been changed.

so if you don't upgrade the VCS-C and VCS-E pair at the same time then media issues will occur.

this is only true for your orgnization, if some other organization is still running on x7.x version and yours is x8.1 it won't create any problem.

regards

Alok

[Nick Halbert-Lillyman]

Alok,

Not sure what you mean here - you say it will work to other organisations, but that traversal zones are incompatible between X7.x and X8.x?

Both Wayne and myself (and I imagine many more customers) have traversal zones to other organisations, so if we were to upgrade our VCS-C/VCS-E, the other organisation's VCS would need to be upgraded as well or the traversal zone to the other organisation wouldn't work.  I've seen this deployment a few times, it's probably more common than you think and I suspect there will be quite a few customers in a similar position.

[Wayne DeNardi]

Thanks for echoing my concerns Nick.  I'm still as confused as before.

In one sentence Alok's saying that traversal zones don't work if mismatched between X7.x and X8.1, then in the next paragraph says that the other organisation can be running a different version without a problem...

Alok, as Nick and I have both indicated, we have traversal zones to these other organisations - if one organisation, or the other, upgrades to X8.1 then, as there's now a mismatch of versions, will it break or not?  Is it only broken for traversal zones between Cs and Es, or between Es and other Es as well?

If, as you're indicating, that all VCS devices everywhere must be upgraded to X8.1 at the same time, this will be a hell of a job requiring dozens of VCS-Cs and Es throughout multiple organisations to be done simultaneously - that'll be a scheduling and approvals nightmare!

There has to be a simpler way!

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.

[Alok Jaiswal]

Wayne,

sorry for the confusion. now i got what you actually mean by traversal to other organization.

if you have traversal zone to other organizations then yes all the servers has to be upgraded to x8.1 simultaneously.

i don't think  there is a workaround for it, because it by default chooses the demultiplexing ports in the range of 50000.

Regds

Alok

[Martin Koch]

But to be honest, shouldn't that be part of the negotiation of ports, is that hard coded in the traversal protocol?

Thought its just using sip and h460 and assent which could negotiate the ports.

Sure new ports would require a new firewall opening.

And why the hack was it changed anyhow we clearly see the downside: backward compatibility issues, what the benefit of the port change?

I see multiple reasons to keep a mixed environment:

* service provider environment offering traversal zones as a service (like mentioned here)

* need to have different software versions (like if you require provisioning with opends, as this does not exist on >X8)

* huge enviroments with dozens of VCSs, especially with cross linked traversal zones

* dont be dependent on a specfic version. Just picture there is a critical bug or some other issue comes up in VCS-E X8.1 and you need to revert, ...

* ...

That the new provisioning is mandatory is one thing but also require all to be upgraded at the same time, ... dont you think that these things would better have been separated?

How is it, does the oposite way work proper, VCS-C on X8.1 and VCS-E on X7.2.2 or is that also limited?

Wayne: I guess what was referred there is that your DNS and Neighbor zones will work fine to "other (external) organizations"

Please remember to rate helpful responses and identify helpful or correct answers.

[Wayne DeNardi · Accepted solution]

Wayne: I guess what was referred there is that your DNS and Neighbor zones will work fine to "other (external) organizations" 

Yes, for a completely seperate external agency, that's correct.  My point was probably phrased badly - I was referring to another agency that was connected to via a traversal zone from my VCS-E.

I've raised this issue with my local Cisco office and Account Representative, as they're actively trying to get my upstream company's VCSes upgrade to X8.1 for the added features - but if that will break my group of devices, and others that also traverse to them, they'll need to reconsider doing that until an adequate workaround to this issue can be found.

I'd really hoped that the upgrade would be similar to all the previous versions, where an upgraded box would continue to work on the older port ranges until specifically changed by the administrator, but any new box would have the new range by default (but could be changed to match any other connected devices).  And the release notes do say that the traversal media ports do work this way.

So, the big issue then must be with the demuxing ports on the Expressway which are now "using the first set of ports from the general range of traversal media ports" (50000 and 500001 on an upgraded VCS) rather than 2776 and 2777.  Couldn't we have an "Enable legacy demux mode" setting added in to the software to enable us to keep backwards compatibility with the older versions and still use the original 2776 and 2777 ports in this mode, or default the "Upgraded" versions to this?  Or give us the ability to manually change the demux ports/port range?

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.

Edit: Points added to everyone who agrees this is a major issue!

[AFRLHQVTC AFRLHQVTC · Accepted solution]

We are very concerned with the negative impacts of this as well.  We  already run a tighter range of ports then the default 50000-54999 and  have multiple VCS pairs across the country and are neighbored with other  VCS that we do not own and cannot force to upgrade.  All of our  scattered VCS installations utilitze different approving authorities and  management to implement firewall rules as well so a change in that port  range is not very easy or quick to get passed.   

There is also a new vulnerability that was announced and the only solution is to upgrade to x8.1.

For those of you that havent read it yet:

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140122-vcs

So  I think everyone would benefit if Cisco would release a maintenance  version x8.1.xxx and include some type of backwards compatibility. 

[Martin Koch]

Yes, I fully agree with you!

What I did not is to send a feature request with a high critical level to my Cisco contact.

In general I would like to see two things:

* Have a fix for the mentioned bug in the X7.2 tree as well

* have a backwards compatibility of the traversal zone

Please remember to rate helpful responses and identify helpful or correct answers.

[Chris Swinney]

Hi all,

This is obviously causing some heartache but it would appear that no one has actually test this configuration and is relying on Cisco's say so that this won't work (and what do they know, right???). So, being the nice kinda of guy that I am, and having a test VCS-E and VCS-C that are both capable of being updated if need to x8.1, I thought I would give this a shot.

So the VCS-E and VCS-C are both on x.7.2.2. A traversal zone exists between the two and is functional both for SIP and H.323. I then upgraded the VCS-E to x8.1. With no major other configuration change (other than to set the fall-back protocol on the DNS zone to TCP rather than UDP as UDP is switch off for SIP - the VCS-E moaned about this), I checked the zone peering. Both the H.323 and SIP where active.

We have a test MXP 6000 that is registered to the VCS-C (x.7.2.2). We also have a production environment with a separate VCS-E and VCS-C. We can place a call from the production environment to the MXP and from the MXP to the production environment with now issue and with video in both directions: such that:

MXP 6000 (h.323) --> VCS-C (x7.2.2) --> VCS-E (x8.1) -->   (Internet) --> VCS -E (x7.2.2) --> VCS-C (x.7.2.2) --> Jabber (SIP)

And vice versa

Initially, the I didn't get video to the Jabber client, but disconnected  and reconnected and all was OK. I have seen this issue many, many times  with Jabber in a normal environment, so I do not think this is anything  specific to this test. I have also tried dialling in via the VCS-E (x8.1) from a pure H.323 MCU with no issues. 

I haven't run exhaustive or very through test as yet, but rather this was a quick look see. I will check out a pure SIP call and things like dual video, but I don't now expect that there will be an issue.

So the question is, why are Cisco saying to us all that this isn't going to work???

Regards

Chris

[Nick Halbert-Lillyman]

Good on you for testing Chris.  With the changes to the way port ranges work, I imagine there could possibly be issues with multiple calls of the same protocol being run at the same time in this setup (although that could also be fine).

[Chris Swinney]

I have just read elsewhere (https://supportforums.cisco.com/message/4157547) that others have tested and found issues, so I  would like to dig into this deeper to understand what is causeing the  issue - is it the Traversal zone on the VCS's, or is it an intermediary  firewall/security device?

Chris

[Chad Patterson]

It is fine for you to have your VCS's running on 7.2.2 and 8.1. The only issue you may run into is the changed media port ranges and a few other port changes. I do not think the documentation states that connected VCS systems must be on the same version of code for it to work properly. It is probably a recomendation as you will then get the most functionality out of the system by having them on x8.1, but not a requirement.

If you are having issues on your VCS control and expressway and they are on 2 different versions of code, it is very likely that you are just having an issue with a firewall between the systems not being updated to use to correct ports. I see this happen all the time.

[Chris Swinney]

Hi Chad,

Chad Patterson wrote:
It is fine for you to have your VCS's running on 7.2.2 and 8.1. The only issue you may run into is the changed media port ranges and a few other port changes. I do not think the documentation states that connected VCS systems must be on the same version of code for it to work properly. It is probably a recomendation as you will then get the most functionality out of the system by having them on x8.1, but not a requirement.

I think you might have missed the whole point of this thread! The documentation does indeed state that when upgrading to x8.1, then you need the equivalent VCS also to be on x8.1. Previous documentation stated that the equivalent VCS could be on a version from x5 (I think). Did you read the concerns people are voicing?

I can understand if people have very restrictive firewall rule in place, however, we rely on established connection outbound and have no specific inbound rules in place. This mean that that as long as the VCS-C can connect to the VCS-E, the the established connection on the traversal zone will build the media paths to the multiplex port on the VCS-E. You should therefore only need to ensure that a very few number of ports (5 or 6) are open OUTBOUND from the VCS-C to VCS-E.

Cheers,

Chris