| 0 comments ]

Overview

Add a note hereAfter completing this chapter, you will be able to:

  • Add a note here Design addressing solutions to support summarization

  • Add a note hereDesign routing solutions to support summarization, route filtering, and redistribution

  • Add a note hereDesign scalable EIGRP routing solutions for the enterprise

  • Add a note hereDesign scalable OSPF routing solutions for the enterprise

  • Add a note hereDesign scalable BGP routing solutions for the enterprise

Add a note hereThis chapter examines a select number of topics on both advance IP addressing and select design issues with Border Gateway Protocol (BGP), Enhanced Interior Gateway Routing Protocol (EIGRP), and Open Shortest Path First (OSPF). As one would expect, advanced IP addressing and routing protocol design encompasses a large amount of detail that has already filled a number of books on routing protocols and networking best practices. The text will parallel topics covered in the Design course.

Designing Advanced IP Addressing

Add a note here Designing IP addressing at a professional level involves several advanced considerations. This section reviews the importance of IP address planning and selection and the importance of IP address summarization. It also discusses some applications of summary addressing.


IP Address Planning as a Foundation

Add a note hereStructured and modular cabling plant and network infrastructures are ideal for a good design with low maintenance and upgrade costs. In similar fashion, a well-planned IP addressing scheme is the foundation for greater efficiency in operating and maintaining a network. Without proper planning in advance, networks may not be able to benefit from route summarization features inherent to many routing protocols.

Add a note hereRoute summarization is important in scaling any routing protocol. However, some existing IP addressing schemes may not support summarization. It takes time and effort to properly allocate IP subnets in blocks to facilitate summarization. The benefit of summarized addresses is reduced router workload and routing traffic. Although modern router CPUs can handle a vastly increased workload as compared to older routers, reducing load mitigates the impact of periods of intense network instability. In general, summary routes dampen out or reduce network route churn, making the network more stable. In addition, summary routes lead to faster network convergence. Summarized networks are simpler to troubleshoot because there are fewer routes in the routing table or in routing advertisements, compared to nonsummarized networks.

Add a note hereJust as using the right blocks of subnets enables use of more efficient routing, care with subnet assignments can also support role-based functions within the addressing scheme structure. This in turn enables efficient and easily managed access control lists (ACL) for quality of service (QoS) and security purposes.

Add a note hereIn addition to allocating subnets in summarized blocks, it is advantageous to choose blocks of addresses within these subnets that can be easily summarized or described using wildcard masking in ACLs. With a well-chosen addressing scheme, ACLs can become much simpler to maintain in the enterprise.

Add a note here Summary Address Blocks

Add a note here Summary address blocks are the key to creating and using summary routes. How do you recognize a block of addresses which can be summarized? A block of IP addresses might be able to be summarized if it contains sequential numbers in one of the octets. The sequence of numbers must fit a pattern for the binary bit pattern to be appropriate for summarization. The pattern can be described without doing binary arithmetic.

Add a note hereFor the sequential numbers to be summarized, the block must be x numbers in a row, where x is a power of 2. In addition, the first number in the sequence must be a multiple of x. The sequence will always end before the next multiple of x.

Add a note hereFor example, any address block that matches the following is able to be summarized:

  • Add a note here128 numbers in a row, starting with a multiple of 128 (0 or 128)

  • Add a note here64 numbers in a row, starting with a multiple of 64 (0, 64, 128, or 192)

  • Add a note here32 numbers in a row, starting with a multiple of 32

  • Add a note here16 numbers in a row, starting with a multiple of 16

Add a note hereIf you examine 172.19.160.0 through 172.19.191.0, there are 191 – 160 + 1 = 32 numbers in a row, in sequence in the third octet. Note that 32 is 25, a power of 2. Note also that 160 is a multiple of 32 (5 * 32 = 160). Because the range meets the preceding conditions, the sequence 172.19.160.0 through 172.19.191.0 can be summarized.

Add a note hereFinding the correct octet for a subnet-style mask is fairly easy with summary address blocks. The formula is to subtract N from 256. For example, for 32 numbers in a row, the mask octet is 256 – 32 = 224. Because the numbers are in the third octet, you place the 224 in the third octet, to form the mask 255.255.224.0.

Add a note hereA summary route expressed as either 172.19.160.0, 255.255.224.0, or as 172.169.160/19 would then describe how to reach subnets starting with 172.19.160.0 through 172.19.191.0.

Add a note here Changing IP Addressing Needs

Add a note hereIP address redesign is needed to adapt to changes in how subnets are now being used. In some networks, IP subnets were initially assigned sequentially. Summary address blocks of subnets were then assigned to sites to enable route summarization.

Add a note hereHowever, new requirements are developing requiring additional subnets:

  • Add a note here IP telephony: Additional subnets or address ranges are needed to support voice services. In some cases, the number of subnets double when IP telephony is implemented in an organization.

  • Add a note here Layer 3 switching at the edge: Deploying Layer 3 switching to the network edge is another trend driving the need for more subnets. Edge Layer 3 switching can create the need for a rapid increase in the number of smaller subnets. In some cases, there can be insufficient address space, and readdressing is required.

  • Add a note here Network Admission Control (NAC): NAC is also being deployed in many organizations. Some Cisco 802.1X and NAC deployments are dynamically assigning VLANs based on user logins or user roles. In these environments, ACLs control connectivity to servers and network resources based on the source subnet, which is based on the user role.

  • Add a note here Corporate requirements: Corporate governance security initiatives are also isolating groups of servers by function, sometimes called “segmentation.” Describing “production” and “development” subnets in an ACL can be painful unless they have been chosen wisely. These new subnets can make managing the network more complex. Maintaining ad hoc subnets for voice security and other reasons can be time-consuming. When it is possible, describing the permitted traffic in a few ACL statements is a highly desirable. Therefore, ACL-friendly addressing which can be summarized helps network administrators to efficiently manage their networks.

Add a note here Planning Addresses

Add a note hereThe first step in implementing ACL-friendly addressing is to recognize the need. In an environment with IP phones and NAC implemented, you will need to support IP phone subnets and NAC role subnets in ACLs. In the case of IP phones, ACLs will probably be used for both QoS and voice-security rules. For NAC role-based subnets, ACLs will most likely be used for security purposes.

Add a note hereServers in medium-to-large server farms should at least be grouped so that servers with different functions or levels of criticality are in different subnets. That saves listing individual IP addresses in lengthy ACLs. If the servers are in subnets attached to different access switches, it can be useful to assign the subnets so that there is a pattern suitable for wildcarding in ACLs.

Add a note hereIf the addressing scheme allows simple wildcard rules to be written, those simple ACL rules can be used everywhere. This avoids maintaining per-location ACLs that need to define source or destination addresses to local subnets. ACL-friendly addressing supports maintaining one or a few global ACLs, which are applied identically at various control points in the network. This would typically be done with a tool such as Cisco Security Manager.

Add a note hereThe conclusion is that it is advantageous to build a pattern into role-based addressing and other addressing schemes so that ACL wildcards can match the pattern. This in turn supports implementing simpler ACLs.


Applications of Summary Address Blocks

Add a note hereSummary address blocks addressing can be used to support several network applications:

  • Add a note hereSeparate VLANs for voice and data, and even role-based addressing

  • Add a note hereBit splitting for route summarization

  • Add a note hereAddressing for virtual private network (VPN) clients

  • Add a note hereNetwork Address Translation (NAT)

Add a note here These features are discussed in greater detail in the following sections.

Add a note here Implementing Role-Based Addressing

Add a note hereThe most obvious approach to implement role-based addressing is to use network 10. This has the virtue of simplicity. A simple scheme that can be used with Layer 3 closets is to use 10.number_for_closet.VLAN.x /24 and avoid binary arithmetic. This approach uses the second octet for closets or Layer 3 switches, the third octet for VLANs, and the fourth octet for hosts.

Add a note hereIf you have more than 256 closets or Layer 3 switches to identify in the second octet, you might use some bits from the beginning of the third octet, because you probably do not have 256 VLANs per switch.

Add a note hereAnother approach is to use some or all of the Class B private addressing blocks. This approach will typically involve binary arithmetic. The easiest method is to allocate bits using bit splitting. An example network is 172.0001 xxxx.xxxx xxxx.xxhh hhhh. In this case, you start out with 6 bits reserved for hosts in the fourth octet, or 62 hosts per subnet (VLAN). The x bits are to be split further.

Add a note hereThis format initially uses decimal notation to the first octet and binary notation in the second, third, and fourth octets to minimize conversion back and forth.

Add a note hereIf you do not need to use the bits in the second octet to identify additional closets, you end up with something like 172.16.cccc cccR.RRhh hhhh:

  • Add a note hereThe c characters indicate that 7 bits allow for 27 or 128 closet or Layer 3 switches.

  • Add a note hereThe R characters indicate 3 bits for a role-based subnet (relative to the closet block), or 8 roles per switch.

  • Add a note hereThe h characters indicate 6 bits for the 62-host subnets specified.

Add a note hereThis addressing plan is enough to cover a reasonably large enterprise network.

Add a note hereAnother 4 bits are available to work with in the second octet if needed.

Add a note hereUsing a role-aware or ACL-friendly addressing scheme, you can write a small number of global permit or deny statements for each role. This greatly simplifies edge ACL maintenance. It is easier to maintain one ACL for all edge VLANs or interfaces than different ACLs for every Layer 3 access or distribution switch.

Add a note here Bit Splitting for Route Summarization

Add a note hereThe previous bit-splitting technique has been around for a while. It can also be useful in coming up with summary address block for routing protocols if you cannot use simple octet boundaries. The basic idea is to start with a network prefix, such as 10.0.0.0, or a prefix in the range 172.16.0.0 to 172.31.0.0, 192.168.n.0, or an assigned IP address. The remaining bits can then be thought of as available for use for the area, subnet, or host part of the address. It can be useful to write the available bits as x, then substitute a, s, or h as they are assigned. The n in an address indicates the network prefix portion of the address, which is not subject to change or assignment.

Add a note here Generally, you know how big your average subnets need to be in buildings. (A subnet with 64 bits can be summarized and will cover most LAN switches.) That allows you to convert six x bits to h for host bits.

Add a note hereYou can then determine how many WAN links you need and how many you are comfortable putting into one area to come up with how many a bits you need to assign. The leftover bits are s bits. Generally, one does not need all the bits, and the remaining bits (the a versus s boundary) can be assigned to allow some room for growth.

Add a note hereFor example, suppose 172.16.0.0 is being used, with subnets of 62 hosts each. That commits the final 6 bits to host address in the fourth octet. If you need 16 or fewer areas, you might allocate 4 a bits for area number, which leaves 6 s bits for subnet. That would be 26 or 64 subnets per area, which is quite a few.

Add a note here Example—Bit Splitting for Area 1

Add a note hereThis example illustrates how the bit-splitting approach would support the addresses in OSPF area 1. Writing “1” as four binary bits substitutes “0001” for the a bits. The area 1 addresses would be those with the bit pattern 172.16.0001 ssss.sshh hhhh. This bit pattern in the third octet supports decimal numbers 16 to 31. Addresses in the range 172.16.16.0 to 172.16.31.255 would fall into area 1. If you repeat this logic, area 0 would have addresses 172.16.0.0 to 172.16.15.255, and area 2 would have addresses 172.16.32.0 to 172.16.47.255.

Add a note hereSubnets would consist of an appropriate third octet value for the area they are in, together with addresses in the range 0 to 63, 64 to 127, 128 to 191, or 192 to 255 in the last octet. Thus, 172.16.16.0/26, 172.16.16.64/26, 172.16.16.128/26, 172.16.16.192/26, and 172.16.17.0/26 would be the first five subnets in area 1.

Add a note hereOne recommendation that preserves good summarization is to take the last subnet in each area and divide it up for use as /30 or /31 subnets for WAN link addressing.

Add a note hereFew people enjoy working in binary. Free or inexpensive subnet calculator tools can help. For those with skill writing Microsoft Excel spreadsheet formulas, you can install Excel Toolkit functions to help with decimal-to-binary or decimal-to-hexadecimal conversion. You could then build a spreadsheet that lists all area blocks, subnets, and address assignments.

Add a note here Addressing for VPN Clients

Add a note hereFocusing some attention on IP addressing for VPN clients can also provide benefits. As role-based security is deployed, there is a need for different groupings of VPN clients. These might correspond to administrators, employees, different groups of contractors or consultants, external support organizations, guests, and so on. You can use different VPN groups for different VPN client pools.

Add a note hereRole-based access can be controlled via the group password mechanism for the Cisco VPN client. Each group can be assigned VPN endpoint addresses from a different pool. Traffic from the user PC has a VPN endpoint address as its source address.

Add a note here The different subnets or blocks of VPN endpoint addresses can then be used in ACLs to control access across the network to resources, as discussed earlier for NAC roles. If the pools are subnets of a summary address block, routing traffic back to clients can be done in a simple way.

Add a note here NAT in the Enterprise

Add a note hereNAT is a powerful tool for working with IP addresses. It has the potential for being very useful in the enterprise to allow private internal addressing to map to publicly assigned addresses at the Internet connection point. However, if it is overused, it can be harmful.

Add a note hereNAT and Port Address Translation (PAT) are common tools for firewalls. A common approach to supporting content load-balancing devices is to perform destination NAT. A recommended approach to supporting content load-balancing devices is to perform source NAT. As long as NAT is done in a controlled, disciplined fashion, it can be useful.

Add a note hereAvoid using internal NAT or PAT to map private-to-private addresses internally. Internal NAT can make network troubleshooting confusing and difficult. For example, it would be difficult to determine which network 10 in an organization a user is currently connected to.

Add a note hereInternal NAT or PAT is sometimes required for interconnection of networks after a corporate merger or acquisition. Many organizations are now using network 10.0.0.0 internally, resulting in a “two network 10.0.0.0” problem after a merger.

Add a note hereIt is also a recommended practice to isolate any servers reached through content devices using source NAT or destination NAT. These servers are typically isolated because the packets with NAT addresses are not useful elsewhere in the network. NAT can also be used in the data center to support small out-of-band (OOB) management VLANs on devices that cannot route or define a default gateway for the management VLAN, thereby avoiding one management VLAN that spans the entire data center.

Add a note here NAT with External Partners

Add a note hereNAT also proves useful when a company or organization has more than a couple of external business partners. Some companies exchange dynamic routing information with external business partners. Exchanges require trust. The drawback to this approach is that a static route from a partner to your network might somehow get advertised back to you. This advertisement, if accepted, can result in part of your network becoming unreachable. One way to control this situation is to implement two-way filtering of routes to partners: Advertise only subnets that the partner needs to reach, and only accept routes to subnets or prefixes that your staff or servers need to reach at the partner.

Add a note hereSome organizations prefer to use static routing to reach partners in a tightly controlled way. The next hop is sometimes a virtual Hot Standby Router Protocol (HSRP) or Gateway Load Balancing Protocol (GLBP) address on a pair of routers controlled by the partner.

Add a note hereWhen the partner is huge, such as a large bank, static routing is too labor intensive. Importing thousands of external routes into the internal routing protocol for each of several large partners causes the routing table to become bloated.

Add a note hereAnother approach is to terminate all routing from a partner at an edge router, preferably receiving only summary routes from the partner. NAT can then be used to change all partner addresses on traffic into a range of locally assigned addresses. Different NAT blocks are used for different partners. This approach converts a wide range of partner addresses into a tightly controlled set of addresses and will simplify troubleshooting. It can also avoid potential issues when multiple organizations are using the 10.0.0.0/8 network.

Add a note here If the NAT blocks are chosen out of a larger block that can be summarized, a redistributed static route for the larger block easily makes all partners reachable on the enterprise network. Internal routing will then have one route that in effect says “this way to partner networks.”

Add a note hereA partner block approach to NAT supports faster internal routing convergence by keeping partner subnets out of the enterprise routing table.

Add a note hereA disadvantage to this approach is that it is more difficult to trace the source of IP packets. However, if it is required, you can backtrack and get the source information through the NAT table.

0 comments

Post a Comment