Capturing Traffic from remote sites?


#1

Trying to understand all my options for getting data from remote sites to EH. Assuming we have many small sites all interconnected via high speed WAN and only a single EH v6 at HQ. As I understand it, we have the following options to capture traffic at the remote sites and deliver to EH at HQ.

Span (local only)
Tap (local only)
RSPAN (local L2 only)
ERSPAN (Remote via GRE, but Cisco proprietary - sites are mostly Juniper)
NetFlow (Remote)
RPCAP (Local or Remote but seems intrusive and difficult to implement/manage)

And of course the favorite method for EH sales reps, buy an EH for every site! :slight_smile:

Am I missing anything? Curious how others have solved this dilemma?


#2

Some of the Spanagg vendors (e.g. Gigamon) have the ability to capture traffic with a remotely placed box, and then “tunnel” back to a central data center. Not sure if this methodology would work great for you as it would require spanagg hardware at BOTH the remote site AND at the central data center.


#3

my personal opinion:

  • choose local when available
  • choose remote when you really really have to
  • if there’s/are a necessities to use remote, then consider to place the EH at the most close to the remote point.

I really do the EH recommendations are the best practices

if using remote, I think you’ll have other factor to consider for example network b/w and throughput, the size of data being mirrored, how will the data being mirrored impact your business services, etc…


#4

I’ve run across some companies that are looking into these: GigaVUE-VM I have no idea how well they work but it’s a promising alternative to VMWare ERSPAN which has been sub-optimal for many.

You might want to add these to the list.


#5

@dkraut -

Sending full-packets mirror traffic from the remote site to the datacenter across a small WAN link may not be necessary for what you’re looking to accomplish.

For instance, on your datacenter Extrahop, you can create a Custom Device to represent your branch office. This will aggregate all the activity between the datacenter and the branch office onto a single object (the Custom Device), which you can then use in Dashboards, assign Alerts and Triggers to, etc.

This approach is useful when you need to compare end user experience across all your remote locations on a single dashboard.

If you have hundreds of branch offices, you can use this Extrahop Helper Chrome Extension to create the Custom Devices for you by pasting in the CIDR block match criteria from a spreadsheet.

Where I see your question coming up most frequently is when you’re looking to analyze branch office traffic that doesn’t already touch the datacenter (i.e. Branch A talks to Branch B, or devices within Branch A talk to each other).

@dkraut - can you clarify what kind of visibility you’re looking to get for your branch offices?


#6

Hi lipsum,

We’re mostly interested in Discovery and Application Dependency Mapping. For example, we know from interviewing app owners that “Example-App” is comprised of ServerA, ServerB and ServerC, but how do we know that for sure? The only way to prove this is to use ExtraHop to verify who ServerA, ServerB and ServerC are communicating with on a daily basis. For a small app in a single data center, this is easy, but where it gets tricky is with larger apps that may be spread across multiple locations. I think this boils down to how to efficiently capture traffic (both physical and virtual) from remote locations and send it back to ExtraHop so you have a holistic view of your network. Unfortunately, not every company has the ability to install an ExtraHop device at each location and playing the shell game with virtual EH is painful and has many downsides. Thanks!


#7

dkraut -

In this case, NetFlow is probably your friend. The EH Solutions Architecture team does a lot of app dependency mapping for our customers, and NetFlow is our go-to when direct access to the traffic isn’t feasible.

Hope that helps…