Total 3 Blogs

Created by - Orhan Ergun

Should I use Cisco OTV for the Datacenter Interconnect ?

Should I use Cisco OTV for the Datacenter Interconnect? This question comes from not only from my students but also the companies which I provide consultancy. I will not go through the OTV details, how it works, design recommendations etc. But let me remind you what is OTV and why OTV is used , Where it makes sense very briefly.  OTV (Overlay Transport Virtualization) is a tunnelling mechanism which provides to carry Layer 2 ethernet frame in IP. (As I indicated in other articles, when I say MAC in IP, it is the same thing with MAC over IP). So, OTV is Layer 2 in Layer 3 tunnelling mechanism. You can hear it is an encapsulation mechanism as well, which is true although there is small difference. You don’t need to have MPLS underlay to create OTV tunnels. It uses IS-IS for the MAC address reachability and stops layer 2 protocol PDUs at the OTV Edge device where encapsulation happens. This is good because, you don’t want to extend Layer 2 protocol PDUs such as Spanning Tree if you have multiple datacenters. Failure stays and affects only one datacenter, not all. (Failure domain boundary concept) Another datacenter interconnect requirement is ARP proxy. Not a mandatory but it is good that your tunnelling mechanism (I should say Layer 2 extension mechanism probably) provides a way to reply ARP messages locally. OTV provides this functionality as well. Should I use Cisco OTV for the Datacenter Interconnect ? There are some problems and I will highlight two most obvious ones and especially one of them might stop many networks to use OTV. Since MAC reachability information is carried through IS-IS, you can have scalability problems to carry MAC addresses through IS-IS. BGP allows to scale up to millions MAC or IP prefixes. (EVPN, PBB-EVPN) Also I think there are some implementation limit for OTV. Up to some amount of locations can participate in overlay. But here we should be fair and say that although VPLS doesn’t have this limitation, it doesn’t make sense to use VPLS for 10 or more datacenter interconnection due to data plane learning and we all know the problems of data plane learning I guess. By the way 10 is not a calculated number at all, I just used as an example. If the number of MAC addresses are more per datacenter probably even less number of datacenter interconnection can cause a problem. So, OTV and IS-IS, for the large number of MAC addresses per datacenter can be a problem but definitely this is not the case for many networks today. If we are talking about Massive Scale Datacenters, they don’t use layer 2 extension, and in fact they don’t use layer 2 protocol inside the datacenter either. (BGP, specifically EBGP they use and there are many reasons for it, let’s talk about them in a separate article) Another problem with OTV of course is it is Cisco Preparatory. If you want to use different devices at the DC-Edge of your network, you cannot. OTV is not interoperable with the other overlay technologies. You cannot use OTV together with VPLS for example. I intentionally compared VPLS with OTV throughout the post, because VPLS is one of the most commonly used Datacenter interconnect mechanism in today networks. Again, let’s think the real networks. Do you really care using multiple vendors ? Or if Cisco gives you better price, better support and good documentation, most importantly best sales engineers ( ??  ), do you still consider not to be vendor lock-in ? Or do you think decision is taken for the political reasons in your company. Let me hear your thoughts in the comment section below.To have a great understanding of SP Networks, you can check my new published “Service Provider Networks Design and Perspective” Book. 

Published - Tue, 26 Nov 2019

Created by - Orhan Ergun

Introduction to VPN (Virtual Private Network)

Introduction to VPN (Virtual Private Network) Let’s start with the definition. VPN is a logical network and created over shared physical infrastructure. Shared infrastructure can be private such as MPLS VPN of a Service Provider or over the Public infrastructure such as Internet. There are many concepts to understand VPN in detail but in this article I will cover the definition, common design considerations, and some not well known concepts about it. We can group VPNs into two categories. WAN and the Datacenter VPN Technologies. WAN VPN Technologies 1.GRE 2.mGRE (Multipoint GRE) 3. IPSEC 4. DMVPN 5.GETVPN 6.L2TPV3 7.LISP 8. MPLS L3 VPN Datacenter VPN Technologies 1.EoMPLS (Ethernet over MPLS (a.k.a VPWS) 2. VPLS (Virtual Private Lan Service) 3. OTV (Overlay Transport Virtualization) 4. EVPN 5. PBB-EVPN 6. VXLAN (And other host based overlays such as NVGRE, STT, GENEVE) Of course this is not the complete list. Please note that some of the technologies which I grouped into WAN technologies can be used in the Datacenter and vice versa. For example LISP can be used in Datacenter as well and VPWS and VPLS can be used on the Wide Area Network as well. I am going to cover each of these technologies in the individual article so please stay tuned and follow the website by subscribing the email list. Also please know that there is a video lesson which I explain all these technologies in my Self Paced CCDE Course in detail. VPN Design Considerations  VPNs can be further categorised as Overlay and Peer to Peer. Overlay VPNs is what I described above. Private network is created over the shared physical infrastructure. For better illustration, imagine customer is receiving a Layer 2 MPLS VPN service from the Service Provider. In Overlay VPN model, endpoints are the customer devices, which is called as CE (Customer Equipment). MPLS Layer 3 VPN is a Peer to Peer  technology. In Peer to Peer  model, customer has a routing neighborship with the Service Provider. Endpoints are not the customer sites in this model. One side of the VPN is a customer device  (CE) and remote end is Service Provider device (PE). All of the above technologies add extra information to the packet or frame which increases the overall MTU.Network links should accommodated to handle bigger MTU. For example GRE adds extra 24 byte. (GRE header is 4 byte and new IP header is 20byte. mGRE adds 28 bytes and so on.) VPNs work based on encapsulation and decapsulation. For example in GRE, mGRE or DMVPN encapsulate IP packets into another IP packet and VPLS or EVPN encapsulates Layer 2 frame into an MPLS packets. Some VPNs require tunnel as well. For example although I didn’t include in the list above but MPLS Traffic Engineering is used as a VPN mechanism and requires a tunnel. This doesn’t mean that there is no encapsulation and decapsulation in MPLS Traffic Engineering, of course there is, but it requires tunnel as well. Or GRE requires a tunnel and encapsulation (IP header is encapsulated in GRE header). Some of the above technologies support routing protocol, some don’t.In order to run routing protocols over tunnel, tunnel endpoints should be aware from each other.In other words, tunnel should be bidirectional tunnel and co-associated. For example MPLS Traffic Engineer tunnels don’t support routing protocol,since the MPLS-TE LSPs (Label Switch Paths) are unidirectional which mean Head-end and Tail-end routers are not associated and not bidirectional. All WAN technologies except IPSEC and LISP in our list supports routing protocols. Some VPN technologies cannot run over Internet. For example GETVPN, due to IP header preservation, cannot run over public Internet. But by building private infrastructure over Internet with GRE for example, GET VPN can run over GRE over Internet. VPN Choice Check List  Will you use it over Private or Public infrastructure ? How many locations will be connected? (Some has scalability challenges) Will you run a routing protocol on top of it ? What is the security requirement ? (Do you need to encrypt the data?) Which one do you know best ? Do you need to carry IP traffic only or do you need to carry non-IP as well ? So what is the payload? Do you need Multicast, QoS and IPv6 support ? (Some of them don’t support, some of them are very poor) Do your device hardware and software support the protocol which you choose ? Do you have a budget problem ? (Some VPN services are more expensive than others) Is there any Layer 8 and above issue ?

Published - Tue, 26 Nov 2019

Created by - Orhan Ergun

GRE Tunnels – Generic Routing Encapsulation – Use Cases

GRE Tunnels  GRE tunnels are by far most common tunnelling technology. Very easy to setup, troubleshoot and operate. But in large scale deployment, configuring GRE tunnels become cumbersome, because GRE tunnel is a point to point tunnel. GRE Tunnel Characteristics  • GRE tunnels are manual point to point tunnels. Tunnel end points are not automatically derived. Network operator needs to configure the tunnel end points manually. • Supports routing protocols to run over. You can run any routing protocols on top of GRE tunnels. • IPv4 and IPv6 can be transported over GRE. Some VPN technologies may not support IPv6 or IPv6 routing protocols. • Non-IP protocols such as IPX, SNA etc. can be carried over GRE tunnel as well. Most of the tunnelling technologies cannot carry Non- IP traffic. For example, IPSEC tunnel cannot carry Non-IP Traffic. • If there are too many sites that need to communicate with each other, GRE is not scalable. But in Hub and Spoke topologies it can be used since whenever new spoke site is added, only new site and hub should be revisited. Not all the spokes need configuration. • Even though in Hub and Spoke topologies, the configuration can be too long on the Hub site. mGRE (Multipoint GRE) version of GRE tunnel reduces the configuration on the Hub site greatly. • GRE tunnel adds 24 bytes to the IP Packet. 4 byte GRE header and 20 bytes new IP header is added; this increases MTU size of the IP packet. Careful planning on the interface MTU is necessary. Gre Tunnel Headers • GRE doesn’t come by default with encryption so in order to encrypt the packet; IPSEC should be enabled over GRE tunnel. GRE Tunnel Uses Cases: • Classical use cases of GRE tunnel is over Internet with IPSEC, VRF- lite to carry different VPN information separately in the Campus, WAN or datacenter and IPv6 tunnelling over IPv4 transport. • GRE is used mostly together with IPSEC to support the traffic that is not supported by IPSEC by default. For example IPSEC tunnels don’t support Multicast by default but together with GRE, GRE over IPSEC supports multicast traffic.

Published - Tue, 26 Nov 2019