Monday 9 October 2017

Rapid per VLAN Spanning Tree protocol (Rapid PVST+): Synchronization

Introduction


This article describes the Rapid per VLAN Spanning Tree Protocol (Rapid PVST +) synchronization process based on Proposal / Agreement messages. The purpose of the synchronization is to form a new loop-free layer 2 topology as a response to changes in stable STP domains. The synchronization process is started by a switch that loses its connection to a current STP root switch and it does not have an STP Alternate port.
The article also describes the topology change process that occurs when the STP non-Edge port status changes from Discarding/Learning state to Forwarding state.
The idea for writing this article started when I studied the new Cisco VXLAN-based Campus Fabric model and I wanted to compare its complexity with the complexity of the traditional Campus network.

Figure 1-1: Spanning Tree topology


Thursday 6 July 2017

Border Gateway Protocol – Finite State Machine (BGP-FSM)

Introduction


The BGP-FSM model presents different states during BGP neighbor negotiation: Idle, Connect, Active, OpenSent, OpenConfirm and Established. It also describes the events that launch changes from one state to another. This article is based on Based on RFC 4271 – A Border Gateway Protocol 4 (BGP-4).

There are 28 events, which are grouped into four categories.
  • Administrative Events: Events that either start or stop the process.
  • Timer Events: Expiration of HoldTimer, KeepaliveTimer or ConnectRetryTimer trigger this event.
  • TCP connection based events: These events describe the different state of the TCP three-way handshake.
  • BGP message based events: Receiving or sending BGP messages: OPEN, KEEPALIVE, UPDATE and NOTIFICATION launch this event.

A Complete list can be found in Appendix A.

Figure 1-1 shows the map of different states and related event numbers. Timers and counters are excluded from both the text part and picture to keep things as clear as possible.

Figure 1-1: Overview of BGP-FSM.

Monday 12 June 2017

Cisco Performance Routing version 3 - PfRv3

Introduction

In my previous posts, DMVPN Part I – IV, I have described and built a dual homed DMVPN overlay network over MPLS and Internet WAN. In this post, I am going to enable an intelligent path control with the Performance Routing version 3 (PfRv3). Using a DMVPN together with a PfRv3, we can have a transport independent WAN, where forwarding decision is done based on the application requirements (e.q bandwidth, delay, jitter, and packet loss) instead of only relying on information received from routing protocols.

Figure 1 shows the example topology. There is one Master Controller (MC) S1R4 and two Border Routers (BR) S1R1 and S1R2 on the Hub site. On the Remote site, there is a router which has two roles, site Master Controller (MC) and site Border Router (BR). Remote site BR and Hub BRs are connected over MPLS and the Internet using a DMVPN overlay technology. A routing protocol for overlay network is BGP. The complete DMVPN configuration can be found in the document: “DMVPN Part III. BGP over DMVPN WAN”. On the Hub site, there is an internal router that has four loopback interfaces which represent LANs. There are two business critical networks, 172.16.2.0/24 – Voice and 172.16.3.0/24 – CRM. We will use these two networks in the PfRv3 demonstration. 

Figure 1: Example topology picture

Monday 15 May 2017

Dynamic Multipoint VPN (DMVPN) Part IV. - Direct Internet Access – DIA


Introduction

In this DMVPN article, I am going to implement Direct Internet Access (DIA) in the Remote Site. In initial situation, both edge routers in the Central site advertises the default route over the DMVPN tunnels to the router S2R1 with iBGP. Router S1R1 advertises the default route with a better Local Preference value so that one is installed in the routing table of router S2R1.

Figure 1. Default route from the Central site over the DMVPN WAN.

Thursday 20 April 2017

DMVPN Part III. BGP over DMVPN WAN

Introduction

In this article, I am going to set up BGP routing over the dual homed DMVPN WAN. Why I use BGP and not some other routing protocol (OSPF, ISIS, RIP, EIGRP)? I want to use route summarization and advance, centralized route filtering. OSPF does not full fill these requirements. It is a Link State routing protocol and all routers within the OSPF area must have identical Link State Database. This means that route filtering and summarization can only be done between areas, not inside the area. The other Link State routing protocol IS-IS is not supported with DMVPN, so it is also out of the question. RIP is a Hop Count routing protocol and we could use it if we want to implement a very simple routing. However, I want to use advanced, centralized routing policy, so RIP is not my choice. Then we have two vector based protocols; EIGRP (distance vector) and BGP (path vector). These are the “de facto” routing protocols for routing over the DMVPN WAN and I could pick either one. However, I prefer BGP as a WAN routing protocol, so that is why I am going to use it in my example.

In our example topology (figure 1), we have two sites:

Central Site: We have edge routers S1R1 and S1R2, with two virtual Routing Instance (VRF); default and front-door VRFs. Physical interfaces 3 and 4 on both routers belong to default VRF and also participates in OSPF Area 0. Both routers S1R1 and S1R2 have also tunnel interfaces, Tunnel11 and Tunnel12 respectively that belongs to the default VRF. Internal BGP peering between the Central site and Remote site runs between Tunnel interfaces. Physical Interface 2 in both edge routers belongs to front-door VRF, which is a termination point for the WAN connection. There is no iBGP peering between routers S1R1 and S1R2. Both edge routers are BGP route-Reflectors. Router S1R3 has four networks attached to it (172.16.0.0/24, 172.16.1.0/24, 172.16.2.0/24 and 172.16.3.0/24). We advertise these networks via OSPF as well as the default route.  It also has an Interface Looback1000 with address 10.28.158.1, which we are going to use for testing a default route. Network 10.28.158.0/24 is not advertised with OSPF.


Branch Site: We only have one router in Branch Site. There are two Tunnel Interfaces and one LAN interface, which all belongs to default VRF. There are two front-door VRFs, one for the MPLS connection and one for the Internet connection. Note that Interface towards the Internet gets its IP address via DHCP from the router INET-R112.




Figure 1: Physical topology and IP addressing.

Tuesday 4 April 2017

DMVPN Part II. Spoke-to-Spoke tunnels, NHRP operation in DMVPN


Introduction

In this article, I will go through the process of DMVPN tunnel establishment between Spoke sites. I am using the same network topology and network setup than in my previous article “DMVPN Part I.  Basic Operation and Configuration, March 31, 2017”. Note that prefix for all interfaces/networks is 2001:db8. Figure 1 shows the processes of Spoke-to-Spoke tunnel establishment.




Figure 1.

Friday 31 March 2017

DMVPN Part I. Basic Operation and Configuration


Introduction


DMVPN is Cisco proprietary overlay network technology used for building dynamic, transport independent multipoint GRE tunnels over any packet switched networks (Internet, MPLS, 4G, satellite, etc.). 
DMVPN has evolved over time. In the first phase (Phase-1), dynamic tunnels are formed only between Spoke and Hub sites and Spoke-to-Spoke traffic goes through the Hub site. In the next Phase (Phase-2), the on-demand tunnel will be formed between Spoke sites belonging to the same DMVPN domain and traffic does not have to go via the Hub site. However, Phase-2 does not allow on-demand tunnels between Spoke sites belonging to the different DMPN domain, and traffic must go via the Hub that connects these two Domains. The Phase-3 phase (Phase-3) makes it possible to create an on-demand tunnel between two Spoke sites belonging to the DMVPN domain.

This article is about DMVPN Phase 3.

DMVPN Phases