Design advice and guidance for merging/interconnecting two separate company networks
looking for some design advice/guidance.
our company has recently merged for want of a better word (perhaps not quite as straightforward as a merger as the 2 companies will remain separate entities - for the time being at least - but there will be a need for some interconnecting to each other's systems)
Now, at the moment detailed requirements (e.g. what systems will need accessed, how many people, etc) are very vague and there is a lot of politics involved. However, at some stage we are going to be asked to provide some connectivity between the 2 company networks and I want to ensure that we are as prepared as possible to do this (usually once the politics are out of the way, its a case of "we want this and we want it by yesterday!")
Our network is a hub and spoke type model with remote branches having ADSL connections and connecting into head office over IPSEC VPN connections, terminating on our head office ASA. All our networking kit is Cisco.
We don't know details of the other company's network but they will have a similar estate with remote branches connecting into their head office (from what I can understand, they use consumer grade routers such as Netgear and I think their remote connectivity is via SSL VPNs but I don't have any of that confirmed. I also suspect their network connectivity is provided by a managed services provider whereas ours is largely installed, configured and managed in-house)
I'm looking for advice and guidance on what considerations need to be made in setting-up interconnectivity between the networks and thoughts on the best way of achieving it (albeit with admittedly vague requirements at present!)
So far, I have these questions for our counterparts:
What vendor do they use? (e.g. Cisco)
What type of equipment do they have? (firewalls, routers, switches etc)
How are their sites interconnected? (e.g. MPLS, IPSEC VPN, SSL VPN)
Do they run any routing protocols?
What capacity is their main office internet connection and do they know what sort of utilisation levels they have on it?
What private address ranges do they use? (this might be the biggest headache if there are any overlaps)
We also need to consider what degree of "trust" we can give to their network (for example, how do we know they are not riddled with security flaws, viruses, etc - and I guess they may well be thinking the same of us) Any suggestions on how we can resonably gain confidence on the trustworthiness of the network we would be connecting to? Or what we can put in place to minimise the risk of any vulnerabilities they might have on their network? (Baring in mind this is a very politically sensitive situation as there is naturally a fear factor between the IT Depts of 2 companies who join together!)
To my mind, IPSEC VPN connection between the 2 head offices would be the most realistic option? Their branches will need to conect to our head office resources too - but they could just route them through their head office connection over to us? (i.e. we wouldn't have to set-up a site-to-site VPN connection for each individual branch as that would add some considerable overhead)
Any thoughts, advice, guidance etc from anyone who has been through similar or carried out such projects in the past would be most appreciated.
Design advice and guidance for merging/interconnecting two separ
the questions you are asking are correct ones.
I agree with VMiller that the IP addressing should be sorted out (sooner rather than later) to see if there are any conflicts and that firewalls should be setup on both sides of a WAN link. Since we are the ones acquiring the companies that merge with us, it also gives us the advantage of being the ones that request the other company re-IP address their environment. We would then provide them with none conflicting IP addressing and assist them with any questions they might have.
I've worked on quite a few mergers/acquisitions and typically setting up a site-site VPN is the first thing we do. Why? Because, we can typically get this setup much quicker than, as an example, an MPLS circuit. The other reason is Security.
In terms of Security, there has to be some sort of audit to determine if there are any current exposures (one project I worked on for a Bank in Central America actually had its webpage under the control of a hacker) and what needs to be done to ensure both sides are meeting the Security requirements.
Once we've done this, the site-site VPN is typically removed in favour of MPLS circuit(s).
Well, this actually turned out to be a bit of a long drawn out story.
However, to try to summarise - what essentially happened was along the lines of that suggested in the posts above. First of all we established a site-to-site VPN between the 2 networks - this was intended as a short-term tactical solution but, in typical fashion, lasted far longer than originally anticipated.
Eventually the 2 networks were merged into a single MPLS based solution (which was more of a challenge than it might sound, given the different ISPs involved, different operating models, different architectures etc)
The one thing I will say is that, when it came to the full merger of the 2 networks it was by no means a trivial task so I would urge anyone undergoing a similar task not to underestimate the complexity of it all (both technically and politically!)
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...