I need to exchange ideas, regarding a solution that I need to come up with.
First I will define the current setup has been done on our core network.
We have VSS 6500 cores swtiches as a primary core switches, and this vss cores are connected with server-farm switches and access layer switches as typical a campus network and then we also have about 20 or so, remote fibre connections connecting to our vss-core switches (i.e. connecting as trunks) to some remote access-switches used by third-parties from remote-locations to access resource at our organisation via the vss-cores.
Now our management want to tighten the belt and close security holes as much as possible.
For this solution I cannot use private-vlan to isolate remote-switche's traffic, as these connections are trunks, and there is no such a thing as private-trunks and so I abandon private-vlan notion.
Then I was thinking of introducing an ASA firewall, through which all remote-fibre access-switches must traverse via this ASA.
As you know, ASA cannot accommodate that many fiber ports and since this solution is a cleanup-job, (in a sense, I need to fix someone else mess, which was previously done). Beside our company do not wish to deploy a new Nexus switch (since Nexus become an expensive clean-up), just to connect those remote fiber connection to isolate from vss-core.
A last option I was thinking of, to introduce VRF-Lite on VSS-Cores, in a way which all truck ports from remote-switches will be part of a VRF instance along with an ASA’s outside interface which will be dot1q trunks as well for all given required internal vlans traverse via the outside to inside interface (possibly trunk as well), and this ASA’s inside interface will be part of the global routing instance same as on VSS-Core, so that remote-switches vlans will be monitored and will have restricted or control access.
Please share your thoughts and all inputs will be greatly appreciated and rated and please see a diagram attached.
Well, remote users at remote-sites are not part of our organization and yet we are providing access to some resources, via our vss-core.
The security concerns is being that switches at remote-sites can be accessed by building management or anyone who has access to wiring-closets could connect a PC and be on our network and it is major privacy concern should anyone tap the wire to access private and confidential data.
We are liable for breach of privacy and last but not least is that remote-users become nuisance to our organization and how we manage and run our own business and how we manage our change-management activites and it become virtual impossible as they need access to our resources and our network-service personnel time and time again engaged in problem shooting those remote connections and application uses.
Early network team has not put much thoughts when establish connection to our network from remote-switches and it is my problem to find a solution to secure the connection and provide limited access as possible.
Thanks for the explanations. Now, I understand your situation better. If the SVIs for the remote locations terminate at the VSS, how about adding a set of firewall service modules to the VSS pair and have the SVIs terminate as outside connections and then apply security policies to allow communication with inside connections of the firewall?
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...