AWS Networking – Part II: Create VPC – AWS Console

The first thing to do when we create a VPC is to log in to the AWS console. Then we select the AWS Region where we want to launch our VPC. We are going to use VPC Region Europe (London) eu-west-2. As the last step, we give the name to VPC and associate a CIDR block 10.10.0.0/16 to it.

Figure 1-3: Virtual Private Cloud (VPC) – Example VPC.

AWS Networking – Part I: Virtual Private Cloud (VPC) Introduction

AWS Virtual Private Cloud (VPC) is a virtual network for Amazon Elastic Cloud Compute instances (EC2) within AWS Region. AWS Regions, in turn, belongs to the global AWS Cloud environment. Each AWS Region consists of three or more physical data centers, Availability Zones (AZ). At the time of writing, Seoul and Tokyo have four, and Northern Virginia has six AZs. All other regions have three AZs. VPC spans over regional AZs but not between AWS Regions. In other words, VPCs are region-specific virtual networks. 

A VPC has to have a CIDR (Classless Interdomain Routing) IP block attached to it. The VPC CIDR defines the IP range that we can use when creating subnets to VPC. CIDR range is VPC specific and can overlap with other VPC’s CIRD range. If there should be VPC-to-VPC inter-connection, VPC CIDR IP ranges have to be unique per VPC. 

We can allocate subnets for EC2 instances from the VPC’s CIDR range. Subnets are AZ-specific, and they can’t be span from one AZ to another. Subnets are classified either as Public Subnets or Private Subnets. Public Subnet has a route to Internet GW (Internet Gateway) in its Routing Table (RT). EC2 instances launched in a Public Subnet have to have a public IPv4 address in order to have an Internet connection. Note that IPv6 addresses are always assigned from the public address space. EC2 launched in a Private Subnet doesn’t need a public IPv4 address, they can have an Internet connection through the NAT GW. To allow Internet connection to EC2 instances in Private Subnet, we need to add a route to NAT GW into the Private Subnet Routing Table. We can allow a stateful egress-only Internet connection for EC2 instances with IPv6 addresses in Private Subnet by using Egress-Only Internet GW. This way EC2 instance has an Internet connection but hosts on the internet can’t initiate a connection to EC2. IP connectivity between EC2 instances within VPC is established between private IP address even if one of the EC2s is attached to Public Subnet and has a Public IP address. VPC has a main Routing Table that is used with subnets which we don’t define subnet-specific RT.

Each VPC also has a default Network Access Control List (NACL). The default NACL is bind to all subnets in VPC by default. NACL is stateless by nature, traffic to and from the subnet has to be allowed in both inbound and outbound directions. The default NACL allows all ingress/egress traffic.

Figure 1-1 illustrates our example VPC and its relationship to AWS Availability Zones, AWS Regions, and AWS Account. When we create VPC, we first have to log on to our AWS account. Next, we select an AWS Region, in our case Europe (London) eu-west-2. Then we choose Availability Zones for subnets. In our case, network 10.10.0.0/24 is a Public Subnet in the AZ eu-west-2c, and network 10.10.1.0/24 is a Private Subnet in the AZ eu-west-2a. As the last step, we create subnet-specific Routing Tables where we can later add subnet-specific routes.

Figure 1-1: Virtual Private Cloud (VPC) Basic Building Blocks.

LISP – OMP – BGP EVPN Interoperability – Part VIII: LISP, OMP, and BGP EVPN Comparison

IP reachability

Every Overlay Network solution requires IP reachability between edge devices via Underlay Network. This section explains the basic routing solution in Underlay Network from Campus Fabric, SD-WAN, and Datacenter Fabric perspectives. Figure 7-1 illustrates the IP reachability requirements for Campus Fabric, SD-WAN, and Datacenter Fabric.

Figure 7-1: IP Reachability Requirements.

LISP – OMP – BGP EVPN Interoperability – Part VII: End-to-End Data-Plane Operation

Introduction

This chapter introduces Data-Plane operation and explains how the data packets from EP3 (IP 172.16.30.3) in Datacenter Fabric are forwarded via SD-WAN to EP1 (IP 172.16.100.10) in Campus Fabric. (1) EndPoint3 sends the ICMP Request packet to its gateway switch Leaf-11. Leaf-11 makes routing decisions based on the VRF NWKT routing table. Before forwarding the packet, Leaf-11 adds a VXLAN header where it uses L3VNI 10077. It also sets the outer IP header where it uses the Border-Leaf-13 tunnel interface’s IP address 192.168.50.13 as a destination. Spine-1 routes the packet to Border-Leaf-13 based on the outer IP address. Border-Leaf-13 notices that the destination IP address of the received IP packet belongs to its’s NVE1 tunnel interface. It removes the outer IP header and based UDP destination port it notices that this is VXLAN encapsulated packet. It knows that L3VNI 10077 belongs to VRF NWKT. It strips off the VXLAN header and routes the packet to vEdge-2. The ingress interface towards DC in vEdge-2 belongs to VPN 10. vEdge-2 consults its routing table. Based on it, vEdge-2 constructs tunnel headers and sends ICMP Request to vEdge-1 via Public-Internet using MPLS Label 1003 as a VPN identifier. Routers in Internet routes packet based on the outer destination IP address. When vEdge-1 receives the packet, it notices that the destination IP address is its’ Public IP address. It first removes the outer IP header. Then it checks the tunnel header. Based on the Label value 1003, it knows that packet belongs to VPN 10. It consults the VPN 10 RIB and routes the packet to Border-PxTR-13. The ingress interface on Border-PxTR-13 belongs to VRF 100_NWKT that belongs to LISP Instance 100. It checks the Instance 100 specific LISP mapping in order to know how it should route the packet. The LISP mapping Database does not contain the information because this is the first packet to destination 172.16.100.10. Border-PxTR-13 sends a LISP Map-Request message to MapSrv-22, which replies with a LISP Map-Reply message, where it describes the RLOC of Edge-xTR-11 that has registered the IP address 172.16.100.10. I have excluded the Map-Request/Reply processes from figure 6-1 to keep the figure simple. Border-Leaf-13 encapsulates the ICMP Request packet with a tunnel header. It sets the Instance-Id 100 on the VXLAN header and adds the outer IP header where it uses the Edge-xTR-11’s IP address 192.168.0.13 as a destination address. Core-1 routes the packet to Edge-xTR-11 based on the outer IP header destination address. Edge-xTR-11 processes the ingress IP packet because the destination IP address belongs to it. Based on the destination UDP port 4789, it knows that the following header is a VXLAN header. Edge-xTR-11 knows that the LISP Instance-Id 100 is bind to BD 100. Because Edge-xTR-11 has an L3 interface in BD 100, it resolves the MAC address for the IP address 172.16.100.10 from the ARP table and the egress interface for the MAC from the MAC address table. EP1 processes the ICMP Request packet and sends the ICMP Reply to EP3.

Figure 6-1:End-to-End Data-Plane Operation.

LISP – OMP – BGP EVPN Interoperability – Part VI: LISP Control-Plane – Registering External IP Prefixes

Introduction

This chapter introduces how Border-PxTR-13 registers the external IP prefix 172.16.30.0/24 received as a BGP update from vEdge-1 to MapSrv-22 using LISP Map-register messages. Chapter 2 explains the LISP RLOC-to-EID mapping process in detail so this chapter just briefly recaps the operation. Figure 5-1 illustrates the overall process. vEdge-1 sends a BGP Update message where it describes the NLRI for prefix 172.16.30.0/24. Border-PxTR-13 first imports the information into the LISP processes. Next, it sends a LISP Map-Register message to MapSrv-22. In addition to IP prefix information, the Map-Register message carries Locator Record information that describes the destination IP address used in the outer IP header (tunnel header) when devices route IP packets towards the advertised subnet.  

Figure 5-1:Overall Control-Plane Operation: OMP to LISP

LISP – OMP – BGP EVPN Interoperability – Part V: BGP EVPN MAC Advertisement Route (Type 2).

Introduction

We have seen in previous chapters how the IP address 172.16.100.10 assigned to EP1 is advertised within the LISP domain and advertised as an aggregate route all the way down to Leaf-11 in the BGP EVPN domain. This chapter first explains how the EP3 ‘s IP address 172.16.30.3 is first advertised by Leaf-11 as BGP EVPN MAC Advertisement Route (Route-Type 2) via Spine-1 to Border-Leaf-13. Next, you will learn how Border-Leaf-13 advertises the aggregate route 172.16.30.0/24 to SD-WAN edge device vEdge-2. The last section briefly shows how the routing information is propagated over the SD-WAN. The BGP EVPN NLRI MAC Advertisement Route carries to MPLS Labels which identifies L2VN (10000) and L3VN (10077). In our example, VLAN 10 is part of the VRF NWKT and it is attached to L2VN 10000. L3VNI for VRF NWKT is 10077. 

Figure 4-1:Overall Control-Plane Operation: BGP EVPN to OMP to LISP.

Continue reading

LISP – OMP – BGP EVPN Interoperability – Part IV: BGP EVPN IP Prefix Route (Type 5)

Introduction

Figure 3-1 shows the Overlay Network Control-Plane interaction. Edge-xTR-11 registers reachability information (IP address and location) of EP1 to MapSrv-22. MapSrv-22 stores the information into the Mapping database and then installs it to RIB. Then MapSrv-22 exports the information to the BGP process and sends BGP Update using VPNv4 address format to Border-PxTR-13. Border-PxTR-13 imports NLRI into BRIB and RIB. Then it sends BGP Update to the local SD-WAN edge device vEdge-1. After importing the received information into BRIB and RIB, vEdge-1 exports the information to the OMP process and advertises it over a DTLS connection to vSmart (SD-WAN Control-Plane node). vSmart, in turn, advertises information to remote SD-WAN device vEdge-2. After importing the received information into the RIB, vEdge-2 exports the information to the BGP process and sends BGP Update to Border-Leaf-13. Border-Leaf-13 installs the information into BRIB and RIB. Next, Border-Leaf-13 sends BGP Update message using EVPN route type 5 (IP Prefix Route) to its iBGP peer Spine-1 (BGP Route-Reflector) using auto-generated Route-Target 65030:10077. Spine-1 forwards the BGP Update to Leaf-1, which imports the information into L3VNI used with VRF NWKT and installs the route into the VRF NWKT RIB.

Figure 3-1: Overall Control-Plane Operation.

LISP – OMP – BGP EVPN Interoperability – Part III: SD-WAN Control Plane

 Introduction

Figure 2-1 shows the Control Plane operation when host EP1 using IP 172.16.100.10/32 joins the network. In the previous chapter, we saw how Edge-xTR-11 learned the IP address and registered it to MapSrv-22 by using the LISP Map-register Message where the Instance-Id 100 represents Virtual Network-Id (VN-Id). MapSrv-22, in turn, advertised the NLRI to Border-PxTR-13 as BGP VPNv4 Update message where extended community RT 1:100 (=VN-Id) is used as a kind of VPN identifier (BGP VPNv4 route import/export policy is based on RT value). This chapter first explains how Border-PxTR-13 sends BGP IPv4 Update message to local SD-WAN device vEdge-1. The eBGP peering between Border-PxTR-13 and vEdge1 is VRF based and BGP updates over it don’t carry any VN-Id. vEdge-1 imports the routing information from BRIB to RIB. Then it advertises the routing information by using OMP (Overlay Management Protocol) to the SD-WAN centralized Control Plane vSmart over the DTLS tunnel using System-IP as an originator-Id and VPN label 1003 as a VN-Id. vSmart forwards this update to SD-WAN device vEdge-2 located in Datacenter. vEdge-2 installs the route into the routing table. After that, it exports the routing information from the RIB to the BGP process and sends the BGP IPv4 Update message to Border-Leaf-13 over VRF NWKT eBGP peering without VN-Id.

Figure 2-1: Overall Control-Plane Operation.

LISP – OMP – BGP EVPN Interoperability – Part II: VPNv4 Update from Control Plane to Border-PxTR

The previous chapter describes how Edge-xTR-11 used LISP Map-Register message to advertise EID-to-RLOC information to MapServ-22. It also explained how MapSrv-22, as a role of Mapping Server, stores the information into Mapping Data Base. MapSrv-22 is also Map-Resolver. This means that when it receives the LISP Map-Requestmessage from the xTR device, it will respond with a Map-Reply message. If MapSrv-22 knows the EID-to-RLOC mapping, it places this information into the Map-Reply message. If MapSrv-22 doesn’t have mapping information, it instructs requesting xTR to forward traffic to its Proxy-xTR. This, however, is not the case in our example. What we want to do is advertise the EP1 reachability information to Border-PxTR. In order to do that, we need to a) export EID-to-RLOC information from the Mapping Data Base to instance-specific VRF_100 RIB. Then we can advertise it by using BGP and because we want to include virtual network identifier into update we use MP-BGP VPNv4 because there we have Route Target Attribute. The next sections describe the process in detail.

Phase 1: Map-Server - RIB Update

LISP Map-Server doesn’t install EID-to-RLOC mapping information from the Mapping Database into a RIB by default. To do that we need to export the information from the LISP Mapping DataBase to RIB by using the LISP Instance-specific command route-export site-registrations.  Example 1-6 illustrates the update process. Example 1-7 shows the RIB entry concerning EP1 IP address 172.16.100.10/32 in VRF 100_NWKT. Due to redistribution, the route is shown as directly connected, via Null0. If you take a look at the timestamps in example 1-6 and compare it to timestamps in example 1-3, you will see that the RIB update happens right after the unreliable EID-to-RLOC registration process.

 Complete device configuration can be found in chapter 1 Appendix 1.

Figure 1-10: EID-to-RLOC information from LISP to RIB.

LISP – OMP – BGP EVPN Interoperability – Part I: LISP EID-to-RLOC Registration

I have written a couple of books about Network Virtualization Overlay over Layer 3 (NVO3). My first book was about Datacenter network virtualization based on BGP L2VPN EVPN. After that, I wrote a book about Campus networks based on LISP. In my latest book, I introduced the Cisco SD-WAN solution running OMP in Control-Plane. I wanted to write one more book where I combine these three different NVO3 solutions. I haven’t used pictures in the “About This Book” section in my previous books but now I decided to do that because one picture tells more than 1000 words. The figure below combines these three NVO3 solutions and illustrates what is needed to have IP connectivity between EP1 in the LISP domain and EP2 in the BGP EVPN domain. After reading this book you should be able to understand the processes of how IP reachability information about local hosts are advertised from the LISP domain over the SD-WAN to BGP EVPN domain and another way around. I wanted to keep this complex solution as simple as possible. That is why I didn’t include any redundancy.

Cisco SD-WAN

Table of Contents

Chapter 1: Setting Up On-Prem Controllers 1

    Introduction 1

    Configuring IOS-XE Certification Server 2

    Enabling HTTP Server and NTP 2

    Certificate Server Configuration 2

    vManage Configuration 4

    System Information 6

    VPN Configuration 6

    Certification enrollment 8

    vBond Initial Configuration 15

    System Information 17

    VPN Configuration 18

    Certification enrollment 19

    vSmart Initial Configuration 25

    System Information 26

    VPN Configuration 26

    Certification enrollment 27

    Control Connection Verification 33

SD-WAN Part V: Hub and Spoke with Restrected Spoke Sites

Introduction

Cisco Viptela SD-WAN solution builds a full-mesh topology between vEdge devices by default when there are no Control Policies implemented. This means that vEdges tries to build an IPSec/GRE tunnel to every reachable TLOC public IP addresses no matter which site or color (transport network) TLOCs belong to. We have already change the default behavior by using the restrictoption (chapter 2) under tunnel interfaces. In this way, tunnels are only established between TLOCs belonging to the same color. In this chapter, we are going to create a Hub and Spoke topology by implementing a Control Policy where the vSmart advertises TLOC/OMP routes from site 30 to sites 10 and 20 and TLOC/OMP routes from sites 10 and 20 to site 30. vSmart doesn’t advertise TLOC/OMP routes between sites 10 and 20. Site 10 and 20 will be our Branch/Remote sites and site 30 will be the Hub/DataCenter site.

Figure 5-1 recaps the operation of the Overlay Management Protocol (OMP). vEdge1 in site 10 advertises TLOC route advertisement to vSmart where it describes its System Id, transport color, and encapsulation method as well as Public/Private IP and restricts attributes (among several other attributes). vSmart forwards TLOC routes received from vEdge1 to both vEdge2 (site 20) and vEdge3 (site 30). vEdge1 also advertises OMP routes where it describes the reachability information about its local subnet 172.16.10.0/24 bound to VPN10.

Figure 5-1: TLOC Route advertisement.

SD-WAN Part IV: MPLS Network with IS-IS Segment Routing as SD-WAN Transport

Introduction

In order to have IP connectivity between hosts A and B over the underlay transport network, we need to build a tunnel (IPSec or GRE) between the Public  IP addresses of vEdge devices (TLOC Routes). Then we also need VPN-specific subnet routing information (OMP Routes) to be able to route traffic over the tunnel. This chapter discusses the role and operation of various protocols involved in Control Plane operations when an MPLS Transport network is used as an Underlay Network for SD-WAN solution. The first section introduces the Segment Routing solution for building a Label Switch Path (LSP) between PE routers over the MPLS backbone by using the IS-IS routing protocol for both routing and label distribution. The second section explains how to build L3VPN between vEdge Public IP addresses over the LSP. Figure 4-1 shows the high-level routing model used in this chapter.

Figure 4-1: Control Plane Model.

Cisco SD-WAN – Part III: Overlay Management Protocol

Introduction

This chapter introduces the operation of the Overlay Management Protocol (OMP). It starts by introducing TLOC Routes which are used for establishing tunnels between vEdges. Next, it explains OMP Routes which in turn are used for advertising client VPN-specific networks reachability information. I am also going to show the data plane encapsulation when data is sent between the hosts in site 10 and site 30. The purpose of the data plane section is to show how the label attribute advertised within OMP routing advertisements is used to identify customer VPN. In order to see inside captured packets, I am using GRE tunnels instead of IPSec. Figure 3-1 illustrates the example topology used in this chapter. The customer VPN 10 is used on both sites. Site 10 subnet is 172.16.10.0/24 and site 30 subnet is 172.16.30.0/24. Interface ge0/­0 in both vEdges is connected to the Public-Internet, and interface ge0/1 is the connected to MPLS transport network where the customer has its dedicated MPLS VPN.

Figure 3-1: SD-WAN Example Topology.

Cisco SD-WAN – Part II: Manual vEdge Provision Process

Introduction

This chapter explains how we can provision vEdge devices manually. It starts by explaining how to build an initial system and tunnel interface configurations. Then it goes through the various certificate installation steps (CA root certificate, Certificate Signing Request (CSR), and granted certificate). After the initial configuration and certificate process section, this chapter shows how we can verify the Control Plane operation. Figure 2-1 illustrates our example topology. For simplicity, there are only two vEdge devices used in this chapter.

Figure 2-1: SD-WAN Topology.

Cisco SD-WAN: vManage, vBond, and vMSmart On-Prem Installation Process.

Introduction

This section explains the process how to build an on-prem Cisco Viptela based SD-WAN control plane system. It starts by setting up an enterprise Certificate Server using the Cisco CSR1000V cloud router. Next, it goes through the process of root certificate generation. The rest of the chapter explains the initial configuration and certification installation processes from vManage, vBond, and vSmart viewpoints.

Figure 1-1: Control-Plane Components Topology.

Object-based Approach to Cisco ACI:

 A Guide to Understand the Logic Behind Application Centric Infrastructure 

This book will be soon available

Click "read more >>" to open the Table of Contents and see the About the Book section

ACI Fabric Access Policies Part 4: Leaf Interface Profile, Leaf Switch Policy Group, and Leaf Switch Profile,

Leaf Interface Profile

 

This section explains how to create an object Interface Profile whose basic purpose is to attach the set of physical interfaces into this object. Phase 6 in Figure 1-40 illustrates the APIC Management Information Model (MIM) from the Interface Profile perspective. We are adding an object L101__102_IPR under the class AccPortP (Leaf Interface Profile). The name of the object includes Leaf switch identifiers (Leaf-101 and Leaf-102) in which I am going to use this Interface Profile. This object has a Child object Eth1_1-5 (class InfraHPorts) that defines the internet block and which has a relationship with the object Port_Std_ESXi-Host_IPG. By doing this we state that ethernet interfaces 1/1-5 are LLDP enabled 10Gbps ports which can use VLAN Identifiers from 300-399. Note that in this phase we haven’t yet specified in which switches we are using this Interface Profile.

 The RN rules used with related objects:

 Objects created under the class InfraAccportP (Leaf Interface Profile):Prefix1-{name}, where the Prefix1 is “accportprof”. This gives us RN “accportprof-L101_L102_IPR”.

 Objects created under the class InfraHPortS (Access Port Selector): Prefix1-{name}-Prefix2-{type}, where the Prefix1 is “hports” and the Prefix2 is “typ”. This gives us RN “hports-Eth1_1-5_typ-range”.

Objects created under the class InfraPortBlk (Access Port Block): Prefix1-{name}, where the Prefix1 is “portblk” and where the name is Property (autogenerated). This gives us the RN “portblk-Block2”.

Figure 1-39: APIC MIM Reference: Interface Profile.

Continue reading

ACI Fabric Access Policies Part 3: AAEP, Interface Policy and Interface Policy Group

Attachable Access Entity Profile - AAEP

This section explains how to create an object Attachable Access Entity Profile (AAEP) that is used for attaching a Domain into Port Group. Phase 3 in Figure 1-20 illustrates the APIC Management Information Model (MIM) from the AAEP perspective. Class AttEntityP is a Child class for infra, and they both belong to packages Infra. I have already added the object attentp-AEP_PHY into the figure.The format of the RN for this object is Prefix1-{name}, where the Prefix1 is attentp. This gives us the RN attentp-PHY-AEP.

Figure 1-20: APIC MIM Reference: Attachment Access Entity Profile.

ACI Fabric Access Policies Part 2: Physical Domain

 Physical Domain

Figure 1-15: Fabric Access Policy Modeling: Physical Domain (click image to enlarge).

Continue reading