Configuring multiple VRFs on a 9500 pair to segregate remote sites

[spfister336]

We have multiple remote locations connecting to a central site which has a pair of 9500s. In between the remote sites and the central sites is AT&T's ASE switched Ethernet service. I need to come up with a solution to keep the remote sites from reaching each other. I thought of using a separate VRF instance for each site, but I wasn't sure if this is a scalable solution (we currently have 30-40 remote sites). In addition to the Internet connection for all remote sites being at the central site, there are several other resources the remote sites will need access to (e.g., servers in a virtual data center). Am I on the right track here? 

[Flavio Miranda]

Hi

 You are.  The limitation you need to look is:

●     ASIC tables for switching scale up to 256K MAC addresses and routing scale up to 2M routes.

 The number of VRF is not the problem but the routing can be.

Now, for internet access and shared  resources, you need to work with routing leak between VRF or VRF and Global Routing table.

[balaji.bandi]

if the Delivery is 1G bearer then that should be ok to terminate on Cat 9500, if this is less than 10-100MB you may see some issue on the interface level. how about other ends remote site ?

you can call as WAN Edge Access switch, all Layer 2 will terminate here. will all remote sites use the Internet from the central Site Internet Pipe

then you need to look decent Firewall with next-gen firewall features Like IPS and content filtering (on the Perimeter side)

When you mentioned DC firewall you may need some Firewall DC network to protect the services.

example one I copied from cisco Live ;

[Seb Rupik]

Hi there,

Use of VRFs and route leaking between them could grow into a painful admin overhead. Your switched Ethernet service should provide you with a q-in-q capability, this means a tagged packet from a remote site could arrive at the central site and retain the same VLAN ID. This could be switched on the 9500 towards a firewall Layer 3 sub-interface. The firewall would provide ACLs to control inter-site communication and also permit access to the central and internet based services.

Ideally you would want to police the inter-site traffic before it left the remote site as this would save WAN bandwidth, but would require careful curation of 40+ ACLs on 40+ different devices. Granted this could be automated, but using a single firewall at the central location mitigates this.

cheers,

Seb.

[spfister336]

Yes, I was worried that the VRF idea would be hard to maintain. I was hoping for a simpler solution, but I think some people here are trying to push the VRF solution. 

Wouldn't an ACL on the central site stop inter-site traffic? Each site's routes are summarized down to 4, and it's really one of those 4 that we're really interested in restricting.

[Seb Rupik]

Agreed, ACLs at the central site would be the simplest solution but placing those ACLs at the remote site WAN links would be best.

cheers,

Seb.

[spfister336]

I'm not sure I understand why separate ACLs on the remote site end would be better than 1 at the central site

[spfister336]

One point I just though of... there really isn't much site-to-site traffic currently. The issue driving this is the concern to prevent malware spreading from one remote site to others.

[Seb Rupik]

What's to say your central services don't become a focal point of infection and circumvent any ACLs you have in place. Perhaps having a central firewall which acts as the routing hub for all of the WAN sites is the best option. Something like a Palo Alto excels in this position.

cheers,

Seb.