Download pdf. Campus Network Design Fundamental – Ch 12 QoS and Voice

QoS and Voice

Venti Systems will implement IP telephony in the head office only.

Head-Office QoS and Voice

Because IP telephony is included in the Venti Systems design, you must also consider managing the quality of service that the traffic experiences. Recall that although you typically think of applying queuing only to slow WAN links, LAN links can also be congested, so queuing should be deployed on any link that could potentially experience congestion, to provide the needed services to the network traffic. Queuing policiesin other words, how each traffic class is handledshould be consistent across the enterprise.

Venti Systems will use IP phones to digitize and packetize the voice traffic. As illustrated earlier in Figure 12-6, IP phones with a built-in switch will be used; one port will connect to the access switch and another will connect to the user’s laptop. Access switches will provide inline power for the IP phones, using power over Ethernet (PoE).

The voice and data traffic will be on separate VLANs to allow easier implementation of QoS tools; the connection to the access switch is an 802.1q trunk, with the laptop on the native VLAN.

Classification and marking of voice traffic will be done by the IP phone. Recall that the point within the network where markings are accepted is known as the trust boundary; any markings made by devices outside the trust boundary can be overwritten at the trust boundary. A Cisco IP phone could be considered to be a trusted device because it marks voice traffic appropriately, while a user’s laptop would not usually be trusted because users could change markings (which they might be tempted to do to attempt to increase the priority of their traffic). Therefore, the access switches will mark the laptop traffic appropriately.

 

Classification and Marking

Recall that the type of service (ToS) field within an IPv4 packet header marks, or indicates, the kind of traffic that is in the packet. This marking can then be used by other tools within the network to provide the packet the service that it needs. The first 6 bits in the ToS field of an IP packet are known as the DiffServ Code Point (DSCP) bits. Using Layer 3 DSCP QoS markings allows QoS to be provided end to end throughout the network. If some access switches support only Layer 2 {class of service [CoS]) markings, these markings must be mapped to the appropriate DSCP values. This would be a function performed by the distribution switches (in this case, by the collapsed core switches). The distribution switches must also apply DSCP values to traffic that has not been marked elsewhere.

 

As described in Chapter 6, “Quality of Service Design,” Cisco created a QoS Baseline that provides recommendations to ensure that both its products, and the designs and deployments that use them, are consistent in terms of QoS. The baseline includes an 11-class scheme, and companies can evolve to this level of classification. Venti Systems will start with a 5-class scheme, as illustrated in Figure 12-10.

 

Figure 12-10. Venti Systems’ QoS Classes

 

Figure 12-10

Figure 12-10

After traffic has been classified and marked and sent on its way through the network, other devices will then read the markings and act accordingly. Tools such as weighted random early detection (WRED) and low latency queuing (LLQ) will be used.

Cisco Automatic QoS (AutoQoS) provides a simple, automatic way to enable QoS configurations in conformance with the Cisco best-practice recommendations. Venti Systems will use AutoQoS to create configuration commands to perform such things as classifying and marking VoIP traffic and then applying strategies for that traffic. The configuration created by AutoQoS becomes part of the normal configuration file and can therefore be edited if required.

The call-processing function previously performed by the PBX will now be handled by a call-processing manager, CCM, a software-based system that provides functions such as setting up and terminating calls, routing to voice mail, and so forth. CCM is installed on a Cisco Media Convergence Server (MCS) and selected third-party servers. Because this is a relatively small IP telephony network (with less than 2500 phones), two CCM servers will be deployed: one to act as a publisher (and store the master copy of the database of configurations) and the other to act as a subscriber (the device with which phones register). The subscriber also acts as a backup to the publisher. The Cisco Unity unified messaging solution will be deployed to deliver e-mail, voice mail, and fax messages to a single inbox so that users can, for example, listen to their e-mail over the telephone, check voice messages from the Internet, and forward faxes to wherever they might be. The complete voice network architecture, with the redundant components removed for clarity, is illustrated in Figure 12-11.

 

Figure 12-11. Venti Systems’ IP Telephony Architecture

 

Figure 12-11

Figure 12-11

The voice gateway to the PSTN can be implemented with a variety of devices. For example, Cisco multiservice access routers communicate directly with CCM and support a wide range of packet telephonybased voice interfaces and signaling protocols. Alternatively, voice gateway modules can also be installed in Cisco switches.

If voice traffic travels across WAN links, the traffic should be compressed to reduce the required bandwidth. Currently, voice traffic is not going over WAN links in this design; if it does in the future, G.729 compression is recommended. RTP header compression, cRTP, would also be considered on these WAN links.

Another way that could be used to reduce the bandwidth required by voice calls is voice activity detection (VAD). Recall that, on average, about 35 percent of a call is in fact silence; when VoIP is used, this silence is packetized along with the conversation. VAD suppresses the silence, so instead of sending IP packets of silence, only IP packets of conversation are sent. The network bandwidth is therefore being used more efficiently and effectively.

Because voice is being transported in IP packets, security of voice traffic is inherent in the security provided for other data, as described earlier.

Branch-Office QoS and Voice

The Seattle office will have a PBX system installed to replace the outsourced Centrex solution. The PBX will be the one that was previously installed in the Grandics Corporation office.

Remote User QoS and Voice

Remote users will use their own phone and will use a company calling card for long-distance calls.

 

Download pdf. Campus Network Design Fundamental – Ch 12 Email

E-Mail

Basic Internet e-mail security calls for the corporate mail server to not be accessible directly from the Internet. Therefore, as shown in Step 1 of Figure 12-9, incoming e-mail messages transit through the DMZ to a mail relay server. The mail relay server “sanitizes” all messages of viruses, spam, and conspicuous attachments, prior to forwarding them to the corporate mail server located on the inside network, as shown in Step 2 of Figure 12-9. This sanitizing of e-mail will be accomplished for now by software that resides on the mail relay server; a hardware-based solution will be considered in the future if the volume of e-mail warrants it.

 

Figure 12-9. A Mail Relay Server Sanitizes Incoming E-Mail

 


Figure 12-9

Figure 12-9

Head-Office E-Mail

Head office users will access their e-mail directly from the corporate e-mail server. See the “Remote User E-Mail” section for an explanation on how users will access their e-mail from home or while on business trips.

In addition to accessing e-mail through their laptops, senior executives and sales staff will be provided with personal digital assistants (PDAs) to extend the benefits of corporate e-mail. As shown in Step 3 of Figure 12-9, the PDA e-mail synchronization server maintains a Messaging Application Programming Interface (MAPI) connection on the user’s mailbox, and automatically synchronizes its content to the user’s hand-held device, as shown in Step 4 of Figure 12-9.

Branch-Office E-Mail

The branch office, international offices, and remote users will access their e-mail and files through VPN connectivity back to the head-office servers, as shown earlier in Figure 12-7.

Branch office users’ mail software will attempt to poll the corporate mail server at its 10.0.0.0 subnet address. The branch-office router, upon seeing the request for the corporate head-office subnet, will initiate a VPN tunnel terminating at the head-office VPN concentrator (if no VPN tunnels are currently live), transiting through the firewall on its way.

Remote User E-Mail

Remote users, whether connecting from home or from a hotel room, will require the activation of their VPN client prior to accessing the corporate e-mail server, which is located on the inside network at the head office.

Most organizations do not permit their staff to simultaneously establish a VPN tunnel to the corporate head office and connect directly to the Internet. Allowing both Internet and VPN connections is known as split tunneling (as mentioned earlier) and is rarely permitted because, while the laptop’s VPN session is up, that laptop would provide too much exposure to the corporate network. If split tunneling were allowed, a hacker could compromise the laptop, and then after he is inside the user’s laptop, the hacker could make his way back to the corporate network through the VPN tunnel. Therefore, as long as the VPN tunnel that terminates at the head-office concentrator is up, the remote user cannot browse the Internet.

 

Download pdf. Campus Network Design Fundamental – Ch 12 IP Address

IP Addressing and Routing Protocol

The network includes multiple VLANs and therefore multiple IP subnets. Private IP addresses, in the 10.0.0.0 range, will be used. Network Address Translation (NAT) will be used on the Toronto office perimeter firewall and on the Seattle office perimeter router.

Head-Office IP Addressing and Routing Protocol

The head office needs the following three registered IP addresses:

  • Internal traffic to the Internet will be translated to address 1 (which is the perimeter firewall external interface registered address and will be overloaded by NAT).

    Note

    NAT and overloading are explained in Chapter 3, “IPv4 Routing Design.”

  • The VPN concentrator will have static NAT to address 2.
  • The mail relay server will have static NAT to address 3.

The perimeter firewall in Toronto has five subnets: one to the Internet, one to the mail relay server, two to the VPN concentrator, and one to the internal network.

The servers in the head office will all be in one VLAN, which will be configured as a private VLAN. As explained in Chapter 2, “Switching Design,” a private VLAN ensures that if one server is compromised, the hacker would not be able to directly attack the other servers because traffic is restricted by the switch.

All VPN tunnels to the head office will be on one subnet, in the private 10.0.0.0 range. The VPN concentrator assigns the address that the VPN client will use on the VPN tunnel after they connect. The VPN concentrator keeps track of the addresses (the Outside Global address to the Outside Local address translation).

IP phone voice traffic will be put on a separate VLAN from the data traffic. Each VLAN will be present in only one access layer switch to limit the size of the broadcast domain and eliminate Layer 2 topological loops.

Because the private 10.0.0.0 addresses are being used, many host bits are available for subnetting. Thus, large ranges can be used, to allow easy subnet calculations and future growth. Table 12-1 provides the subnet allocations.

 

Table 12-1. IP Subnet Allocation

Subnet Allocation
10.0.x.0/24 x = 0 through 31; Toronto data VLANs
10.0.x.0/24 x = 100 through 131; Toronto voice VLANs
10.1.y.0/24 y = 0 through 255; Toronto internal LANs
10.2.0.0/24S Seattle VLAN
10.3.0.0/24 VPN VLAN
10.0.x.0/24 x = 0 through 31; Toronto data VLANs

 

The Dynamic Host Configuration Protocol (DHCP) assigns dynamic IP addressing information to users’ laptops when they require them. DHCP server functionality will be from the collapsed backbone Layer 3 switches and the branch-office router.

The Enhanced Interior Gateway Routing Protocol (EIGRP) is chosen as the routing protocol for the new network because of its flexibility, fast convergence, simple configuration, and scalability features.

Branch-Office IP Addressing and Routing Protocol

The Seattle office router external interface will have a static IP address assigned by its ISP. This router will have a static route to the head office subnets over a VPN tunnel; it will dynamically create a VPN tunnel when traffic is to be sent to the head office. This VPN is considered to be a LAN-to-LAN connection.

The branch office is one VLAN. Branch users’ laptops will use private addresses on the inside network. These private addresses will be translated by the edge router if the traffic is destined to an external network on the Internet. If the traffic is destined to the head office, the packets, including the private addresses, will be encapsulated inside a VPN tunnel.

The servers within the branch office will also be configured on a private VLAN, to provide additional security.

Remote User IP Addressing and Routing Protocol

Remote users will be assigned an IP address, either from their HAN if they are located behind a router or firewall at home or from their ISP if they connect directly on the Internet. The VPN concentrator assigns the address that the VPN client will use on the VPN tunnel after they connect.

 

Download pdf. Campus Network Design Fundamental – Ch 12 Security

Security

The head-office and branch-office networks will both be located behind a firewall. The basic rules of a firewall are that traffic that originates from the inside network is allowed to return; however, traffic that originates from outside is not allowed to penetrate the corporate network. As with most rules, these basic firewall rules are often broken, but with add-on precautions.

As an example, we examine Venti Systems’ VPN connectivity, illustrated in Figure 12-7. When a remote user wants to connect to the head office, he launches his VPN client software, which in turn attempts to build a VPN tunnel with the destination as the firewall. By default, a firewall drops all packets that originate from the outside. But a VPN connection needs to terminate on the VPN concentrator, and therefore must transit through the firewall to the VPN concentrator. For VPN connectivity to work, the firewall must be configured with a rule stipulating that incoming IPsec traffic will be allowed in. This traffic must make its way to the VPN concentrator, which is in the demilitarized zone (DMZ), on interface E3 of the firewall in this network. Any other traffictraffic that is not IPsec datais refused entry at the E0 interface on the firewall. This exception to the firewall rule is sometimes referred to “punching a hole” in the firewall.

 

Figure 12-7. Firewall Rules Allow VPN Tunnels

 

If the VPN concentrator succeeds at decrypting the data, it treats this as an indication that the originator is a safe source. However, when the remote user’s data first transited through the firewall, it was encrypted, and therefore the firewall could not do a deep packet inspection. So that no chances are taken, the VPN concentrator is therefore configured to send the data that it just unencrypted back through the firewall (on interface E4 in the figure) for a deep inspection, before allowing it access to the internal head-office network (interface E1 in Figure 12-7).

Venti Systems, like any corporation, needs to create and disseminate its acceptable usage and security policies and procedures to all employees. These policies apply to the following items:

  • Users’ laptops
  • Network usage
  • Wireless usage
  • Internet usage
  • E-mail
  • Instant messaging (IM)

Note

IM programs typically tunnel through other protocols, bypassing firewalls, thus leaving the network open to viruses and other security problems. Corporate confidential information (such as financial spreadsheets or staffing details) can also be sent in an IM message, so policies similar to those for e-mail should be in place. Employees should be made aware that IM, like e-mail, is neither secure nor private.

Note

A more extensive discussion on security policies and best practices can be found in The Business Case for Network Security: Advocacy, Governance, and ROI, by Paquet and Saxe, Cisco Press, 2005.

Strong authentication will be implemented for local and remote access to all managed devices, through an access control server (ACS). The ACS is located in the Management module, as discussed in the section “Network Management,” later in this chapter. Strong authentication requires a two-factor authentication method, including two items from the following list:

  • What a user knows
  • What a user has
  • What a user is
  • What a user does

A password or personal identification number (PIN) is something a user knows, while a token (for example, a bank card or small device with an LCD) is something a user has. As an example, to be granted remote access at an automated teller machine (ATM), a customer must produce something he hashis bank cardalong with something he knowshis PIN. In this design, we will use a security token as part of a two-factor, one-time password (OTP) authentication. Tokens (key-chain-size devices) will be provided to users. The LCD on the tokens shows OTPs, one at a time, in a predefined order, for about 1 minute before the next password in the sequence appears. The token is synchronized with a token server that has the same predefined list of OTPs for that one user. Therefore, at any given time, only one valid password exists between the server and each token. The user must enter both the OTP (from something he has) and his PIN (something he knows) to be granted access to the network.

Within the new design, data will be encrypted while stored on a server, because static data located on a server is vulnerable. (Some pundits equate the encrypted WAN transmission of data, which is otherwise clear text while stored on a server, to using an armored truck to transfer money from a paper bag to a cardboard box.)

For server backup, the company is considering using a third-party backup service in which a service provider backs up data onto its disks over a WAN connection, eliminating issues such as dealing with tapes, off-site storage, and so forth. However, this also means that the data is now on the disks of another company, so the security and privacy of such data must be ensured. For example, if sensitive data were encrypted on the main servers, it would also be encrypted on the backup server, which would provide one level of protection. The service provider should be investigated thoroughly to ensure that it meets the policies and procedures required by the company.

Note

Storing off-site data is also part of the company’s disaster recovery plan.

Head-Office Security

All the standard security best practices will be implemented at the head office, including changing default passwords on network devices, locking access to the server room and wiring closet, deactivating unused switch ports, and so forth.

Best practices call for redundancy of critical infrastructure. Because the firewall bridges the head office to the Internet and to the company’s other facilities, redundancy of this deep-inspection device is a must.

The Cisco PIX Firewall allows two firewalls, a primary and a secondary, to implement failover mode, as shown earlier in Figure 12-3. Provided that the secondary firewall is identical to the primary, Cisco charges only for the hardware, so the cost for the secondary unit is minimal. The secondary firewall is configured exactly the same as the primary firewall and maintains an identical copy of the connections table used by the primary firewall, to monitor the status of individual data sessions. This connections table is synchronized over a dedicated Ethernet cable. The secondary firewall monitors the health of the primary firewall through the failover serial cable, and will be ready to take over should the primary unit experience significant performance issues.

To use failover mode, you need two identical PIX Firewalls. They must have the following characteristics:

  • They must be running the same version of the PIX OS.
  • They must have the same number and type of interfaces in the same slots.
  • The primary must be running an unrestricted license of the PIX OS.
  • The secondary must run either an unrestricted license or a failover license of the PIX OS.
  • If the primary has a Data Encryption Standard (DES) or Triple Data Encryption Standard (3DES) license, the secondary must also have one.

The critical network segments and devices will be equipped with IDS sensors and IPS software, respectively, as shown in Figure 12-8. This figure shows the Server and Management modules of the Enterprise Campus functional area and the Enterprise Edge functional area.

 

Figure 12-8. Intrusion Detection and Protection at Work

 


IDS sensors monitor traffic on a network and attempt to identify intrusions and hostile activity. IDS sensors can operate in stealth mode, meaning that their interfaces that connect to the DMZ or the outside network operate strictly at Layer 2, in promiscuous mode, copying the data, as it transits a network segment, to the IDS management server through its nonstealth interface. This is done either through a hub or by connecting to a Switched Port Analyzer (SPAN) port of a switch. Operating in stealth mode, sensors are not vulnerable to IP attacks from hackers because the interface is not reachable by IP. Sensors are configured to alert a management console should they detect suspicious activity, though invariably by the time the alert is delivered to the network administrator, the attack has already taken place.

Note

A SPAN port is a port on a switch that is configured to mirror the data passing through any other switch port or group of switch ports.

IPS software installed on critical devices scans incoming traffic and actively monitors all the devices’ resources, such as memory, processes, and so forth.

Venti Systems will investigate the possibility of subcontracting the analysis of the data reported by its security systems, because the company believes in the saying, “If you log it, read it.” Because Venti will have multiple IDS sensors potentially releasing many false positive alarms, the job of parsing through all those events will be subcontracted to a company that specializes in this field and uses sophisticated correlation tools. This firm will therefore inform the network administrator of a security event only when her intervention is warranted.

All servers will be equipped with IPS software to monitor all functions of the serverprocesses, memory usage, disk space, directory creation or deletion, and so forthand to report suspicious activity to the IDS Management server. Depending on the configuration, these IPS systems should be able to shun a malicious user, that is, to report the malicious activity to the firewall and request that this particular source be denied further access to the network.

Port-level security will be implemented on all Layer 2 switch ports.

Wireless networks present security risks which must also be mitigated. Strategies include the following:

  • Monitoring, in real time, of rogue access point detection, to ensure that only authorized access points are installed in the network
  • Using IEEE 802.1x port-level authentication and Temporal Key Integrity Protocol (TKIP) encryption
  • Changing the service set identifier (SSID), a unique identifier for a wireless access point or router, from the default (for example, from linksys or tsunami) to something difficult to guess, thereby prohibiting hackers from easily finding the access point
  • Disabling SSID broadcasts so that drive-by hackers cannot detect an access point whose name they don’t know

Branch-Office Security

The Seattle office router will be configured with the firewall feature set. The router-firewall configuration will be the default so that only traffic that originated from the inside network will be allowed to return. Traffic originating from outside will not be allowed to enter the network.

Remote User Security

Remote users’ laptops will be configured with antivirus software, a personal firewall, and the corporate VPN client. Personnel will use strong authentication to be granted access to the corporate network.

 

Download pdf. Campus Network Design Fundamental – Ch 12 Switching

Switching

Layer 2 and Layer 3 switches are used in both the Toronto and Seattle offices, as described in the following sections. (The security features implemented on the switches are described in the “Security” section, later in the chapter.)

Head-Office Switching

Within the Toronto office, Layer 2 switches are used in the Building access layer to provide connectivity for the users’ laptops and IP phones. These access switches have inline power for the IP phones, and they redundantly connect to the collapsed backbone Layer 3 switches. The Spanning Tree Protocol (STP) is therefore not required, because no Layer 2 loop exists between the switches. As is normally recommended, though, STP should not be turned off, just in case a loop is configured in the future. To shorten the time it takes for the ports to come up, PortFast should be configured on each switch port that is connected to a laptop/IP phone combination.

IP phones with a built-in switch will be used; one port connects to the access switch and another connects to the laptop, as illustrated in Figure 12-6. The IP phone and laptop send traffic on two separate virtual LANs (VLANs); the connection to the access switch is an Institute of Electrical and Electronics Engineers (IEEE) 802.1q trunk, with the laptop on the native VLAN.

 

Figure 12-6

Figure 12-6

Figure 12-6. IP Phone with a Built-In Switch Connects to the Access Switch and User’s Laptop

 


Note

In Figure 12-6, the connection between the laptop and the IP phone is not an IEEE 802.1q trunk. Data on this connection is all in a single VLAN; that VLAN is the native VLAN on the IEEE 802.1q trunk between the laptop and the access switch.

 

The Server module has Layer 2 access switches connected directly to the collapsed core.

The Toronto office also has Layer 3 switches, as shown earlier in Figure 12-2; the routing functionality required of these devices is described further in the “IP Addressing and Routing Protocol” section, later in the chapter. Because these switches are connected redundantly, the Gateway Load Balancing Protocol (GLBP) (as described in Chapter 10, “Other Enabling Technologies”) should be used to allow both load sharing and redundancy.

Branch-Office Switching

The Seattle office also has Layer 2 switches, but because IP telephony is not used in this office, no special requirements exist for the switches. STP is again not required, because no Layer 2 loop exists between the switches. Just as in Toronto, STP should not be turned off, and PortFast should be configured on each switch port that is connected to a laptop.

Remote User Switching

The remote users do not require switches. However, users might have a router with a built-in switch (for example, a wireless broadband router with a built-in four-port switch can be used in an employee’s home office).

 

Download pdf. Campus Network Design Fundamental – Ch 12 Design Model

Design Model

Recall from Chapter 1, “Network Design,” that when designing a network, the following tasks should be considered:

  • Determine requirements
  • Analyze the existing network, if one exists
  • Prepare the preliminary design
  • Complete the final design development
  • Deploy the network
  • Monitor, and redesign if necessary
  • Maintain documentation (as a part of all the other tasks)

Chapter 11 provides the background for the case study, including the details of the existing network and the requirements for the new and updated network. In this chapter, we produce the design. For the purposes of this case study, we assume that the relevant personnel at Venti Systems are being consulted along the way and that they are approving the design as we go. We do not go into the deployment or monitoring steps for this case study, but we provide all the details that would be necessary to produce the design documentation.

We use the Enterprise Composite Network Model, including hierarchical layers as appropriate (as detailed in Chapter 1), for this case study design. The three functional areas of the model are Enterprise Campus, Enterprise Edge, and Service Provider Edge. Each of these functional areas can be further divided into various modules, as illustrated in Figure 12-1. Each of the modules can include the hierarchical core, distribution, and access layer functionality.

 

Figure 12-1

Figure 12-1

 

Figure 12-1. Modules of the Enterprise Composite Network Model[1]

Venti Systems has no e-commerce, and communication between offices and remote users will be through virtual private networks (VPNs) over the Internet. We therefore do not include the e-commerce, WAN, or Frame Relay/Asynchronous Transfer Mode (ATM) modules.The following sections provide the design models for the head office (in Toronto), branch office (in Seattle), and remote users (including the international sales personnel). Following those sections is a description of the users’ devices and the servers.

Head Office

The new Toronto office will initially have one building, with an option to acquire a second building. Up to 185 people will be at this location within 18 months, and IP telephony is to be used for all internal calls. Redundancy is required, both at the infrastructure level and for some servers. VPN connectivity to the Seattle office and for remote users is to be used and wireless connectivity within the building is to be implemented.

Enterprise Campus

The Campus Infrastructure and Server modules of the Enterprise Campus for the head office are illustrated in Figure 12-2.

 

Figure 12-2

Figure 12-2

 

Figure 12-2. Part of the Venti Systems Head-Office Enterprise Campus

 

 

Note

IP phones and wireless access points are shown in Figure 12-2; the details of how these technologies are integrated within the network are described in the “QoS and Voice” and “Wireless” sections, respectively, later in this chapter.

The Management module is described in the “Network Management” section, later in this chapter.

 

The Campus Infrastructure module includes Layer 2 access switches for connectivity between the end-users’ laptops and IP phones and the rest of the network. These switches provide inline power for the IP phones as well as user authentication and quality of service (QoS) marking. Redundancy for the laptops is provided through their wireless connections.

The collapsed backbone combines the Building Distribution and Core functionality in Layer 3 switches. Routing, route filtering, route summarization, and filtering are performed here. Redundancy to the Building access switches, to the Server access switches, to the Edge Distribution module, and to the Management module is provided to ensure a highly available and reliable backbone.

The centralized Server module contains the internal servers, including e-mail and file servers, and Cisco CallManager (CCM) servers for IP telephony. Redundancy is implemented to the collapsed backbone so that users always have access to the servers they need. Layer 2 access switches are used in this module to connect to the collapsed backbone.

The Edge Distribution module, shown as part of Figure 12-3, is the interface between the Enterprise Campus (through the Core) and the Enterprise Edge functional areas. This module uses Layer 3 switching to provide high-performance routing; redundancy is also implemented to ensure that campus users always have access to the Enterprise Edge.

 

Figure 12-3

Figure 12-3

 

Figure 12-3. Venti Systems’ Enterprise Collapsed Edge: Corporate Internet, VPN Access, and PSTN

 

 

Note

Figure 12-3 shows the physical network topology, including redundant devices and connections. Subsequent figures might show the logical topology, without the redundancy, for ease of understanding concepts.

Enterprise Edge and Service Provider Edge

The modules of the Enterprise Edge and Service Provider Edge for Venti Systems’ head office are also shown as part of Figure 12-3. The Enterprise Edge’s VPN/Remote Access module is collapsed into the Corporate Internet module because all external traffic will be converging from the Internet to the head office.

The Corporate Internet module provides Internet access for the users (and usually passes VPN traffic from remote users to the VPN/Remote Access module). This module includes an e-mail relay server (as detailed in the “E-Mail” section, later in this chapter). Security systems include firewalls and intrusion detection systems (IDSs) to ensure that only legitimate Internet traffic is allowed into the enterprise. (Security is described further in the “Security” section, later in the chapter.) The Domain Name Service (DNS) of the Internet service provider (ISP) will be used.

A VPN/Remote Access module usually terminates VPN traffic from external users. Devices in this module include VPN concentrators to terminate the remote user connections, and firewalls and IDS appliances to provide security. In our Venti Systems design, this functionality is collapsed with the Corporate Internet module. A VPN concentrator is attached behind the redundant firewalls to initiate and terminate VPN tunnels to and from the branch office and remote users.

The ISP module represents the connection to the Internet. Venti Systems connects to the ISP through a digital subscriber line (DSL) connection. A backup Internet connection is not initially required, because no mission-critical applications are running over the Internet, and the additional cost and complexity are not deemed necessary at this time. Venti Systems will negotiate with its ISP a comprehensive service-level agreement (SLA), including availability above 99.997 percent.

The public switched telephone network (PSTN) module is shown in Figure 12-3 because all external calls will be through the PSTN, not through IP telephony. Recall, though, that remote users will not dial in; rather, they will connect through a VPN, so PSTN access is not required for dial-in functionality. As is common for enterprises, PSTN redundancy is not required. Venti Systems will negotiate with its PSTN provider a comprehensive SLA, including a 99.999 percent availability.

Branch Office

As indicated in Chapter 11, few changes are required to the network in the Seattle office because the work done there is not information-intensive. The Seattle office originally outsourced its Internet connectivity, telephone, and e-mail services.

E-mail will be accessed using the server at the Toronto office, through the VPN connection. Internet connectivity will be through DSL.

The Seattle office will remain Layer 2 switched only because of the small number of people and the simplicity of the network. The office will connect to the Internet through the Cisco 2514 router that was decommissioned from Toronto and on which the Internet Operating System (IOS) will be upgraded to the latest IOS firewall feature set (at least to Release 12.2[29]). This router will be then able to route traffic and to terminate VPN tunnels.

Figure 12-4 illustrates the network at the Seattle office.

 

Figure 12-4

Figure 12-4

 

Figure 12-4. Seattle Office Network: A Router with Integrated Firewall Will Provide VPN Access to the Head Office

 

As also shown in Figure 12-4, the Seattle office will get a new private branch exchange (PBX) (from the old Grandics Corporation office); IP telephony will not be implemented at this time.

Remote Users

All remote users will access the network through a VPN connection to the Toronto office. All employees, in all offices, who need a computer will be given a wireless-enabled laptop; all of these laptops will be from the same vendor, running the same operating system, with a standard suite of programs installed. (Existing desktop PCs and any laptops that are not compatible with the new standard will be replaced.) The laptops will be configured with VPN client software that provides connectivity to the head office. A significant advantage of running a software VPN client is that the encrypted tunnel originates from the laptop so that the data traveling on the home-area network (HAN) toward the head office is encrypted, making the transmission safer. A typical connection from a remote user is illustrated in Figure 12-5.

 

Figure 12-5

Figure 12-5

Figure 12-5. Typical Remote User Connection

 

 

The users’ laptops are as described in the following section.

User Devices

All users’ laptops will have the following features:

  • Wireless, PSTN, and Ethernet connectivity.
  • Automatic operating system updates configured so that the latest service packs and security patches are always installed.
  • Automatic application updates configured so that any security-critical updates are always installed.
  • Advanced antivirus software, including antispyware software, installed, with automatic updates configured.
  • VPN client software, to allow VPN with IP security (IPsec) connections to the head office. This software also allows policies to be pushed down from the head office after the connection is made. An example of such a policy is to disallow split tunnels so that after the laptop’s VPN client is connected to the corporate network, the laptop can only send data to the corporate network and cannot simultaneously directly surf the Internet.
  • Personal firewall software.
  • Trust agent software, as described in the “Network Management” section, later in this chapter.

Servers

All servers will include management software so that they can be remotely managed. The servers will also be equipped with intrusion prevention system (IPS) software.

The internal e-mail, finance, and computer-aided design/computer-aided manufacturing (CAD/CAM) file servers will be installed as clusters. As its name implies, a cluster is a group of identical servers interconnected and accessible as a common storage pool. Clustering prevents the failure of a single file server from denying access to data. Should Venti Systems grow, an additional benefit of clustering is that it adds computing power to the network for large numbers of users.

The financial and other business applications used in the three offices will be standardized to use Venti Systems’ applications. The data from the systems in the other offices needs to be converted and incorporated into the new system; a task force will be created for each application to be responsible for migrating the data and integrating the systems.

 

Download pdf. Campus Network Design Fundamental – Ch 12 Intro

Chapter 12. Case Study Solution: Venti Systems

This chapter provides a solution to the case study introduced in the previous chapter and includes the following sections:

This chapter provides a comprehensive network design solution for the case study of a fictitious company called Venti Systems, as introduced in Chapter 11, “Case Study Context: Venti Systems.”

For the purposes of this case study, assume that you have been contracted by Venti Systems to design an upgraded/new network as it completes its acquisition of two complementary companies and moves to new facilities.

 

Download pdf. Campus Network Design Fundamental – Ch 11 Summary

Summary

This chapter introduced the Venti Systems case study, including a description of its current state and that of the two companies that it is in the process of acquiring. The requirements for the upgraded network and the network in the new building were developed, in preparation for the rest of the design steps in the following chapter.

 

Download pdf. Campus Network Design Fundamental – Ch 11 Requirements

 

Network Requirements After Acquisitions Are Complete

As described in Chapter 1, “Network Design,” determining the requirements is the first step that should be taken when designing a new or updated network. This section examines the requirements for the Venti Systems networks.

After the acquisition, the two Toronto-based companies will be moving together to a new head-office location on the west side of the city, to achieve better synergy and to consolidate personnel and manufacturing facilities. The new location currently has one building, and the company has an option to lease the neighboring building if its current growth trend continues. The Seattle office will remain and will become a branch office of the Venti head office. All the international sales offices will remain in operation.

The 100 people in the original Venti Systems office will combine with the 60 Grandics Corporation employees; 15 people are expected to be laid off immediately because of redundancies. The company then expects to hire another 40 people over the next 18 months commensurate with growth. The number of Seattle staff will go from 60 to 45 through natural attrition and departure incentives after the acquisition.

The new organization structure of Venti Systems includes a chief executive officer (CEO) with the following four departments reporting to her, as illustrated in Figure 11-3:

  • Finance
  • Marketing and Sales
  • Operations
  • Human Resources (HR)

 

Figure 11-3

Figure 11-3

Figure 11-3. Organization Structure of the Merged Company

 

The CEO is technology-savvy and has declared that the new head office is to be state of the art. However, even though she would like to have the latest and greatest “bells and whistles” in the new network, she has advised the designers to recognize that, in the real world, the company has requirements and constraints that must be adhered to. Thus, the company can take advantage of new technologies only when they meet requirements and are cost effective. For example, IP telephony/Voice over IP (VoIP) will be implemented in the new Toronto office, but the low volume of calls between offices does not warrant the expense of changing to VoIP in Seattle, in the international offices, or between offices at this time. Because of time differences, most of the communication exchange with the international offices is through e-mail.

With a larger management team and for the sake of efficiency, the new Toronto office is to have a network that takes advantage of wireless connections and VPNs, as well as IP telephony.

Within the new Toronto office network, voice will be given priority over other traffic. IP telephony will replace the outdated PBX system and allow the company to take advantage of other benefits, including unified messaging (using the Cisco Unity product). Calls between offices and to outside locations will be done over the PSTN. A call center is not required at Venti Systems, because of the nature of the business.

Server and infrastructure redundancy will be implemented as necessary. A backup Internet connection is not initially required, because no mission-critical applications are running over the Internet, and the additional cost and complexity are not deemed necessary at this time.

The offices will keep their DSL connections, and all interoffice and remote-user communication will be through VPNs over the Internet.

All e-mail will be processed in the Toronto office, which will include two mail servers: an internal mail server and a mail relay server. The mail relay server will be located in the demilitarized zone (DMZ) and will sanitize e-mail messages before transmitting them to the internal mail server. The branch office, international offices, and remote users will access their e-mail and files through VPN connectivity to the head-office servers. A third personal digital assistant (PDA) e-mail synchronization server will provide push-based e-mail wireless services.

For ease of troubleshooting, the data on separate servers will be segmented as follows:

  • Two Cisco CallManager servers (subscriber and publisher, for IP telephony)
  • A Cisco unified messaging server
  • Three e-mail servers (one internal, one on the DMZ, and one for PDA synchronization)
  • A finance server
  • A CAD/CAM server
  • A general office server
  • Network management servers (the number of these servers will be determined during the design process)

The internal e-mail, finance, and CAD/CAM servers each will be clustered for backup. Sensitive data will be encrypted on servers as necessary. All servers will be equipped with intrusion prevention system (IPS) software, and the network will include intrusion detection systems (IDSs).

To improve performance within the Toronto office, a switched and routed environment will be implemented. Private IP addresses in the 10.0.0.0 range will still be used, but multiple subnets will be required. NAT will still be used on the Internet router, translating all addresses to the registered address configured on the external Ethernet (DSL) interface.

The Toronto office will have a wireless network, to allow complete mobility within the building.

All employees who need a computer will be given a wireless-enabled laptop; all of these laptops will be from one manufacturer, with one operating system, and with a standard suite of programs installed. Any employee with a laptop, including those in the international sales offices, can then become a remote user. All computers, including laptops and engineering workstations, will run the latest generation of antivirus software, which also includes antispyware software.

Because all three companies use the same CAD/CAM system and a common suite of office applications, the merged company will continue to use these same systems. However, some differences exist in the financial and other business applications used in the three offices; these will be standardized to use Venti Systems’ original applications. The data from the systems in the other offices needs to be translated and incorporated into the new system; a task force will be created for each application to be responsible for migrating the data and integrating the systems.

Within the Seattle location, few changes are required to the network because the work done there is not information-intensive. Communication between this office and other offices is mainly done through e-mail, which will be under the merged company domain through the e-mail server in Toronto. The Seattle office will remain as Layer 2 switched only because of the small number of people and the simplicity of the network. The office will have a VPN-enabled router to connect to Toronto. (The Cisco 2514 router, upgraded if necessary to at least the Internet Operating System [IOS] Release 12.2[29] firewall feature set, currently used by the Venti office will be moved to Seattle for this purpose; a new, more feature-rich router will be installed in the Toronto office.)

Management of devices within the network will be updated to include a more secure protocol, secure shell (SSH), for in-band connections.

Two other technologies were examined to see whether they would be useful for Venti Systems: content networking and storage networking. Venti decided that content networking is not required because the company is not involved in either e-commerce or high-volume file access. Storage networking, in the form of network-attached storage (NAS) appliances, might be considered in the future to help improve the performance, scalability, and reliability of access to the R&D data. At this time, NAS will not be implemented, but this decision will be revisited as the need warrants.

Business-related requirements and constraints for Venti Systems include the following:

  • Budget You can assume that sufficient budget is available for both capital and operating expenses for the new Toronto network, including IP telephony, wireless, and VPN, for new laptops, and for the minor upgrades to the Seattle network.
  • Schedule The move to the new office is to be completed within two months; the new network must therefore be in place and functioning by that time. The IP telephony network must be working in the new building because the PBX will not be moved. The business applications must also be merged by then, with integration phased in as defined by the assigned task forces.

    Note

    Venti Systems’ managers have decided to merge the acquired companies quickly, because they realize that if the merging of personnel takes too long, they will only “prolong the pain and defer the gain.” Thus, when the merger/acquisition is announced, the corporate leaders will move at full speed to integrate the two operations.

  • People Training of existing (or newly hired) network personnel on VoIP and IP telephony must be undertaken and completed in time for the implementation to be completed and tested.
  • Legal Venti Systems has no contractual obligations related to the network that must be upheld. New laws require IT governance best practices and the privacy and security of customer and financial data be assured, including a secure backup of such data. Examples of such regulations are Sarbanes-Oxley (SOX) and the California Law on Notice of Security Breaches (Senate Bill [SB] 1386) in the United States, and the Personal Information Protection and Electronic Documents Act (PIPEDA) in Canada.
  • History Because the Seattle plant belongs to the heavy-industry sector, its employees tend to be less high-tech-savvy. This is another reason that VoIP is not being implemented in Seattle at this time. With the culture shock of merging with the other companies, the acquisition of new laptops, and so forth, introducing new phones and a new phone system would probably be too disruptive at this time. In the future, if the benefits that VoIP would bring to this office are warranted, its implementation will be revisited.
  • Policies No policies are in place that might restrict the network design. Venti Systems has no issues related to the use of proprietary technologies. However, policies need to be implemented for things such as Internet access, network and laptop security, and so forth.

Table 11-2 summarizes the requirements for the merged company and its networks.

 

Table 11-2. Requirements for the Merged Company

Venti SystemsToronto Venti SystemsSeattle
Product Power modules and electronics. Powertrain.
Location Toronto-West. Seattle.
Number of Employees 145 (185 within 18 months following the merger, plus 1 each in the home offices in Japan and India). 45 (plus 2 in the small office in Germany).
Main Duties Office workers and engineering. Laborers.
Venti SystemsToronto Venti SystemsSeattle
Network
Topology Switched and routed Switched.
Connectivity UTP, wireless. STP.
IP Addressing Hierarchical, private. Flat, private.
Proprietary Systems/Protocols NoneIP only. NoneIP only.
Servers Cisco CallManager (one publisher and one subscriber), unified messaging, e-mail servers (one internal, one on the DMZ, and one for PDA synchronization), finance server, CAD/CAM server, general office server, and network management servers. Servers to be clustered: internal e-mail, finance, and CAD/CAM. Office server and a CAD/CAM server. E-mail processed by head-office server.
Redundancy Server and infrastructure redundancy.
Applications Business applications, e-mail, and CAD/CAM. Business applications and CAD/CAM.
E-Mail Enterprise e-mail with PDA message-forwarding capability. In-house, using head-office server.
Edge Device Firewall and VPN concentrator. Cisco 2514 with firewall feature set (previously in the Toronto office).
Internet Connectivity DSL. DSL.
Internet Connectivity Backup
Business Continuity Backup done daily; tapes stored off-site. Backup done daily; tapes stored off-site.
Remote Users (Including International Offices) VPN tunnel to head office for mail and file access. Seattle office and remote users access head office through VPN.
Voice IP telephony with unified messaging, and voice gateway to PSTN provider. The voice-enabled router will be equipped with the firewall feature set. New PBX (from Grandics Corporation).
Venti SystemsToronto Venti SystemsSeattle
Security Advanced virus-checking software, IPS, IDS, firewall, and firewall router. Advanced virus-checking software and firewall router.
QoS Voice traffic will be given priority.
Network Management SSH for in-band connections. SSH for in-band connections.
Support for Applications Business applications software will be standardized on head-office current applications. Task forces will be named to plan and implement the integration of each application.
 

Download pdf. Campus Network Design Fundamental – Ch 11 Case Study BG

Background Information and Context

Venti Systems is a manufacturer of high-end automotive power modules. The company is based in the west side of Toronto, in central Canada, and has a sales home office in Tokyo, Japan. Venti Systems is in the process of acquiring two other companies: Grandics Corporation, which is also in Toronto (but on the east side of the city), and Konah Power, based in Seattle, in the north-western United States.

Grandics Corporation manufactures electronic components and has a sales home office in New Delhi, India, while Konah Power manufactures powertrains and has a sales office in Frankfurt, Germany.

The locations of all the offices are shown in Figure 11-1.

 

Figure 11-1

Figure 11-1

 

Figure 11-1. Venti Systems and Its Acquisitions Have a Global Presence

 

Venti Systems, including its two acquisitions, produces a low-volume, high-value-added product. The company expects to grow both organically and by acquisition.

Currently in North America, Venti Systems has 100 people, while Grandics Corporation and Konah Power have 60 people each. One person is located in each of the India and Japan locations; those two employees work from home. The two-person sales staff located in Germany works from a small remote office.

The current network at Venti Systems, as illustrated in Figure 11-2, includes 10BaseT to the desktops and 100BaseT to the servers. All wiring is unshielded twisted-pair (UTP). The company has one e-mail server and two file serversone for business applications and one for computer-aided design/computer-aided manufacturing (CAD/CAM). A fourth server backs up the business application file server for redundancy. A backup of each server is done daily, and the backup tapes are stored off-site. The network is Layer 2 switched, using Cisco Catalyst 1924 switches and one 2950T-24 switch. Each port on the 1900 switches is attached to only one device; hubs were removed a few years ago. Virtual LANs (VLANs) are not used in this network. One Cisco 2514 router, which includes two 10-Mbps Ethernet interfaces and the firewall feature set, is used for Internet connectivity through a digital subscriber line (DSL) connection of greater than 1 Mbps. No backup Internet connectivity exists.

 

Figure 11-2

Figure 11-2

 

Figure 11-2. Venti Systems’ Current Network Topology

 

Because the Venti Systems network is Layer 2 switched without VLANs, it has a flat IP addressing scheme. Private IP addresses, in the 10.0.0.0 network, are used, with Network Address Translation (NAT) on the Internet router translating all addresses to the registered address configured on the external Ethernet interface. The external Ethernet interface connects to the Internet service provider (ISP) DSL network, which offers Point-to-Point Protocol over Ethernet (PPPoE) connectivity.

 

PPPOE

PPPoE capitalizes on two well-known standards: PPP and Ethernet. PPPoE provides connectivity using an Ethernet link for Internet access through a broadband medium, such as a DSL connection or a cable modem.

 

Venti Systems employees do not tend to send or download much data over the Internet connection, so no performance issues exist there. Internally, however, slow responsiveness has been reported, especially by the research and development (R&D) engineers.

Virtual private networks (VPNs) are used to allow remote employees, including the one working in a home office in Tokyo, to access files and their e-mail. Security is provided by the Internet router and with virus-checking software installed on all devices.

Telephone service is provided by a relatively old private branch exchange (PBX) system.

All three companies use the same CAD/CAM system and a common suite of office applications (for word processing and so forth). Some differences exist in the financial and other business applications used.

The current Grandics Corporation network is similar to Venti Systems’ network. The current Konah Power building includes a low-tech industrial-grade network with shielded twisted-pair (STP) wiring, preventing signal attenuation because of electromagnetic interference produced by the heavy machinery. Konah outsources its Internet connectivity, telephone, and e-mail services.

Table 11-1 summarizes the current state of the three companies and their networks.

 

Table 11-1. Current State of the Three Companies

Venti Systems Grandics Corporation Konah Power
Product Power modules Electronics Powertrain
Location Toronto-West Toronto-East Seattle
Number of Employees 100 (plus 1 in the home office in Japan) 60 (plus 1 in the home office in India) 60 (plus 2 in the small office in Germany)
Main Duties Office workers and engineering Engineering Laborers
Network
Topology Flat, switched Flat, switched Flat, switched
Connectivity UTP UTP STP
IP Addressing Flat, private Flat, private Flat, private
Proprietary Systems/Protocols NoneIP only NoneIP only NoneIP only
Servers Applications (and another to backup this applications server), e-mail, and CAD/CAM Applications, e-mail, and CAD/CAM Applications and CAD/CAM
Redundancy Application server backup only
Applications Business applications, e-mail, and CAD/CAM Business applications, e-mail, and CAD/CAM Business applications and CAD/CAM
E-Mail Corporate e-mail access Corporate e-mail access Outsourced
Edge Device Cisco 2514 router with firewall feature set Other vendor’s router with integrated firewall Leased from ISP
Internet Connectivity DSL DSL DSL
Internet Connectivity Backup
Business Continuity Application backup automatic. Backup done daily; tapes stored off site. Backup done daily; tapes stored on site. Backup done daily; tapes stored on site.
Remote Users (Including International Offices) VPN to router for e-mail and file sharing. VPN to router for e-mail and file sharing. No remote access supported. E-mail is outsourced and file sharing is done through e-mail.
Voice Old PBX New PBX Outsourced Centrex
Security Virus check and firewall router Virus check and firewall router Virus check and ISP firewall
QoS
Network Management Telnet to devices Telnet to devices Telnet to devices
© 2011 Belajar, Berbagi Suffusion theme by Sayontan Sinha