Showing results for 
Search instead for 
Did you mean: 

Best practices for segregating remote site traffic


We have a central site running a pair of 9500s as our network core. We have 30+ remote sites, mostly running a pair of 4500Xs. Each of the networks at the remote sites needs to get to the central site for server and internet access, but for the most part they don't need to connect directly with each other. The exceptions would be specialized vendor subnets, like HVAC and Security, who do occasionally directly connect to their equipment at other sites from a given remote site.

Connectivity between central and remote sites is through AT&T ASE on Demand product. We are currently using EIGRP to exchange routes.

I have been given the task to come up with a solution to prevent remote sites from communicating, except for the HVAC and Security VLANs at each site, if possible.

We do not currently have a NAC solution, such as Cisco ISE, but will consider it. Besides this, what is our best solution?

3 Replies 3

try this in Lab 
config the DMVPN, 
config two tunnel,

first tunnel in Hub config with next-hop eigrp self <- this force all traffic to pass to Hub
second tunnel in Hub config with no next-hop eigrp self <- this can support Spoke-Spoke connection 

split the subnet behind Spoke advertise one part through tunnel 1 and other through tunnel 2.

Seb Rupik

Hi there,

Without changing the topology you could look at route-maps and EIGRP distribute-lists. Assuming your sites IP addressing is easily summarised and contiguous, then you should be able configure ACLs at the remote sites to match the IP address summaries of the other remote sites, then use an inbound distribute-list to filter those subnets out. This means that remote sites can still exchange routes with the central site but their routes would not be visible to other remote sites therefore preventing communication.


If your subnetting at the remote sites is a little more chaotic then again you could use the eigrp default-route-tag command applied at each remote site with a unique ID to tag these internal routes. Then at the central site you could use outbound distribution lists applied to the interfaces connecting to the remote sites which would filter out the other remote site tags.





Thank you for the replies... Once I take care of the routes directly from one site to another, won't I need an ACL at the central site. Otherwise, couldn't site reach each other just by going through the central site?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: