Resolution to the Challenge – Part 2 with Mohamed Sobair

 

Network Design Methodology in Action:
Challenge Resolution

 

In my first blog of this series, “A Design Challenge”, I proposed a network design challenge with the goal of applying the methodology described in the “Now What?” blog. Let’s analyze the challenge and find the design option that best fits according to that methodology.

 

 

List all of the business requirements in this challenge:

  1. Vision Tier-2 ISP wants a cost-effective solution.

  2. Vision Tier-2 ISP requires business continuity.

  3. Vision Tier-2 ISP wants to provide data (unicast and multicast), voice and VPN services across its 3 cities.

 

List all of the technical requirements in this challenge:

  1. Solution scalability.

  2. Solution simplicity.

  3. Resiliency for the physical layer and core.

  4. Increased policy control granularity.

  5. Intra-city (Intra-POP) connectivity.

  6. Inter-city (Inter-POP) connectivity.

 

Compare and contrast all options side-by-side against the requirements and constraints:

To resolve the challenge we can make a summary of all of the requirements and all the proposed solutions using a table like the one below.

 

Header 1Hierarchical RR design with 2 horizontal RRs in a BGP cluster (Design Option 1)Hierarchical RR design with 2 vertical RRs in a BGP cluster (Design Option 2)Hierarchical RR design with all city RRs in a single BGP cluster (Design Option 3)BGP Confederation with each city RRs in a single BGP cluster (Design Option 4)BGP Confederation with 2 horizontal city RRs, each in a different BGP cluster (Design Option 5)

BGP Confederation

with 2 vertical city RRs, each in a different BGP cluster (Design Option 6)

Business continuity / ResiliencyFully meets requirementPartially meets requirementPartially meets requirementPartially meets requirementFully meets requirementPartially meets requirement
ScalabilityFully meets requirementFully meets requirementFully meets requirementPartially meets requirementPartially meets requirementPartially meets requirement
SimplicityFully meets requirementFully meets requirementFully meets requirementPartially meets requirementPartially meets requirementPartially meets requirement
Policy ControlPartially meets requirementPartially meets requirementPartially meets requirementFully meets requirementFully meets requirementFully meets requirement
MP-BGP capabilityFully meets requirementFully meets requirementFully meets requirementFully meets requirementFully meets requirementFully meets requirement
Intra-City (Intra-POP) ConnectivityFully meets requirementDoes not meet requirementDoes not meet requirementDoes not meet requirementFully meets requirementDoes not meet requirement
Inter-City (Inter-POP) ConnectivityFully meets requirementPartially meets requirementPartially meets requirementPartially meets requirementFully meets requirementPartially meets requirement

 

Justify the option chosen (why correct) and the options not chosen (why incorrect):


Option 1 - The best option in this case. Hierarchical RR design with both city RRs in one cluster provides the following:

  1. Resiliency: With the hierarchical RR design with 2 horizontal RRs in a BGP cluster, there’s resiliency for the POPs as well as for the core: in case one RR in a cluster fails, the second RR takes over and provides intra-city and inter-city connectivity. The same applies if there is a physical link failure.

  2. Scalability: This option is very scalable since there’s no need for all PE routers to peer with each other, but rather all PE routers will peer only with the RRs in the corresponding cluster. An LSP will be created end-to-end between PE routers, minimizing the total number of TCP connections.

  3. Simplicity: Route reflection is a simpler and more scalable solution than confederation. It’s easier to configure and manage, and it doesn’t have the additional complexity of a full-mesh requirement within the sub AS BGP confederation.

  4. Policy Control: RRs provide limited policy control as compared with confederations. Hierarchical RR policy can be provided outside borders. However, with confederation BGP the policy can be provided within the sub AS and outside border.

  5. Intra-city (Intra-POP) connectivity: Intra-city (intra-POP) connectivity is possible since the horizontal RRs for each POPs are in a different BGP cluster, which assures BGP updates are not rejected, providing a secondary path between upper and lower POPs in case one RR fails. Within the same BGP cluster, one RR provides the connectivity between POPs and the secondary is on standby.

  6. Inter-city (Inter-POP) connectivity: Inter-city (inter-POP) connectivity is possible due to the hierarchical RR design. Both City “1” and City “3” RR peer with City “2” RR in a different BGP cluster, providing inter-city connectivity. This is a scalable and workable solution for inter-city connectivity, which allows the RR in a cluster to be a client of an RR in a different BGP cluster. It also provides the needed loop prevention mechanism.

 

Option 2 - Hierarchical RR design with 2 vertical RRs in a BGP cluster: The caveat and problem with this option is that resiliency can only apply to either the upper or the lower network. This option doesn’t provide intra-POP connectivity and only partial inter-POP connectivity, so the resiliency can only be partial because it basically splits the core into two halves. The upper POPs and lower POPs are isolated from each other. In addition, the policy control is only partial with this BGP RR design since it’s applied outside of the BGP border.

 

Option 3 - Hierarchical RR design with all city RRs in a single BGP cluster: The same problem arises here as with option 2.

 

Option 4 - BGP Confederation with each city RRs in a single BGP cluster: The same reasons as with options 2 and 3. In addition, simplicity is only partial because BGP Confederation is not as simple to configure, manage and troubleshoot as Route Reflection. Also, BGP Confederation is not as scalable as BGP Route Reflection or Hierarchical Route Reflection. BGP RR doesn’t eliminate the need of full mesh within the iBGP peers, but BGP Confederations still requires full-meshed iBGP peers within the sub AS.

 

Option 5 - BGP Confederation with 2 horizontal city RRs, each in a different BGP cluster: It can be a second option right after option 1; however with this option there are the same simplicity and scalability limitations as on option 4, which makes it less desirable than option 1.

 

Option 6 - BGP Confederation with 2 vertical city RRs, each in a different BGP cluster: The same problem arises here as with option 4.

 

Conclusion:

It is an integral part of network design to have a broad domain of technologies to be able to apply that knowledge to compare and contrast different solution options in order to meet the customer requirements, but also to justify your design choice. Sometimes the best option is not as obvious as it may seem, especially when many requirements are involved.

 

About the Author

Blog16-17- Mohamed Sobair pic.png

 

Mohamed Sobair, CCIE# 29645, MSc, ITiLv3, JNCIS & PMP has over 10 years of professional experience in the IT Industry providing solutions and consultation services for various Enterprise, Telecom and ISP customers. He is currently volunteering as a Subject Matter Expert for Cisco’s Expert-level program. Mohamed is passionate about design and architecture, usually participating in discussions and making contributions related to Cisco technologies on CLN and Cisco Support Community.

 

 

Here are a few additional ways for us to engage and keep the conversation going: