Secure Access Service Edge (SASE) - Part 1

There have been major changes in technology trends in the last decade. Digital transformation has accelerated the migration of enterprise applications and workloads from traditional data centers to public cloud. 

The applications are available everywhere and can be accessed from anywhere. The 4G/5G technology and cost-effective Internet circuits have enabled users to work from anywhere.  The rigid networks of the past do not work in the new digital economy. Traditional WAN architectures weren't built to support cloud applications. 

These changes have also brought in new challenges. Internet connections are not inherently secure and here is an increase in the usage of BYOD (Bring your own device) which has resulted in the increased attack surface of corporate networks. 

Standard hardware based product life cycle is getting replaced by usage based subscriptions. Businesses are moving from permanently fixed infrastructure to on-demand cloud services.  

Enterprises are looking to extend their security perimeter all the way to the user and provide enhanced user experience and visibility into application performance and usage.

This is where the SASE architecture comes into play. It contains five major components as below.

1) Software-Defined Wide Area Network (SDWAN) : Simplifies IT infrastructure control and management by building a virtual WAN over public and private network that securely connects users to their applications.

2) Secure Web Gateway (SWG) : Provides granular control and visibility to web traffic and enforce appropriate corporate security policies.  

3) Cloud Access Security Broker (CASB) : Helps to manage and protect corporate data that is stored in the cloud. 

4) Zero Trust Network Access (ZTNA) : Connects distributed users with distributed applications without compromising on security or user experience.

5) Firewall-as-a-Service (FWaas) : Cloud service that provides advanced security to the infrastructure, applications, and platforms managed and hosted by an organization in its cloud infrastructure.

We will now look into each of these components in detail.

SDWAN:

In the traditional networks, service providers would give customer a link at each of their locations which would enable any to any full mesh connectivity. The service providers would use VPN technology to create tunnels between various end points, appear to be directly connected to the remote customer devices.

The internet breakout in such a network would be from a central location or from a specific branch office.

Key challenges with this architecture are

- Expensive Bandwidth : The MPLS circuits normally cost more than Internet access. If a branch office has two circuits implemented as active/passive, the backup circuit would seat idle until the primary link fails. It is difficult to achieve load sharing between redundant links.

- Failover : In an active/passive setup, failover is completely dependent upon the state of the link (up/down). 

- Control : Configuration is done locally on each individual router. Any policy change would require manual change on each device.

- Visibility : There is a very little application level visibility with such architecture. One has to rely on external tools to get necessary application data.

The SDWAN solution has the following key components

Management : Centralized management, configuration and monitoring

- Single Pane of glass

- Configuration creating and management

- Centralized deployment system

- Simplified on-boarding process

Control Plane: Distribution of reachability of information

- Tunnel creation

- Route advertisement

- Auto-discovery

- Topology management

Data Plane: Data Transport

- Tunneling and encapsulation

- Encryption

- Data forwarding and path selection

- Implementation of the security process

SDWAN can utilize any underlay transport such as MPLS, DIA or LTE to build overlay tunnels for enterprise traffic. Customer can choose which physical path to use based on path properties, security policies, application type, user groups, path stability etc.

We will look at the remaining components of SASE architecture in second part of the blog.

Containers (Docker) - OS Virtualization

Lately I have been looking at some application virtualization stuff. Majority of us are aware of  how server virtualization works however the concept of application virtualization is relatively new.

To understand what it is, let's first see what server virtualization is. In the old days, organizations used to keep physical servers to run their applications. Normally one physical server would be used to run one or two specific applications. Depending on the number of applications, companies had to maintain server farms which meant management of multiple Hardwares and Softwares, paying for CoLo space and electricity bill for all the physical devices.

Migration Methods

In this post, we will discuss various options to migrate customer's network from one service provider to other service provider. 

Let's assume that you work for an enterprise customer with three sites. All the sites are currently connected through a Layer 3 IPVPN solution provided by service provider A.

MPLS Traffic Engineering

In this post, we will discuss about MPLS Traffic Engineering. To understand where it can be used and what problems it can resolve, let's look at the below topology.

The CE1 and CE2 are customer edge devices with LAN subnet of 1.1.1.1/32 and 7.7.7.7/32 respectively. They are connected with corresponding PE1 and PE2. We are running OSPF and LDP in the service provider core. Both the PE devices exchange VPN labels via MP-BGP and transport label via LDP. 

BGP PIC EDGE

Continuing from our previous post, we will now see how BGP PIC EDGE works. We will use the same topology. The only difference is that I have removed R4 as route-reflector. All the PEs have full mesh IBGP neighbourship. 

At the moment R2 learns 8.8.8.8/32 from R6 and R7. It prefers the path with the next-hop of 6.6.6.6 over 7.7.7.7.

BGP PIC CORE

Happy New Year Folks!

In one of the previous posts, we looked at EIGRP FRR and OSPF LFA feature which helps achieving fast convergence.

There is a similar feature  in BGP which is called PIC (Prefix Independent Convergence). It speeds up the convergence of the FIB in failover conditions. BGP works differently than any IGP. It is designed to carry hundreds of thousands routes in the routing table hence fast failover works differently in BGP. There are couple of ways to implement PIC in BGP. They are "PIC Core" and "PIC Edge". We will look into both of these options.

Let's look at the below topology.

VRF Aware IPSEC VPN

In this post we will see how we can support multiple VRFs in site to site IPSEC VPN implementation.

We will use the below topology. The routers CE1 and CE2 are connected to the Internet. For simplicity, I have used the private IP addressing for the WAN connectivity.



Ok so the first step is to configure required VRFs on both the CPEs.

EIGRP IP FRR & OSPF LFA

In today's modern networks, fast convergence has become a mandatory requirement.
If we want to achieve fast convergence, each of the steps below need to be optimized

1. Failure Detection
2. Failure Propagation
3. Processing of new information
4. Updating RIB/FIB

1. Failure Detection:- "How long does it take me to detect a failure?"
This normally depends on the Hello/Hold down/Dead timers of the routing protocol. We can either tune these timers or use a mechanism such as "BFD" which we have seen in our earlier post.

2. Failure Propagation:- "How long does it take me to tell everyone else?"
In EIGRP, this is done through Query/Reply packets. We can reduce the Query domain by configuring the routers as "stub".

In OSPF, this depends on the area size and the LSA flooding procedure. We can tune the LSA timers to change this.

Carrier Supporting Carrier (CSC)

In this post we will look at the Carrier Supporting Carrier design where smaller service providers use large service providers as backbone in order to connect parts of their network which eliminates the need to build and maintain their own MPLS network.

From customer's point of view, there is no difference in terms of connectivity and it will still appear as they have a normal Layer 3 MPLS connection from the provider.

Let's look at the below topology to understand how it works.

We have a Tier 2 SP who is providing services to customer sites in two different geographical locations. The service provider have their own network within specific regions but not connected with each other directly hence they are using Tier 1 SP's backbone to connect both of their networks and provide end-to-end connectivity to the customer.

Inter-AS MPLS VPN - Option C (BGP+Label)

In this post, we will look into the Inter-AS MPLS VPN - Option C which is also known as "BGP + Label". 

Option C uses eBGP IPv4 session between ASBRs to exchange reachability to PE loopbacks. There will be a VPNv4 neighbourship between service providers VPNv4 route-reflectors (RRs).

Option C takes away the heavy reliance on ASBRs. In this case, ASBRs are only used to exchange the loopback prefixes using eBGP IPv4 sessions.

To understand how it works, let's look at our topology below.

We have two service providers. Both are connected through ASBR routers. In this specific instance, we have local VPNv4 route-reflector for each SP. The customer site CE1 is connected to SP1 and CE2 is connected to SP2.

Inter-AS MPLS VPN - Option B (VPNv4 EBGP between ASBRs)

So far we have seen the Inter-AS MPLS VPN using "back to back VRF" method. Even though it's a relatively easy method to implement, it has few drawbacks.

This procedure doesn't require MPLS enabled on the link between ASBRs however it does not scale very well. 

There is another method in which ASBR's establish VPNv4 neighbourship, exchange MPLS labels and can maintain end-to-end LSP. It is know as "Option B".

Let's see how it works. We are going to use the same topology as we used in last post.

The IP addressing and the core routing remains the same. The only difference is the configuration on ASBR where I have removed the EBGP neighbourship statement and removed the local VRF configuration.

Inter-AS MPLS VPN - Option A (Back to Back VRF)

We have seen how standard L3 MPLS works in the previous post http://ciskonetwork.blogspot.co.uk/2015/03/layer-3-mpls-vpn.html. 

In normal implementation, customer sites are served by a single service provider. The PE routers maintain an IBGP session and the routing information gets exchanged through VPNv4 neighbourship.

What if two customer sites are connected through different service providers? The PE routers of each service provider will not be able to establish IBGP neighbourship with each other hence won't be able to exchange VPNv4 routes.

There are mainly three ways to handle this type of a situation. One of three methods is called "Option A - Back to Back VRF".

IPv6 NAT-PT

In the recent posts, we discussed how we can transport IPv6 traffic over IPv4 backbone using the tunneling techniques. 

These techniques will not work if we have one part of network which can only run IPv4 and the other part can only run IPv6. Since IPv4 and IPv6 are not compatible with each other, we have to use some sort of translation mechanism. The way we can achieve this is through NAT-PT (NAT protocol translation).

Let's look at the below topology and see how NAT-PT can be implemented.

We have three routers R1, R2 and R3. We are running RIPng and RIPv2 between R1-R2 and R2-R3 respectively. R1 is only aware about IPv6 addresses, similarly R3 is only aware about IPv4 addresses.

Our goal is to establish reachability between the IPv6 loopback (2001:1111::1/128) of R1 to IPv4 loopback (3.3.3.3/32) of R3.

IPv6 tunneling over IPv4 - 6to4 Autotunnel

In the previous post, we looked at the IPv6 tunneling technique using IPv4 manual tunnels. We will now see how dynamic multipoint IPv6 tunnel works.

6to4 tunnels allow for the dynamic creation of IPv6 within IPv4 tunnels. Manual tunnel is normally used as point-to-point however 6to4 tunnels can be point-to-multipoint.

The 2002::/16 range has been reserved to use for tunneling. We will have to add the IPv4 address into this range to generate /48 prefix. i.e. if the IPv4 address of the border router is 192.168.1.1 then the 6to4 site address prefix becomes 2002:C0A8:101::/48 (Convert 192.168.1.1 to Hex which results in C0A8:0101)

We will work on the same topology we used in the previous post.

IPv6 tunneling over IPv4 - Manual Tunnel

We know that IPv4 and IPv6 addresses are not compatible with each other. Let's say the existing infrastructure is running on IPv4. If we need to implement IPv6 on few of the hosts, we need to use some sort of a technique for IPv6 hosts to communicate with each other using existing IPv4 network. One of the ways we can achieve this is by using a tunneling method.

In this post we will see how we can implement "Manual Tunnel". 

As shown in the diagram below, we have R1, R2 and R3 connected with each other. 

All three routers are running EIGRP and there is an IPv4 reachability from R1 to R3.

BFD (Bidirectional Forwarding Detection)

In this post, we will look into a feature called BFD (bidirectional forwarding detection). In normal routing protocol operation, the link failure is detected by using the hello/holddown/dead timers. 

Depending on the routing protocol, you can lower the timers to achieve fast failure detection. e.g. in the case of OSPF the lowest dead time can be one second and one can set the hello interval as low as 50ms.

However lowering these timers can result in higher CPU utilization. Also it will unnecessarily waste the link bandwidth. 

There is a better way of achieving fast failure detection through BFD. BFD is a UDP-based protocol that provides fast (in milliseconds) routing protocol independent detection of layer-3 next hop failures.

Let's see how it works. As shown in the diagram below, routers R1 and R2 are connected via Switch 1 and Switch 2. Both the routers are running OSPF and we can see the OSPF neighbourship is up.

Multicast Notes

Well Known Multicast Addresses

224.0.0.1 - All Hosts
224.0.0.2 - All Multicast Routers
224.0.0.9 - RIPv2 Routers
224.0.0.10 - EIGRP Routers
224.0.0.12 - HSRPv2
224.0.0.13 - PIM Routers
224.0.0.22 - IGMPv3
224.0.1.1 - NTP
224.0.1.39 - Cisco-RendezvousPoint-Announce
224.0.1.40 - Cisco-RendezvousPoint-Discovery
232.0.0.0/8 - Reserved for SSM
233.0.0.0/8 - GLOP address range

PIM (Protocol Independent Multicast)

• Protocol independent means that it can work with any unicast routing protocol 
• Pim can be implemented in three modes: sparse mode, dense mode and sparse-dense mode.

Layer 2 MPLS VPN (AToM)

In the previous post, we have seen the configuration of Layer 3 VPN. here we will see how we can configure Layer 2 VPN. 

Layer 3 VPN requires the PE participating in the CE routing. Sometimes PE cannot support specific routing protocol as required by the customer or the CE devices may not be IP aware.

Also customer will have to involve the service provider if they want to do any routing changes.

Layer 2 VPN resolves this issue by providing a layer 2 connectivity between CEs, effectively providing a broadcast domain. Customer can run any routing protocol between the CEs and will be in full control of the routing.

Generally it's done by using AToM (Any transport over MPLS) or L2TPV3 (Layer 2 tunnelling protocol). 

The key difference between both the methods is that AToM uses the MPLS as the transport while L2TPV3 uses IP. 

Let's look at the below scenario and see how we can implement this. We will use AToM in our example.

6VPE

6VPE (IPv6 VPN Provider Edge Router) is a feature which connects the customer sites configured with IPv6 addressing over the existing IPv4 MPLS backbone.

In our last post, we have seen how we can configure standard Layer 3 MPLS connection on Cisco routers and advertise customer's IPv4 prefixes over that. 

We will use the same topology for 6VPE however we will configure IPv6 addresses between PE to CE (R1-R2 and R5-R6) and on the Loopbacks of the CEs (R1 and R6).

This is how our topology looks like

Layer 3 MPLS VPN

In this post we will look at the steps of configuring Layer 3 MPLS VPN on Cisco routers.

As shown in the diagram, R1 and R6 are CE routers. R2 and R5 are PEs while R3 and R4 are P routers.