Routing Strategy for a Tenant Based Data Center Environment

October 3, 2020 | Author: Joanna Matthews | Category: N/A
Share Embed Donate


Short Description

1 Grand Valley State University Technical Library School of Computing and Information Systems 2015 Routing Strategy for ...

Description

Grand Valley State University

ScholarWorks@GVSU Technical Library

School of Computing and Information Systems

2015

Routing Strategy for a Tenant Based Data Center Environment Jacob Pataniczek Grand Valley State University

Follow this and additional works at: http://scholarworks.gvsu.edu/cistechlib Recommended Citation Pataniczek, Jacob, "Routing Strategy for a Tenant Based Data Center Environment" (2015). Technical Library. Paper 224. http://scholarworks.gvsu.edu/cistechlib/224

This Project is brought to you for free and open access by the School of Computing and Information Systems at ScholarWorks@GVSU. It has been accepted for inclusion in Technical Library by an authorized administrator of ScholarWorks@GVSU. For more information, please contact [email protected].

Routing Strategy for a Tenant Based Data Center Environment By Jacob Pataniczek A Project submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Information Systems at Grand

Valley State University September, 2015

_______________________________________________________________________________

Dr. Andrew Kalafut

Date

Table of Contents Table of Acronyms……………………………………………........................................................................... 3 Abstract……………………………………………………………………………………………………………………………………. 4 Basics of BGP……………………………………………………………………………………………………………………………. 4 Route Filtering ………………………………………………………………………………………………………………………… 8 BGP Configuration ………………………………………………………………………………………………………………... 10 MPLS …………………………………………………………………………………………………………………………………….. 12 VRF Configuration …………………………………………………………………………………………………………………. 14 Data Center VRF Configuration …………………………………………………………………………………………….. 16 Conclusion ……………………………………………………………………………………………………………………………. 19 References …………………………………………………………………………………………………………………………… 20

Jacob Pataniczek

2

Acronyms VRF VPN BGP iBGP eBGP MP-BGP TCP MPLS ISIS DC IGP EGP AS ASN WAN LAN IGP EGP PA L2VPN L3VPN PCI MED CE PE P PCI DMZ

Virtual Routing and Forwarding Virtual Private Networking Border Gateway Protocol Internal Border Gateway Protocol External Border Gateway Protocol Multiprotocol Border Gateway Protocol Transmission Control Protocol Multi Protocol Label Switching Intermediate System to Intermediate System Data Center Interior Gateway Protocol Exterior Gateway Protocol Autonomous System Autonomous System Number Wide Area Network Local Area Network Interior Gateway Protocol Exterior Gateway Protocol Path Attribute Layer 2 Virtual Private Network Layer 3 Virtual Private Network Payment Card Industry Multi-Exit Descriptor Customer Edge Router Provider Edge Router Provider Router Payment Card Industry Demilitarized Zone

Jacob Pataniczek

3

Abstract With so much emphasis on security in the current networking world, Data Centers have started to diverge from traditional flat Layer 2 networks and move toward a more secure, segregated architecture of routing and switching. This new architecture takes advantage of some of the same network principles that have been implemented throughout the rest of the Enterprise Network as a strategy to segment Customer Service Representatives from the rest of the users as a requirement of the Payment Card Industry (PCI) standards. This strategy relies heavily on leveraging existing Multiprotocol Label Switching (MPLS) networks using Virtual Routing and Forwarding (VRF) instances. These VRFs are essentially Virtual Local Area Networks (VLANs) for the Layer 3 routing world which allow for separate, unique routing tables within the same router. The objective of this project is to provide Junior Engineers in Network organizations the foundation for learning to build, troubleshoot, and support the new Data Center networks.

Basics of BGP The Border Gateway Protocol (BGP) is an Exterior Gateway Protocol (EGP) that was designed specifically for communication between Autonomous Systems (AS). The basic functions of BGP are simple, they are to advertise prefixes and lengths from an AS to their uplink to the internet, and to utilize its powerful algorithm to choose the best path between two prefixes. Because BGP is a best path routing protocol, it is different than most Interior Gateway Protocol’s (IGP’s) in that it does not typically nor does it by default support load balancing across multiple paths.

Jacob Pataniczek

4

Another manner in which BGP differs from most IGPs is that it does not use multicast for neighbor discovery. BGP is a connection oriented routing protocol, which means that it merely needs to be able to make a TCP (Transmission control protocol) connection to its peer in order to form a neighbor relationship. For this TCP connection, BGP utilizes the well known TCP port of 179. To the right, there is a finite state machine that depicts the various states that a BGP TCP connection may be in. Many IGPs utilize some type of metric to determine the best path through the network. This is yet another way that BGP differs from its interior routing brethren; BGP utilizes no metrics for path selection, rather it examines a series of Path Attributes (PAs), to determine the appropriate path to take through the network to get from router A to router B. These attributes include, but are not limited to, the AS_Path, Local Preference, MultiExit Descriptor (MED), and Weight. As previously stated, BGP was designed for communication between autonomous systems similar to the diagram that is to the left. When BGP is

Jacob Pataniczek

5

configured between two different Autonomous System Numbers (ASNs) it is referred to as an eBGP, External Border Gateway Protocol, peer or neighbor. The typical topology for an eBGP peer is to be a direct connection utilizing a /30 or /31 point-to-point network; although, it is possible by utilizing the eBGP multi-hop command within the BGP configuration to span across multiple hops. BGP may also be configured within the same ASN, although this presents some unique challenges when deployed in a large scale network because Internal Border Gateway Protocol (iBGP) requires a full mesh network architecture in order to properly function. In order to deploy a full mesh, you need to configure a BGP peer for each router within the network, which is okay if you have a network as depicted in the example image to the right; however, once you get into a large scale network such as and ISP, Internet

Service

Provider,

where you can have hundreds or

thousands

of

routers

utilizing iBGP, things can get unwieldy quickly. Most MSOs, multiple-system operators, and ISPs will deploy and use Route Reflectors to alleviate the issue of the full mesh requirement. For this, all routers peer to a set of routers, whose sole purpose is to collect and distribute routes.

Jacob Pataniczek

6

When a route is learned in BGP the network and the next hop IP Address are stored within war01mdvlmi#show bgp BGP table version is 14, local router ID is 172.19.114.21 Status codes: s suppressed, d damped, h history, * valid, > best, i internal, r RIB-failure, S Stale, m multipath, b backup-path, x bestexternal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop *> 0.0.0.0 172.19.221.22 *> 172.19.114.21/32 0.0.0.0 *> 172.19.118.192/28 0.0.0.0 *> 172.19.221.16/29 0.0.0.0 *> 172.19.243.160/28 0.0.0.0 war01mdvlmi#

Metric LocPrf Weight Path 0 20115 20115 i 0 32768 ? 0 0

32768 ? 32768 ?

0

32768 ?

the Route Information Base or RIB. When a route is advertised from one iBGP peer to another iBGP peer the next hop address is retained at the receiving peer, it is not manipulated at all. This functionality is why the use of route reflectors within an iBGP network allows a full mesh to be deployed with minimal BGP peers being configured on each router. The above excerpt shows how the network, next hop address and other path attributes are stored within BGP. BGP may also be run in conjunction with an IGP such as Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), or Intermediate System to Intermediate System, (ISIS) to at which point you would create an MP-BGP, MultiProtocol Border Gateway Protocol, peer. This is typically running on top of an ISPs iBGP network to run an MPLS, MultiProtocol Label Switching network. Once an ISP is running their MPLS network it allows for them to offer services such as Layer 2 and Layer 3 Virtual Private Networks, L2VPN/L3VPN. It is this MPLS network that allows for the segregation of networks via VRF, which our new Data Center Architecture relies upon.

Route Filtering Jacob Pataniczek

7

While BGP does the heavy lifting of directing the packets to take the best path to their destination, there needs to be one important question asked. How do we make sure that only the desired prefixes are entered into BGP and ultimately the routing tables? There are multiple methods of doing this; however, the most popular, and perhaps the most elegant, way to do this is by utilizing route maps, prefix lists, and community lists. The configuration that is used to create a route map is really quite simple, the only requirement for a functioning route map is ‘route-map ‘. Below are some examples of configuring route-maps.

The bottom

configuration in those examples is the minimum required to have a functioning route-map. A route map that is entered with no match statement will by default

route-map TO-VRF permit 100 description Remote_Site_Routes match ip address prefix-list TO-VRF set community 22269:1234 ! route-map FROM-VRF permit 100 description Default Entry match ip address prefix-list FROM-VRF set local-preference 125 ! route-map Match_All deny 10 !

match on all prefixes or IP addresses and either permit or deny depending on the functionality of the route-map. There is also the ability to match the prefixes against a list of predetermined address or addresses. This would be preferred over the example given to match all. How to permit all will be discussed shortly. The match statement in the example is what will be the method used for the purposes of the routing within the DC environment. Besides being able to match and filter prefixes, the route map also has the ability to manipulate the routing decisions that are made by BGP using the set commands. As with the second example, an Engineer may set certain path attributes (PAs) that are passed along with the prefixes within BGP. While the entire BGP route decision process is not within the scope of this discussion, it is worth knowing that the prefix or path that has the highest localJacob Pataniczek

8

preference will be the preferred path within BGP. This is a common tool that may be used to assure that packets will take a preferred path through the network for various reasons. One example of this would be to assure symmetric routing through a stateful firewall cluster. The route map may also be used to explicitly set the next hop address of a packet, or to set a community or tag for a prefix. To finish off the configuration of the route map, within the context of the DC routing design, the Engineer will need to configure a prefix list for the inbound and outbound advertisements. For the inbound routes, the only route that will be taken in is the default route. This is seen in ip prefix-list FROM-VRF seq 100 permit 0.0.0.0/0 ! ip prefix-list TO-VRF seq 1 deny 0.0.0.0/0

the example prefix list

to

the

left

ip prefix-list TO-VRF seq 5 permit 172.19.114.21/32 ip prefix-list TO-VRF seq 10 permit 172.19.221.16/29

named FROM-VRF.

ip prefix-list TO-VRF seq 15 permit 172.19.118.192/28 ip prefix-list TO-VRF seq 16 permit 172.19.243.160/27 le 32 !

The routes

outbound are

determined by the prefix list named TO-VRF. An important note to the example is the first sequenced prefix. Like the route map, the Engineer has the ability to permit or deny a prefix, and in this example, the first sequence is to deny the default route. Even though, like an Access List (ACL), there is an implicit deny all at the end of the prefix list; this sequence explicitly denies the default route from being advertised out to the world, thus preventing a routing loop for the default route within the network. For the next 3 sequences in the example, it is important to know that the prefix is the actual network and mask length. This means that sequence 5 is network 172.19.114.21 with a 32-bit mask, 255.255.255.255, or in other words, a mask with 32 significant bits. Sequence 10 is

Jacob Pataniczek

9

network 172.19.221.16 with a 29-bit mask, 255.255.255.248, or 29 significant bits. Now, the last sequence is where some magic can happen; take note of the last four characters ‘le 32.’ What this is saying is permit any network that matches the first 27 significant bits and has a subnet mask that is between 27 and 32 bits in length. Now, revisiting the idea of permitting all routes, to do this without having a route map with no match, it is a more common practice to add a prefix list that will permit 0.0.0.0/0 le 32.

BGP Configuration Anyone may copy a configuration from a prepared script, change some values, and get a router or switch to function. What makes and Engineer is someone that will take that script and learn how it works. This premise is the reasoning for beginning the configuration section with a basic office router; because to understand what is going on under the hood of the more complex routing design for the Data Center, there must be an understanding of the basics. The

very

basic

configuration to bring up a BGP neighbor requires only the

local

and

Autonomous

remote System

Number (ASN) to be set. For this example, the local ASN is set in the line ‘router bgp

router bgp 22269 bgp log-neighbor-changes redistribute connected route-map TO-VRF neighbor int-regn-wan peer-group neighbor int-regn-wan remote-as 20115 neighbor int-regn-wan password neighbor int-regn-wan ebgp-multihop 4 neighbor int-regn-wan timers 5 15 neighbor int-regn-wan send-community neighbor int-regn-wan allowas-in neighbor int-regn-wan soft-reconfiguration inbound neighbor int-regn-wan route-map FROM-VRF in neighbor int-regn-wan route-map TO-VRF out neighbor 172.19.221.22 peer-group int-regn-wan neighbor 172.19.221.22 description dtr02mdvlmi no auto-summary !

22269’. While it is not in the scope of this training, it is worth noting that the local ASN may also

Jacob Pataniczek

10

be set with the ‘neighbor local-as XXXXX’ command. While some lines of the configuration are self-explanatory, like ‘bgp log-neighbor-changes’, which logs neighbor state changes, others are more ambiguous. First, there needs to be a mechanism for the routes that are in the router’s routing table to be entered into BGP. This will be accomplished with redistribution, which takes routes that were entered into the routing table by one protocol, in our case directly connected, and distributes them into another routing protocol. Because there may be in an instance where certain routes or prefixes are not wanted in BGP, the routes are going to be filtered using a route-map and prefix-list. A peer-group is a set of BGP commands that are grouped together by a legible name rather than an IP Address. Peer-groups are a useful tool if there are going to be multiple neighbors on a router that are going to share a common set of attributes such as, password, timers, routemaps. For eBGP, the connection between the two peers are typically directly connected to each other; however, that does not necessarily need to be the case. This default setting may be overridden by using the ‘ebgp-multihop x’ command, where x is the number of hops that BGP is allowed to traverse to reach the neighbor, similar to a TTL (Time to Live). The timers are by default set for a keepalive of 60 seconds, and the hold time, which is three times the keepalive time, 180 seconds. With these default timers, a neighbor would be down for 3 minutes before it would be recognized as down. This is quite a long time for most networks, so they are reset to a keepalive of 5 seconds, and hold down, again 3 times the keepalive, of 15. This setting will reduce the amount of time that it takes for the link to be recognized as down, thus reducing the time to converge. There are some path attributes that are or are able to be passed from one AS to

Jacob Pataniczek

11

another. These attributes are transitive attributes; the community path attribute is among these. The communities are optional transitive path attributes, which means that it is up to the manufacturer if they do pass them to the next AS. Because of this, it is necessary to tell BGP to send the communities to the next neighbor. There are times when a change to the routing policies, route maps or prefix lists, is made, but the neighborship is not updated or activated. For these instances, it is necessary to reset the policies. The soft reconfiguration allows for this to be down without tearing down the BGP session with the neighbor. The soft reconfiguration may be down both inbound and outbound. The ability to reconfigure inbound must be explicitly configured. The final part of the peer-group is allowas-in. When BGP is configured between two AS, if the router receives a route that is from its own AS, it will drop the routes. With a WAN that is built on a Layer 3 VPN, this can pose a problem since the routers will not learn any routes from its own AS. This problem can be resolved with the allowas-in command.

MPLS Probably the one requirement for a Data Center network aside from security, is resiliency. The network must be up and available. To meet this requirement, it is necessary to utilize the powerful MPLS (Multiprotocol Label Switching) network of the Service Provider. It will be discussed in more detail a later as to the specifics for each of the tools and how they are leveraged. MPLS allows for the creation of a Layer 2 Virtual Private Network, or cross-connect (xconnect). The L2VPN creates a point to point connection between two Customer Edge (CE)

Jacob Pataniczek

12

devices. In other words, it makes it appear as though the connection between the CEs is a single Fiber Optic Cable or Ethernet Cable while each CE is actually connected to a Provider Edge (PE) Router with multiple Provider (P) routers in between. The key tool leveraged from MPLS is the Layer 3 VPN. What this does is create separate routing instances, similar to a VLAN within the same router. There are a couple ways to do this, Easy Virtual Network (EVN) or Virtual Routing and Forwarding (VRF). While EVN is available for use, and it simplifies the configuration quite a bit, it is not widely used and will not be discussed any further, but it is good to know that it is out there. As stated earlier, a VRF allows an Engineer to create multiple routing instances within a single router. This can be seen in the illustration to the right, where there are three separate VRFs within the router. Each VRF has its own separate routing table, and may have its own routing protocol such as OSPF, EIGRP, or IS-IS. This popular solution can solve some security issues, and may be used to segregate certain traffic such as credit card traffic to meet the standards set forth by the Payment Card Industry (PCI). There are two distinct versions of VRF, the first is the full-fledged VRF that utilizes the MPLS network and uses MP-BGP (Multiprotocol BGP). Secondly, VRF-Lite, performs the same functions as VRF; however, does not us MP-BGP and is not MPLS-aware. VRF-Lite is used to segregate routing environments on a single router as to across an entire network of routers.

VRF Configuration Jacob Pataniczek

13

The most basic configuration of a VRF instance requires two things, a name for the VRF definition and a route distinguisher (RD). The name of the VRF may be any alphanumeric word or set of characters you wish. The RD can be any number up to 64 bits in length using the following format, ASN:NN where NN is the number to fill up to the full 64 bits. The RD is used to, vrf definition CRPWAN rd 20115:1000018632 ! address-family ipv4 exit-address-family ! address-family ipv6 exit-address-family ! vrf definition BLGVPN rd 20115:1000018635 ! address-family ipv4 exit-address-family ! address-family ipv6 exit-address-family ! vrf definition GSTWAN rd 20115:1000130735 ! address-family ipv4 exit-address-family ! address-family ipv6 exit-address-family !

Jacob Pataniczek

as may be surmised from the name, distinguish which routes belong to each VRF that is configured on the router. Because of this use, a distinct RD must be used for each VRF. As it will be discussed later it is possible to use the RD to import routes from one VRF or in an MPLS Network another PE, into another VRF on the router.

When the RD is used in an import

statement it is then a Route Target or RT.

The import

statements would be configured in their own address family, which is more or less a way to separate between IPv4 and IPv6. This basic configuration may be seen in the example to the above.

14

router bgp 22269 bgp log-neighbor-changes redistribute connected route-map IPV4-BLGVPN-Connected-to-BGP redistribute static route-map IPV4-BLGVPN-Static-to-BGP redistribute eigrp 20 route-map IPV4-BLGVPN-EIGRP-to-BGP ! address-family ipv4 vrf BLGVPN redistribute connected route-map IPV4-BLGVPN-Connected-to-BGP redistribute static route-map IPV4-BLGVPN-Static-to-BGP redistribute eigrp 20 route-map IPV4-BLGVPN-EIGRP-to-BGP neighbor eBGP-BLGVPN peer-group neighbor eBGP-BLGVPN remote-as 20115 neighbor eBGP-BLGVPN password 7 0006141650560E neighbor eBGP-BLGVPN timers 1 3 neighbor eBGP-BLGVPN allowas-in neighbor eBGP-BLGVPN soft-reconfiguration inbound neighbor eBGP-BLGVPN route-map IPV4-BLGVPN-In in neighbor eBGP-BLGVPN route-map IPV4-BLGVPN-Out out neighbor 192.168.87.121 peer-group eBGP-BLGVPN neighbor 192.168.87.121 activate neighbor 192.168.87.245 peer-group eBGP-BLGVPN neighbor 192.168.87.245 activate exit-address-family address-family ipv4 vrf CRPWAN redistribute connected route-map IPV4-CRPWAN-Connected-to-BGP redistribute static route-map IPV4-CRPWAN-Static-to-BGP redistribute eigrp 20 route-map IPV4-CRPWAN-EIGRP-to-BGP neighbor eBGP_CRPWAN peer-group neighbor eBGP_CRPWAN remote-as 20115 neighbor eBGP_CRPWAN password 7 051F571B20424C0E09 neighbor eBGP_CRPWAN timers 1 3 neighbor eBGP_CRPWAN send-community both neighbor eBGP_CRPWAN allowas-in neighbor eBGP_CRPWAN soft-reconfiguration inbound neighbor eBGP_CRPWAN route-map IPV4-CRPWAN-In in neighbor eBGP_CRPWAN route-map IPV4-CRPWAN-Out out neighbor eBGP_CRPWAN maximum-prefix 5000 neighbor eBGP_CC_FCE_VoIP peer-group neighbor eBGP_CC_FCE_VoIP remote-as 65100 neighbor eBGP_CC_FCE_VoIP local-as 65101 neighbor eBGP_CC_FCE_VoIP password 7 110B1E15431F0E neighbor eBGP_CC_FCE_VoIP timers 1 3 neighbor eBGP_CC_FCE_VoIP send-community both neighbor eBGP_CC_FCE_VoIP allowas-in neighbor eBGP_CC_FCE_VoIP soft-reconfiguration inbound neighbor eBGP_CC_FCE_VoIP route-map IPV4-CC-FCE-VoIP-In in neighbor eBGP_CC_FCE_VoIP route-map IPV4-CC-FCE-VoIP-Out out neighbor 192.168.86.159 peer-group eBGP_CRPWAN neighbor 192.168.86.159 activate neighbor 192.168.86.181 peer-group eBGP_CC_FCE_VoIP neighbor 192.168.86.181 activate neighbor 192.168.87.123 peer-group eBGP_CRPWAN neighbor 192.168.87.123 activate exit-address-family

Jacob Pataniczek

15

The configuration snippet above is an example of how to configure BGP for VRFs on a router. The main idea from this configuration is to note there is a separate address-family for each VRF. Within these address families, it is necessary to redistribute the connected, static, and any routes from the IGP into BGP for each VRF. Along with needing to redistribute separately for each VRF, it should be noted that there are different route maps that are being used for within each VRF. This again reiterates the previous idea that the VRF creates a separate routing instance, with unique routing tables for each VRF on the router.

Data Center VRF Configuration Now that there has been a baseline of knowledge set for the operation of the principles that are going to be used within the DC, the strategy for routing within the DC

vrf context Eco_101 address-family ipv4 unicast route-target import 101:10 route-target import 400:20

may be discussed. The DC routing is

route-target import 40:20 route-target export 101:10

heavily dependent on the use of VRFs

address-family ipv6 unicast route-target import 101:10

and the leaking of routes therein. Each application set will be referred to as an ecosystem, and each ecosystem will reside within its own VRF. In addition to

route-target import 400:20 route-target import 40:20 route-target export 101:10 vrf context NDC-Blue_Transit ip route 0.0.0.0/0 192.168.87.96 254 address-family ipv4 unicast route-target import 101:10

the VRF for the ecosystems, there will

route-target import 400:20 route-target import 40:20

be two additional VRFs defined. These

route-target export 40:20 address-family ipv6 unicast

three VRFs are the Blue-Transit VRF, which will be the main transit between the ecosystems and the rest of the Jacob Pataniczek

route-target import 101:10 route-target import 400:20 route-target import 40:20 route-target export 40:20

16

enterprise network. The second VRF is the Interconnect VRF, which will be the VRF that

vrf context Eco_101 address-family ipv4 unicast route-target import 101:10

will provide interconnectivity between any

route-target import 400:20

other Data Center. The final VRF is the Public-

route-target export 101:10

route-target import 40:20 address-family ipv6 unicast

Transit VRF, which provides DMZ (Demilitarized

route-target import 101:10 route-target import 400:20

Zone) connectivity to the public internet. The examples to the right show how these are going to be configured. The routes from each VRF are

route-target import 40:20 route-target export 101:10 vrf context NDC-Blue_Transit ip route 0.0.0.0/0 192.168.87.96 254 address-family ipv4 unicast

going to be leaked into the Interconnect and

route-target import 101:10

Blue-Transit VRFs, and the routes from those

route-target import 40:20

route-target import 400:20 route-target export 40:20

VRFs are going to be leaked into the

address-family ipv6 unicast route-target import 101:10

ecosystem’s VRF. The way that the routes are leaked between the VRFs is by importing the RT

route-target import 400:20 route-target import 40:20 route-target export 40:20

of the VRF that is meant to be leaked. To illustrate how the routes will be leaked between the VRFs

the example to the left may be

referenced. One important note for the example is that the routes from the Eco_101 and Eco_102 VRFs are not leaked between each other. This allows for the routing for each ecosystem to remain autonomous from each other. This means that if there is an issue in Eco_101, it will not

Jacob Pataniczek

17

impact the routing of Eco_102. Below is another illustration that demonstrates this as well as

the overall routing for all VRFs including the transit VRFs to the internet and enterprise networks. Jacob Pataniczek

18

It was previously mentioned that along with security that network resiliency is key within a Data Center Network. With this design, it is possible for an Engineer to break connectivity between the separate DCs and the connectivity to the enterprise network is still entact. Not only is that connectivity still functioning, but the separate DC is advertising its routes to the enterprise network as well as to the DCs, so there would still be connectivity between the Data Centers. This connectivity would merely be taking a less desirable path. Conclusion To conclude, due to the ever-changing requirements of technologies and today’s emphasis on security and resiliency, Network Engineers are no longer implementing flat Layer 2 networks in Data Centers. One strategy is to move to a multitenant solution where each data center tenant resides within its own routing instances using Virtual Routing and Forwarding. There are two VRFs that hold all of the routes within the Data Center, one that connects to the Enterprise network, and another that is used for interconnectivity between geologically separated data centers. This design allows the engineer to isolate any issue that occurs within the routing of the tenant’s network to that individual VRF. This provides for better resiliency to the other tenants of the data center because they are no longer affected by the other applications or tenants.

Jacob Pataniczek

19

References

Wallace, Kevin. CCNP Routing and Switching ROUTE 300-101. Indianapolis: Cisco Press, 2015 Josyula, Venkata, Malcolm Orr, and Greg Page. Cloud Computing Automating the Virtualized Data Center. Indianapolis: Cisco Press, 2011. Santana, Gustavo. Data Center Virtualization Fundamentals. Indianapolis: Cisco Press, 2013. Kocharians, Narbik, and Peter Paluch. CCIE Routing and Switching v5.0. 5th ed. Vol. 1. Indianapolis: Cisco Press, 2014. Kocharians, Narbik, and Terry Vinson. CCIE Routing and Switching v5.0. 5th ed. Vol. 2. Indianapolis: Cisco Press, 2014. De Ghein, Luc. MPLS Fundamentals. Indianapolis: Cisco Press, 2007. “Virtualized Multi-Tenant Data Center Solution for Infrastructure-as-a- Service” Cisco. 2010. 13 July 2015 “Virtualized Multiservice Data Center (VMDC) 3.0.1 Design Guide” Cisco. 2013. 13 July 2015

Jacob Pataniczek

20

View more...

Comments

Copyright � 2017 SILO Inc.