Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Users might experience few discrepancies in Search results. We are working on this on our side. We apologize for the inconvenience it may have caused.
New Member

CUCM - VCS-C - VCS-E - DNSZone call issue

Hi All,

We have Expressway-E Dual nic and Expressway-C

Traversal Zone between C and E on internal nic

E external nic in DMZ and Nat'ed to public IP

Calls from outside using SIP URI connects with both Audio and Video and have no issues however calls from inside to outside connect with no A\V

Initially I thought this was a firewall issue however all relevant ports and Nat are correct.

Attached call history for call and SIP logs from Expresway-E

 

Any Idea's on what to look at? At this point Ive gone through the eployment\admin and many google pages trying to get this working with no luck.

 

Thanks,

  
  
  
  
  
  
  
  
Everyone's tags (1)
23 REPLIES

is your traversal zone client

is your traversal zone client connecting to the Expressway E's NATed IP?  (ie. External address)

Please rate useful posts.
New Member

Hi George,The traversal zone

Hi George,

The traversal zone is connecting from Expressway-c to epressway-e on the internal nic Lan2

Expressway-E is configured with Dual nic

Lan2 - Internal

Lan 1 - External with static NAT

 

Thanks,

 

As odd as it seems, the Dual

As odd as it seems, the Dual NIC license is mostly to add the ability to Static NAT your public IP address. The issue you're getting with no audio/video is because the Expressway Core is talking to the internal IP of the Expressway Edge, yet when the Expressway Edge responds, it's not talking with that IP, it's talking with it's external IP address. 

Picture this, you're sending traffic from expressway-c (say IP 10.0.0.1) to expressway-e internal IP (say 10.0.1.1). The expressway-e is responding with it's Static NAT Address which is the Public IP (say 12.34.56.78). You send a signal to 10.0.1.1, and receive a response on 12.34.56.78.... Doesn't really go well.

Configure your Expressway Core to talk to the Expressway Edge using it's public IP and configure a Hairpin NAT on your firewall. It's funky, but it's actually how it's supposed to work. 

The purpose of LAN1 if you're doing the Dual NIC is only for clustering (as stated here: http://www.cisco.com/c/en/us/td/docs/telepresence/infrastructure/articles/vcs_benefits_placing_expressway_dmz_not_public_internet_kb_196.html) 

Wonky, but it's how it works. Done a few VCS deployments now (and yes, they're the exact same platform, just different features).

It's actually explained quite well here starting on page 59 (http://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_Basic_Configuration_Cisco_VCS_Control_with_Cisco_VCS_Expressway_Deployment_Guide_X7-1.pdf)

Regards,

 

-Tony

New Member

Sorry but that is incorrect

Sorry but that is incorrect.

You only need to point the VCS-C/Expressway-C at the public IP of a Static NAT VCS-E/Expressway-E when you are NOT doing dual interface. When doing dual interface, you point it at the actual IP of the E's LAN1 (inside).

If you continue past page 59 in your link to the example starting on page 64, you will see the example that correlates to Sean's environment. On page 65 we see this:

n VCS-E LAN1 has static NAT mode disabled

n VCS-E LAN2 has static NAT mode enabled with Static NAT address 64.100.0.10

n VCS-C has a traversal client zone pointing to 10.0.20.2 (LAN1 of the VCS-E)

 

Chad Marsh

Chad, out of curiosity, have

Chad, out of curiosity, have you got that kind of deployment to work? I am interested to hear if you do since I have not been able to get that work. I personally like doing what you mentioned above but I havent had much luck with it. TAC suggested the same thing that Tony mentioned.

Please rate useful posts.
New Member

Yes, at several customers,

Yes, at several customers, including one with clusters of both C & E at a large coffee company you've probably heard of.

When you actually do dual NIC, you must add static routes for your inside network range(s) pointing to the inside gateway via the command line, as there is (still) no way to input them through the GUI, which just baffles me...

For example if your E was 10.0.20.2 and your C and TMS were in 172.21.X.X you could do:

xConfiguration IP Route 1 Address: "172.16.0.0"
xConfiguration IP Route 1 PrefixLength: 12
xConfiguration IP Route 1 Gateway: "10.0.20.1"
xConfiguration IP Route 1 Interface: LAN1
 

 

I had done that same thing

I had done that same thing with version 7.0 and didnt work. Time to try it again. :) Thanks Chad.

Please rate useful posts.
New Member

Can anyone sheed some more

Can anyone sheed some more light on how to get this working? or what to look at?

I have tried everything I can think of but still stuck with no video from inside to outside.

 

Thanks,
 

New Member

I'm trying to get this to

I'm trying to get this to work with a single nic expressway e server, but get no media. Is that the same as your setup, or do you need dual nic?

New Member

Thanks for all the input thus

Thanks for all the input thus far!

I have tried with a static route pointing and the best I can get is 2 way audio and no video (from inside to outside)

ouside to inside works fine.

I have tried this on version 8.1 and 8.2 (In Beta)

Chad, the configuration you

Chad, the configuration you mentioned above, does it work for environments with Dual NIC or Single NIC?

For eg. If i have VCSC as 10.0.0.10, and VCSE with LAN2 as 10.0.0.11 and LAN1 as 172.16.0.1 (DMZ address), how will the routes look?

Please rate useful posts.
New Member

I would change your scenario

I would change your scenario a little since typically you would not have your VCSE inside interface in the same network as your VCSC.

So let's go with this:

VCSE has two physical interfaces configured and connected in two different DMZ subnets. DMZ-Ext is 172.16.10.0/24 and firewall is .1
DMZ-Int is 10.30.10.0/24 and firewall is .1
FW-inside is 10.250.10.0/29, L3 switch is .1, FW is .4
FW-external is some public IP range, but is NAT'ing 204.104.100.25 to 172.16.10.10 from Outside to DMZ-ext.
Inside network with VCSC, TMS, etc is 192.168.10.0/24, .1 is L3 core switch

VCSE LAN2 (outside facing) IP 172.16.10.10 (NAT IP 204.104.100.25)
VCSE LAN1 (inside facing) IP 10.30.10.10
VCSE Gateway IP is External FW interface 172.16.10.1
VCSE CLI will need static route pointing 192.168.10.0 /24 to GW 10.30.10.1

VCSC LAN1 is 192.168.10.10 with GW .1 (L3 switch)

L3 switch and FW either exchange route info or have static routes for required networks.

 

-Chad

Gotcha, so the dual NIC can

Gotcha, so the dual NIC can only be used if your VCSE LAN1 and LAN2 are in different subnets than your VCSC. If you have a VCSE in the DMZ, you will need to use the firewall u-turn methodolgy, correct?

Please rate useful posts.
New Member

"so the dual NIC can only be

"so the dual NIC can only be used if your VCSE LAN1 and LAN2 are in different subnets than your VCSC"

No, I'm not saying that, but most designs would still have a firewall between the VCSE inside interface and the VCSC, so they are usually in different subnets.

 

Chad

Grammatically it may not be

Grammatically it may not be correct based on the documentation - but it's still not only a successful, but a supported method. And I probably should've phrased a few things different - the Dual NIC isn't JUST for clustering, but it's probably it's best use if you configure it how I mentioned above.
Ironic that TAC suggests it as well.

Sean, have you tried adding the static route as mentioned on page 65? Not sure if your Internal/DMZ Firewall is NAT'ing or not. So it may or may not apply.

Regards,

 

-Tony

New Member

I guess I can't say I'm

I guess I can't say I'm surprised that TAC would give that kind of advice, but although it would work, you are essential still doing single interface and routing on a stick, while your LAN1 becomes just a private failover link I guess?

In most cases where I have done dual-NIC, it is because the environment requires it, such as when there is an internal and an external DMZ, and no traffic is allowed to route between them (e.g.: web server farm).

 

-Chad

Ok, that needs to be changed

Ok, that needs to be changed to the external IP that is assigned to NIC2. Also the expressway c should be able to ping this public IP.
Please rate useful posts.
New Member

Thanks George, but then whats

Thanks George, but then whats the point in Dual nic if Expressway-C have to connect to the public IP of Expressway-E for the traversal zone? If I was using a single NIC on the expressway-E then I agree I would need to point to the external IP

I thought the traffic flows were CUCM -> Expressway-C - Traversal Zone -> Expressway-E internal -> expressway-E External - > Public

and

Public -> expressway-E External -> Expressway-E Internal -> traversal zone -> Expressway-C - CUCM

where the traversal zone is connected on the internal nic's

We have a multi port ASA seperating the DMZ, Public and internal networks so I cant reach the public IP of expressway without NAT relection configured on the ASA. The deployment guides I have seen advise using the internal nics for traversal to avoid having to configure NAT reflection.

 

Thanks,

In theory, correct. However I

In theory, correct. However I havent able to get it to work that way. Will see if one of the other experts respond as well. If you do get it to work, please post back here since that would make the configuration much easier. If you look at the SDP, the media address is 93.93.103.3 which I assume is your Public NAT Ip and since the internal IP cant reach it, you get no media. 

Please rate useful posts.
New Member

Maybe this:

Maybe this:?

CSCum90139

Symptoms: Expressway X8.1 uses the Ethernet 2 IP address for the media part in SDP rather than the configured Static NAT IP address. This results in calls failing on the media part.

Conditions: Running Expressway X8.1 with Static NAT and encryption B2BUA enabled (a media encryption policy other than Auto).

Workaround: Recommended configuration for Expressway-C with Expressway-E deployments is to configure the same media encryption policy setting on the traversal client zone on Expressway-C, the traversal server zone on Expressway-E, and every zone on Expressway-E, and to only use static NAT on the Expressway-E. With this configuration the encryption B2BUA will only be enabled on the Expressway-C.

New Member

Thanks Chad.I was running 8.1

Thanks Chad.

I was running 8.1 but as I am testing Jabber Guest as well We are on X8.2  now.

Suprisingly changing the encryption has made a differance, calls now work but are audio only in both directions.

Where as before from outside to inside we got A/V and inside to outside nothing we now have Audio in both directions but no video - sort of a step in the right direction.

I am still testing differant scenarios with the zones and encrytion.

New Member

X8.2? I don't see that posted

X8.2? I don't see that posted yet, or are you Cisco internal? I'd be curious if it shows that bug resolved in X8.2, as that currently hampers VCS/Expressway design choices with WXeTP.

New Member

Hi Chad,Its not posted yet, I

Hi Chad,

Its not posted yet, I am running the Jabber Guest trial

https://communities.cisco.com/community/technology/collaboration/usergroups/collaboration/cisco_jabberc

Anyway I am back to having A\V from outside and only Audio from Inside

Certainly making progress

983
Views
0
Helpful
23
Replies
CreatePlease to create content