Transport Gateway HTTP versus Email

[tylerpalmer]

Which mode is generally preferred for the Transport Gateway: HTTP or email? Are there advantages to using one mode over the other?

I seem to remember talking with someone from Cisco about this and remember that they had some good arguments for which mode was preferred, but I just can't remember the content of that discussion

[tylerpalmer]

Nevermind. Found the answer to that one in the Deployment Guide:

"HTTPS direct is the Cisco recommended and most commonly used method."

[Lawrence Searcy · Accepted solution]

We need to separate out the whether we are talking about traffic from the end device (router, switch, UCS) to the transport gateway or traffic from the transport gateway to Cisco Smart Call Home backend or the end device directly to Cisco's Smart Call Home backend.

The transport gateway is essentially a proxy server for your end devices so that the end devices themselves do not have to talk across the internet. Any network engineer worth their salt will block traffic generated by their infrastructure devices (routers, switches) to the internet for security reasons. The only exceptions I might consider would be firewalls that sit at the boundary between the internal network and the internet. I might allow those to communicate directly with the Cisco Smart Call Home backend via HTTPS. But I probably would prefer they talk to the Transport gateway and allow only the transport gateway to talk across the internet to the Cisco Smart Call Home backend so you can track outbound communications easier.

For the traffic from end devices to the transport gateway, I recommend HTTPS. The drawback is It is more complicated to setup with the certificate. This would encrypt the traffic between the end device and the transport gateway. Or we can assume that the internal network is safe from eavesdropping. In that case, any method (http, email, https) to the transport gateway is fine. I don't like to make that kind of assumption.

When would I use email? Well, some devices like the UCS can only do email so there is no other choice. The UCS can send email to the transport gateway's email account and the transport gateway can download it. Unfortunately, the end devices only do simple SMTP on port 25 which is sent in the clear (unencrypted) from the end device to the email server.

For the traffic from the transport gateway to the Smart Call Home backend, the transport gateway always encrypts it via HTTPS to send to Cisco's Smart Call Home backend.

So you might ask, "Can the end device send *email* to Cisco's Smart Call Home backend directly?" Yes, but this is not recommended because it is sent in the clear (unencrypted) across the internet.

You also might ask, "What about anonymous Smart Call Home?" Well, in that case, the customer does not have a smartnet contract and is helping Cisco by reporting crashes on their end device (Like Windows error reporting and Apple Error Reporting). The end device will automatically setup and make an HTTPS connection directly to Cisco's Smart Call Home backend when it reports an error.

Cisco is transitioning the software to having the customers turn on anonymous Smart Call Home for easy HTTPS setup and then configuring registered Call Home. This completely removes the certificate setup by the end user.

[Lawrence Searcy · Accepted solution]

I forgot to add that another reason to do email from the end device to the transport gateway is that all messages sent from the end device can also be sent to a NOC email alias for processing by the NOC. It allows the NOC to monitor all email communication from the internal infrastructure devices to Cisco's Smart Call Home backend and receive all error messages including error messages that might not automatically open TAC cases. These emails are considered "unprocessed" emails.

Once the information is received by Cisco's Smart Call Home backend, notification emails are sent after Smart Call Home analysis to the configured notification list for the end device and TAC cases are automatically opened if the error sent in by the end device is configured in the Smart Call Home backend rules to do so.

I should add that the unprocessed emails to the NOC are not really necessary since all error messages received by Cisco's Smart Call Home backend will generate a notification email that can be sent to a NOC email alias. Having the NOC receive unprocessed emails would just allow for monitoring communications with Cisco's Smart Call Home backend. But I guess if the issue that generated the error message prevents communication between the transport gateway and Cisco's Smart Call Home backend, then receiving that email might be helpful to the NOC.

Message was edited by: Lawrence Searcy

[tylerpalmer]

Lots of good info here. Thanks, Lawrence.