Branch Office Design

Sometimes when engineers think of a branch office they think of a small 10 person remote office, but really the branch is any location where employees work that is geographically separate from your main headquarters. A branch can be huge, it could be as large as your main campus; it might also have very specific connectivity requirements for the network based around what functions that branch office serves for the company.

Before we get too far into the design recommendations and considerations for the branch office, lets just make sure we have this in perspective. Recall the enterprise architecture model with the 4 functional areas and submodules within them. The branch is intended to be a module in the remote area. The reason I bring this up is your company’s growth will be far easier if your designs are repeatable. If you have a cookie cutter design for your branch office you can just tweak for the specific needs and roll out, not only will that make planning and installing a new branch office far easier, but management and troubleshooting time with be significantly reduced. Documentation will be far easier, I mean you get my point, right? Of course each deployment will have its own requirements that may require some tweaks to the design, but overall it’s great to come up with and reuse the same design rather than reinvent the wheel every time.

Right, so when designing a branch office there’s some main considerations you’ll want to take into account. How much scalability is expected? This branch office might only have 25 people in it now, but does management expect to lease the suite next door and move 250 people into it?

What level of redundancy is required? Another way to put this is, how critical is this branch office to the company’s operations? This branch may be a design office where most of the work done is local on their machines with only the occasional file transfer to the file servers a few times a week. On the other hand, this branch office may be where an executive works that accesses a critical LOB application near constantly. This would certainly change the conversation a bit when talking about redundancy options for the design.

Will wireless services be needed, and to what extent? We’ll get into the details of this a bit later in the series when we cover wireless design.

Finally of course we need to know what kind of budget we have for the design.

So when you start thinking about a design for the branch, there’s a few physical components that are pretty much the building blocks. You see routers for WAN and internet access. Cisco recommends the ISR for its ability to provide a rich feature set in a single appliance. Over here we have a scale showing the models of ISR generation 2, aka ISR G2, routers and where they fit speedwise. It really just gives you a sense that the 891 is a small router that really might be given to a teleworker or used in a small office; whereas the 3945 is a big beefy router able to support more users and applications that require more bandwidth.

Depending on the size of the branch, you might be able to get by with an etherswitch module for an ISR which provides network switching capability with up to 48 ports, or you may want an external switch. The 3850 down here is great as a stackable switch, in a larger branch you might go for a chassis switch like the 4500 series in the middle here.

You may not always need it and in 2 of the 3 branch designs cisco recommends we don’t see them, but you may use a security appliance like the Cisco ASA firewall. A 5506 X is what’s on the right here.

Remember the design is based around what the business needs are at the branch. Most offices including branch offices have wireless capabilities, so you may have some access points, and depending on the extent of the wireless services required you may even have a controller at the branch, perhaps the WLC module for the ISR.

Similarly for IP phones. Most businesses now use IP phone systems and you may have only a centralized call processing system in your server farm or datacenter, or also have minimal call processing capabilities at the branch in case the MPLS goes down that the phones are still functional. We’ll go into this a bit more later in the series.

So we have a sense of the hardware we’ll see at the branch, let’s talk a bit about our WAN connectivity options. There’s really 3 different routes you can go with this. Either an MPLS, or other service provider-only WAN design; a hybrid design where you either have an active-active or active-passive configuration of MPLS with public internet VPN; or you may opt to go for only public internet connections and only use internet VPN for WAN connectivity. Ya know, I’ve really seen this become a lot more common. With how easy it is to get diverse high speed internet access; and how cheap it is! You can get 2, hey even 3, internet connections and just set up VPN connections to the main office. You could use this to provide more bandwidth when available by maybe running EIGRP to load balance, or just use them as failover. The one big downside of this is the lack of QoS. If your carrier is having congestion issues, your applications may suffer and there’s nothing you can really do about it. This is where IP SLA can come in handy. Any network engineer when asked what an SLA is will probably immediately respond back ‘a service level agreement’ which is a contract between you and the carrier for the level of service they’ll provide, which usually includes the amount of downtime, time to resolution in the event of failure, and also support QoS. But in Cisco devices, IP SLA is a functionality that can monitor various network health indicators and take action when they fall outside a given threshold. For example you can monitor the level of jitter on a line, which is the variance in latency and is utterly toxic to realtime applications like voice and video, you can do an FTP file transfer, load and HTTP website, or just ping some remote device. Using this information you can use floating static routes to prefer one WAN link over another

The most common deployment I’ve seen and done myself is hybrid though. Many times the client wants the ability to do QoS and the level of reliability and guaranteed service that comes with a provider managed WAN, but they don’t want the cost of have TWO provider managed WANs and so opt for a public internet VPN as a fallback.

So as for the exam, Cisco very clearly defines the different branch office sizes and the type of design that should be used in each category. The first is the small branch office. This is defined as any office supporting less than 50 users. You’ll have a single router that’s single or multi-homes depending on your provider availability and budget. You may use integrated switching with your ISR or a separate stackable switch like the 3850 for LAN access. Of course you may also have wireless services at this branch.  You may choose to provide more redundancy by using dual power supplies for your routers.

The medium sized branch office is defined as supporting 50 to 100 users. At this level you’ll now employ dual routers for redundancy and then must configure a first hop redundancy protocol like HSRP or GLBP. You’ll have outgrown integrated switching module for your ISR and will use external switching; there’s no real need yet for a chassis switch and a stackable switch is recommended for the redundancy and manageability benefits gained. At this size as well you’ll want to be sure to have multiple WAN connections available for redundant connectivity.

Finally we have the large branch office. This is defined as support 100 to 1000 users. Immediately you might ask ‘but what if my branch office is larger than that’, well first, that’s a mighty large branch office 😊 but at that size you would move back to the enterprise campus architecture and try to maintain a 2 or 3 tier design depending on the size.

At this level Cisco recommends deploying security appliances, ASAs, in a failover cluster for redundancy. EIGRP can be run with the dual WAN routers to allow load balancing between the routers and possibly the WAN links as well. It would be perfectly fine to stick the with stackable 3850 switches here as well, but you may want to go with a chassis switch like the 4500 series to take advantage of the redundancy options there as well like redundant powersupplies and supervisor modules.

With layer 3 switching you may configure your FHRP between the redundant switches, or ASA the failover clustering provides first hop redundancy.

So this was the overview on how to design for the branch office and the types of considerations that should take place.

Course Video