Blog Posts From VIP Perspectives Tagged With open_viewhttps://learningnetwork.cisco.com/blogs/vip-perspectives
Thu, 10 Aug 2017 22:18:40 GMTJive Engage 7.0.3.1 (http://jivesoftware.com/products/)2017-08-10T22:18:40ZAutomating Cisco Using Ansiblehttps://learningnetwork.cisco.com/blogs/vip-perspectives/2017/08/10/automating-cisco-using-ansible
<!-- [DocumentBodyStart:38c13367-3da0-457e-9fd8-4920c843116d] --><div class="jive-rendered-content"><p><a><img alt="Automating Cisco Using Ansible" src="/resources/statics/273911/SM_VIPPerspective_Blog_Image.jpg" style="float: left; padding: 6px 20px 8px 0px;" width="285"/></a></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">Automation is definitely one of many buzz words going around in the networking world. I heard a few things about it, but until recently I didn&#8217;t have much idea about how it actually looks and feels. Then, a change came. A few months ago I was introduced to a wonderful configuration management platform called Ansible. The company I work for uses it to manage configuration of VMWare NSX infrastructure in the data centers, but I was more interested in its capabilities to manage hardware network components. And it didn't disappoint me. </span></p><p dir="ltr" style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">Ansible is a simple configuration management software that uses a concept of playbooks which are essentially scripts that run against devices in your environment. It is highly extensible, because it uses modules written in Python, and anyone with some coding skills could write his/her own module for a certain device or enhance the existing module's functionality.</span></p><p dir="ltr" style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">In this post I'd like to just demonstrate how Ansible can be used to automate networks. First, let's try to get an idea of what automation is and where it is applicable. In my humble opinion, automation can save time in performing simple, repetitive, high-volume tasks. For the sake of this particular example, I've chosen VLAN creation as a task. Let's imagine that we've got a simple topology:</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;"><a href="https://lh3.googleusercontent.com/nSr4iimeUSqLMTqr4Kjl8piq2ohUvyfhtx8lgFiHW_iAyUNVAoc_z9DpAsxGqpUZDQCeZNtdvfItsrTNKu-XKP2o5WQ2_vh4N8lbA7BExrjeI3gNF-_o4ah4rBlX5AO3oAER-7fg"><img class="jive-image" height="244" src="https://lh3.googleusercontent.com/nSr4iimeUSqLMTqr4Kjl8piq2ohUvyfhtx8lgFiHW_iAyUNVAoc_z9DpAsxGqpUZDQCeZNtdvfItsrTNKu-XKP2o5WQ2_vh4N8lbA7BExrjeI3gNF-_o4ah4rBlX5AO3oAER-7fg" style="border: none;" width="602"/></a></span></p><p dir="ltr" style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">Switches SW1 and SW2 are our edge switches, and their ports connect to access switches, where customer devices are connected. Our task is to automate the provisioning of&nbsp; VLANs for new customers. We need to make sure the following is accomplished:</span></p><p dir="ltr" style="margin-top: 2pt; margin-bottom: 2pt; text-indent: -18pt; padding: 0 0 0 18pt;"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">&middot;</span><span style="font-size: 7pt; font-family: 'Times New Roman'; color: #575757; font-weight: 400; font-style: normal;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">a VLAN is created on all switches with a customer name as VLAN name</span></p><p dir="ltr" style="margin-top: 2pt; margin-bottom: 2pt; text-indent: -18pt; padding: 0 0 0 18pt;"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">&middot;</span><span style="font-size: 7pt; font-family: 'Times New Roman'; color: #575757; font-weight: 400; font-style: normal;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">a VLAN is allowed on all the relevant trunk ports</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">By default we don't allow any VLANs on any trunk links. The only VLANs that exist in the beginning are VLAN 1 and management VLAN 4094. The IP subnet on management VLAN is 192.168.0.0/24</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;"><a href="https://lh3.googleusercontent.com/4i-L-uZ3JddP5PHgzK4g72QLvGpS4CGNf_xuo1wRJ4PG_kTU6tWjx9KHDImSUNg5WRrJRrEKbA9a1idyBTP5CY4OajowkEvuwTmoVoQ5kRsr2E4nz1Uz0eJi7E4K8x9yv3_SpS0a"><img class="jive-image" height="319" src="https://lh3.googleusercontent.com/4i-L-uZ3JddP5PHgzK4g72QLvGpS4CGNf_xuo1wRJ4PG_kTU6tWjx9KHDImSUNg5WRrJRrEKbA9a1idyBTP5CY4OajowkEvuwTmoVoQ5kRsr2E4nz1Uz0eJi7E4K8x9yv3_SpS0a" style="border: none;" width="602"/></a></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">We've got Ansible command station in VLAN 4094 and configured with the IP address from 192.168.0.0/24 range.</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">Let's start. </span></p><p dir="ltr" style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">First thing we need of course is access credentials for switches. The username and password are "admin" and "admin". Absolutely unbreakable combination! Ansible uses SSH connection, so it needs to have the credentials for SSH access. I'll create a YAML file, called "creds.yml" and put my credentials in there.</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;"><a href="https://lh4.googleusercontent.com/Opm52suPxaKa7izQRKsm-4_70ar37eXje_hhzyeePmtAwnvS45QzysJ_MQ0MOOYkTVgY8T5a7EWY76YWX7g2gm29RApZmudNSI7r4F6eeuuY0k6hp6cV4wPb5dk4Om39sguRNhBR"><img class="jive-image" height="177" src="https://lh4.googleusercontent.com/Opm52suPxaKa7izQRKsm-4_70ar37eXje_hhzyeePmtAwnvS45QzysJ_MQ0MOOYkTVgY8T5a7EWY76YWX7g2gm29RApZmudNSI7r4F6eeuuY0k6hp6cV4wPb5dk4Om39sguRNhBR" style="border: none;" width="502"/></a></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">Next, we need an inventory file. Inventory file contains descriptions of your devices. It also allows to group your devices in an arbitrary manner and assign variables to them. For this example, I'll split my switches into groups called "coreswitches" and "edgeswitches". I'll also create a group called "switches," which will include both of the previous groups. That will come in handy if I want to perform some tasks only on core or only on edge switches.</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;"><a href="https://lh5.googleusercontent.com/au_kER_etN_ZJK5rWFJz4XcDjIflmd9zE1VX20UCbV6LHGn94oY5oNFJTDaxvHSx1-EqMCgF3daGH1PYvJgFY76Mj-dMHEfRhfKHO1Py_ewWVag3boGfH7Q-TIZrTaJeGaQdMF8G"><img class="jive-image" height="259" src="https://lh5.googleusercontent.com/au_kER_etN_ZJK5rWFJz4XcDjIflmd9zE1VX20UCbV6LHGn94oY5oNFJTDaxvHSx1-EqMCgF3daGH1PYvJgFY76Mj-dMHEfRhfKHO1Py_ewWVag3boGfH7Q-TIZrTaJeGaQdMF8G" style="border: none;" width="408"/></a></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">Now to the playbook! The playbooks are written using YAML format. It is a simple markup language that is unlike XML; for example, it is very easily readable. Here is my playbook with comments:</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;"> </span><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;"><a href="https://lh4.googleusercontent.com/5KuVCWBG5wtLxjhtHccLcdoOoTCD5Y-AKK96s_DMPCj3Ax895bZhHvbPucfUMLjpF0V8kpTEM5GCy6aH8FGJ2XzMjFtkhAV4Fk7XSfMaxFkcrw4sj3QysWkcMcsxpBbOjvK2Gcpg"><img class="jive-image" height="284" src="https://lh4.googleusercontent.com/5KuVCWBG5wtLxjhtHccLcdoOoTCD5Y-AKK96s_DMPCj3Ax895bZhHvbPucfUMLjpF0V8kpTEM5GCy6aH8FGJ2XzMjFtkhAV4Fk7XSfMaxFkcrw4sj3QysWkcMcsxpBbOjvK2Gcpg" style="border: none;" width="602"/></a></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">Now, you can see, I'm using a few variables that we haven't defined yet. All these variables will go into the customer configuration files. One file per customer. And here is the first one:</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;"><a href="https://lh6.googleusercontent.com/J1uVJemte1D2C1wlAV7lgeLB681IFAMUpye_5inNSsOITxVGnc_fEPbAAKoQh8p1MhWjbryhNUPFQ4xfuV7tw-7W9abPGGs_T3m3NR0LNN8cbXp9sWODTDZBSvWzXFf8DRg2fpjj"><img class="jive-image" height="230" src="https://lh6.googleusercontent.com/J1uVJemte1D2C1wlAV7lgeLB681IFAMUpye_5inNSsOITxVGnc_fEPbAAKoQh8p1MhWjbryhNUPFQ4xfuV7tw-7W9abPGGs_T3m3NR0LNN8cbXp9sWODTDZBSvWzXFf8DRg2fpjj" style="border: none;" width="437"/></a></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">Here are all of our variables and lists of variables:</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">a separate list for edge switch ports, having two variables per item: "sw" - switch IP address and "port" - the trunk port to add VLAN to. Same format list for coretrunks and variables&nbsp; for VLAN and VLAN name.</span></p><p dir="ltr" style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">Now we've got everything in place to run the playbook. A little tweak to the default Ansible configuration file /etc/ansible/ansible.cfg to accept our local inventory file as default inventory:</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;"><a href="https://lh4.googleusercontent.com/SUAYPaj1UiYtM-1FCacOah3v3fPOduIOe94snrKdh8VOIl2zrTK4CE_piKwA9u__cch_Q5s8mLKmAh2td5HlDujcoqjOU-wnExkJA_K9s_xnz-t_dyG70yKxX6bTcQ06mCSOlfs3"><img class="jive-image" height="349" src="https://lh4.googleusercontent.com/SUAYPaj1UiYtM-1FCacOah3v3fPOduIOe94snrKdh8VOIl2zrTK4CE_piKwA9u__cch_Q5s8mLKmAh2td5HlDujcoqjOU-wnExkJA_K9s_xnz-t_dyG70yKxX6bTcQ06mCSOlfs3" style="border: none;" width="602"/></a></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">And now we are ready to run our playbook:</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">The command to run a playbook is ansible-playbook [playbook-name]</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">Last thing to remember is that we still have a single undefined variable in the playbook, which is called "custfile". That is the variable we pass to Ansible during the execution, using option -e like that: ansible-playbook customer-vlan.yml -e "custfile=CUSTOMER1.yml". Let's give it a go now.</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;"> </span><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;"><a href="https://lh6.googleusercontent.com/WsNuIch3NVUwnim4Q6Ax7J-fvQuYkC29cwHGyTf1U4h5bGxNxTKuc_TZVJGqr6k6VqJBK2G45qAInsJBNVy4EaP_1tzevkDv6pPVzeOjs6HSMMDQ8C6y1Q3-ypDmfAVBd2dFTZoS"><img class="jive-image" height="553" src="https://lh6.googleusercontent.com/WsNuIch3NVUwnim4Q6Ax7J-fvQuYkC29cwHGyTf1U4h5bGxNxTKuc_TZVJGqr6k6VqJBK2G45qAInsJBNVy4EaP_1tzevkDv6pPVzeOjs6HSMMDQ8C6y1Q3-ypDmfAVBd2dFTZoS" style="border: none;" width="602"/></a></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">Looks promising. Just before running the playbook, I started the ping from CUST1-1 to CUST1-2, and here is the result:</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;"> </span><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;"><a href="https://lh3.googleusercontent.com/I-RIfdUw1sBwx_vRebv_VL_td05szqparlEq_TEyTFBg_YZIjA1geUBVD0OWtVKb3VtrPSgfJKrljy3j0gtARwOaO5ct86_131-6CM_DkPmCeCzJDRNtmF8ZeWj4EA5wv5O4z2IK"><img class="jive-image" height="311" src="https://lh3.googleusercontent.com/I-RIfdUw1sBwx_vRebv_VL_td05szqparlEq_TEyTFBg_YZIjA1geUBVD0OWtVKb3VtrPSgfJKrljy3j0gtARwOaO5ct86_131-6CM_DkPmCeCzJDRNtmF8ZeWj4EA5wv5O4z2IK" style="border: none;" width="602"/></a></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">Success! Let's verify our config on SW2.</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;"><a href="https://lh4.googleusercontent.com/uzhoDA79lJdeG8W6UIlPiUVKx1RuqrUT0VTHFL6LbdsybjMX2fsWtwFC26delFLd_GLBJCU6RQiD2XZoPyZVonsrfYMQ7pWRGxCt2Kiw_9AfUZzIK_YLHNqGVO8BYRF5lP2pkuWr"><img class="jive-image" height="447" src="https://lh4.googleusercontent.com/uzhoDA79lJdeG8W6UIlPiUVKx1RuqrUT0VTHFL6LbdsybjMX2fsWtwFC26delFLd_GLBJCU6RQiD2XZoPyZVonsrfYMQ7pWRGxCt2Kiw_9AfUZzIK_YLHNqGVO8BYRF5lP2pkuWr" style="border: none;" width="602"/></a></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">VLAN is present and allowed on the correct ports. That might seem like quite a lot of work to configure single VLAN and couple of trunk ports, but guess what? To repeat this, all we need is a new customer file, so let's copy the original one and modify just VLAN number and name. Of course we could modify the edge switches and ports or core switches and ports, but since our topology is very limited, all that stays the same.</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;"><a href="https://lh6.googleusercontent.com/fsrVzH-yotjpUzvSpEWKe4UNY4QQ8RQZ3R33vxvn5CiwUOprOPITIK3tclJCPI2hnhZkELxnl16vvPI-2K6cwChzI242AN6bBsCj_pBDk9ih-ci9j7-qtYGNUJ83aS01PgnlT89E"><img class="jive-image" height="284" src="https://lh6.googleusercontent.com/fsrVzH-yotjpUzvSpEWKe4UNY4QQ8RQZ3R33vxvn5CiwUOprOPITIK3tclJCPI2hnhZkELxnl16vvPI-2K6cwChzI242AN6bBsCj_pBDk9ih-ci9j7-qtYGNUJ83aS01PgnlT89E" style="border: none;" width="517"/></a></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">After running the command "ansible-playbook customer-vlan.yml -e "custfile=CUSTOMER2.yml" here is what we get on SW1:</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;"><a href="https://lh4.googleusercontent.com/T2L6syBXELVkzEEWobpJb97iB1NicOWhbHKUQ12HRHlvYDuKJcB9Mp_zrcMFOI82nm1Tjmw3UtTKXXRYVBsAmS0_KagaP5Zj_Z4mXeEZ_a7QxdiPeQ6gAFxRMvkFG10xKgdMVekD"><img class="jive-image" height="379" src="https://lh4.googleusercontent.com/T2L6syBXELVkzEEWobpJb97iB1NicOWhbHKUQ12HRHlvYDuKJcB9Mp_zrcMFOI82nm1Tjmw3UtTKXXRYVBsAmS0_KagaP5Zj_Z4mXeEZ_a7QxdiPeQ6gAFxRMvkFG10xKgdMVekD" style="border: none;" width="602"/></a></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">The beauty of it is that it now takes much less time to execute a task, and also it reduces the error possibility. It also scales very easily to more switches and more ports.</span></p><p dir="ltr" style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #575757; font-weight: 400; font-style: normal;">Of course this post is not aimed at getting you proficient with Ansible. I just wanted to demonstrate its capabilities in relation to Cisco devices configuration automation. I've used it to build and re-build IGP and BGP topologies in my lab. Here are some useful links on how to use Ansible:</span></p><p dir="ltr"><a class="jive-link-external-small" href="http://docs.ansible.com/ansible/intro.html" rel="nofollow" target="_blank"><span style="font-size: 10pt; font-family: Arial; color: #2989c5; font-weight: 400; font-style: normal; text-decoration: underline;">Introduction &#8212; Ansible Documentation</span></a></p><p dir="ltr"><a class="jive-link-external-small" href="http://shop.oreilly.com/product/0636920035626.do" rel="nofollow" target="_blank"><span style="font-size: 10pt; font-family: Arial; color: #2989c5; font-weight: 400; font-style: normal; text-decoration: underline;">Ansible: Up and Running - O'Reilly Media</span></a></p><p dir="ltr"><a class="jive-link-external-small" href="https://www.ansible.com/videos-ansible-automates-2017" rel="nofollow" target="_blank"><span style="font-size: 10pt; font-family: Arial; color: #2989c5; font-weight: 400; font-style: normal; text-decoration: underline;">https://www.ansible.com/videos-ansible-automates-2017</span></a></p></div><!-- [DocumentBodyEnd:38c13367-3da0-457e-9fd8-4920c843116d] -->Thu, 10 Aug 2017 21:56:04 GMTbounce@learningnetwork.cisco.comhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2017/08/10/automating-cisco-using-ansible2017-08-10T21:56:04Z1 week 7 hours ago50https://learningnetwork.cisco.com/blogs/vip-perspectives/comment/automating-cisco-using-ansiblehttps://learningnetwork.cisco.com/blogs/vip-perspectives/feeds/comments?blogPost=4027Networking Terminology – Understand What You Sayhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2017/07/12/networking-terminology
<!-- [DocumentBodyStart:22a8512d-6481-41a1-892e-84d71d851eb4] --><div class="jive-rendered-content"><p><a><img alt="Networking Terminology &#8211; Understand what you say" src="/resources/statics/1389573/NetworkingTerminology_blog_v2.jpg" style="float: left; padding: 0px 20px 8px 0px;" width="280"/></a></p><h2>Introduction</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">My intention with this blog post is to highlight a couple of scenarios that you are likely to face as a network engineer. Scenarios where it&#8217;s very important that you understand exactly what the words you choose to use actually mean to <em>your co-worker</em>. Whether it&#8217;s between a client or an internal discussion between network engineers and management &#8211; understanding the network terminology is extremely important!</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">I often end up discussing how to solve a specific technical problem. When I think about network terminology, I think about how easy it is to confuse someone if you assume that they know what you are talking about. In other words &#8211; I need to make sure that I use the correct network terminology so that we both understand each other.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">My goal is that after you have read through this post, you will have a better understanding of the challenges that exist when discussing networks as part of your work. It's not as easy as it seems to discuss networking and use the terminology in a way that makes sense. Cisco engineers have a bad habit of assuming that the Cisco terminology is the general networking terminology used. And there is a lot of other networking terminology that is also confusing and easily misunderstood. It's very easy to discuss networking and overlook the fact that you might use the same words &#8211; but they mean different things to different engineers.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">So this will be a less technical blog where I will mostly focus on some of the networking terminology that often leads to misunderstanding and confusion during discussions.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>Why all the talk about Cisco engineers?</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">If you are working with networking of any kind, everybody has heard about Cisco. Even if you don&#8217;t use Cisco equipment in your networks, the engineers managing the networks have probably been Cisco-educated at some point in their career. Most engineers I&#8217;ve spoken with have started their networking career using Cisco equipment, regardless of whether they actually ended up using it for their employer or not.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">There are many reasons for that, but I believe the main one is because Cisco has done a tremendous job of producing study materials available to the &#8220;public mass&rdquo;. Just to name a few of the things Cisco has made available:</span></p><ul><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Cisco Learning Network</span></li><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Cisco Networking Academy</span></li><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Strong career path &amp; certification paths</span></li><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Cisco Press</span></li><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Cisco Live</span></li><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Cisco documentation (Understanding x technology sections are great!)</span></li></ul><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>Why has Cisco invested so much time (and $) into creating education content?</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">If you think about it, there are plenty of reasons why any company would want to create such a strong brand that, no matter where you go, everybody has heard about it. So, not to be naive &#8211; Cisco does this with some expected return on their investment. In most cases, the materials are made available to get you hooked on Cisco technology and equipment, or to pass a Cisco-specific exam (such as CCNA R&amp;S).</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">If you are new to networking and begin studying it, you will hear about Cisco. They have created some of the best content available to teach new talents about how networks work.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Many network engineers start their career by reading about networking from content created by Cisco. Whether it&#8217;s to study for a Cisco certification exam or to learn about a networking technology, Cisco is there to support you in your studies. This comes with the side effect that once you start working as a network engineer, you [unintentionally] will favor Cisco when making decisions about which networking brand to use. Because one key factor in choosing a vendor is always going to be how well you understand their products.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">There is absolutely nothing wrong with that, but let&#8217;s consider what&#8217;s also included in their exams and in their content.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-family: arial, helvetica, sans-serif;"><span style="; font-size: 10pt;"><strong>A lot of </strong></span><span style="font-size: 10pt;"><em>networking terminology<strong>!</strong></em> <em>Terminology</em> that you must understand to pass their exams! <em>Terminology</em> that is even only used on Cisco equipment, but not by the rest of the industry! Because of this, you will remember the Cisco networking terminology and <em>assume</em> that everyone else understands what you mean! That&#8217;s why I talk about Cisco engineers!</span></span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">I hope that I can at least encourage you to think about these things so you will become better equipped to avoid the confusions that can lead to really bad implementations in your networks!</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h2>What is Network Terminology?</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">I've been thinking about this, and the best way I can explain it is...</span></p><blockquote class="jive-quote">
<p><span style="font-family: arial, helvetica, sans-serif;"><em>All the words we use to describe how interconnected electronic devices transmit and receive information.</em></span></p>
</blockquote><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">That doesn&#8217;t sound too bad, does it?</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Well&hellip;.the problem is that there is no standard, so it&#8217;s up to each vendor to choose how to use <em>their</em> version of network terminology. This is a very important piece of information to remember when having a discussion with engineers from multiple vendors. Don't make the mistake and assume that every engineer is using the SAME networking terminology, even if it's the same words!</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">I want to provide you with a few examples where it's possible that if you <em>assume</em> that everybody is using the same networking terminology without verifying it, it can lead to wrong decisions. And to get there, we need to define some common networking terminology first!</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h2>Disclaimer</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">I could walk you through a deep technical dive into the technologies I will discuss, but I choose to leave out a lot of technical data and technical explanations for a reason. I want to keep this as simple as possible and just go deep enough to discuss the issue I want to highlight &#8211; that networking terminology is easy to mix up and can be very confusing if used incorrectly! <strong>I strongly encourage you</strong> to <em><span style="text-decoration: underline;">do your own researc</span><span style="text-decoration: underline;">h</span></em> to understand the technologies discussed!</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">To avoid confusion during this post, I have organized this by what I choose to call &#8220;General Networking Terminology&rdquo; and &#8220;Cisco Terminology.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>General Network Terminology</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">There are several technologies used in a network that almost everybody working with networks has heard about. There are too many to cover in this post, so this section will very briefly just cover these technologies:</span></p><ul><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Ethernet</span></li><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Topologies</span></li><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Traffic Flows</span></li><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Bandwidth</span></li><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Virtualization (very briefly)</span></li></ul><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>ETHERNET</h3><p><span style="font-family: arial, helvetica, sans-serif;"><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-4019-329118/700px-Ethernet_Type_II_Frame_format.png"><img alt="700px-Ethernet_Type_II_Frame_format.png" class="jive-image image-1" height="123" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-4019-329118/700px-Ethernet_Type_II_Frame_format.png" style="height: 138.731px; width:700px;" width="700"/></a></span></p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 12pt; font-family: arial, helvetica, sans-serif;"><br/></span></p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Ethernet is the most used LAN technology today for interconnecting devices on a network. When sending data over Ethernet, a standard Type II Ethernet frame is 1518 bytes long and carries a MAC header (which includes addressing information about the sender and receiver), a payload (data), and a checksum (CRC).</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Ethernet is used to connect different network segments together and is considered a shared medium. That means collisions can occur, so each segment needs to use CSMA/CD* (even with a switch). These segments are called a collision domain*. In a HUB all ports connect to the same network segment*, so each port in a HUB belongs to the same collision domain. Using a switch instead &#8211; all switch ports connect to a different network segment, so each switch port is a different collision domain.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">When using a switch, it will make a frame forwarding decision based on the destination MAC address used in the MAC-header. Since a switchport is its own collision domain it means a frame will be forwarded between multiple network segments. The frame can be sent as a unicast frame, a multicast frame, or a broadcast frame. A unicast frame is sent to a single destination on the network segment, a multicast frame is sent to a <span style="color: #333333;">selected group of addresses on the network segment</span>, while a broadcast frame is sent to all hosts on the network segment. </span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">The switch will make the forwarding decision using its CAM table. A unicast frame is forwarded out of a single switch port. A multicast frame is forwarded out of all switch ports that are members of the multicast group (selected group). The broadcast frame will be sent out of all switch ports. The scope of how far the broadcast frame will be forwarded is called the broadcast domain*. But a switch will never forward a frame back out on the same switch port that it was received on.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Ethernet supports multiple topologies and multiple network designs, and if you are not careful, you can end up with a very large multicast group or a very large broadcast domain. Both will impact your overall network performance, so it&#8217;s a good general rule to keep your broadcast domain as small as possible.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-family: arial, helvetica, sans-serif;"><span style="font-size: 10pt;"><strong>*Note:</strong></span><span style="font-size: 10pt;"> Learn more about CSMA/CD, segments, collision domain, and broadcast domain on your own!</span></span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>TOPOLOGIES</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">A network topology refers to how the network nodes (hosts) are interconnected, including the physical cabling and the logical signaling. A very important skill for any network engineer is the ability to discuss different network topologies. That also includes being able to understand the difference between a physical topology and a logical topology.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">In many cases, the physical topology is a star topology, while the logical topology is a bus topology. When I discuss network topologies, I often need to explain the differences between the physical topology and the logical topology to explain a problem. A common mistake is to believe that the physical topology and the logical topology are the same.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">&#8220;In many cases, the physical topology is a star topology, while the logical topology is a bus topology.&rdquo; What does this mean?</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p><strong>Physical Topology</strong></p><p><span style="font-size: 10pt;">The physical topology is easy to understand. Just draw how the devices are actually cabled and wired and you get the physical topology. Examples used today are:</span></p><p><span style="font-family: arial, helvetica, sans-serif;"><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-4019-329119/topology1.png"><img alt="topology1.png" class="jive-image image-2" height="192" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-4019-329119/topology1.png" style="height: auto;" width="214"/></a><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-4019-329120/topology2.png"><img alt="topology2.png" class="jive-image image-3" height="200" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-4019-329120/topology2.png" style="height: auto;" width="220"/></a><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-4019-329121/topology3.png"><img alt="topology3.png" class="jive-image image-4" height="194" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-4019-329121/topology3.png" style="height: auto;" width="279"/></a></span></p><p><span style="font-family: arial, helvetica, sans-serif;">#1. Star Topology&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #2. Ring Topology&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #3. Tree Topology</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>Logical Topology</strong></p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">It&#8217;s much more difficult to try to understand how the logical topology looks. The logical topology is equal to how the communication appears from the perspective of the connected users (hosts).</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">What impacts the logical topology?</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">In general, depending on how your network is cabled, it will impact how your logical topology will look.&#8211; But what&#8217;s often overlooked is that multiple other components also affect your logical topology. Depending on which protocols you are using and how they are configured, you will create different logical topologies.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">The most common protocol used in Ethernet is STP* (Spanning Tree Protocol). It&#8217;s used to prevent bridge-loops* (often called switch loops). STP will make sure that all redundant connections that can cause a bridge loop will be blocked when you cable multiple switches together. Since STP will block links in that case, it affects the logical topology. The communication path that hosts can take in your network is changed because of the links that STP blocked to avoid bridge loops.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">I only mention STP briefly to show that it affects the logical topology and there is much more to learn about how it works. Let's look at an example of how a logical topology looks before STP and after STP.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p><span style="font-family: arial, helvetica, sans-serif;">&nbsp; <span style="font-size: 12pt; text-decoration: underline;">Topologies before STP</span></span></p><p><span style="font-family: arial, helvetica, sans-serif;"><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-4019-329122/topology3.png"><img alt="topology3.png" class="image-5 jive-image" height="194" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-4019-329122/topology3.png" style="height: auto;" width="279"/></a><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-4019-329123/topology4.png"><img alt="topology4.png" class="jive-image image-6" height="224" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-4019-329123/topology4.png" style="height: auto;" width="248"/></a></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: arial, helvetica, sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Physical Topology&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Multiple Logical Topologies</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">The logical topology between User 1 and User 2 have multiple paths available. User 1 could reach User 2 via multiple paths, for example:</span></p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif; color: red;">ASW1-&gt;DSW2-&gt;ASW3</span></p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif; color: #339966;">ASW1-&gt;DSW1-&gt;ASW3</span></p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif; color: yellow;">ASW1-&gt;DSW1-&gt;CSW1-&gt;DSW2-&gt;ASW3</span></p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">(There are more available paths, which I left out.)</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">A network cabled like that will not perform well without a protocol to prevent loops caused by the multiple paths available. STP is going to help us block some of the redundant links, and you can configure it and tune it to meet your network requirements. Depending on your STP configuration, you can end up with different logical topologies even if the physical topology remains the same. From the perspective of the connected hosts, STP allows you to build these logical topologies:</span></p><p><span style="font-family: arial, helvetica, sans-serif;"><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-4019-329127/topology5.png"><img alt="topology5.png" class="jive-image image-7" height="205" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-4019-329127/700-205/topology5.png" style=" width: 780.11px;" width="700"/></a></span></p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">In this case, STP can create multiple logical topologies based on a physical topology. It can be tuned and configured according to best practices you want your core switch to be the root bridge* so that traffic will flow over CSW1. This section doesn't cover any of the advanced features of STP or how it works other than to demonstrate that it will affect the logical topology.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">STP is not the only protocol that will build a logical topology; there are too many protocols to discuss in this post to cover them all. I&#8217;ll just name a few others for reference purposes:</span></p><ul><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">EtherChannels (used to hide physical topology for the protocols that build logical topologies)</span></li><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Routing protocols (provides a logical view of interconnected networks and how to reach them)</span></li><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">GRE (used to build a &#8220;virtual&rdquo; or logical point-to-point link)</span></li></ul><p><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;"><br/></span></p><p><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">I strongly encourage you to research more protocols than STP to get a better understanding of how logical topologies can be created!</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>TRAFFIC FLOWS</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">I mentioned that &#8220;traffic will flow over CSW1&rdquo; before. What does that really mean?</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">When discussing traffic flows, you need to understand the difference between ingress traffic and egress traffic. Traffic usually flows ingress on one interface and egress out another interface. It's also possible that the ingress and egress traffic is using the same interface in advanced topologies. This is what creates the &#8220;Tx&rdquo; and &#8220;Rx&rdquo; counters in your interfaces.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p><span style="font-family: arial, helvetica, sans-serif; font-size: 10pt;">&nbsp; RFC 3697 defines traffic flow as:</span></p><blockquote class="jive-quote">
<p style="margin-left: 36.0pt;"><span style="font-family: arial, helvetica, sans-serif; font-size: 10pt;">"<em>A sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that the source desires to label as a flow. A flow could consist of all packets in a specific transport connection or a media stream. However, a flow is not necessarily 1:1 mapped to a transport connection.</em>"</span></p>
</blockquote><p style="min-height: 8pt; padding: 0px; margin-left: 36.0pt;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">In other words, it is the direction in which the packets are being forwarded. The flow can be spread across multiple logical paths for redundancy or load-balancing* purposes. Just like STP, there are technologies that can hide the physical topology to create a different logical topology. Talking about interfaces and traffic flows, a port channel (EtherChannel) is one such thing.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">To view your ingress- and egress-generated traffic, all you need to do is look at your Tx and Rx counters on your interfaces. On the interface where the traffic is received, you will see an increased Rx counter. Similarly, you will see an increased Tx counter on the interface where the traffic is forwarded out. These are your ingress and egress traffic flows.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt;">There is no difference between a virtual interface* (port channel) and a physical interface as far as how the counters look, but there is a </span><span style="font-size: 10pt;"><em>huge</em></span><span style="font-size: 10pt;"> difference between the traffic flow over a port channel interface and a physical interface. That&#8217;s why you will see generally higher counters on a port channel interface. Here&#8217;s an example of a port channel with eight physical links (2.79Gbp/s):</span></p><p><span style="font-family: arial, helvetica, sans-serif;"><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-4019-329132/traffic_flow1.png"><img alt="traffic_flow1.png" class="jive-image image-8" height="483" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-4019-329132/700-483/traffic_flow1.png" style="height: 428px; width: 620px;" width="700"/></a></span></p><p><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">If we look at the individual links in the bundle, we can also see exactly how much each link has been affected by the traffic flows as part of the port channel bundle. Showing only one link as an example (31.80Mbp/s):</span></p><p><span style="font-family: arial, helvetica, sans-serif;"><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-4019-329136/traffic_flow2.png"><img alt="traffic_flow2.png" class="image-9 jive-image" height="472" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-4019-329136/700-472/traffic_flow2.png" style="height: 419px; width: 620px;" width="700"/></a></span></p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">This may look confusing at first, but what the port channel interface does is it bundles multiple physical links together in a &#8220;channel&rdquo; and creates one virtual logical interface. In other words, it hides the physical topology to create a logical topology.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">What happens with the traffic flows when it's sent over a virtual port channel interface?</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>LINK AGGREGATION</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Link Aggregation, or simply &#8220;LAG,&rdquo; is the terminology used by most vendors for bundling multiple physical links into a virtual logical one, which Cisco displays as a port channel interface. A port channel is used to provide redundancy for the physical topology by creating a single logical link for your network hosts to communicate through. There are two options to choose from: LAcP (vendor-neutral, most common) or PAgP (cisco proprietary, less common).</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Some of you are probably wondering why I mentioned that LAG was used to provide physical topology redundancy and NOT to increase the available bandwidth as well.</span></p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">It makes sense to think that since you connect multiple links and create a virtual interface that consists of them. The problem is that every single traffic flow generated from your hosts will still use only a single physical link from the bundle.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">There are a couple of reasons for that, which mostly involve solving application problems. I will not explain those, but it's a problem for applications that need to be solved. To solve this problem, there is a hashing algorithm involved to figure out which physical link to use from the bundle. It doesn&#8217;t matter if you choose LAcP or PAgP &#8211; they will both need to use the host flows as the string value to be computed through a hashing algorithm.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">And when I say &#8220;host flows,&rdquo; I&#8217;m talking about the information contained within a flow, such as source/destination MAC address, source/destination IP address, and source/destination TCP/UDP ports.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>HASHING</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Why do we use hashing and what is it?</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Hashing is a widely used concept within the IT world. It&#8217;s a multi-purpose technique used to generate a value based on a string that is computed through a mathematical function. The mathematical function used is called the hashing algorithm, and the value computed is called the hash value. A hash value is used because as long as you provide the same input string to a hashing algorithm, it will always generate exactly the same output hash value.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">We can then use the computed hash value instead of the original string for simplicity. In networks, we run a lot of data through a hashing algorithm to scramble data before we transmit it (encrypt it). But the same technique can also be used to choose a physical link to use when they&#8217;re bundled into a logical interface.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-family: arial, helvetica, sans-serif; font-size: 10pt;"><span style="text-decoration: underline;">Now pay attention to what I said there</span><strong> - The same input string will <span style="text-decoration: underline;">always</span> generate the same output hash value.</strong></span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">It&#8217;s a very big misunderstanding in the networking world that a port channel interface is mainly used to provide active/active forwarding. It&#8217;s used to provide redundancy for your physical topology. That means that just because you are creating a virtual port channel interface that consists of 2x10Gbp/s links, it doesn&#8217;t spread the load across the links so you get a total of 20Gbp/s available bandwidth for your data flows.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">A hashing algorithm is used to decide which physical link to use, and it means that as long as all the same parameters are used in the input string, then the algorithm will <span style="text-decoration: underline;">ALWAYS</span> choose the same physical link to send your data over. This is done using a XOR function, and I'll provide a brief example of how that works.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">It takes a couple of parameters used as input string, then computes the string through a XOR-based hashing algorithm. The computed hash value will then decide which physical link is going to be used. There are many configuration options available to decide manually which parameters to include in the input string to be computed through the hashing algorithm. The default parameters are platform-dependent.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">To compute the hash value, a XOR function is performed based on the following:</span></p><ul><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Input parameters from the flow to be hashed.</span></li><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">The number of physical links in the port channel bundle.</span></li></ul><p><span style="font-family: arial, helvetica, sans-serif; font-size: 10pt;">&nbsp;&nbsp;&nbsp; </span></p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Consider a flow that&#8217;s using Source IP 192.168.0.1 and Destination IP 192.168.1.1. I&#8217;ll line them up in binary and then perform a XOR function on the binary values. The number of bits that are used depends on the number of links in the bundle.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="text-decoration: underline; font-family: arial, helvetica, sans-serif; font-size: 10pt;">Here&#8217;s how it works using XOR</span></p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">SRC: 11000000. 10101000.00000000. 00000001<br/> DST: 11000000. 10101000.00000001. 00000001<br/> <strong>XOR: 00000000.00000000.00000001.00000000</strong></span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">The number of links in the bundle determines how many bits will be used from the XOR function. A link means a bit value, so two links are just two binary values. Link 0 or link 1. Only the last bit is needed to decide which link to use if it consists of two links. It's more easily represented like this:</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">SRC: xxxxxxxx. xxxxxxxx.xxxxxxxx. xxxxxxx1<br/> DST: xxxxxxxx. xxxxxxxx.xxxxxxxx. xxxxxxx1<br/> <strong>XOR: xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxx<span style="text-decoration: underline;">0</span></strong></span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">With four links in the bundle we also need to use four bits to decide which link to be used. Link 00, Link 01, Link 10, Link 11. The fourth bits will be used and look like this:</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">SRC: xxxxxxxx. xxxxxxxx.xxxxxxxx. xxxxxx01<br/> DST: xxxxxxxx. xxxxxxxx.xxxxxxxx. xxxxxx01<br/> <strong>XOR: xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxx<span style="text-decoration: underline;">00</span></strong></span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">As you can see, Link 0 will still be used, since &#8220;00&rdquo; in binary is still 0. But with four links in the bundle we have more links available to be used by the algorithm. So remember it doesn&#8217;t help to increase the number of links in a port channel &#8211; the same input parameters will still decide to use the same link in the bundle!</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">In other words, it looks like you have increased bandwidth available with more links in your bundle, but remember how the hashing works!</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>BANDWIDTH</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">The last piece I want to talk about is bandwidth. Everybody has heard about bandwidth &#8211; it&#8217;s increasing everywhere. Some of us are already deploying 100Gbp/s links in their networks. The need for increased bandwidth is driven by more and more data to be transported across a network. I want to highlight two things that can be confusing when talking about bandwidth:</span></p><ul><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Throughput</span></li><li><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Goodput</span></li></ul><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Remember when I talked about the Rx and Tx counters before?</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">That&#8217;s going to be your <em>throughput</em>. Your throughput is all the bits that you can transfer through your network. This includes all the needed headers and everything that is transported across your network. So for example, a 10Gbp/s link is capable of 10Gbp/s throughput. You can transfer 10Gbp/s over that link.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">But what about <em>goodput</em>?</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Goodput is often overlooked, and usually that&#8217;s something your end users will want. Goodput is when you take all your throughput data and strip all the headers and all the application layer overheads and just keep the data that you can use&hellip;that&#8217;s what goodput is! Taking the same example with a 10Gbp/s link, if you transfer a flow at 10Gbp/s and just look at how many of those bits are actually useful to your user sending them, you might end up with 7Gbp/s of goodput.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">In that case, you would have about 30% overhead in that flow.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">When discussing bandwidth, remember that it&#8217;s not all about the speed of the link. Having 8Gbp/s of goodput with 9Gbp/s throughput is better than 10Gbp/s throughput with only 7Gbp/s goodput. So you must consider the goodput and how you can increase the goodput! But that's outside the scope of this post.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>VLAN</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">I&#8217;m sure you&#8217;ve heard about VLAN before, so I&#8217;m not going to discuss what it is except to mention that it is a virtual version of a local-area network. That means we can configure our switches to only forward frames within our virtual network. We can spread this network to other switches using what Cisco calls trunk ports, or we can spread them using access ports. By default, all switch ports on a Cisco switch do not have any trunk ports, but they have all their switch ports as members of VLAN 1.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">I briefly mentioned VLANs because the Cisco VLAN terminology is the number one reason why things can go really wrong if you assume that the Cisco terminology is used everywhere. In short, Cisco decided to use some words that are not easily understood by the rest of the industry. So if you are not careful with these words, you will end up in a lengthy discussion and most likely with a misconfiguration because of it!</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h2>Cisco Terminology</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">This last section is included to highlight why things can be really confusing if you assume that the Cisco terminology is used everywhere. I'll just mention some of the Cisco terminology that is available and use an example based on experience where these can be mixed-up.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>DEFAULT VLAN</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">I mentioned that we can spread VLANs using something called access ports or trunk ports. This is something that you need to manually configure and define as part of your network implementation. By default Cisco provides us with a base configuration that defines all switch ports as members of VLAN 1. This is what Cisco calls the default VLAN. It&#8217;s a term used to describe which VLAN all switch ports belong to by default. With a base configuration out-of-the box, they are all configured as access ports in VLAN 1.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>ACCESS PORT</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Cisco defines a switch port that is member of a specific VLAN to be an access port in that VLAN. Technically speaking, that means that frames forwarded to this switch port will be sent &#8220;untagged&rdquo; for that VLAN. In my opinion, this is a confusing definition, because the rest of the industry uses the terminology "untagged ports" and "tagged ports" to define what type of frames are sent to/from it.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Consider that when you have a discussion about VLAN implementations. The Cisco terminology &#8220;access ports&rdquo; is not used by other vendors, and it's a high chance they will only understand what untagged/tagged ports mean.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>TRUNKING</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">When using Cisco equipment, it means that you can configure a swith port to carry multiple VLANs. When frames from multiple VLANs cross this link, the switch will add a 802.1Q tag to identify which VLAN it originally belonged to. This link will also look at the 802.1Q identifier to know where to forward a frame that is received on this link. This is a Cisco trunk port!</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">In my opinion this is the most confusing Cisco terminology, because the rest of the industry defines trunking as a way to aggregate multiple links as a trunk link. Cisco uses the trunk port to carry multiple VLANs, while other vendors will call this a tagged port.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Consider how extremely easy it is to mix up LAG with VLAN-tagged ports if you use the word trunking in a networking discussion.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>NATIVE VLAN</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Cisco uses the concept of a native VLAN to define which VLAN that should never contain any 802.1Q VLAN identifier in their frames. Technically, using a Cisco switch means the VLAN will never send any tagged frames across trunk ports, and it also means that if any untagged frames are received on a trunk port, they will be forwarded to the native VLAN.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">If you talk with someone that hasn&#8217;t studied Cisco, they will usually look like a question mark when you say the term &#8220;native VLAN&rdquo; and in my opinion this is confusing because a frame is always sent &#8220;untagged&rdquo; or &#8220;tagged&rdquo; in a network!</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>ETHERCHANNELS</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">EtherChannel is the Cisco term for bundling multiple physical links into a logical virtual interface called a port channel. It is the same that I mentioned before when I used the term link aggregation (LAG).</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">If you are having a discussion with other teams outside the networking-area, for example a storage, server or client team - they usually look very confused when hearing this term because they're used to link aggregation. Just remember that this is Cisco terminology if you talk to other vendors or teams!</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h2>3 Case examples why it&#8217;s important to understand Networking Terminology</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">If you&#8217;ve managed to read all the way down here without falling asleep&hellip;then here are my 3 examples of why it&#8217;s so very important to understand the network terminology properly before making implementations/decisions! There are of course more cases or scenarios where things can go wrong, but these three will be a good example for this post and the terminology I've discussed.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>CASE #1 - VLAN terminology mix-up</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">You are planning to implement a VLAN change in your network and decide to have a discussion with another engineer. What happens if you are using Cisco VLAN terminology and the other engineer is not used to Cisco terminology?</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">If you agree to create a trunk port between your switches, then the chances are high that the following happens:<br/> -You end up configuring your end of the switch port as a Cisco trunk port supporting 802.1Q.<br/> -The other engineer end up configuring his end of the switch port as a LAG using LAcP.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Depending on both of your configurations, you might end up with a switch loop. In either case, both of you <em>assumed</em> what a trunk port meant. So the implementation from both ends was not the expected result!</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>CASE #2 - Misunderstanding how much bandwidth is available</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">You are told to increase the available bandwidth in your network because users have complained that their bandwidth needs are not enough. You decide that link aggregation/Etherchannel can be used to increase the bandwidth, so you bundle multiple links into a port channel.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">What happens when you say that you have doubled the amount of available bandwidth and your users discovers that it&#8217;s not working?</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Remember that creating a port channel interface does not increase the throughput by the amount of available bandwidth. You need to consider the hashing function and the difference between goodput and throughput to make sure that you provide a good user experience.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h3>CASE #3 - Not considering the needed topologies before placing/moving hosts in your network</h3><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">During a network overview, it was discovered that some of your links in your network are utilized more often than other links, and you want to spread the load out more evenly due to this. There are multiple options available to address this, but you decide to move hosts around to try and spread out the load.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">What happens if you don&#8217;t consider the logical topology that the hosts need to use to be able to communicate? For example, what if your hosts require L2 adjacency due to high availability functions?</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">If you don&#8217;t consider the logical topology needs for your hosts, you might end up isolating hosts in two different logical topologies when they need to be in the same logical topology. The end result could be that the applications will fail to work as intended. One example of this would be a high availibility feature of a host for virtual machines. It's highly likely that you can end up isolating two hosts in different L2 topologies so that in case of a host failure, the failover feature doesn't work. This is difficult to troubleshoot because everything would be working <em>until it fails </em>and it's discovered that the failover feature didn't work. I've seen this happen, and it's not a good day at work.</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Remember to distinguish between the physical topology and the logical topology. It&#8217;s often discussed when faced with problems associated with load-distribution or high availability features!</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><h2>Final words</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="margin-top: auto; margin-bottom: auto;"><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">I hope that I did at least manage to encourage you to take a step back and think about the terminology you use when you discuss networks with other individuals. Networks are becoming more and more complex, and the time spent discussing incidents, designs, or implementations is increasing because of this. There is good reason to consider the networking terminology you are using to increase the quality of your discussions!</span></p><p style="min-height: 8pt; padding: 0px; margin-top: auto; margin-bottom: auto;">&nbsp;</p><p><span style="font-size: 10pt; font-family: arial, helvetica, sans-serif;">Last but not least, thank you for reading all the way down here, and I wish you all the best in your networking career!</span></p></div><!-- [DocumentBodyEnd:22a8512d-6481-41a1-892e-84d71d851eb4] -->bandwidthterminolgyccent_ccnatrunkaccessport channelnetworking_terminologyvip_blogWed, 12 Jul 2017 22:06:38 GMTbounce@learningnetwork.cisco.comhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2017/07/12/networking-terminology2017-07-12T22:06:38Z1 month 6 days ago150https://learningnetwork.cisco.com/blogs/vip-perspectives/comment/networking-terminologyhttps://learningnetwork.cisco.com/blogs/vip-perspectives/feeds/comments?blogPost=4019IP SLA Fundamentalshttps://learningnetwork.cisco.com/blogs/vip-perspectives/2017/06/13/ip-sla-fundamentals
<!-- [DocumentBodyStart:c766c005-7d01-4bf6-bd8e-e70d91e76493] --><div class="jive-rendered-content"><p><a><img alt="IP SLA Fundamentals" src="/resources/statics/1389573/IP_SLA_Fundamentals_blog_v2.jpg" style="float: left; padding: 6px 20px 8px 0px;" width="280"/></a></p><h3>Introduction</h3><p>Most of us, as network engineers, have been in a situation where users have reported performance issues with the network or that the network is down and we have to investigate to discover the root cause of the problem. When this happens, we usually rely on some sort of network monitoring and reporting application in order to get an idea of what our network is doing at the time.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>In this write-up, I will delve a little into the world of systems monitoring utilizing Cisco IOS IP SLA to gather and report on statistics. There are several other monitoring features that can be used in conjunction with IP SLA, including SNMP and NetFlow to assist in determining the cause of a network issue. However, this post will focus on IP SLA. IP SLA can be used to monitor and keep track of a number of statistics and report on them, but this blog post will only focus on a few.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h3>What is IP SLA</h3><p>IP SLA is an active method of monitoring and reliably reporting on network performance. By "active," I refer to the fact that IP SLA will generate and actively monitor traffic continuously across the network. An IP SLA Router is capable of generating traffic and reporting on it in real time. IP SLA can be configured in such a way that it can report on statistics such as:</p><ul style="list-style-type: disc;"><li><p>Jitter</p></li><li><p>Response time</p></li><li><p>Packet loss</p></li><li><p>Voice Quality Scoring (MOS)</p></li><li><p>Connectivity</p></li><li><p>Server or website responses and downtime</p></li><li><p>Delay</p></li></ul><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Although you do not need a Cisco Router at the other end of what you are monitoring, you are able to obtain a more detailed output if you do. This Cisco router is referred to as an IP SLA Responder.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>From the above list, you can see the benefits of utilizing Cisco IP SLA to perform network monitoring and reporting functions. IP SLA provides the ability to monitor a traffic path to a destination while also confirming that a particular web server is accepting connections. While this information is useful and can be seen through <strong>show</strong> commands on the IP SLA device, to make IP SLA reporting more human-readable, you can use an SNMP agent to poll the IP SLA router. There are a number of SNMP agents available that are capable of retrieving this information, including SolarWinds, Cacti, or PRTG to name a few.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>There are also other use cases for IP SLA, such as policy-based routing (PBR); however, the focus of this blog post is on the monitoring of the network.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h3>How IP SLA works</h3><p>IP SLA can be configured in two parts. There is the IP SLA router, which generates the traffic, and the IP SLA Responder (which can be any device, not just a Cisco router). One point I should mention is that the IP SLA Responder is not required for IP SLA to function, but it does allow for more detailed information gathering and reporting. In order to understand a little how the IP SLA function works, let&#8217;s take a look at how IP SLA is configured for UDP jitter to monitor the link between two Cisco routers, with one configured as an IP SLA Responder.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>The IP SLA ICMP jitter operation is configured to send an ICMP Timestamp Request (Type 13) to the configured destination host and is expecting an ICMP Timestamp Reply (Type 14) response from the destination. This ICMP packet contains three timestamp fields. One is the Originating timestamp, which is the timestamp from the source IP SLA router of the time that the packet was sent. The next two timestamp fields are the Receive timestamp, and the Transmit timestamp. As the field names suggest, the IP SLA Responder will insert the timestamp of when that packet was received, then also the timestamp of when it is transmitted. This can be seen in the below packet capture of the IP SLA ICMP jitter response showing the ICMP Timestamp Reply message.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a><img src="/resources/statics/1389573/IPSLA_image1.jpg"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Having the Receive and Transmit timestamps allows the IP SLA packet to not only measure the RTT of the packet getting from the source to the destination, but also to record how long the destination device takes to process the packet. If the IP SLA probe response is taking a long time, this could indicate that the receiving end device may be under high load and need to be investigated. There is also a fourth timestamp that is added to the calculated jitter, and this is when the IP SLA probe receives the packet back again. To verify the IP SLA operation statistics use the <strong>show</strong> command <strong>show ip sla statistics </strong>&lt;sla number&gt;<strong> detail</strong>.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="margin-left: 36pt;"><a><img src="/resources/statics/1389573/IPSLA_image2.jpg"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Each of the different IP SLA operations will function in a slightly different way, but follows the same principles. For example, the IP SLA Path Echo operation will use ICMP ping packets.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h3>Configuring IP SLA</h3><p>There are a few components that go together and need to be configured for IP SLA to function. First you need to decide what type of IP SLA operation you want to configure, whether it be ICMP jitter, HTTP GET request, DNS request, VoIP, etc. You then need to configure the IP SLA schedule to tell the IP SLA router when and how often to run the IP SLA operation and also when to stop it. There is also the IP SLA Responder that needs to be configured if you are using an IP SLA Operation that can make use of it.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Due to the large number of configuration options available for IP SLA (showing how to configure all of them would mean writing a book instead of a blog article), I will only show how to configure IP SLA to perform one operation, which for this article will be a check on an FTP server. Note that IP SLA only supports an FTP get request in order to report on the RTT it takes for the IP SLA Operation to communicate and download the file from the FTP server. Also note that this particular IP SLA operation does not require the IP SLA Responder to be configured.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>When configuring IP SLA, you first need to specify the IP SLA operation number. The IP SLA operation number can be anywhere from 1 to 2147483647. Once the IP SLA operation number has been configured, you can select which type of IP SLA operation you want.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="margin-left: 36pt;"><a><img src="/resources/statics/1389573/IPSLA_image3.jpg"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>To configured the FTP operation, you will need to specify the username and password along with the FTP path in this format: <em><a class="jive-link-external-small" href="ftp://" rel="nofollow" target="_blank">ftp://</a><span>&lt;username&gt;:&lt;password&gt;@&lt;server-ip&gt;/&lt;filename&gt;</span></em>. If you do not specify a username and password, then the default of anonymous and test are used.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="margin-left: 36pt;"><a><img src="/resources/statics/1389573/IPSLA_image4.jpg"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Once the FTP path has been configured, you can now configure any timeout parameters along with any other configuration options you wish to alter. For this example, I will leave everything as default values.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>The next step is to schedule the IP SLA operation to start, and tell the router how long to run for. You can configure the IP SLA operation to run for various periods of time. For our FTP operation, we want the IP SLA operation to only run from 8am to 5pm.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="margin-left: 36pt;"><a><img src="/resources/statics/1389573/IPSLA_image5.jpg"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>This tells the router to start the IP SLA operation 200 after 8am in the morning, continue for 9 hours, and to have this re-occur every day. Without the recurring keyword, the operation would only run once.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>To verify that our IP SLA operation has started and that we are getting successful results, we can use the <strong>show</strong> command <strong>show ip sla statistics 200 detail</strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="margin-left: 36pt;"><a><img src="/resources/statics/1389573/IPSLA_image6.jpg"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>This information can be polled by your SNMP Agent, which will usually record and graph your IP SLA results, making viewing historical data easier.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h3>Conclusion</h3><p>This blog has hopefully provided you with a basic understanding of how IP SLA works and how it can be used to monitor your network and services. The configuration examples above show only a very small portion of what IP SLA is capable of performing. There are other features of IP SLA that do not just include the monitoring of a network.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>More detailed information regarding the configuration of IP SLA can be found here. <a class="jive-link-external-small" href="http://www.cisco.com/c/en/us/td/docs/ios/12_4/ip_sla/configuration/guide/hsla_c.html" rel="nofollow" target="_blank">http://www.cisco.com/c/en/us/td/docs/ios/12_4/ip_sla/configuration/guide/hsla_c.html</a></p></div><!-- [DocumentBodyEnd:c766c005-7d01-4bf6-bd8e-e70d91e76493] -->Tue, 13 Jun 2017 23:26:22 GMTbounce@learningnetwork.cisco.comhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2017/06/13/ip-sla-fundamentals2017-06-13T23:26:22Z2 months 4 days ago170https://learningnetwork.cisco.com/blogs/vip-perspectives/comment/ip-sla-fundamentalshttps://learningnetwork.cisco.com/blogs/vip-perspectives/feeds/comments?blogPost=4017Being a Cisco SMEhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2017/05/18/being-a-cisco-sme
<!-- [DocumentBodyStart:239bc86d-4485-432f-a651-11d7fe66586f] --><div class="jive-rendered-content"><p><a><img alt="Being a Cisco SME" src="/resources/statics/1389573/SME_VIPPerspective_Blog_v2.jpg" style="float: left; padding: 0px 20px 8px 0px;" width="280"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>Introduction</h2><p>I'm a person that you don't necessarily know, but you may be familiar with some of my work: I act as a Cisco subject matter expert (SME) developing questions for various Cisco exams. My intention here is to describe what it is like to act as a SME so that you may decide whether it is something for you. My experience may not be the exact same as what you (the reader) would experience as a SME, but this should at least give you an idea of what to expect.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>What is it all about?</h2><p>Being a SME is about participating in the development of high-quality exam items. Here are a few responsibilities that a SME typically has:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ul><li><p>Authoring and editing items for written exams.</p></li><li><p>Reviewing items for the written exams.</p></li><li><p>Participation in Job Role Analysis meetings (JRA).</p></li><li><p>Participation in Job Task Analysis meetings (JTA).</p></li><li><p>Participation in Standard Setting meetings.</p></li></ul><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>When you are selected as a SME, your first assignment will likely be authoring a certain number of items for an exam. Often you will be assigned specific blueprint topics to which you will write an item, but in some cases you are free to choose for yourself. Of course this depends on the current needs &#8212; the Exam Program Manager will instruct you on the specifics. Each authored item should map to a certain level (difficulty), which is defined as what a typical candidate for the given exam level is expected to know. This is based on an on-going analysis of tasks and skill levels found in real-life jobs on that specific level. Almost needless to say, the level you should be aiming for depends on which exam level you are authoring for &#8212; the typical tasks for a CCNA, CCNP, or CCIE level candidate are of course not identical.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Typical item types you will meet in your work as a SME are:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ul><li><p>Multiple choice single answer (MCSA).</p></li><li><p>Multiple choice multiple answer (MCMA)</p></li><li><p>Enhanced matching (also known as Drag and Drop, or DND)</p></li></ul><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>You may also come across simlets, but personally I have never done any work with simlets &#8212; I guess they're primarily developed in-house at Cisco.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Once you have been selected for a project, you will receive an email from the Exam Program Manager, which will outline the project and formally invite you to participate. First you will likely be invited to a briefing (approximately 1 hour) on WebEx. Here you will get some guidelines as to how to write proper questions (called stems) along with effective possible choices (where one or more choices should be correct while the rest should be plausible, but not correct under any circumstance). Ideally, this starts with a stem that is worded in a way, so that it does not leave room for interpretation and at the same time is short and easy to read and understand (things like avoiding complex and long sentences &#8212; you should be aiming at 7th grade English). Often, you will receive a slide deck that you can use for reference when actually developing the items. For instance, all IP addressing should adhere to RFC 1918 or certain subnets that Cisco has allocated for this purpose. For IPv6, you always use something in the 2001:db8::/32 range (the official demonstration/documentation prefix). There are other goodies in this slide deck too, so keep it near you.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>After you have gained some experience as a SME, you may also be selected to review items authored by other SMEs. Your purpose in this regard is to assess whether the questions are fair, relevant, and technically correct. Your assessment is based on a number of factors, which might be (but is not limited to):</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ul><li><p>Is the item tailored to the actual exam level (CCENT, CCNA, CCNP, CCIE, and so on)?</p></li><li><p>Is the item technically correct?</p></li><li><p>Will adding an exhibit to the item make it easier to understand?</p></li><li><p>If there already is an exhibit in the item, is it relevant, correct, and relevant to the question?</p></li><li><p>Is it too easy or too hard (based on the expected skill set of the candidate)?</p></li><li><p>Is the item open to interpretation?</p></li><li><p>Is the item free of ambiguity or bias?</p></li><li><p>Is it clear and concise in its wording?</p></li><li><p>Is the item aligned with the current blueprint for the exam?</p></li><li><p>When you read the item for the first time, which answer would you pick?</p></li><li><p>Is the question actually measuring expertise of the candidate, or do you consider it a trivia or memorization question?</p></li></ul><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>The input you provide will be collected and combined with input from other SMEs reviewing the same set of questions, and it will help the Exam Program Manager determine whether the item needs additional work before going into production or if it is ready as it is. Review projects will also be kicked off with a WebEx meeting to provide you with relevant information on the tasks ahead of you.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Once the WebEx meeting has been completed, you will receive your actual assignments (number of questions to author or review) along with a deadline. The Exam Program Managers are aware that you likely are doing this in your spare time, so if you run into problems keeping the deadline, just be open about it and communicate. Often you can get an extension of the deadline.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>With regards to the JRA/JTA meetings, this is where SMEs meet to articulate relevant job role expertise, define the Minimally Qualified Candidate (MQC), define the knowledge, skills, and abilities a person needs to become certified, and also weight the blueprint. These meetings are crucial to keep the exams relevant and up-to-date, and if you are selected to participate in these meetings, you will not only be able to influence how the exam evolves, but you will also be able to network with other SMEs.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Finally, by participating in Standard Settings meetings you also get a say in what the cut score of an exam form should be.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Other activities could include helping create preparation materials, such as the Learning Matrix (previously known as Streamlined Preparation resources), or writing blogs, where you get an opportunity to share your views and thoughts on technologies, exams, and other topics related to certifications.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>As you can see, there are many different aspects of being a SME. It really illustrates how important a role SMEs play in keeping Cisco exams up-to-date and relevant.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Please note that being selected as a SME doesn't guarantee that you will get to participate in all of the aforementioned activities.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>What should I know?</h2><p>First of all, you will be asked to sign a Non-disclosure agreement (NDA) for each project you participate in. This is because you obviously are not allowed to disclose any of the content you are exposed to during the project. This step is mandatory &#8212; you can't participate if you don't sign the NDA.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Signing the NDA also has other implications. You are for instance not allowed to mentor or teach classes within the same technology track as you are authoring/reviewing items for. This restriction is enforced for one year after your last activity in a project (the exact terms are outlined in the NDA you sign). So if you're involved in a Data Center project, you can't teach Data Center classes and/or mentor individuals pursuing exams in the Data Center technology track (at any level). Another thing worth mentioning is that CCSIs are excluded from participating in the SME program, because of the rather obvious conflicts of interest.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>The amount of time you should expect to spend highly depends on your imagination and skills in writing the questions. When you first start out, you will likely spend quite a lot of time getting things right (and checking it, checking it, checking it, and checking it once again, just to be sure), but as you gain experience, you're likely able to get things done a bit faster. Personally, I can spend anywhere from five minutes to several hours developing a single item, depending on the specifics of the item. Is it a simple question on a topic, or are you doing some sort of simulation where you present some output for the candidate to analyze?</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Reviewing items is also very dependent on the question. Some are easy to review, while others may require you to spin up a simulation to verify that everything is correct and without ambiguity.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>As a rule of thumb, you should expect a project to take somewhere between 10 and 30 hours. Likely this is over a time frame of two to four weeks, which is usually what you will have to finish your work.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>In order to participate in a project for an exam, it is a requirement that you hold a valid certification pertaining to that particular exam. So, if you're to develop items for CCNP ROUTE, you must have a valid CCNP Routing and Switching certification. Finally, writing questions for a specific exam does <strong>not</strong> disqualify you from taking the actual exam yourself - that is allowed.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>What's in it for me?</h2><p>You don't get paid for the work you are doing, but usually the Exam Program Manager can provide you with certain options as a token of gratitude, once the project has finished. This could be a time extension for your current certifications (on or below the level you've done work for), a Cisco Press title of your own choosing, or exam vouchers. This information will be communicated by the Exam Program Manager.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>To me, this isn't the important thing though. The important thing is that you keep yourself up-to-speed and your knowledge sharp on the topics in the exams, where you are doing SME work. This can help you reach even higher personal skill levels. Obviously, you need pretty solid knowledge within a topic if you are to write meaningful questions on it. Personally, I really enjoy doing SME work. I benefit from keeping my knowledge fresh, but I also have the chance to influence the way Cisco exams are heading. I can actually help make sure that candidates get a fair and relevant test, when they sit down in front of the computer in the test center. That is my way of giving something back to the community and Cisco.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>Now what?</h2><p>If you are interested, you can head on over to this link, where you can also sign up: <a class="jive-link-wiki-small" data-containerId="2215" data-containerType="14" data-objectId="22141" data-objectType="102" href="https://learningnetwork.cisco.com/docs/DOC-22141">Cisco Certifications Subject Matter Expert Recruitment Program</a> . Once you submit you application, Cisco will go through the submitted information. You might be requested to provide additional information such as a bio and/or resume. This will serve as a proof that you are qualified to work on the project you have been initially selected for.</p></div><!-- [DocumentBodyEnd:239bc86d-4485-432f-a651-11d7fe66586f] -->Thu, 18 May 2017 16:31:18 GMTbounce@learningnetwork.cisco.comhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2017/05/18/being-a-cisco-sme2017-05-18T16:31:18Z3 months 5 hours ago110https://learningnetwork.cisco.com/blogs/vip-perspectives/comment/being-a-cisco-smehttps://learningnetwork.cisco.com/blogs/vip-perspectives/feeds/comments?blogPost=3970Network Design 101: Scratching the surfacehttps://learningnetwork.cisco.com/blogs/vip-perspectives/2017/04/18/network-design-101-scratching-the-surface
<!-- [DocumentBodyStart:8b4d2aa9-f2fc-45f7-971e-50c3a56f3a76] --><div class="jive-rendered-content"><p><a><img alt="Network Design 101: Scratching the surface" src="/resources/statics/1389573/NetworkDesign101_blog.jpg" style="float: left; padding: 6px 20px 8px 0px;" width="285"/></a></p><h2>Introduction</h2><p style="text-align: justify;">Most of us have been several times in that place where we - as network engineers - contemplate a network diagram and have several questions come to us like lightning strikes: &#8220;Is this the best way to do it?&rdquo; &#8220;Could it be improved somehow?&rdquo; &#8220;What if?&rdquo;</p><p style="text-align: justify;"><span><br/></span></p><p style="text-align: justify;">In this write-up I intend to give an introductory view of network design and share situations and conditions that could be present in the process. These situations would affect the final result of a design and, having them in mind along with the correct mindset, would turn the table in your favor.</p><p style="text-align: justify;"><span><br/></span></p><p style="text-align: justify;">The goal of this post is to highlight considerations, benefits, drawbacks, when architectures are followed to create a network design, and what could happen when conditions in the environment change. It will not dig deep in a technology discussion from an implementation point of view, as design is not an exact science, and goals can be accomplished in several ways.</p><p><span><br/></span></p><h2 style="text-align: justify;">Network architecture and network design</h2><p style="text-align: justify;">In the process of writing this post, several experts gave their support to check and validate the information poured into the following lines. I encountered an interesting debate about the meaning of the words &#8220;architecture&rdquo; and &#8220;design&rdquo; when applied to networking. As a result of being a process that involves several visions, technologies, and perspectives, the corresponding definitions don't have a clear and exact meaning for everybody. They clearly may and will vary depending on roles and people involved. All the contributors were right from their point of view, and the next paragraphs are a result of their advice, knowledge, and experience.</p><p style="text-align: justify;"><span><br/></span></p><p style="text-align: justify;">According to <a class="jive-link-external-small" href="http://www.opengroup.org/subjectareas/enterprise/architecture" rel="nofollow" target="_blank">The Open Group Architecture Forum</a> (TOGAF), which is a framework followed for developing an enterprise architecture, the term "architecture" is defined in the following ways:</p><p style="text-align: justify;"><span><br/></span></p><ol style="text-align: justify;"><li><p>A formal description of a system, or a detailed plan of the system at component level, to guide its implementation (source: ISO/IEC 42010:2007).</p></li><li><p>The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.</p></li></ol><p style="text-align: justify;"><span><br/></span></p><p style="text-align: justify;">And specifically, when referring to technology architecture, it's described as follows:</p><p style="text-align: justify;"><span><br/></span></p><p style="margin-left: 22pt; text-align: justify;"><strong>Technology Architecture</strong> describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.</p><p style="text-align: justify;"><span><br/></span></p><p style="text-align: justify;"><span style="font-size: 10pt;"><br/></span></p><p style="text-align: justify;"><span style="font-size: 10pt;">Doing a quick change in the wording, hopefully to make it easier to swallow without losing the main goal behind the concept, we could see the architecture as &#8220;the big picture,&rdquo; whose main goal is to envision the network being molded, sculpted, and shaped from its actual state to its ultimate state. </span><span style="font-size: 10pt;"><strong>When designing a network, it all comes down to creating something that should fulfill business needs/requirements and application requirements within constraints.</strong></span><span style="font-size: 10pt;"> The process of carving, etching, and creating the network is what we could call network design.</span></p><p style="text-align: justify;"><span><br/></span></p><h2 style="text-align: justify;">Environmental approach</h2><p style="text-align: justify;">There are two possible scenarios we can run into, and it's important to highlight the approach needed when dealing with them. Those scenarios could be described in the following manner:</p><p style="text-align: justify;"><span><br/></span></p><p style="margin-left: 22pt; text-align: justify;"><strong>Greenfield:</strong> A greenfield is an environment that does not posses any constraint imposed by a previous work. In other words: it's the environment where you start from scratch and build everything from the ground up.</p><p style="text-align: justify;"><span><br/></span></p><p style="margin-left: 22pt; text-align: justify;"><strong>Brownfield:</strong> Unlike greenfield, a brownfield is an environment that does have constraints imposed by a previous work. A network already established that needs to be modified while being in production. This is the common case you would find in real world.</p><p style="text-align: justify;"><span><br/></span></p><p style="text-align: justify;">The difference in the approach for both scenarios lies in the conditions where they are exposed. Following previous terminology, in a brownfield environment, the network needs to be sculpted to meet business and application requirements, having in mind that there are previous constraints already in place because of an existing design and an already operating infrastructure. On the other hand, when dealing with a greenfield environment, as the network is designed from scratch, it's carved and then delivered, already meeting the requirements considered for its conception from the beginning.</p><p style="text-align: justify;"><span><br/></span></p><p style="text-align: justify;">As stated previously, the way we can carve the network is only possible if we know what shape we want it to have; in other words, an artist cannot mold a sculpture without a shape in mind or an inspiration to follow. This is the moment when interaction with the business is required.</p><p style="text-align: justify;"><span><br/></span></p><p style="text-align: justify;">To know which design model to follow, which technologies and topologies to implement and how to do it, we need to interact with business. Whatever the implementation intended, it needs to be clear from the beginning about what the business needs are. This phase could be challenging, as there are several visions given by management and technical staff.</p><p style="text-align: justify;"><span><br/></span></p><p style="text-align: justify;">Making use of analogies here: If you were to ask technical staff what is needed, you would get a requirement with a budget similar to buying a Ferrari. But, when you go to management with those requirements received from the technical staff, they would have (most probably) enough budget to buy a Kia. Even though everybody (technical guys) would like to have a network that goes from 0 to 100Kmph in 3 seconds (who doesn't?), it's not always the best decision, or even the possible or necessary one, according to business. The wise procedure would be to coordinate meetings to get information and mix the best of two worlds. What are the business needs and how are they accomplished from a technical perspective? What would be the outcome of implementing certain technology over another?</p><p style="text-align: justify;"><span><br/></span></p><p style="text-align: justify;">With those requirements in mind, we can design a network having certain technologies working together to accomplish our goal or goals, which should include enabling the network we are designing to deliver the services needed by the applications and allow business to generate revenue.</p><p style="text-align: justify;"><span><br/></span></p><p style="text-align: justify;">Businesses often decide to go for the Kia because of budget reasons, and then a major break happens, and fixing it costs the same as the initial Ferrari proposed, or even more. It's always a matter of projection. The discussion should be done with present and future in mind. Technologies that could be adopted in the future and expected network growth are examples of these considerations.</p><p style="text-align: justify;"><span><br/></span></p><p style="text-align: justify;">It&#8217;s worth mentioning that, as network design is not an exact science, you can&#8217;t find an ultimate solution that would work flawlessly for all possible cases, but it always comes down to the specific needs and requirements. <strong>The only wrong design is the one conceived without considering business and application requirements.</strong> Of course, as requirements, there will also be constraints. Examples of these elements are: legacy technologies already implemented to be considered (compatibility/interoperability between technologies), single-vendor/multi-vendor environments (vendor specific technologies/open standards), economical constraints (limited budget), geographical constraints (where are devices located, service providers available locally, WAN transport availability), application requirements/constraints (jitter sensibility, reconnections, TCP/UDP-based, multicast/unicast transport required, data encryption), and many more details that you should be familiar with would affect the result of your design.</p><p style="text-align: justify;"><span><br/></span></p><h2 style="text-align: justify;">Network design principles</h2><p style="text-align: justify;">Additionally, along with requirements and constraints, an ideal design should (but doesn't always) possess the following principles as the foundations for its conception:</p><p style="text-align: justify;"><span><br/></span></p><p style="margin-left: 22pt; text-align: justify;"><strong>Hierarchy:</strong> It's always ideal to break a big design into smaller areas/layers, have clear segmentation between areas, assign functions to them and devices composing each one of them. Function or functions being executed by each device must be clearly defined.</p><p style="min-height: 8pt; padding: 0px; text-align: justify;">&nbsp;</p><p style="margin-left: 22pt; text-align: justify;"><strong>Modularity:</strong> Implementing hierarchy also enhances modularity. As network and functions are divided into several modules/areas, failure domains are limited to certain areas. This means that a failure (hardware/software/link) in a given module/layer/area would represent an impact that affects the area itself and may or may not affect other parts of the network.</p><p style="text-align: justify;"><span><br/></span></p><p style="margin-left: 22pt; text-align: justify;"><strong>Scalability:</strong> The capacity the network would have to grow without affecting functions belonging to its module or any other layer or module. Relying also on modularity, making the network grow would be a matter of adding another module.</p><p style="text-align: justify;"><span><br/></span></p><p style="margin-left: 22pt; text-align: justify;"><strong>Resiliency:</strong> Guarantee that the network would be highly available to meet users or business expectations about a permanent service offering. The network should be able to work under normal and abnormal circumstances (e.g. device/link/software failures, huge traffic loads, DoS attacks) and scheduled events (eg. maintenance windows). Accretion of availability can be accomplished in several ways; one of them is to have redundant connections between failure domains (these connections are called choke points). This would reduce the time the network would take to recover from a failure and forward traffic around it to guarantee service offering over adverse conditions.</p><p style="text-align: justify;"><span><br/></span></p><p style="margin-left: 22pt; text-align: justify;"><strong>Flexibility:</strong> Be able to modify sections of the network, add new technologies and modules, and make protocols work together without having to make a major modification.</p><p style="text-align: justify;"><span><br/></span></p><p style="text-align: justify;">Keep in mind that the business could decide to make a sudden change in the design, which would lead to the following questions: is your network design flexible enough for this? Can you make changes without redesigning it completely?</p><p style="text-align: justify;"><span><br/></span></p><p style="text-align: justify;">To prevent twists like the one described above, it's important to set the scope and goals of the design, along with constraints, as early as possible. If a new requirement is raised after this, there must be an agreement with the client about how to integrate it with the current design and how it will affect the whole process agreed before (schedule and pricing do matter).</p><p style="text-align: justify;"><span><br/></span></p><h2 style="text-align: justify;">Final thoughts</h2><p style="text-align: justify;">This blog was intended to explain the design mindset, the thinking involved, and the reasons behind it, along with a taste of real world situations and conditions that do really happen. The idea is to spread the word and to let people know that design is not just putting boxes together to make traffic flow and lights green. It's a process that requires deep thinking, preparation, and analysis.</p><p style="text-align: justify;"><span><br/></span></p><p style="text-align: justify;">I hope it somehow helps to clarify doubts. After an extensive review of related literature, I thought this would be a way to put everything together, give a brief introduction, and help to understand topics or terms that could be confusing or hard to catch.</p><p style="min-height: 8pt; padding: 0px; text-align: justify;">&nbsp;</p><p style="text-align: justify;">UPDATE: Spanish version can be found here: <a class="jive-link-blog-small" data-containerId="4035" data-containerType="37" data-objectId="4002" data-objectType="38" href="https://learningnetwork.cisco.com/community/espanol/blog/2017/05/26/vuelo-rasante-sobre-el-diseno-de-redes">Vuelo Rasante Sobre el Dise&#241;o de Redes</a></p></div><!-- [DocumentBodyEnd:8b4d2aa9-f2fc-45f7-971e-50c3a56f3a76] -->designbusinessnetwork_designrequirementsapplicationvipintroductorybusiness_constraints101Tue, 18 Apr 2017 14:30:08 GMTbounce@learningnetwork.cisco.comhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2017/04/18/network-design-101-scratching-the-surface2017-04-18T14:30:08Z2 months 3 weeks ago320https://learningnetwork.cisco.com/blogs/vip-perspectives/comment/network-design-101-scratching-the-surfacehttps://learningnetwork.cisco.com/blogs/vip-perspectives/feeds/comments?blogPost=3989Anatomy of GRE Tunnelshttps://learningnetwork.cisco.com/blogs/vip-perspectives/2017/03/14/anatomy-of-gre-tunnels
<!-- [DocumentBodyStart:e54d356a-f1e7-4bfe-b8d8-ae628a2c3a0e] --><div class="jive-rendered-content"><p><a><img alt="Anatomy of GRE Tunnels" src="/resources/statics/1303575/GRE_Tunnels_blog_v2.jpg" style="float: left; padding: 0px 20px 8px 0px;" width="280"/></a></p><h1>Introduction</h1><p><span style="font-family: helvetica;"><br/></span></p><p dir="ltr"><span style="font-family: helvetica;">With the recent iterations of the CCNA exam blueprint, GRE tunnels have become one of the most commonly discussed topics here on CLN. With this blog, I hope to explain and demonstrate the basic configuration required to form GRE tunnels with specific use cases in mind. I will also address certain pitfalls encountered while implementing GRE tunnels, beginning with a basic overview of tunneling.</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>Tunneling Overview</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="font-family: helvetica;">Tunnels provide a way to transport protocols that the underlying network does not support. There are several reasons why this may be:</span></p><ul><li><span style="font-family: helvetica;">The network infrastructure doesn&#8217;t support the protocol being used</span></li><li><span style="font-family: helvetica;">The network infrastructure cannot route the packets due to lack of routing information or addressing types (public addressing vs. private addressing)</span></li><li><span style="font-family: helvetica;">The network infrastructure doesn&#8217;t support the traffic type (multicast or broadcast)</span></li></ul><p><br/><span style="font-family: helvetica;">The most common use case for tunnels is to connect remote, geographically separated sites over an existing network, most notably routing over a public infrastructure (such as the Internet). When used in this manner, tunnels create VPN overlay networks between remote sites. Packets destined to remote private networks are encapsulated within a new IP header that is used to traverse the public internet.<br/></span></p><p><span style="font-family: 'andale mono', times;"><br/><span style="font-family: helvetica;">Tunnels accomplish this by creating a virtual network (<strong>overlay network</strong>) on top of a physical underlying infrastructure (<strong>underlay network</strong>), providing a logical interface that emulates a direct physical link connecting the two sites. The tunnel interface encapsulates the original protocol traffic, the <strong>passenger protocol</strong>, using a <strong>carrier protocol</strong>. The <strong>carrier protocol</strong> is then encapsulated inside a <strong>transport protocol,</strong> which is used to route over the underlying infrastructure.</span></span><span dir="ltr"><br/></span></p><p><span><span><span style="color: #000000; font-size: 10pt; font-family: Arial;"><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3971-326647/Intro.jpg"><img alt="Intro.jpg" class="jive-image image-4" height="314" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3971-326647/Intro.jpg" style="height: auto;" width="620"/></a></span><br/></span></span><span style="font-family: helvetica;">Traffic that enters the tunnel is forwarded, hidden from the underlying infrastructure. It is received on the other end to be unwrapped and further processed. The devices in the transit network do not examine the original packet's IP header or the payload.</span></p><p><br/><span dir="ltr" style="font-family: helvetica;">There are many varieties of<strong> carrier protocols</strong></span><span style="font-family: helvetica;"> that can be used to form tunnels, such as L2TP, IP-in-IP, and GRE to name a few. As mentioned earlier, the focus of this blog is on point-to-point GRE tunnels.</span><span><span><br/></span></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>GRE Tunnels</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">GRE tunnels provide an interface the device can use to forward data. The &#8220;data&rdquo; in this sense is the </span><span dir="ltr" style="font-family: helvetica;"><strong>passenger protocol</strong> itself, such as IPv6 or IPv4. These tunnels are comprised of three main components:</span></p><ol><li><span style="font-family: helvetica;">Delivery Header (Transport Protocol)</span></li><li><span style="font-family: helvetica;">GRE Header (Carrier Protocol)</span></li><li><span style="font-family: helvetica;">Payload Packet (Passenger Protocol)</span></li></ol><p><span style="font-family: helvetica;"><br/><span dir="ltr">The </span><span dir="ltr"><strong>passenger protocol</strong> is sent to the GRE tunnel interface where it is encapsulated by the <strong>GRE header</strong>. The resultant packet is encapsulated by the <strong>transport protocol,</strong> which adds the <strong>delivery header</strong> used to route across the underlying network. For example, if IPv6 is to be tunneled across an IPv4 infrastructure, the device forwards the IPv6 packet to the GRE tunnel interface. The GRE tunnel interface adds its header and uses the IPv4 protocol stack to encapsulate and deliver across the underlying IPv4 network infrastructure.</span></span></p><p><br/><span style="font-family: helvetica;">GRE can be used with many different combinations of passenger and transport protocols. However, IPv4 and IPv6 are the most common transport protocols for GRE. For example:</span></p><ul><li><span style="font-family: helvetica;">GRE can use IPv4 as the transport protocol to tunnel an IPv4 packet across the underlying network infrastructure.</span></li><li><span style="font-family: helvetica;">GRE can use IPv4 as the transport protocol to tunnel an IPv6 packet across the underlying network infrastructure.</span></li><li><span style="font-family: helvetica;">GRE can use IPv6 as the transport protocol to tunnel an IPv4 packet across the underlying network infrastructure.</span></li><li><span style="font-family: helvetica;">GRE can use IPv6 as the transport protocol to tunnel an IPv6 packet across the underlying network infrastructure.</span></li></ul><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>Why Use GRE Tunnels?</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">GRE&#8217;s support for multiple protocols and packet types makes it ideal for solving many of the problems faced when trying to form VPNs across the Internet. The most obvious issue is that private addressing used in the enterprise cannot be routed across the public Internet. GRE solves this by encapsulating the IP header with private addressing using an outer IP header that uses public addressing.</span></p><p><br/><span style="font-family: helvetica;">When it comes to routing, as we know hello messages used by IGPs to discover neighbors are sent as multicast, and the IGP adjacencies are limited to directly connected neighbors.</span></p><p><br/><span style="font-family: helvetica;">When an IGP tries to discover neighbors, by default, it will multicast hello messages out to all of the interfaces on which it is enabled. However, in certain situations multicast transmission or routing multicast traffic is unsupported, such as over the public Internet or when using IPsec VPN tunnels. Additionally, even if this limitation were surmounted, IGPs only form adjacencies with directly attached neighbors.</span></p><p><br/><span style="font-family: helvetica;">GRE can be used to solve both of these problems:</span></p><ol><li><span style="font-family: helvetica;">GRE supports multicast traffic allowing hello messages generated by an IGP to be transported through the GRE tunnel across the underlying infrastructure as a unicast packet. IPsec can then be used to encrypt all traffic flowing through the GRE tunnel.</span></li><li><span style="font-family: helvetica;">GRE configuration creates a logical direct connection between two sites over the underlying infrastructure. This means the control plane of the IGP believes it is directly connected to the neighbor with which it is exchanging hellos and therefore can form the adjacency.</span></li></ol><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>GRE Configuration</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">To illustrate the utility of GRE tunnels, the following example topology has been created. Below there are two sites that need connectivity to each other by the means of a GRE tunnel over a public infrastructure:</span></p><p><span style="font-family: 'times new roman', times;"><br/></span></p><p><span style="font-family: 'times new roman', times;"><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3971-326646/Main.jpg"><img alt="Main.jpg" class="jive-image image-3" height="326" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3971-326646/Main.jpg" style="height: auto;" width="620"/></a><br/></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">This topology includes all of the issues discussed in the previous section:</span></p><ul><li><span style="font-family: helvetica;">The two sites require direct connectivity over another underlying infrastructure.</span></li><li><span style="font-family: helvetica;">The two sites utilize multiple protocols (IPv4 and IPv6).</span></li><li><span style="font-family: helvetica;">The two sites utilize IPv4 private addressing.</span></li><li><span style="font-family: helvetica;">The two sites need to exchange routing information in order to establish reachability.</span></li></ul><p><br/><span style="font-family: helvetica;">A GRE tunnel capable of tunneling both IPv4 and IPv6 simultaneously has been configured with 102.1.1.0/24 as the overlay network. The 12.1.1.0/24 and 23.1.1.0/24 networks form the transport (underlay) connecting R1 and R2 to the public internet. The tunnel endpoints are the loopback interfaces 1.1.1.1/32 and 2.2.2.2/32 on R1 and R2 respectively. Connectivity between the loopbacks has been established using static default routes.</span></p><p><br/><span style="font-family: helvetica;">The following steps list the basic GRE tunnel configuration for this scenario:</span></p><ol><li><span style="font-family: helvetica;">Create a tunnel interface</span></li><li><span style="font-family: helvetica;">Identify the carrier protocol (GRE)</span></li><li><span style="font-family: helvetica;">Identify the passenger protocol (IPv4, IPv6)</span></li><li><span style="font-family: helvetica;">Identify the source/destination of the delivery header</span></li></ol><p><span style="font-family: helvetica;"><br/></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R1:</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000; font-weight: bold;"><br class="kix-line-break"/></span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">interface Tunnel100</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000; font-weight: bold;"><br class="kix-line-break"/></span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> tunnel mode gre</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000; font-weight: bold;"><br class="kix-line-break"/></span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> ip address</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000; font-weight: bold;"> </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">102.1.1.1 255.255.255.0</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000; font-weight: bold;"> </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000; font-weight: bold;"><br class="kix-line-break"/></span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> ipv6 enable&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000; font-weight: bold;"><br class="kix-line-break"/></span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> tunnel source</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000; font-weight: bold;"> </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Loopback0</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000; font-weight: bold;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000; font-weight: bold;"><br class="kix-line-break"/></span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> tunnel destination</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000; font-weight: bold;"> </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">2.2.2.2</span></p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R2:</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">interface Tunnel100</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> tunnel mode gre</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> ip address 102.1.1.2 255.255.255.0 </span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> ipv6 enable&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> tunnel source Loopback0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></p><p><span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> tunnel destination 1.1.1.1</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #e34adc; font-weight: bold;"><br class="kix-line-break"/></span></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h3>Step 1:</h3><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">The first step is to create the logical interface for the tunnel. In Cisco IOS, tunnels are formed using tunnel interfaces. Tunnel interfaces are virtual interfaces that act as if they are directly connected interfaces and are created using the </span><span dir="ltr" style="font-family: helvetica;"><strong>interface tunnel [tunnel interface number]</strong> global configuration command. </span></p><p><span dir="ltr" style="font-family: helvetica;"></span><br/><span style="font-family: helvetica;">The tunnel interface number can be any locally significant number and is arbitrary. However, it is good practice to choose a tunnel interface number starting at 10 or above. This is because certain features, such as IP multicast, also require tunnels and may select lower numbers by default.</span><span><span><span dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: Arial; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: Arial; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: Arial; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: Arial; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h3>Step 2:</h3><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">Once the tunnel interface is created, the carrier protocol needs to be defined. GRE over IPv4 is the default carrier protocol for tunnel interfaces on Cisco IOS and is automatically enabled whenever you create a tunnel interface. The</span><span style="font-family: helvetica;"><span dir="ltr"> <strong>tunnel mode gre ip</strong> can be used&nbsp; to manually change the transport protocol to IPv4, and the <strong>tunnel mode gre ipv6</strong></span><span dir="ltr"> command can be used to change the transport protocol to IPv6. </span></span><span><span><br/></span></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h3>Step 3:</h3><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">Once the carrier protocol has been defined (GRE by default), the passenger protocol must be identified. This is accomplished by configuring the appropriate addresses under the tunnel interface. For the example topology, IPv4 and IPv6 is required to be carried inside the IPv4 tunnel. </span></p><p><span dir="ltr" style="font-family: helvetica;"><br/></span></p><p><span dir="ltr" style="font-family: helvetica;">Simply assigning an IPv4 address using the <strong>ip address x.x.x.x x.x.x.x</strong> command designates the passenger protocol as IPv4. Similarly, assigning an IPv6 address to the tunnel interface designates an IPv6 packet as the passenger protocol. The addresses assigned to the tunnel interface directly are referred to as overlay, tunnel, or VPN addresses.</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">Configuring the tunnel address not only identifies the passenger protocol for the tunnel but it also enables that protocol stack to run over the tunnel. This allows the tunnel interface to source control plane traffic using the tunnel address. This is how routing information is exchanged between tunnel endpoints. The next-hop for all routes through the tunnel is the remote tunnel&#8217;s IP address.</span><span><span><br/></span></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h3>Step 4:</h3><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-size: 10pt; font-family: helvetica;">In the final step, the source/destination address of the transport header needs to be identified. For the tunnel to work, the tunnel endpoints must have reachability to these addresses. The term &#8220;tunnel endpoint&rdquo; identifies the two devices that create the beginning and end of the tunnel. For example, in the topology, R1 and R2 are the tunnel endpoints.</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;"><span dir="ltr">The source address of the tunnel is configured using the </span><span dir="ltr"><strong>tunnel source</strong> command. The source can be any interface on the local router or any valid IP address. The tunnel destination is the address of the remote tunnel endpoint and is set using the<strong> tunnel destination</strong> command. In order for the tunnel to be operational, the tunnel destination must be reachable by the local router. </span></span></p><p><span style="font-family: helvetica;"><span dir="ltr"><br/></span></span></p><p>The source/destination is mirrored between the two tunnel endpoints. The source of one endpoint is the destination of the other. <span style="font-family: helvetica;">The IP addresses configured as the source/destination should also match the configured <strong>tunnel mode</strong>. For instance, if the <strong>tunnel mode</strong> is <strong>gre ipv6</strong> the source/destination addresses should be IPv6 addresses.</span><span style="font-family: helvetica;"><br/></span></p><p><br/><span dir="ltr" style="font-family: helvetica;">The <strong>tunnel source</strong> can be a loopback or a physical interface. Depending on the network topology, using loopbacks can provide the most high-availability, because loopback addresses are not tied to a physical interface. If a physical interface goes down, the routing protocol of the underlying network can route around the failure.</span></p><p><br/><span style="font-family: helvetica;">Optionally, a tunnel key can be configured under the tunnel interface. The tunnel key helps the receiving router associate the received tunnel packet with the proper tunnel interface. This is used in case multiple tunnel interfaces are associated with the same source and destination. In the example topology, since only a single tunnel interface has been created between R1 and R2, the configuration of the tunnel key is not required.</span></p><p><br/><span style="font-family: 'times new roman', times;"><span style="font-family: helvetica;">At the end of the above configurations, we should have an operational logical point-to-point link between R1 and R2 using the GRE tunnel interface.</span><span style="color: #000000; font-size: 10pt;"> </span></span></p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R1#show ip route</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">[--omitted--]</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"><br class="kix-line-break"/></span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 102.0.0.0/8 is variably subnetted, 2 subnets, 2 masks</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">C&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">102.1.1.0/24 is directly connected, Tunnel100</span></p><p dir="ltr"><span style="color: #000000; font-family: 'Courier New'; font-size: 9pt;"><br/></span></p><p dir="ltr"><span style="color: #000000; font-family: 'Courier New'; font-size: 9pt;">R1#show int tunnel 100</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Tunnel100 is up, line protocol is up</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; [-- omitted --]</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #cc0000;">&nbsp; <span style="color: #ff0000;">Tunnel source 1.1.1.1, destination 2.2.2.2</span></span></p><p><span><span style="font-size: 9pt; font-family: 'Courier New'; color: #ff0000;">&nbsp; </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">Tunnel protocol/transport GRE/IP</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> </span></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">Pings between the tunnel interfaces on R1 and R2 succeed, verifying communication between the two endpoints.</span></p><p><span style="color: #000000; font-family: 'Courier New'; font-size: 9pt;"><br/></span></p><p><span style="color: #000000; font-family: 'Courier New'; font-size: 9pt;">R1#ping 102.1.1.2 source 102.1.1.1</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Type escape sequence to abort.</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Sending 5, 100-byte ICMP Echos to 102.1.1.2, timeout is 2 seconds:</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Packet sent with a source address of 102.1.1.1</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">!!!!!</span></p><p><span><span><span style="color: #ff0000; font-size: 10pt; font-family: Arial;"><a href="https://lh3.googleusercontent.com/tT36gjCzeO0TV0W3EUMIjOklO_8xG9ATYFHeHwqpC6wNJHYYdYcA_aicftZEQxoZHAMtg2bj3TUocvihP3Y8iYoVI9VJIzTEb0pdYShPuan_a21odOARsKP4pQSPjZ9rgF8vTU37"><img alt="Screen Shot 2017-03-01 at 6.06.01 PM.png" class="jive-image" height="304" src="https://lh3.googleusercontent.com/tT36gjCzeO0TV0W3EUMIjOklO_8xG9ATYFHeHwqpC6wNJHYYdYcA_aicftZEQxoZHAMtg2bj3TUocvihP3Y8iYoVI9VJIzTEb0pdYShPuan_a21odOARsKP4pQSPjZ9rgF8vTU37" style="border-style: none;" width="624"/></a></span><br/></span></span></p><p><span style="color: #000000; font-size: 10pt; font-family: Arial;"><br/></span></p><p><span style="font-family: helvetica;">Notice the outer IP header (</span><span dir="ltr" style="font-family: helvetica;"><strong>transport protocol</strong>) with source/destination 1.1.1.1 and 2.2.2.2, followed by the GRE header (<strong>carrier protocol</strong>), and then the original IP packet (<strong>passenger protocol</strong></span><span style="font-family: helvetica;">) with source/destination 102.1.1.1 and 102.1.1.2, followed by the payload, which in this case is the ping.</span><span><span><br/></span></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>Routing Over GRE Tunnels</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>In order to provide reachability through the tunnel for the networks behind each tunnel endpoint, an overlay routing protocol must be enabled to advertise the prefixes through the tunnel. In the example, OSPF is used as the overlay routing protocol. The commands <strong>ip ospf 1 area 0</strong> and <strong>ipv6 ospf 1 area 0</strong> are issued on the tunnel interface. This causes R1 and R2 to form an IPv4/IPv6 OSPF adjacency over the tunnel with each other and exchange routes through the tunnel.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R1:</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"><br class="kix-line-break"/></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">interface Tunnel100</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">ip address 102.1.1.1 255.255.255.0</span></p><p dir="ltr"><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">ip ospf 1 area 0</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">ipv6 enable</span></p><p dir="ltr"><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">ipv6 ospf 1 area 0</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">tunnel source Loopback0</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">tunnel destination 2.2.2.2</span></p><p><br/><span style="font-family: 'times new roman', times;"><span style="font-family: helvetica;">Since the tunnel interfaces are transit links, traffic will never be destined for the tunnel interface itself, negating the need for an IPv6 global unicast address. IPv6 IGPs use the link-local address when forming adjacencies. A simple trick in this scenario is to enable IPv6 on the tunnel interface with the </span><span style="font-family: helvetica;"><span dir="ltr"><strong>ipv6 enable</strong></span><span dir="ltr"> command. This causes the router to generate only a link-local address and use it to form the IGP adjacencies.</span><span dir="ltr"> </span></span></span></p><p><br/><span style="font-family: helvetica;">The end result is the routes learned from R2 by R1 are installed in R1&#8217;s routing table with the tunnel interface as the exit interface:</span><span style="color: #000000; font-size: 10pt; font-family: Arial;"> </span></p><p><span><span><br/></span></span></p><p dir="ltr"><span style="color: #000000; font-family: 'Courier New'; font-size: 9pt;">R1#sh ip route OSPF</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">[--omitted--]</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Gateway of last resort is not set</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">192.168.20.0/32 is subnetted, 1 subnets</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">O&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">192.168.20.1 [110/1001] via 102.1.1.2, 00:00:32, </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">Tunnel100</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #cc0000;"><br class="kix-line-break"/><span style="color: #0000ff; font-size: 9pt;">!Notice the Next-Hop is the IPv4 address assigned to R2&#8217;s tunnel interface</span></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"><br class="kix-line-break"/></span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R1#show ipv6 route ospf</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">[--omitted--]</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"><br class="kix-line-break"/></span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">O&nbsp; 2001:20::/64 [110/1001]</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp;&nbsp;&nbsp; via </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">FE80::BBBB, Tunnel100 </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #cc0000;"><br class="kix-line-break"/></span></p><p><span><span style="color: #0000ff; font-size: 9pt; font-family: 'Courier New';">!Notice the Next-Hop is the IPv6 Link-Local address of R2&#8217;s tunnel interface</span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"><br class="kix-line-break"/></span></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">Any route in the routing table that uses the tunnel interface as the exit interface will be tunneled across to R2 using the GRE tunnel. </span><span style="font-size: 10pt; font-family: helvetica;">A ping is performed from PC1&#8217;s IPv4/IPv6 addresses to PC2&#8217;s IPv4/IPv6 addresses to verify reachability.</span></p><p><span style="color: #000000; font-size: 9pt; font-family: 'Courier New';"><br class="kix-line-break"/></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">PC1&gt; ping 2001:20::2</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">2001:20::2 icmp6_seq=1 ttl=60 time=217.214 ms</span></p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">PC1&gt; ping 192.168.20.2</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">84 bytes from 192.168.20.2 icmp_seq=1 ttl=62 time=59.990 ms</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">The captures below confirm the tunnel is fully operational. The IPv4 and IPv6 echo requests are being sent encapsulated in a GRE header which is then encapsulated with a transport header as it is sent across the tunnel.</span></p><p><span><span><span style="color: #000000; font-size: 10pt; margin-bottom: 6pt; font-family: Arial; margin-top: 18pt;"><a href="https://lh4.googleusercontent.com/YD7tNnaBwCI4JLLKF7CWrp8_Ko6HRAmMaxj98P3nwmgHdxQeE0wQhcGyrSopYpNTDt0rnRZDfRLKfQRSt1Wpx8YwRb9tEcNL418mOvye7FaOFQqFtkBB4Ug5TaJzTynnXC9NDOxO"><img alt="Screen Shot 2017-03-01 at 6.36.53 PM.png" class="jive-image" height="77" src="https://lh4.googleusercontent.com/YD7tNnaBwCI4JLLKF7CWrp8_Ko6HRAmMaxj98P3nwmgHdxQeE0wQhcGyrSopYpNTDt0rnRZDfRLKfQRSt1Wpx8YwRb9tEcNL418mOvye7FaOFQqFtkBB4Ug5TaJzTynnXC9NDOxO" style="border-style: none;" width="624"/></a></span><span style="color: #000000; font-size: 10pt; margin-bottom: 6pt; font-family: Arial; margin-top: 18pt;"><a href="https://lh6.googleusercontent.com/qkZfE3jPw2s5WP73b_VLqo1qyT2LywRuCoZDSU92D7MK-vDoTsCNADYbriWJi3d7n-RpSAWBb2bLPgjHZ9QxNtaN8DU84SzHr1FUZb4LhRNGXjELONa0gMX4kmwSXpenh7ke3fx-"><img alt="Screen Shot 2017-03-01 at 6.46.41 PM.png" class="jive-image" height="77" src="https://lh6.googleusercontent.com/qkZfE3jPw2s5WP73b_VLqo1qyT2LywRuCoZDSU92D7MK-vDoTsCNADYbriWJi3d7n-RpSAWBb2bLPgjHZ9QxNtaN8DU84SzHr1FUZb4LhRNGXjELONa0gMX4kmwSXpenh7ke3fx-" style="border-style: none;" width="624"/></a></span></span></span></p><h2>GRE Tunnel Interface State and Keepalives</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">One of the shortcomings of GRE tunnels is the inability of the remote tunnel endpoints to signal to each other their line protocol status. </span><span style="font-family: helvetica;"><span dir="ltr"><br/><br/></span>In order to understand this better let&#8217;s consider the topology again. R1 uses Loopback0 (1.1.1.1/32) as the tunnel source and has a default static route for the tunnel destination 2.2.2.2/32. In addition, there is also a static route on R1 to the network 192.168.20.0/24 behind R2.<span dir="ltr"><br/></span></span><span style="color: #000000; font-size: 10pt; font-family: Arial;"><br class="kix-line-break"/></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R1#show running-config | in ip route</span></p><p dir="ltr"><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">ip route 0.0.0.0 0.0.0.0 12.1.1.2</span></p><p dir="ltr"><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">ip route 192.168.20.0 255.255.255.0 Tunnel100</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"><br class="kix-line-break"/></span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R1#show ip route</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"><br class="kix-line-break"/></span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">[--omitted--]</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">S*&nbsp;&nbsp;&nbsp; 0.0.0.0/0 [1/0] via 12.1.1.2</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">S&nbsp;&nbsp;&nbsp; 192.168.20.0/24 is directly connected, Tunnel100</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"><br class="kix-line-break"/></span><span style="font-size: 9pt; font-family: Arial; color: #000000;"><br class="kix-line-break"/></span><span style="font-family: helvetica;">Next, we disable the tunnel interface 100 on R2 by shutting it down.</span><span style="font-size: 9pt; font-family: Arial; color: #000000;"><br class="kix-line-break"/><br class="kix-line-break"/></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R2(config)#int tunnel 0</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R2(config-if)#</span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">shutdown</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"><br class="kix-line-break"/></span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">*Feb 26 13:17:55.903: %LINK-5-CHANGED: Interface Tunnel0, <span style="color: #ff0000;">changed state to administratively down</span></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"><br class="kix-line-break"/></span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R1#show ip </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">interface tunnel 100</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"><span style="color: #ff0000;">Tunnel100</span> is up, </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">line protocol is up</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; Internet address is 102.1.1.1/24</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-size: 10pt; font-family: helvetica;">We can see above that bringing down the Tunnel interface on R2 has no impact on the line protocol status of the connected GRE tunnel interface on R1. This is the stateless nature of GRE tunnels by default. The tunnel endpoints are not aware of the state of the remote endpoint or the network conditions between them.</span></p><p><br/><span style="font-family: helvetica;">As a result of this limitation, the routing table still shows routes that use the tunnel interface as the exit. Both of the static routes, to the tunnel destination and to the network 192.168.20.0/24, persist in the routing table with the exit interface as the tunnel, even though the remote tunnel endpoint has been brought down. Traffic routed through this interface will never reach their destination.</span><span style="color: #000000; font-size: 10pt; font-family: Arial;"><br class="kix-line-break"/><br class="kix-line-break"/></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R1#show ip route</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">[--omitted--]</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"><br class="kix-line-break"/></span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">S*&nbsp;&nbsp;&nbsp; 0.0.0.0/0 [1/0] via 12.1.1.2</span></p><p><span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">S&nbsp;&nbsp;&nbsp; 192.168.20.0/24 is directly connected, </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">Tunnel100</span></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">So in order for point-to-point GRE tunnel interface status to be in up/up state, the following must be true on the local router:</span><br/><br/></p><ol><li><span dir="ltr" style="font-family: helvetica;">The<strong> tunnel source</strong> must&nbsp; be a valid IP address or up/up interface with a valid IP address assigned.</span></li><li><span dir="ltr" style="font-family: helvetica;">The <strong>tunnel destination</strong> must be routable, not necessarily reachable.</span></li></ol><p><br/><span style="font-family: helvetica;"><span dir="ltr">For the <strong>tunnel source</strong></span><span dir="ltr"> to be considered valid, if the source is an interface, this interface must be in the up/up state and have a valid IP address assigned. This interface can be a physical interface or a loopback interface. If the interface is not being used as the source, then there must be a valid IP address configured as the tunnel source. This point requires more emphasis and explanation leading to the point that a tunnel source can be configured in two ways:</span></span></p><p><span style="font-family: helvetica;"><br/></span></p><ol><li><span style="font-family: helvetica;"><span dir="ltr">Specify the interface as the keyword in the</span><span dir="ltr"><strong> tunnel source</strong> command (<strong>tunnel source loopback0</strong>)</span></span></li><li><span style="font-family: helvetica;"><span dir="ltr">Specify the IP address in the <strong>tunnel source</strong> command (<strong>tunnel source 1.1.1.1</strong></span><span dir="ltr">)</span></span></li></ol><p><span style="font-family: helvetica;"><br/><span dir="ltr">When using the</span><span dir="ltr"> <strong>interface</strong> keyword as the tunnel source, the tunnel interface status is tied to the status of that interface. For eg, in the below, the tunnel source was configured using the loopback0 keyword (<strong>tunnel source Loopback0</strong></span></span><span style="font-family: helvetica;">). When the loopback interface is shut down the tunnel interface goes down as well. This is confirmed in the output below where the tunnel line protocol status has changed to up/down.</span></p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R1#show running-config interface tunnel 100</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">interface Tunnel100</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; tunnel source </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">Loopback0</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"><br class="kix-line-break"/></span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R1#show running-config interface loopback 0</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">interface Loopback0</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> ip address 1.1.1.1 255.255.255.255</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">shutdown</span></p><p dir="ltr"><span style="color: #0000ff; font-size: 12px; font-family: 'Courier New';">!Loopback has been shutdown</span></p><p><span style="color: #000000; font-family: 'Courier New'; font-size: 9pt;"><br/>R1#show ip int brief</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Interface&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">IP-Address&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">OK? Method Status&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Protocol</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Loopback0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">1.1.1.1&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">YES manual<span style="color: #ff0000;"> administratively down down</span></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Tunnel100&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">102.1.1.1&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">YES manual </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">up&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #ff0000;">&nbsp; </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">down</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #cc0000;"><br class="kix-line-break"/></span><span style="color: #0000ff; font-size: 9pt; font-family: 'Courier New';">!Notice line Protocol status is down</span></p><p><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000; font-style: italic;"><br/></span></p><p><span style="font-size: 10pt; font-family: helvetica;">However, if we use an IP address as the tunnel source (</span><span dir="ltr" style="font-size: 10pt; font-family: helvetica;">tunnel source 1.1.1.1</span><span style="font-size: 10pt; font-family: helvetica;">), the tunnel interface will stay up regardless of the loopback interface&#8217;s administrative status, as shown below:</span></p><p><span style="font-size: 10pt; font-family: helvetica;"><br/></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R1#show running-config interface tunnel 100</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">interface Tunnel100</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; tunnel source </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">1.1.1.1</span></p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R1#show running-config interface loopback 0</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">interface Loopback0</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> ip address 1.1.1.1 255.255.255.255</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">shutdown</span></p><p><span style="color: #0000ff; font-size: 9pt; font-family: 'Courier New';">!Loopback has been shutdown</span></p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R1#show ip int brief</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Interface&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">IP-Address&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">OK? Method Status&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Protocol</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Loopback0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">1.1.1.1&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">YES manual <span style="color: #ff0000;">administratively down down</span></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Tunnel100&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">102.1.1.1&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">YES manual </span><span style="font-family: 'courier new', courier;"><span style="color: #ff0000; font-size: 9pt;">up&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; color: #ff0000;">&nbsp; </span><span style="color: #ff0000; font-size: 9pt;">up</span></span></p><p><span><span style="color: #0000ff; font-size: 9pt; font-family: 'Courier New';">!Line protocol status still remains up</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000; font-style: italic;"><br class="kix-line-break"/></span></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">In both examples above, there is no reachability between the tunnel endpoints. When the Loopback0 interface on R1 is shutdown, R1 loses its connected route to 1.1.1.1/32 in its RIB. When R2 tunnels a packet to R1, the destination of the transport header will be 1.1.1.1/32. R1 receives this packet and the routing fails because R1 does not have a route for 1.1.1.1/32 in its RIB. This can be verified using </span><span dir="ltr" style="font-family: helvetica;"><strong>debug ip packet</strong></span><span style="font-family: helvetica;"> and pinging between the tunnel interfaces of R1 and R2:</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"><br/>R1#</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">*Feb 26 17:35:14.791: IP: s=2.2.2.2 (FastEthernet2/0), d=1.1.1.1, len 100, input feature, MCI Check(101), rtype 0, </span><span style="color: #000000; font-size: 9pt; font-family: 'Courier New';">forus FALSE</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">, sendself FALSE, mtu 0, fwdchk FALSE</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">*Feb 26 17:35:14.791: IP: s=2.2.2.2 (FastEthernet2/0), </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">d=1.1.1.1</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">, len 100, </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">unroutable</span></p><p><span style="font-size: 9pt; font-family: 'Courier New'; color: #cc0000;"><br/></span></p><p><span style="font-size: 10pt; font-family: helvetica;">Another factor that is tied to the Tunnel interface status is a valid tunnel destination address. The </span><span style="font-family: helvetica;"><span style="font-size: 10pt;"><strong>tunnel destination</strong></span><span style="font-size: 10pt;"> must be routable by the local router. In other words, the local router must have a route to the destination in its routing table. This can be accomplished with a static route as we saw above. However, this address doesn&#8217;t have to be reachable by the local router, meaning the local router will not verify end-to-end reachability of the destination address.</span></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">As long as a valid tunnel source address or interface and a valid tunnel destination address (routable) is configured, the tunnel interface stays up on the local router even if the other side of the tunnel is not operational.</span></p><p><br/><span style="font-family: helvetica;">As we saw, this raises a problem. If a problem in the underlying network prevents successful delivery of the tunnel packets, the traffic flowing through the tunnel will be black holed. This also keeps the static routes intact in the routing table, preventing an alternate route from being installed.</span></p><p><span style="font-family: helvetica;"><br/><span dir="ltr">The GRE keepalive function can be used to verify the end-to-end reachability and bring down the line protocol status of the tunnel. The keepalive function is disabled on the tunnel interface by default and can be enabled using the </span><span dir="ltr"><strong>keepalive [seconds [retries]]</strong> </span></span><span style="font-family: helvetica;"> keyword.</span><span style="color: #000000; font-size: 10pt; font-family: Arial;"><br class="kix-line-break"/><br class="kix-line-break"/></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">interface Tunnel100</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> ip address 102.1.1.1 255.255.255.0</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> ip ospf 1 area 0</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> ipv6 enable</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> ipv6 ospf 1 area 0</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #cc0000; font-weight: bold;"> </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">keepalive 10 3</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> tunnel source <span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Loopback0</span></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"> tunnel destination 2.2.2.2</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"><br class="kix-line-break"/></span><span style="color: #0000ff; font-size: 9pt; font-family: 'Courier New';">!The above configures the router to send keepalives every 10 seconds. If a keepalive is not received after 3 tries the router will bring down the line protocol status of the Tunnel interface</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">When the keepalives are enabled on R1&#8217;s tunnel interface 100, the following happens:</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ol><li><span dir="ltr" style="font-family: helvetica;">R1 constructs a GRE header with no payload and protocol type 0. The protocol type 0 indicates that it is a keepalive packet. This becomes the <strong>passenger protocol.</strong></span></li><li><span style="font-family: helvetica;">R1 adds an outer IP header to the above GRE packet with the source set to the tunnel destination, 2.2.2.2/32, and the destination of the packet set to the local router&#8217;s tunnel source, 1.1.1.1/32.</span></li><li><span dir="ltr" style="font-family: helvetica;">The above outer IP header is then encapsulated with another GRE header with the protocol type set to 0x0800 (IP). This becomes the <strong>carrier protocol.</strong></span></li><li><span dir="ltr" style="font-family: helvetica;">Next, a new outer IP header is added to the GRE header in order to transport it over the underlying infrastructure. This becomes the <strong>transport protocol</strong> that carries the keepalive packet as the payload.</span></li><li><span style="font-family: helvetica;">R2 receives the above packet, removes the first GRE header to reveal the IP packet with the source set to itself and forwards the packet back to the destination 1.1.1.1/32.</span></li><li><span style="font-family: helvetica;">R1 receives the above GRE packet with the protocol type of 0 which signifies that this is a keepalive packet.</span></li></ol><p><span style="font-family: helvetica;"><br/>So the innermost GRE packet was effectively bounced back to R1 by R2, allowing the GRE keepalive mechanism to work without any configuration on R2.</span></p><p><br/><span style="font-family: helvetica;">The capture below shows the GRE keepalive packet generated by R1 and destined to R2. In essence, R1 has tricked R2 into echoing a packet back to it. Using this method, R1 can verify that the remote tunnel endpoint R2 is up. If this packet isn&#8217;t received within a specific time period, R1 brings down the tunnel interface. With the use of keepalives, the tunnel status is based on the actual reachability to the destination.</span></p><p><span><span><span style="color: #000000; font-size: 10pt; font-family: Arial;"><a href="https://lh6.googleusercontent.com/oYodxjyHMPH0cckvgTVNTu28Z8mLjUU3P-rn_AsnRSAq9BpW_RfUlZ1FQGeC9xaCtZBezrkgISOBv_FcD3UvK_vDSXuw3kjBBdWz51x8HqtmrgKE1M8rkzcDumPfj5-cjfcGTP5j"><img alt="Screen Shot 2017-02-27 at 3.36.25 PM.png" class="jive-image" height="107" src="https://lh6.googleusercontent.com/oYodxjyHMPH0cckvgTVNTu28Z8mLjUU3P-rn_AsnRSAq9BpW_RfUlZ1FQGeC9xaCtZBezrkgISOBv_FcD3UvK_vDSXuw3kjBBdWz51x8HqtmrgKE1M8rkzcDumPfj5-cjfcGTP5j" style="border-style: none;" width="624"/></a></span><br/></span></span><span style="font-family: helvetica;">The GRE keepalives should be enabled at both tunnel endpoints in order to avoid routing black holes.</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>Recursive Routing</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">The last section of this blog is about another case that can cause the tunnel to be in an up/down state. This could happen when the tunnel destination is routed and learned through the tunnel itself, resulting in recursive routing.</span></p><p><br/><span style="font-family: helvetica;">A possible error message that indicates a recursive routing issue while working with GRE Tunnels is the following:</span></p><p><span style="color: #000000; font-size: 9pt; font-family: helvetica;"><br/></span></p><p><span style="color: #000000; font-size: 9pt; font-family: 'Courier New';">*Feb 26 03:26:57.689: %ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of Tunnel100 - looped chain attempting to stack</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">*Feb 26 03:27:01.648: %TUN-5-RECURDOWN: </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">Tunnel100 temporarily disabled due to recursive routing</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">The error above indicates that the router experienced a problem when trying to forward traffic through the tunnel interface because of an internal logical loop that caused it to temporarily disable the tunnel. This loop is caused by recursive routing, where the tunnel destination address is matched by a route in the RIB with the tunnel interface itself as the exit interface.</span></p><p><br/><span style="font-family: helvetica;">A few common scenarios that can lead to recursive routing are:</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ul><li><span style="font-family: helvetica;">The route to reach the tunnel destination through the tunnel is a more specific route than through the underlying path</span></li><li><span style="font-family: helvetica;">The tunnel interface provides a better metric to reach the tunnel destination. This could happen in case of using a single IGP as the underlay and the overlay, such as RIP. In this case, the hop count to reach the tunnel destination is 1 (because the tunnel appears as a directly connected interface), which could be lower than the hop count through the underlying infrastructure.</span></li></ul><p><br/><span dir="ltr" style="font-family: helvetica;">Expounding on scenario 1, consider In the example topology 1.1.1.1/32 and 2.2.2.2/32 are the endpoints for the GRE tunnel. </span><span style="font-family: helvetica;">A static default route on R1 provides reachability to the tunnel destination 2.2.2.2/32, exiting the physical interface:</span></p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R1#show ip route static</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">[--omitted--]</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Gateway of last resort is 12.1.1.2 to network 0.0.0.0</span></p><p><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">S*&nbsp;&nbsp;&nbsp; 0.0.0.0/0 [1/0] via 12.1.1.2</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;"><br/></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R1#show ip cef </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">2.2.2.2</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">2.2.2.2/32</span></p><p><span><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp; nexthop </span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">12.1.1.2 FastEthernet2/0</span></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">Next, on enabling OSPF on the loopback interface on R2, R1 learns the tunnel destination 2.2.2.2/32 through its tunnel interface.</span><span style="color: #000000; font-size: 10pt; font-family: Arial;"> </span></p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R2(config)#int lo0</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R2(config-if)#</span><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">ip ospf 1 area 0</span></p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">R1#show ip route</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">[--omitted--]</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">Gateway of last resort is 12.1.1.2 to network 0.0.0.0</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">S*&nbsp;&nbsp;&nbsp; 0.0.0.0/0 [1/0] via 12.1.1.2</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2.0.0.0/32 is subnetted, 1 subnets</span></p><p dir="ltr"><span style="color: #ff0000; font-size: 9pt; font-family: 'Courier New';">O&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2.2.2.2 [110/1001] via 102.1.1.2, 00:00:02, Tunnel100</span></p><p dir="ltr"><span style="color: #0000ff; font-size: 9pt; font-family: 'Courier New';">!Static default routes are least specific.</span></p><p dir="ltr"><span style="color: #0000ff; font-size: 9pt; font-family: 'Courier New';">!Tunnel destination is reachable via the tunnel itself due to a more specific route learned via OSPF</span></p><p><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000; font-style: italic;"><br/></span></p><p><span style="font-family: helvetica;">The route to the tunnel destination 2.2.2.2/32 on R1 through the tunnel is a more specific route than the static default route. In effect, R1 installs the route through the tunnel destination. This leads R1 to believe that to reach the tunnel endpoint it should use the tunnel interface itself.</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-family: helvetica;">This causes a loop in the logic on R1.</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ol><li><span style="font-family: helvetica;">When R1 encapsulates a packet going through the GRE tunnel, it adds destination address 2.2.2.2/32 to the transport header.</span></li><li><span style="font-family: helvetica;">R1 routes the new packet using the RIB.</span></li><li><span style="font-family: helvetica;">The route in the RIB to 2.2.2.2/32 points to tunnel interface 100.</span></li><li><span style="font-family: helvetica;">R1 forwards the packet to the tunnel interface and tries to encapsulate the packet again. This causes it to route the packet back to the tunnel interface.</span></li><li><span style="font-family: helvetica;">R1 detects this problem and breaks the loop by shutting down the tunnel interface.</span></li><li><span style="font-family: helvetica;">The routing adjacency is torn down with R2 and clears the error state.</span></li><li><span style="font-family: helvetica;">A few seconds later the tunnel will come back up due to the static default route</span></li><li><span style="font-family: helvetica;">The routing adjacency between R1 and R2 is re-established, and R2 once again advertises its endpoint through the tunnel.</span></li><li><span style="font-family: helvetica;">R1 re-learns 2.2.2.2/32 through its tunnel interface, taking it back to step 1.</span></li></ol><p><br/><span dir="ltr" style="font-family: helvetica;">The process will continue over and over, hence the term <strong>recursive</strong>.</span></p><p><br/><span style="font-family: helvetica;">In order to prevent recursive routing with tunnels, the key point we need to take away is to make sure that the route to the tunnel destination in the RIB does not point to the tunnel interface itself as the exit interface. For this we need to make sure that the tunnel destination is not learned via the tunnel. Depending on the implementation, a few possible solutions include:</span></p><ul><li><span style="font-family: helvetica;">Separate IGPs can be used for the underlay and the overlay while ensuring the tunnel destination is never advertised in the overlay protocol.</span></li><li><span style="font-family: helvetica;">In case a single IGP is being utilized:</span><ul><li><span style="font-family: helvetica;">The metric of the route learned through the tunnel should be higher than the path through the underlying network. For routing protocols like OSPF and EIGRP, this is taken care of automatically because the tunnel interface bandwidth and delay are set artificially high, resulting in routes learned through the tunnel having a higher metric by default.</span></li><li><span style="font-family: helvetica;">Route filtering could be used to filter the tunnel endpoints from being learned over the tunnel. This is useful for a routing protocol like RIP that uses hop count as a metric.</span></li></ul></li></ul><p><span style="font-family: helvetica;"><br/></span></p><p dir="ltr"><span style="font-family: helvetica;">For the example topology, the simplest way to prevent recursive routing is by using a specific static route to reach the tunnel destination. In this way, due to the order of preference, the static route will always be preferred over the dynamically learned route to the tunnel destination.</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>Conclusion</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="font-family: helvetica;">This blog has emphasized the purpose and common use cases for point-to-point (P2P) GRE tunnels using the most basic configuration steps. The last two sections detailed GRE tunnel interface state and the recursive routing issues encountered while implementing GRE tunnels. The configurations and solutions were engineered to be as simple as possible for demonstration purposes and may not follow exact best-practice standards.</span></p></div><!-- [DocumentBodyEnd:e54d356a-f1e7-4bfe-b8d8-ae628a2c3a0e] -->grekeepalivestunneltunnel interface staterecursive routingvpnTue, 14 Mar 2017 17:06:10 GMTbounce@learningnetwork.cisco.comhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2017/03/14/anatomy-of-gre-tunnels2017-03-14T17:06:10Z5 months 4 days ago370https://learningnetwork.cisco.com/blogs/vip-perspectives/comment/anatomy-of-gre-tunnelshttps://learningnetwork.cisco.com/blogs/vip-perspectives/feeds/comments?blogPost=3971DMVPN: The Phases In-Depthhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2017/02/15/dmvpn-the-phases-in-depth
<!-- [DocumentBodyStart:07e4a797-5f69-4d19-825f-7d24d737313e] --><div class="jive-rendered-content"><h1 dir="ltr" style="margin-top: 10pt; margin-bottom: 6pt;"><a><img alt="DMVPN: The Phases In-Depth" src="/resources/statics/1303575/DMVPN_InDepth_blog_v2.jpg" style="float: left; padding: 12px 20px 8px 0px;" width="267"/></a>Introduction</h1><p dir="ltr">In this blog, I aim to go a little deeper into how the different DMVPN phases work and how to properly configure the routing protocol to operate in each phase. The routing protocol of choice for this blog is EIGRP classic configuration.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr">At the end of this blog, the reader should have a solid understanding and justification for each configuration command used in the different phases and their impact on the overall DMVPN routing design. The focus is purely on the basic&nbsp; configurations without IPsec for simplicity.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2 dir="ltr">Nature of DMVPN clouds</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr">DMVPN clouds create nonbroadcast multiaccess (NBMA) networks. Given the nature of NBMA networks, all traffic (multicast, broadcast, and unicast) must be sent across the network as unicast packets. This simply means multicast traffic destined for an IGP neighbor (hello messages) will always be encapsulated in a unicast packet for delivery. For this reason, it is crucial that the hub router always knows the identities of all the spokes for which it is the Next-Hop Server (NHS). For this purpose, the <strong>ip nhrp map multicast dynamic</strong> command on the hub is used to dynamically create mappings in the NHRP multicast table for each spoke that registers with it.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr">On the DMVPN spokes, which are next-hop clients (NHCs), a static multicast mapping is created for each hub. This can be achieved in one of two ways:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ul><li><span dir="ltr"><strong>ip nhrp map multicast [nbma address of hub]</strong></span></li><li><span dir="ltr"><strong>ip nhrp nhs [tunnel address of hub] nbma [nbma address of hub] multicast</strong></span></li></ul><p><br/><span dir="ltr">With this set up, routing adjacencies are only formed between the hub and the spokes. Spokes do not form routing adjacencies with each other. All that needs to be done is to match the tunnel interface with a network command on the routers. The IGP will activate and run just like over a physical interface. </span></p><p><span dir="ltr"><br/></span></p><h2 dir="ltr"></h2><h2 dir="ltr">Phase 1</h2><p><br/><span dir="ltr">DMVPN phase 1 only provides hub-and-spoke tunnel deployment. This means GRE tunnels are only built between the hub and the spokes. Traffic destined to networks behind spokes is forced to first traverse the hub.</span></p><p><span dir="ltr"></span><br/><span dir="ltr">The topology below shows two spokes connected to the hub router. The hub is configured with an mGRE tunnel and the spokes with a P2P GRE tunnel. </span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3948-325903/Phase-1modified.jpg"><img alt="Phase-1modified.jpg" class="jive-image image-4" height="723" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3948-325903/Phase-1modified.jpg" style="height: 640px; width: 620px;" width="700"/></a><br/><br/><span dir="ltr">There are two critical configurations that make this a Phase 1 implementation:</span></p><ol><li><span dir="ltr">Configuring the spoke's tunnel interface as P2P GRE tunnel (In all phases, the hub is always configured with an mGRE tunnel)</span></li><li><span dir="ltr">The next hop on the spokes always point towards the hub</span></li></ol><p><br/><span dir="ltr">Configuring the spokes with a P2P GRE tunnel restricts it from building dynamic spoke-to-spoke tunnels. This way, each time Spoke-R2 needs to reach Spoke-R3, only a single tunnel towards Hub-R1 is built. The traffic sourced from the device 192.168.20.1 on Spoke-R2 destined for 192.168.30.1 behind Spoke-R3, always hits Hub-R1 first. The following happens on the Hub-R1:</span></p><ol><li><span dir="ltr">Hub-R1 receives the traffic from Spoke-R2. </span></li><li><span dir="ltr">Hub-R1 removes the GRE header, exposing the original IP packet. The original packet has the destination of Spoke-R3&#8217;s remote network.</span></li><li><span dir="ltr">Hub-R1 encapsulates the original IP packet with a new GRE header and forwards it to Spoke-R3. </span></li></ol><p><br/>The next hop plays a key role here. The next hop for 192.168.30.1 on Spoke-R2 shows Hub-R1&#8217;s tunnel IP as the next hop:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Spoke-R2#show ip route eigrp</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">--- Omitted ---</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Gateway of last resort is 20.1.1.2 to network 0.0.0.0</span></p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000; font-weight: bold;">D </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000; font-weight: bold;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000; font-weight: bold;">192.168.30.0/24 [90/28288000] via </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold; text-decoration: underline;">172.16.1.1</span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000; font-weight: bold;">, 00:02:40, Tunnel0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000; font-weight: bold;"><br/></span></p><p dir="ltr">This is important to understand because it prevents Spoke-R2 from ever attempting to build a direct tunnel towards the remote Spoke-R3. In simple words, Spoke-R2 will always use the Hub-R1 as its next hop to reach the remote Spoke-R3&#8217;s subnets.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr">Because all spoke-to-spoke traffic in DMVPN Phase 1 always traverses the hub, it is actually inefficient to even send the entire routing table from the hub to the spokes. This means we can summarize all of the routing information from the hub down to the spokes. This can be achieved in one of two ways:</p><p><span><span><br/></span></span></p><ol><li><span dir="ltr"><span style="font-size: 10pt;">Flood a default summary route to the spokes for all traffic. This is achieved in EIGRP using the </span><span style="font-size: 10pt; font-weight: bold;">ip summary-address eigrp [asn] 0.0.0.0 0.0.0.0</span><span style="font-size: 10pt;"> command under the tunnel interface.</span><span style="font-size: 10pt; font-weight: bold; text-decoration: underline;"> </span></span></li><li><span dir="ltr"><span style="font-size: 10pt;">Flood a summary route only for the remote spoke networks (192.168.20.0 and 192.168.30.0). This is achieved in EIGRP using the </span><span style="font-size: 10pt; font-weight: bold;">ip summary-address eigrp [asn] 192.168.0.0 255.255.224.0 </span><span style="font-size: 10pt;">command under the tunnel interface.</span></span></li></ol><p><span><span><br/></span></span></p><p dir="ltr">For this example, a default summary route will be sent to the spokes from Hub-R1. After making this change, the routing table on Spoke-R2 looks like this:</p><p><span style="font-size: 10pt; font-family: Arial; color: #000000;"><br/></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Spoke-R2#sh ip route eigrp</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">--- omitted ---</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Gateway of last resort is 172.16.1.1 to network 0.0.0.0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">D*</span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">0.0.0.0/0 [90/28160000] via </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold; text-decoration: underline;">172.16.1.1</span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">, 00:00:13, Tunnel0</span></p><p><span><span><br/></span></span></p><p dir="ltr">Notice the next hop for the default route is still Hub-R1&#8217;s Tunnel IP. The following is the configuration on Hub-R1&#8217;s tunnel interface:</p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Hub-R1#show run int tun0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">interface Tunnel0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip address 172.16.1.1 255.255.255.0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> no ip redirects</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip nhrp authentication cisco</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip nhrp map multicast dynamic</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip nhrp network-id 123</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">ip summary-address eigrp 123 0.0.0.0 0.0.0.0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> tunnel source Ethernet0/0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> tunnel mode gre multipoint</span></p><p><span><span><br/></span></span></p><p dir="ltr">A traceroute to 192.168.30.1 (Spoke-R3&#8217;s remote network) on Spoke-R2 yields the following result. Notice Hub-R1 (172.16.1.1) is always traversed:</p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Spoke-R2#traceroute 192.168.30.1</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Type escape sequence to abort.</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Tracing the route to 192.168.30.1</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">VRF info: (vrf in name/id, vrf out name/id)</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; 1 </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">172.16.1.1</span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> 1 msec 0 msec 1 msec</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; 2 172.16.1.3 0 msec 1 msec 0 msec</span></p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Spoke-R2#traceroute 192.168.30.1</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Type escape sequence to abort.</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Tracing the route to 192.168.30.1</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">VRF info: (vrf in name/id, vrf out name/id)</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; 1 </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">172.16.1.1</span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> 1 msec 5 msec 5 msec</span></p><p><span style="color: #000000; font-size: 10pt; font-family: 'Courier New';">&nbsp; 2 172.16.1.3 0 msec 1 msec 0 msec</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>Phase 2</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr">In Phase 1, traffic between the spokes would always hit the hub. This was a shortcoming of DMVPN as, in a larger deployment, the hub would always have to be burdened with encapsulate/decapsulate overhead for the spoke-to-spoke traffic. In addition to increased routing overhead on the hub, spoke-to-spoke traffic would take a suboptimal path by detouring to the hub and then reaching the remote spoke. Phase 2 improved on Phase 1 by allowing spokes to build a spoke-to-spoke tunnel on demand with these restrictions:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ul><li><span dir="ltr">Spokes must use multipoint GRE tunnels</span></li><li><span dir="ltr">The spokes must receive specific routes for all remote spoke subnets</span></li><li><span dir="ltr">The next hop of the entry in the routing table must list the remote spoke as the next hop</span></li></ul><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr">Here is the same topology diagram from Phase 1 redesigned for Phase 2:</p><p dir="ltr" style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3948-325904/Phase-2modified.jpg"><img alt="Phase-2modified.jpg" class="image-5 jive-image" height="723" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3948-325904/Phase-2modified.jpg" style="height: 640px; width: 620px;" width="700"/></a></p><p dir="ltr" style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr">First, it must be ensured the spokes utilize multipoint GRE tunnels. Configuring mGRE on the Spokes allows multiple GRE tunnels to be formed using a single tunnel interface. This is achieved by removing the static <strong>tunnel destination</strong> command and replacing it with the <strong>tunnel mode gre multipoint</strong> command.</p><p><span><span><br/></span></span></p><p dir="ltr">Second, the spokes must receive specific routes for all remote spoke subnets. For EIGRP, this is accomplished by disabling split horizon on the tunnel interface. The split-horizon algorithm is, &#8220;Do not advertise a route out an interface if the router uses that interface to reach that network.&rdquo;<span style="font-size: 10pt; font-family: Arial; color: #000000;"> </span></p><p><span><span><br/></span></span></p><p dir="ltr">In DMVPN, the hub uses its Tunnel0 interface to reach the networks behind the spokes. Split horizon will prevent the hub from advertising those networks to remote spokes. Thus, in order for DMVPN to work in Phase 2 with EIGRP, split horizon must be disabled on the tunnel interface using the <strong>no ip split-horizon eigrp [asn]</strong> command.</p><p><span><span><br/></span></span></p><p dir="ltr">Finally, the next hop for all of the routes must point to the remote spoke. This is the key to triggering the generation of a spoke-to-spoke tunnel. Let&#8217;s examine this from Spoke-R2&#8217;s perspective. If we look at the routing table in properly configured Phase 2 implementation, we see the following:</p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Spoke-R2#show ip route eigrp</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">--- omitted ---</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Gateway of last resort is not set</span></p><p><span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">D </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">192.168.30.0/24 [90/28288000] via </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold; text-decoration: underline;">172.16.1.3</span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">, 00:01:08, Tunnel0</span></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #000000;"><br/></span></p><p dir="ltr">Notice the next hop for 192.168.30.1 is 172.16.1.3, Spoke-R3 itself. The importance of this is seen whenever we examine the CEF entries for 172.16.1.3, starting with the adjacency table:</p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Spoke-R2#show adjacency 172.16.1.3</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Protocol Interface&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Address</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">IP&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Tunnel0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">172.16.1.3(5) (</span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold; text-decoration: underline;">incomplete</span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">)</span></p><p><span><span><br/></span></span></p><p dir="ltr">Note the adjacency is incomplete. In order for Spoke-R2 to build the GRE header, it needs to know the mapping of Spoke-R3&#8217;s NBMA address (30.1.1.1) to Tunnel IP (172.16.1.3). The incomplete adjacency triggers a CEF punt to the CPU for further processing (to resolve the address):</p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Spoke-R2#sh ip cef 172.16.1.3 internal</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">172.16.1.0/24, epoch 0, flags attached, connected, cover dependents, need deagg, RIB[C], refcount 5, </span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">--- omitted ---</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; path F2EE8BD8, path list F3476CDC, share 1/1, type connected prefix, for IPv4</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000; font-weight: bold;">connected to Tunnel0, adjacency </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold; text-decoration: underline;">punt</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000; font-weight: bold;">&nbsp; output chain: </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold; text-decoration: underline;">punt</span></p><p><span><span><br/></span></span></p><p dir="ltr">This causes Spoke-R2 to send a resolution request to Hub-R1 for Spoke-R3&#8217;s NBMA address. The request gets forwarded from Hub-R1 to Spoke-R3. Spoke-R3 replies directly to Spoke-R2 with its mapping information. During this process, Spoke-R2 will send the actual data packet to Hub-R1 to be delivered to Spoke-R3 as a last-ditch effort to not drop the traffic. The first traceroute will look like this:</p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Spoke-R2#traceroute 192.168.30.1</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Type escape sequence to abort.</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Tracing the route to 192.168.30.1</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">VRF info: (vrf in name/id, vrf out name/id)</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; 1 172.16.1.1 1 msec 5 msec 5 msec</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; 2 172.16.1.3 1 msec 6 msec 0 msec</span></p><p><span><span><br/></span></span></p><p dir="ltr">After the NHRP resolution is complete, Spoke-R2 can build a dynamic tunnel to Spoke-R3, and traffic will not pass through Hub-R1 anymore. Spoke-R2 also caches the mapping information for Spoke-R3 in its DMVPN table. Subsequent traceroutes look like this:</p><p><span style="font-size: 10pt; font-family: Arial; color: #000000;"><br/></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Spoke-R2#traceroute 192.168.30.1</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Type escape sequence to abort.</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Tracing the route to 192.168.30.1</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">VRF info: (vrf in name/id, vrf out name/id)</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; 1 172.16.1.3 6 msec 5 msec 4 msec</span></p><p><span><span><br/></span></span></p><p dir="ltr">Spoke-R2&#8217;s DMVPN table:</p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Spoke-R2#show dmvpn</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">--- omitted ---</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Interface: Tunnel0, IPv4 NHRP Details</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Type:Spoke, NHRP Peers:2,</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> # Ent&nbsp; Peer NBMA Addr Peer Tunnel Add State&nbsp; UpDn Tm Attrb</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ----- --------------- --------------- ----- -------- -----</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">1 10.1.1.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">172.16.1.1</span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">UP 00:15:36 </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">S</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">1 30.1.1.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">172.16.1.3</span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">UP 00:05:25 </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">D</span></p><p><span><span><br/></span></span>This resolution process is all possible because Hub-R1 passes the routing update with the next hop unmodified to the spokes. This is achieved in EIGRP using the <strong>no ip next-hop-self eigrp 123</strong> command under the tunnel interface.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr">Following is the Phase 2 Hub-R1 interface configuration followed by Spoke-R2's configuration:</p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Hub-R1#show run int tun0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">interface Tunnel0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip address 172.16.1.1 255.255.255.0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> no ip redirects</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;"> no ip next-hop-self eigrp 123</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;"> no ip split-horizon eigrp 123</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip nhrp authentication cisco</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip nhrp map multicast dynamic</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip nhrp network-id 123</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> tunnel source Ethernet0/0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> tunnel mode gre multipoint</span></p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Spoke-R2#show run int tun0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">interface Tunnel0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip address 172.16.1.2 255.255.255.0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> no ip redirects</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip nhrp authentication cisco</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip nhrp network-id 123</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip nhrp nhs 172.16.1.1 nbma 10.1.1.1 multicast</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> tunnel source Ethernet0/0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">tunnel mode gre multipoint</span></p><p><span><br/></span>Because the next hop for each prefix must be preserved, in Phase 2 it is not possible to summarize from the hub to the spokes. Doing so would recreate Phase 1 behavior where the spokes would send all traffic to the hub (as the next hop for the summary route) eliminating the advantages of Phase 2&#8217;s spoke-to-spoke tunnels.</p><p><span style="color: #000000; font-family: Arial; font-size: 16pt;"><br/></span></p><h2>Phase 3</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr">Though DMVPN Phase 2 deployment provided direct spoke-to-spoke tunnels, one of the limitations is maintaining full routing tables on the spokes. Each route for remote spoke networks needs to be a specific route with the next hop pointing to the remote spoke&#8217;s tunnel address. This prevents the hub from being able to send down a summarized route to the spokes for a more concise routing table.</p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #000000;"><br class="kix-line-break"/></span>Phase 3 overcomes this restriction using NHRP traffic indication messages from the hub to signal to the spokes that a better path exists to reach the target network. This functionality is enabled by configuring <strong>ip nhrp redirect</strong> on the hub and <strong>ip nhrp shortcut</strong> on the spokes. The redirect command tells the hub to send the NHRP traffic indication message while the shortcut command tells the spokes to accept the redirect and install the shortcut route.</p><p><span><span><br/></span></span></p><p><span><span>Here is the resultant topology diagram modified for Phase 3 implementation:</span></span></p><p><span><span><br/></span></span></p><p><span><span><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3948-325908/Phase-3modified.jpg"><img alt="Phase-3modified.jpg" class="jive-image image-6" height="723" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3948-325908/Phase-3modified.jpg" style="height: 640px; width: 620px;" width="700"/></a><br/></span></span></p><p><span><span><br/></span></span></p><p dir="ltr">As in case with Phase 1, the hub router is configured to send summarized routing information down to the spokes.<span style="font-size: 10pt; font-family: Arial; color: #000000;"> </span></p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Spoke-R2#sh ip route eigrp</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">--- omitted ---</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Gateway of last resort is 172.16.1.1 to network 0.0.0.0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">D*</span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">0.0.0.0/0</span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000; font-weight: bold;"> </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">[90/28160000] via 172.16.1.1, 00:01:03, Tunnel0</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr">When Spoke-R2 sends traffic to the network behind Spoke-R3 (192.168.30.1):</p><ol><li><span dir="ltr">The first packet is routed to Hub-R1 (following the summarized route). </span></li><li><span dir="ltr">Hub-R1 &#8220;hairpins&rdquo; this traffic back onto the DMVPN network, triggering the NHRP process on Hub-R1 to generate the traffic indication to Spoke-R2 to resolve a better next hop for the remote network 192.168.30.1. </span></li><li><span dir="ltr">Spoke-R2 receives this Indication message and processes the redirect to Spoke-R3.</span><span style="font-size: 10pt;"> </span></li></ol><p><span><span><br/></span></span></p><p dir="ltr">The below output is taken from <strong>debug nhrp packet</strong> on Spoke-R2:</p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 8pt; font-family: 'Courier New'; color: #000000;">*Feb&nbsp; 4 14:09:50.535: NHRP: </span><span style="font-size: 8pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">Receive Traffic Indication</span><span style="font-size: 8pt; font-family: 'Courier New'; color: #000000;"> via Tunnel0 vrf 0, packet size: 97</span></p><p dir="ltr"><span style="font-size: 8pt; font-family: 'Courier New'; color: #000000;">--- omitted ---</span></p><p dir="ltr"><span style="font-size: 8pt; font-family: 'Courier New'; color: #000000;">*Feb&nbsp; 4 14:09:50.543:&nbsp; (M) </span><span style="font-size: 8pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">traffic code: redirect(0)</span></p><p><span><span><br/></span></span></p><p dir="ltr">Spoke-R2 must now send a resolution request to Hub-R1 for the destination 192.168.30.1. This message contains its own NBMA to tunnel address mapping:</p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">*Feb&nbsp; 4 14:25:54.672: NHRP: Send Resolution Request via Tunnel0 vrf 0, packet size: 85</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">*Feb&nbsp; 4 14:25:54.672:&nbsp; src: 172.16.1.2, dst: 192.168.30.1</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">--- omitted ---</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">*Feb&nbsp; 4 14:25:54.672:</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">src NBMA: 20.1.1.1</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">*Feb&nbsp; 4 14:25:54.672: </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;"> </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">src protocol: 172.16.1.2, dst protocol: 192.168.30.1</span></p><p><span><span><br/></span></span></p><p dir="ltr">Hub-R1 forwards this packet to Spoke-R3. Spoke-R3, using the above mapping information, responds directly to Spoke-R2 with its own mapping information:</p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">*Feb&nbsp; 4 14:25:54.677: NHRP: Receive Resolution Reply via Tunnel0 vrf 0, packet size: 133</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">--- omitted ---</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">*Feb&nbsp; 4 14:25:54.677:</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">client NBMA: 30.1.1.1</span></p><p dir="ltr"><span style="font-size: 9pt; font-family: 'Courier New'; color: #000000;">*Feb&nbsp; 4 14:25:54.677:</span><span style="font-size: 9pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">&nbsp;&nbsp;&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">&nbsp; </span><span style="font-size: 9pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">client protocol: 172.16.1.3</span></p><p><span><span><br/></span></span></p><p dir="ltr"><em>NOTE: The above is only half of the process. Spoke-R3 will also send a resolution request to Hub-R1 for Spoke-R2&#8217;s NBMA address. This gets forwarded to Spoke-R2. Spoke-R2 responds directly to Spoke-R3 with a resolution reply completing the process.</em></p><p><span><span><br/></span></span></p><p dir="ltr">At this point, the spokes can now modify their routing table entries to reflect the NHRP shortcut route and use it to reach the remote spoke.<span style="font-size: 10pt; font-family: Arial; color: #000000;"> </span></p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #000000; font-style: italic;">NOTE: The behavior of modifying the routing table was implemented in IOS 15.2(1)T. This change was made to allow the router to forward the traffic using CEF.</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: Arial; color: #000000; font-style: italic;"><br/></span></p><p dir="ltr">For example, on Spoke-R2 an (H) route will be created in the routing table. Another (H) route is installed for the Tunnel IP address of Spoke-R3. This is inserted under the connected route for the tunnel interface because it is more specific:</p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Spoke-R2#sh ip route</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">--- omitted ---</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Gateway of last resort is 172.16.1.1 to network 0.0.0.0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">D*</span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">0.0.0.0/0 [90/28160000] via 172.16.1.1, 00:16:35, Tunnel0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">R </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">10.0.0.0/8 [120/1] via 20.1.1.2, 00:00:09, Ethernet0/0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">C&nbsp;&nbsp;&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; 20.1.1.0/24 is directly connected, Ethernet0/0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">L&nbsp;&nbsp;&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; 20.1.1.1/32 is directly connected, Ethernet0/0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">R </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">30.0.0.0/8 [120/1] via 20.1.1.2, 00:00:09, Ethernet0/0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">C&nbsp;&nbsp;&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; 172.16.1.0/24 is directly connected, Tunnel0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">L&nbsp;&nbsp;&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; 172.16.1.2/32 is directly connected, Tunnel0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">H&nbsp;&nbsp;&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">&nbsp; 172.16.1.3/32 is directly connected, 00:14:33, Tunnel0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">192.168.20.0/24 is variably subnetted, 2 subnets, 2 masks</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">C&nbsp;&nbsp;&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; 192.168.20.0/24 is directly connected, Loopback1</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">L&nbsp;&nbsp;&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">192.168.20.1/32 is directly connected, Loopback1</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">H </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">&nbsp; </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">192.168.30.0/24 [250/1] via 172.16.1.3, 00:14:33, Tunnel0</span></p><p><span><span><br/></span></span></p><p dir="ltr">Similar to Phase 2, the first data packet will traverse the hub while the spokes resolve the proper addresses. After the resolution is completed, data will be sent to the remote spokes directly, bypassing the hub.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr">The configuration for DMVPN and EIGRP in Phase 3 mirrors Phase 1 configuration with the addition of the <strong>ip nhrp redirect/shortcut</strong> commands on the hub and spoke routers:<span style="font-size: 10pt; font-family: Arial; color: #000000;"><br class="kix-line-break"/><br class="kix-line-break"/></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Hub-R1#show run int tun0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">interface Tunnel0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip address 172.16.1.1 255.255.255.0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> no ip redirects</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip nhrp authentication cisco</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip nhrp map multicast dynamic</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip nhrp network-id 123</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">ip nhrp redirect</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">ip summary-address eigrp 123 0.0.0.0 0.0.0.0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> tunnel source Ethernet0/0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> tunnel mode gre multipoint</span></p><p><span><span><br/></span></span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">Spoke-R2#show run int tun0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;">interface Tunnel0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip address 172.16.1.2 255.255.255.0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> no ip redirects</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip nhrp authentication cisco</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip nhrp network-id 123</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> ip nhrp nhs 172.16.1.1 nbma 10.1.1.1 multicast</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> </span><span style="font-size: 10pt; font-family: 'Courier New'; color: #ff0000; font-weight: bold;">ip nhrp shortcut</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> tunnel source Ethernet0/0</span></p><p dir="ltr"><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000;"> tunnel mode gre multipoint</span></p><h2></h2><h2></h2><h2>Summary</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr">This blog examined the basic configuration of DMVPN with routing while highlighting the shortcomings of each initial DMVPN implementation. Phase 1 provided an optimized control plane on the spokes through summarization of routing information. However, the major limitation was the inability to create a direct spoke-to-spoke tunnel and optimize the data plane. Phase 2 improved on this by allowing spokes to dynamically form spoke-to-spoke tunnels. This also came at the cost of burdening the spokes with specific routes for all remote destinations. Phase 3 eliminated these limitations using NHRP shortcut switching enhancements, optimizing both the data and control planes.</p><p><br/>The configurations in this blog reflect the least amount of configuration required to create a working solution. They are for the purpose of basic academic understanding. In a real implementation, the configuration needs to be fined tuned on per-case basis for the most optimized performance.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-size: 10pt; font-family: Arial; color: #000000; font-style: italic;"><br/></span></p><p><span style="font-size: 10pt; font-family: 'Courier New'; color: #000000; font-weight: bold;"><br/></span></p></div><!-- [DocumentBodyEnd:07e4a797-5f69-4d19-825f-7d24d737313e] -->Wed, 15 Feb 2017 15:16:44 GMTbounce@learningnetwork.cisco.comhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2017/02/15/dmvpn-the-phases-in-depth2017-02-15T15:16:44Z6 months 21 hours ago400https://learningnetwork.cisco.com/blogs/vip-perspectives/comment/dmvpn-the-phases-in-depthhttps://learningnetwork.cisco.com/blogs/vip-perspectives/feeds/comments?blogPost=3948Planes and Perspectiveshttps://learningnetwork.cisco.com/blogs/vip-perspectives/2017/01/17/planes-and-perspectives
<!-- [DocumentBodyStart:a1360090-d3a9-45d8-8d94-36dd49616dad] --><div class="jive-rendered-content"><p><a><img alt="ertification vs. Degree: What Do I Need to Succeed?" src="/resources/statics/1328674/PlanesAndPerspectives_Blog.jpg" style="float: left; padding: 0px 20px 8px 0px;" width="280"/></a></p><p>For the beginner, embarking on the study of networking can be daunting as it often presents words and concepts once understood suddenly imbued with new meaning. Computer science is a relatively new idea first proposed in 1956 by Louis Fein in a study for Stanford University. The administrators were dubious of what Fein called "computer-related science." A Computer Science Department would officially be established in 1962 by Purdue University, but a "coherent definition" of this new science would take another three years for recognition and two more years before realizing accreditation. <a class="jive-link-external-small cisco-google-tracker" href="https://books.google.com/books?id=7lqBDQAAQBAJ&amp;pg=PA37&amp;lpg=PA37&amp;dq=louis+fein+1959+computer+science&amp;source=bl&amp;ots=ZN5hC_u7qy&amp;sig=ihzxbVRozz1xYtmq-Kbz6c_80yU&amp;hl=en&amp;sa=X&amp;ved=0ahUKEwi_mrn22rDRAhWF6yYKHXCrD6oQ6AEIJzAB#v=onepage&amp;q=louis%20fein%201959%20computer%20science&amp;f=false" rel="nofollow" target="_blank" title="More info">More info</a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>The word semantics, a sub-field of linguistics,&nbsp; was first used by Michel Breal in 1883 to describe how words can have different meanings for different people based on experiential and environmental qualities. In 1967 Robert Floyd would be given credit for programming language semantics, although programming is widely attributed to Ada Lovelace who used an algorithm to calculate Benoulli numbers as far back as 1843. Semantically, programming had an enormous lead over networking in adapting language to suit its purposes. <a class="jive-link-external-small cisco-google-tracker" href="http://www.biography.com/people/ada-lovelace-20825323#babbage-and-the-analytical-engine" rel="nofollow" target="_blank" title="More info">More info</a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>As a younger human I considered a network to be one of the big TV stations of the era, or the phone system. A protocol was a code prescribing etiquette, rules of behavior or a diplomatic exchange. A program was a show on TV or an instructional outline at school; programming was a schedule of those shows and, later, coded instructions to be inserted into some device. An algorithm defined the notion of decidability, a switch was something to turn on the lights, a route was a road map identifier, and a plane was a big transport with wings, or something used to smooth wood, or a two dimensional surface that extended to infinity.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>A side note on definitions and perspective:</p><p>From a conceptual viewpoint, most networking ideas are interchangeable across vendors. Naturally, I lean toward Cisco for resolution and the last word for any differences that may crop up. As an example, trunking with Cisco is quite distinct as compared to some other vendors. My preference is, of course, obvious. <a class="jive-link-external-small cisco-google-tracker" href="https://travelingpacket.com/2014/05/19/hp-vs-cisco-vlan-trunking/" rel="nofollow" target="_blank" title="More info">More info</a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>When computing and, eventually, networking came into my life and work, I realized that many of the definitions of things I was comfortable with were suddenly changing daily.&nbsp; My perspective of planes would be challenged as well.</p><p>It is agreed that three operational planes exist for the management of network traffic.</p><p>Data Plane:</p><p>Processes traffic through a network device (transit traffic)</p><p>Control Plane:</p><p>Destined for the network device or originated by it</p><p>Management Plane (sometimes considered a subset of Control):</p><p>Monitors device operation and performance (typically utilizing a protocol such as SNMP)</p><p><a class="jive-link-external-small cisco-google-tracker" href="http://stackoverflow.com/questions/30190944/what-is-management-plane-in-sdn" rel="nofollow" target="_blank" title="More info">More info</a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>More specifically:</p><p><strong><br/></strong></p><p>Control Plane:</p><ul><li>&nbsp;&nbsp;&nbsp; Decides where traffic is going (i.e. routing protocols, etc.)</li><li>&nbsp;&nbsp;&nbsp; System configuration, management information</li><li>&nbsp;&nbsp;&nbsp; Exchange topological information</li><li>&nbsp;&nbsp;&nbsp; Policing (Management Plane Protection)</li><li>&nbsp;&nbsp;&nbsp; CLI, HTTP, SSH, etc.</li><li><a class="jive-link-external-small" href="http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t11/htsecmpp.html#wp1049321" target="_blank" title="More info">More info</a></li></ul><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-weight: normal;">Data Plane:</span></p><ul><li>&nbsp;&nbsp;&nbsp; Often called the Forwarding Plane</li><li>&nbsp;&nbsp;&nbsp; Utilizes the control plane to forward onto the destination</li><li>&nbsp;&nbsp;&nbsp; Utilizes the control plane to make packet drop determinations</li></ul><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a class="jive-link-external-small" href="http://www.ipspace.net/About_Ivan_Pepelnjak" rel="nofollow" target="_blank">Ivan Pepelnjak</a> has a very nice graphic as well as more specific information on SDN:</p><p><a class="jive-link-external-small cisco-google-tracker" href="http://blog.ipspace.net/2013/08/management-control-and-data-planes-in.html" rel="nofollow" target="_blank" title="More info">More info</a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Grey areas begin to emerge, and here is where to consider perspective.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>For example:</p><ul><li>user doc to other user through network device = Data Plane</li><li>user to directly connected network device for CLI access = Data to Management</li><li>network device to network device topology update = Data to Control</li></ul><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Certainly this is a simplification, for it is known there are many protocols at play for any packet stream, in any network at any time slice. In networking, definitions that were once trustworthy and dependable are constantly being reevaluated and redefined to suit a present requirement. Understanding planes requires consideration of perspective; however, the perspective is subject to change. The furtherance of Software Defined Networking will insure that, as abstraction and agility promotes automation and there is less reliance on human intervention.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Further reading:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a class="jive-link-external-small" href="http://www.cisco.com/web/services/news/ts_newsletter/tech/chalktalk/archives/200809.html" rel="nofollow" target="_blank">http://www.cisco.com/web/services/news/ts_newsletter/tech/chalktalk/archives/200809.html</a></p><p><a class="jive-link-external-small" href="http://www.ciscopress.com/articles/article.asp?p=2272154&amp;seqNum=3" rel="nofollow" target="_blank">http://www.ciscopress.com/articles/article.asp?p=2272154&amp;seqNum=3</a></p><p><a class="jive-link-external-small" href="http://blog.ipspace.net/2014/01/control-and-data-plane-separation-three.html" rel="nofollow" target="_blank">http://blog.ipspace.net/2014/01/control-and-data-plane-separation-three.html</a></p></div><!-- [DocumentBodyEnd:a1360090-d3a9-45d8-8d94-36dd49616dad] -->Tue, 17 Jan 2017 23:19:36 GMTbounce@learningnetwork.cisco.comhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2017/01/17/planes-and-perspectives2017-01-17T23:19:36Z6 months 1 month ago40https://learningnetwork.cisco.com/blogs/vip-perspectives/comment/planes-and-perspectiveshttps://learningnetwork.cisco.com/blogs/vip-perspectives/feeds/comments?blogPost=3930Let’s Cook: SRTP!!!https://learningnetwork.cisco.com/blogs/vip-perspectives/2016/11/07/let-s-cook-srtp
<!-- [DocumentBodyStart:380d68a3-7947-4546-8393-f8d6f2799225] --><div class="jive-rendered-content"><p><a><img alt="Let&#8217;s Cook: SRTP!!!" src="/resources/statics/1261018/LetsCookSRTP_blog.jpg" style="float: left; padding: 8px 20px 8px 0px;" width="290"/></a></p><p>SRTP (Secure Real-Time protocol), as the name suggests, is a secure RTP, or in simple terms, encrypted RTP. SRTP can be implemented in both CUCM or CME environments. There are a lot of things involved which we need to prepare before going forward. The goal of this post is to provide an understanding of implementing this protocol, but it cannot be considered as a complete guide because there is so much information that cannot be summarized in a single blog. This post will be focused on implementing the SRTP functionality in a CUCM environment.</p><p style="min-height: 8pt; padding: 0px; text-indent: 36.0pt;">&nbsp;</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>There are multiple things to consider, so we will take a look at all of them one by one.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>If we have ever downloaded a full ISO image of CUCM from Cisco, we must have seen two images of every version released. These are categorized as:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ul style="list-style-type: disc; font-size: 14px;"><li>(a) Restricted (includes full encryption capabilities | export restricted outside U.S.)</li><li>(b) Un-restricted (includes fewer encryption capabilities | can be exported outside U.S.)</li></ul><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>We need the restricted version image to deploy SRTP in a CUCM environment as it contains all encryption capabilities. We can convert or upgrade an existing cluster from restricted to un-restricted, but the opposite is not possible. The cost &amp; license procedure is all the same for both.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3888-323886/image.png"><img alt="image.png" class="jive-image image-1" height="205" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3888-323886/700-205/image.png" style="height: 182px; width: 620px;" width="700"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>Two Types of Security Modes in CUCM Cluster:</strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ol style="list-style-type: lower-alpha; font-size: 14px;"><li>Non-Secure Mode: as the name suggests, there is almost no security with this mode, and it is enabled by default.</li><li>Mixed Mode: This mode can work as non-secure + secure mode; I think that&#8217;s why it&#8217;s called mixed mode.</li></ol><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>When We install CUCM, the default mode is always non-secure mode, which means no signalling &amp; media encryption is enabled. We need to convert the cluster security mode from non-secure to mixed mode. As the name suggests, mixed mode supports both non-secure as well as secure (encryption) modes via the phone security profile.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Navigate to <strong>CUCM Admin Page &gt; System &gt; Enterprise Parameters</strong> and verify whether the cluster was set to mixed mode (a value of 1 indicates mixed mode):</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Non-Secure Mode:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3888-323887/N-S+M.png"><img alt="N-S M.png" class="jive-image image-2" height="142" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3888-323887/700-142/N-S+M.png" style="height: 126px; width: 620px;" width="700"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Secure Mode:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3888-323888/S-M.png"><img alt="S-M.png" class="jive-image image-3" height="142" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3888-323888/S-M.png" style="height: auto;" width="612"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>There are two ways to change cluster security to mixed mode:</strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ol style="list-style-type: decimal; font-size: 14px;"><li>Use USB security tokens &amp; install the CTL plugin on the machine (PC). USB tokens contain the private key to sign the CUCM certificates. We need to buy secure USB tokens for this procedure.</li><li>Token-less CTL method. {it was introduced since Version 10.0(1) of CUCM}</li></ol><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>We will focus on the second method for now, as it does not require any cost involvement (:P) and it&#8217;s the best choice if we want to test this feature in a lab environment. The token-less method will use self-signing process instead of signing the certificates via USB security tokens.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>Note:</strong> Before singing the certificates make sure all information in the certificates is correct. Most information in the certificates is taken from information provided during CUCM installation.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>If We want to modify or correct the information, then...</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong><em>Go to: System -&gt; Security -&gt; Certificate </em></strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Click on the desired certificate to edit the information. We can also see which CUCM service the particular certificate is associated with.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>We can also check all the certificates self-signed/ca-signed in CUCM OS Administration. It will also show the expiration date of certificates.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong><em>CUCM -&gt; OS Administration -&gt; Security -&gt; Certificate Management</em></strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>There are lots of things to discuss about certificates which cannot be done in this post as of now.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>Note:</strong> We must be aware of what we are about to do. Try to keep a backup in case anything goes wrong.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="text-decoration: underline;"><strong>Implementation or Configuration:</strong></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Let&#8217;s take a walk towards the implementation process. We are assuming our cluster is in non-secure mode now. We will need the CLI credentials of CUCM publisher for converting the security mode of the cluster.</p><p style="min-height: 8pt; padding: 0px; margin-bottom: .0001pt; background: white;">&nbsp;</p><p style="margin-bottom: .0001pt; background: white;"><span style="font-size: 8.5pt; font-family: Courier; color: #525252;">admin:</span><span style="color: #525252; font-size: 8.5pt; font-family: 'inherit',serif;"><strong>show ctl</strong></span><span style="font-size: 8.5pt; font-family: Courier; color: #525252;"><br/> Length of CTL file: 0<br/> </span><span style="color: #525252; font-size: 8.5pt; font-family: 'inherit',serif;"><strong>CTL File not found</strong></span><span style="font-size: 8.5pt; font-family: Courier; color: #525252;">. Please run CTLClient plugin or run the CLI - utils ctl.. to<br/> generate the CTL file.<br/> Error parsing the CTL File.<br/> admin:</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>We can see above there is no CTL file present in the cluster and it&#8217;s in non-secure mode. We can also verify via enterprise parameters as shown in the above image.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>We need to run the below command in publisher to convert the mode into mixed mode:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>In CUCM Administration, Go To</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>Serviceability &gt; Tools &gt; Control Center - Feature Services</strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Enable CAPF as well as CTL services on the CUCM publisher and CTL service on all CUCM subscribers.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>We need to run below command in publisher to convert the mode into Mixed-mode:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-size: 8.5pt; font-family: Courier; color: #525252;">admin:</span><span style="color: #525252; font-size: 8.5pt; font-family: inherit, serif;"><strong>utils ctl set-cluster mixed-mode</strong></span><span style="font-size: 8.5pt; font-family: Courier; color: #525252;"><br/> This operation will set the cluster to Mixed mode. Do We want to continue? (y/n):y<br/> <br/> Moving Cluster to Mixed Mode<br/> Cluster set to Mixed Mode<br/> Please Restart the TFTP and Cisco CallManager services on all nodes in the cluster<br/> that run these services<br/> admin:</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Once completed, restart the TFTP and Cisco Call Manager services on all of the nodes in the cluster that run these services. Restart all of the IP phones so that they can obtain the CTL file from the CUCM TFTP service.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="margin-bottom: 12.0pt; background: white;"><span style="font-size: 8.5pt; font-family: Courier; color: #525252;">admin:</span><span style="color: #525252; font-size: 8.5pt;"><strong>show ctl</strong></span><span style="font-size: 8.5pt; font-family: Courier; color: #525252;"><br/> The checksum value of the CTL file:</span><span style="color: #525252; font-size: 8.5pt;"><strong><br/> <strong>256a661f4630cd86ef460db5aad4e91c(MD5)</strong></strong></span><span style="font-size: 8.5pt; font-family: Courier; color: #525252;"><br/> 3d56cc01476000686f007aac6c278ed9059fc124(SHA1)<br/> <br/> Length of CTL file: 5728<br/> The CTL File was last modified on Fri Mar 06 21:48:48 CET 2015<br/> <br/> </span><span style="color: #525252; font-size: 8.5pt;"><strong>[...]</strong></span><span style="font-size: 8.5pt; font-family: Courier; color: #525252;"><br/> CTL Record #:5<br/> ----<br/> BYTEPOS TAG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LENGTH&nbsp; VALUE<br/> ------- ---&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ------&nbsp; -----<br/> 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RECORDLENGTH&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1186<br/> 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DNSNAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1<br/> 3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SUBJECTNAME&nbsp;&nbsp;&nbsp; 56&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cn="SAST-ADN008580ef ";ou=IPCBU;o="Cisco Systems<br/> 4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FUNCTION&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; System Administrator Security Token<br/> 5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ISSUERNAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 42&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cn=Cisco Manufacturing CA;o=Cisco Systems<br/> 6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SERIALNUMBER&nbsp;&nbsp;&nbsp; 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="color: #525252; font-size: 8.5pt;"><strong>83:E9:08:00:00:00:55:45:AF:31</strong></span><span style="font-size: 8.5pt; font-family: Courier; color: #525252;"><br/> 7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PUBLICKEY&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 140<br/> 9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CERTIFICATE&nbsp;&nbsp;&nbsp; 902&nbsp;&nbsp;&nbsp; 85 CD 5D AD EA FC 34 B8 3E 2F F2 CB 9C 76 B0 93<br/> 3E 8B 3A 4F (SHA1 Hash HEX)<br/> 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IPADDRESS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4<br/> </span><span style="color: #525252; font-size: 8.5pt;"><strong>This etoken was used to sign the CTL file.</strong></span><span style="font-size: 8.5pt; font-family: Courier; color: #525252;"><br/> <br/> The CTL file was verified successfully</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Before Enabling Mixed Mode:</p><p><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3888-323889/NC.png"><img alt="NC.png" class="jive-image image-4" height="232" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3888-323889/NC.png" style="height: auto;" width="319"/></a></p><p>After Enabling Mixed-Mode &amp; CTL file installed on IP Phone:</p><p><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3888-323890/C.png"><img alt="C.png" class="image-5 jive-image" height="237" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3888-323890/C.png" style="height: auto;" width="320"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Till now we had enabled the security mode in the cluster, and the phones are ready but they will not run SRTP yet. We need to create a profile for it or tell the phone to do so with some parameters for every device type and protocol.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="text-decoration: underline;"><strong>Device Security Modes:</strong></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>There are 3 types of Device Security Modes:</p><ol style="list-style-type: lower-alpha; font-size: 14px;"><li>Non-Secure: No security features except image, file, and device authentication exist for the phone. A TCP connection opens to Cisco Unified Communications Manager.</li><li>Authentication: Cisco Unified Communications Manager provides integrity and authentication for the phone. A TLS connection that uses NULL/SHA opens for signaling.</li><li>Encryption: Cisco Unified Communications Manager provides integrity, authentication, and encryption for the phone. A TLS connection that uses AES128/SHA opens for signaling, and SRTP carries the media for all phone calls.</li></ol><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3888-323891/DSM.jpg"><img alt="DSM.jpg" class="jive-image image-6" height="201" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3888-323891/DSM.jpg" style="height: auto;" width="462"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Now Go to CUCM administration page:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong><em>System -&gt; Security Profile -&gt; Phone Security Profile </em></strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong><em>Click -&gt; Add New</em></strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Create a security profile. For every device model &amp; protocol its using. Select the desired one &amp; save.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3888-323892/PSP.png"><img alt="PSP.png" class="jive-image image-7" height="311" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3888-323892/PSP.png" style="height: auto;" width="568"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>TFTP Encrypted Config: When this check box is checked, Cisco Unified Communications Manager encrypts phone downloads from the TFTP server.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="text-decoration: underline;"><strong>Phone Security Profile CAPF</strong></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>We can choose the authentication type for the device:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ol style="list-style-type: lower-alpha; font-size: 14px;"><li>Existing Certificate (LSC or MIC) &#8211; Installs/upgrades, deletes, or troubleshoots a locally significant certificate if a manufacture-installed certificate (MIC) or locally significant certificate (LSC) exists in the phone. Cisco recommends using LSC, as MIC can be compromised.</li><li>Authentication String &#8211; Installs/upgrades, deletes, or troubleshoots a locally significant certificate only when the user enters the CAPF authentication string on the phone.</li><li>Null String: Installs/upgrades, deletes, or troubleshoots a locally significant certificate without user intervention. This option provides no security; Cisco strongly recommends that we choose this option only for closed, secure environments.</li></ol><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3888-323893/PSp1.png"><img alt="PSp1.png" class="jive-image image-8" height="314" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3888-323893/PSp1.png" style="height: auto;" width="568"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="text-decoration: underline;"><strong>Certificate Operation Over IP Phone: </strong></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>If we have updated the CTL (Cisco Trust List) file with new or re-generated certificate and want to manually push the updated certificates into the phone, we need to go to protocol-specific section of the device page, and from there we can install/delete/troubleshoot the issue.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3888-324005/cln.png"><img alt="cln.png" class="jive-image image-13" height="243" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3888-324005/cln.png" style="height: auto;" width="513"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Apply device security profile on the device page and reset the phone. To apply to multiple phones at once, use the BAT tool.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3888-323895/PSI.png"><img alt="PSI.png" class="image-10 jive-image" height="142" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3888-323895/PSI.png" style="height: auto;" width="592"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Now we make a call between the two phones to check if we see a lock icon on the call display over phone. It means the call is encrypted, it&#8217;s running SRTP and some CUCM versions will show a shield icon and some a lock icon as shown below.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3888-323896/SRTP.png"><img alt="SRTP.png" class="jive-image image-11" height="233" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3888-323896/SRTP.png" style="height: auto;" width="318"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>This is just a basic practice for SRTP, but if we are going to implement the same in a production environment, we will also need to take care of certificate import on the Gateways/Conference Bridge router and on the SRST router.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="text-decoration: underline;"><strong>Secure-SRST:</strong></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Let&#8217;s take a look at secure SRST. This guide will be focusing on implementation of sSRST over unified SRST, not CME-SRST.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>The first step is the requirement:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ol style="list-style-type: lower-alpha; font-size: 14px;"><li>UCK9 license</li><li>SRST license</li><li>Security license (needed to run the encryption capabilities of the SRST)</li><li>Cisco IOS image with payload encryption capabilities. In other words, the IOS image should not be NPE (non-payload encryption).</li></ol><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>We need to import the CUCM certificates into the SRST &amp; enable secure SRST in the SRST profile.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3888-323897/SRS.png"><img alt="SRS.png" class="jive-image image-12" height="288" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3888-323897/SRS.png" style="height: auto;" width="539"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="text-decoration: underline;"><strong>CUCM: SRST Profile:</strong></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>We need to manually import a few certificates from CUCM to the SRST router where as SRST self-signed certificates will be automatically transferred to CUCM when we check the box (is SRST Secure?). If transfers complete successfully, changes will be saved in the profile; otherwise the change will not be saved in the SRST profile in CUCM.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>When we enable secure SRST, CUCM asks for the SRST self-signed certificate and credential service running on the SRST router and does the same with CUCM. This process is called certification enrollment.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Everything cannot be covered here in a single blog so I will try to include more information future posts. I want to thank my friends Ebin &amp; Engg for helping me prepare this blog. And a special thanks to CLN team for providing a platform to share things &amp; learn together. Thanks !!!</p></div><!-- [DocumentBodyEnd:380d68a3-7947-4546-8393-f8d6f2799225] -->srtpvip_blogchandan_takuliMon, 07 Nov 2016 22:19:35 GMTbounce@learningnetwork.cisco.comhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2016/11/07/let-s-cook-srtp2016-11-07T22:19:35Z9 months 1 week ago50https://learningnetwork.cisco.com/blogs/vip-perspectives/comment/let-s-cook-srtphttps://learningnetwork.cisco.com/blogs/vip-perspectives/feeds/comments?blogPost=3888Talk Python to Mehttps://learningnetwork.cisco.com/blogs/vip-perspectives/2016/09/30/talk-python-to-me
<!-- [DocumentBodyStart:ced5a819-bc76-4b1e-b7a2-7f1197301f21] --><div class="jive-rendered-content"><p><a><img alt=" Talk Python to Me" src="/resources/statics/1291323/TalkPythonToMe_blog.jpg" style="float: left; padding: 2px 20px 8px 0px;" width="280"/></a></p><p>Recently I have started learning Python. Is it because the sky is falling? Have I handed my CCIE and CCDE plaque back to Chuck Robbins? Not yet&hellip;</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>People that know me know that I have a big hunger for learning things. I&#8217;ve been on the networking side for 10 years now, and I decided that I wanted to learn coding to be able to interact better with developers and system administrators. If I can understand their challenges, then I can use that as input into my designs in my roles as a network architect. The networking industry is changing, and we need to broaden our skill set. Does that mean we won&#8217;t need experts in the future? No. Does that mean everyone has to become a programmer? No. Learning to code, however, brings a lot of benefits and can help set you apart from the competition when applying for jobs.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>So why should someone learn Python?</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ul><li><strong>It&#8217;s easy.</strong> Python is a lot easier to code in than many languages. I never really enjoyed coding before because I found it complex and I didn&#8217;t get past the initial barrier to become comfortable with coding. With Python, the learning curve is much better and the code is more readable due to how it uses indentation.<br/><br/></li><li><strong>It helps you think programmatically.</strong> Learning Python has brought me back to my university days where I had to do a lot of programmatic thinking. To give you an example, I have used a Google class to learn Python, and it has mini scenarios or challenges like the following one:<br/><br/># B. front_x<br/># Given a list of strings, return a list with the strings<br/># in sorted order, except group all the strings that begin with 'x' first.<br/># e.g. ['mix', 'xyz', 'apple', 'xanadu', 'aardvark'] yields<br/># ['xanadu', 'xyz', 'aardvark', 'apple', 'mix']<br/># Hint: this can be done by making 2 lists and sorting each of them<br/># before combining them.<br/><br/>This kind of thinking about how to break tasks down into smaller components is very useful also for a network engineer. It&#8217;s a very good skill to have when troubleshooting networks as well as building them. The task is solved with the code below:</li></ul><p style="min-height: 8pt; padding: 0px; padding-left: 30px;">&nbsp;</p><!--[CodeBlockStart:e29c8a26-5fa2-464d-bbcb-768836a522e0][excluded]--><pre class="python" name="code">
def front_x(words):
&nbsp; x_list = []
&nbsp; other_list = []
&nbsp; for word in words:
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if word.startswith('x'):
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; x_list.append(word)
&nbsp;&nbsp;&nbsp; else:
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; other_list.append(word)
&nbsp; return sorted(x_list) + sorted(other_list)
</pre><!--[CodeBlockEnd:e29c8a26-5fa2-464d-bbcb-768836a522e0]--><div style="display:none;"></div><p style="padding-left: 30px;"><br/>First a function is defined with the def front_x where a list of words is input into the function. Two new lists are created and are empty at the beginning. A for loop is then used to iterate through the list and find words starting with &#8220;x&rdquo; and inserting them into the x_list. Words that do not start with &#8220;x&rdquo; are inserted into another list. The result is then returned by combining the two lists.</p><p style="padding-left: 30px;"><strong><br/></strong></p><ul><li><strong>It helps you study more efficiently for certifications.</strong> When studying for a certification, you will most likely have to do labs. Often some form of base topology and base configuration is used, and then each lab has unique configuration. By learning to code you can automate things like building the base topology and the base configuration. It&#8217;s also useful for things like building logical networks and advertising them into BGP. It&#8217;s tedious to create the configuration for 100 loopbacks and advertise them into BGP, but it can easily be done in Python with code, such as in the example below:</li></ul><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><!--[CodeBlockStart:a7fe137d-6d7c-4138-8b06-42d6bd123ca2][excluded]--><pre class="python" name="code">
for x in range(101):
&nbsp;&nbsp;&nbsp; print "interface loopback" + str(x)
&nbsp;&nbsp;&nbsp; print "ip address 1.1." + str(x) + ".1 255.255.255.0"
&nbsp;&nbsp;&nbsp; print "!"
print "router bgp 65000"
print "address-family ipv4 unicast"
for x in range(101):
&nbsp;&nbsp;&nbsp; print "network 1.1." +str(x) + ".0 mask 255.255.255.0"
</pre><!--[CodeBlockEnd:a7fe137d-6d7c-4138-8b06-42d6bd123ca2]--><div style="display:none;"></div><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ul><li><strong>It can be used to automate.</strong> Before you reach the level of automation, you must first understand how all the pieces fit together. You can&#8217;t automate what you don&#8217;t know. This goes back to my point that we still need people with expertise in something. You can start automating simple tasks like provisioning VLANs. Maybe that is something that takes a lot of time today when that time could be better spent on improving the network or learning new skills.</li></ul><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ul><li><strong>It&#8217;s fun.</strong> Coding is fun and there are amazing sites out there that will help you learn to code, such as CheckIO (<a class="jive-link-external-small" href="https://checkio.org/" rel="nofollow" target="_blank">https://checkio.org/</a>) where you solve puzzles and play games while learning how to code. How cool is that?! There are several other similar sites, and the Python community is really good, so there is definitely no issue in finding resources to learn how to code in Python.</li></ul><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>I hope I&#8217;ve inspired you to start coding. I know my code above might not be the prettiest, but it works and it&#8217;s more important to just start coding than being worried if it&#8217;s the most efficient code or not. See you around people!</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>====</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Note from Jennifer (Community Manager):</p><p>Earlier this year, Cisco Learning Network Premium released an introductory ten-part training video series on Python, one of the most popular programming languages in use today. To find out more about this series, check out Karlo's blog: <a class="jive-link-blog-small" data-containerId="3374" data-containerType="37" data-objectId="3747" data-objectType="38" href="https://learningnetwork.cisco.com/blogs/premium-updates/2016/03/28/introduction-to-python-programming">Introduction to Python Programming</a></p></div><!-- [DocumentBodyEnd:ced5a819-bc76-4b1e-b7a2-7f1197301f21] -->Fri, 30 Sep 2016 19:50:18 GMTbounce@learningnetwork.cisco.comhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2016/09/30/talk-python-to-me2016-09-30T19:50:18Z10 months 2 weeks ago180https://learningnetwork.cisco.com/blogs/vip-perspectives/comment/talk-python-to-mehttps://learningnetwork.cisco.com/blogs/vip-perspectives/feeds/comments?blogPost=3858Can I Use Certifications as Job Experience?https://learningnetwork.cisco.com/blogs/vip-perspectives/2016/08/31/can-i-use-certifications-as-job-experience
<!-- [DocumentBodyStart:4d854c58-571a-4a97-a571-f9db7da9e4db] --><div class="jive-rendered-content"><p><a><img alt="Optical Fiber Explained and Demystified" src="/resources/statics/1289670/CanIUseCertificationsAsJobExperience_blog.jpg" style="float: left; padding: 8px 20px 8px 0px;" width="290"/></a></p><p>The networking industry is a constantly evolving field that needs more and more talented people to start filling roles that are opening up. Even with this, it seems that without experience, it is still hard to break into the industry. This poses a very unique situation out there for people just starting their careers, but there are ways that, with some outside-the-box thinking, breaking into the field shouldn't be as daunting as it sounds.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>I was extremely fortunate enough to lead a discussion on using certifications as experience on your resume (<a class="jive-link-external-small cisco-google-tracker" href="https://www.netacadadvantage.com/prepare-for-work-blog/-/blogs/experiences-that-propel-your-career-webinar-series?_33_redirect=%2F" rel="nofollow" target="_blank" title="Session 2: Certifications as Experience">Session 2: Certifications as Experience</a>).&nbsp; If we take a step back and look at it from a high level, it makes a lot of sense to do this. During your studies you are building up topologies, breaking down protocols to see how they work, and troubleshooting along the way. This is everything an employer is looking for in a candidate for a junior/entry level position. In going through your certifications you go through a lot of what you would be asked to do at a job, which may include:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ul style="font-size: 14px;"><li>Working to solve a problem</li><li>Researching new technology</li><li>Building a network</li><li>Working in a team (if in a study group)</li></ul><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>Let&#8217;s take a look at the above bullet points more in depth.</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>Working to solve a problem</strong></p><p>How many times have you tried to follow along and implement OSPF or EIGRP, and for one reason or another, it didn&#8217;t turn out the way you read in a book or watched in a video? This is a great way to show that you were faced with a problem and the steps you took to solve it. Not only is this a learning experience on how to solve a problem, but it can also start you down the road to be an expert troubleshooter!</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>Researching New Technology</strong></p><p>When you are studying for a <a class="jive-link-external-small" href="/community/certifications" target="_blank" title="certification">certification</a>, you are in essence researching technology that is new to you. How you prepared for the test is a good way to demonstrate during an interview your ability to gather and apply information. This shows that you have the skills to pull in other resources when you may come across something that may be new to you.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>Building a Network</strong></p><p>This is one that a lot of people overlook. You may not know you have built and designed a network, but you have when studying for a certification test. This is a great way to showcase your familiarity with hardware components, such as why you choose to use a WIC-1T over an Ethernet connection. Have samples of topologies you built and, if asked, be able to say why you went with one style of connection over the other.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>Working on a team</strong></p><p>If you were involved in any study groups, this is a great way to show how you work in a team. If you led any discussions or presented anything for the group, this is a way to showcase your presenting skills, which in a networking role can be a plus if you are going to be presenting to clients or management.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Looking at how you can approach a certification test, you can use a lot of what you applied to get the certification as experience. The key to this is to highlight what you feel the job would be looking for that you achieved during your certification studies, and then you can segue into some of the other things that you may have done that are not on your resume.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Using certifications as job experience is only one piece of the puzzle. I was always taught to put anything on your resume that you came across more than once in your career in a &#8220;technical skills&rdquo; section. For instance, studying for your CCNA you learn technical skills like OSPF, EIGRP, RIP, and STP, just to name a few. You could put on your resume under technical skills what you learned from going through your certification studies. I think a lot of people overlook this, because they are not doing this in a corporate environment, and they think they can&#8217;t put it on their resume; but you can. You do have familiarity with it just in a different way than on-the-job learning.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Everyone&#8217;s mileage may be different with this approach. If I saw a resume like this come across my desk and I felt like they were a fit for the position, I would defiantly bring the candidate in and have a chat with them. It is good to know that when you think you have nothing for a resume with work experience, you can potentially include what you used for your certification studies as a way to try to break into the industry.</p></div><!-- [DocumentBodyEnd:4d854c58-571a-4a97-a571-f9db7da9e4db] -->Wed, 31 Aug 2016 21:17:05 GMTbounce@learningnetwork.cisco.comhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2016/08/31/can-i-use-certifications-as-job-experience2016-08-31T21:17:05Z11 months 2 weeks ago140https://learningnetwork.cisco.com/blogs/vip-perspectives/comment/can-i-use-certifications-as-job-experiencehttps://learningnetwork.cisco.com/blogs/vip-perspectives/feeds/comments?blogPost=3846Key Takeaways from CLUS2016https://learningnetwork.cisco.com/blogs/vip-perspectives/2016/08/03/key-takeaways-from-clus2016
<!-- [DocumentBodyStart:62f02c64-d304-467c-a431-c05469bdeb50] --><div class="jive-rendered-content"><p><a><img alt="Key Takeaways From CLUS2016" src="/resources/statics/1277905/KeyTakeawaysFromCLUS2016_blog.jpg" style="float: left; padding: 0px 20px 5px 0px;" width="280"/></a>Cisco Live US 2016 is in the books, and what a great event it was! Like every year, it&#8217;s a crazy intense week, and my week was filled with attending sessions, meeting people, doing interviews, and a lot more. I was happy to see a big gathering of both people from Cisco and Cisco VIP&#8217;s this year. From the Cisco side, I got to meet Karlo Bobiles for the first time. Matt and Brett were there and I also met with Raymond, Rigo, and Adam. All such great people!</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>I think this year also was the year with the most VIPs<span class="_Tgc">&#8212;</span>at least from the events I&#8217;ve been to. The Nordic region was well represented with me from Sweden, Riikka from Finland, and Mark from Denmark. Elvin was there, and I met with Steven, Erick, and Aref for the first time. All such cool and knowledgeable people!</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>For those that couldn&#8217;t make it this year, I hope to see you next year! There is a lot going on in the industry right now, and based on what I learned at CLUS, these are my key takeaways.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>You may have heard of the three monkeys from Japanese culture: &#8220;See no evil, hear no evil, speak no evil.&rdquo;</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>See no evil &#8211; Cisco Tetration Analytics</strong></p><p>We lack visibility in our networks today both for security and troubleshooting purposes. Packet capturing is difficult to do well and without impacting performance. We don&#8217;t have good tools outside of Wireshark to analyze traffic, and we lack the tools to do &#8220;what if&rdquo; scenarios and to replay an event that happened in our network. We don&#8217;t have storage or compute to analyze all the traffic, so we sample.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Cisco Tetration Analytics is a product that can use software sensors installed on an end host or hardware sensors based on the Nexus 9300 platform. It can process millions of flows per second and store billions of records for easy access. Every flow and every packet is monitored. The platform can provide information available to us today, such as how much data a flow consisted of, variations in IP/TCP flags, TTL of the packet, and so on. What is really nice, though, is the analytics part where you can test a policy to be deployed and see its effect on either recorded traffic or live traffic! You can search for a flow from the DB, and Tetration can also be used to generate a policy for an APIC, such as the one used in ACI. Tetration will give us insight into our networks that we didn&#8217;t have before.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>Hear no evil &#8211; Cisco Defense Orchestrator</strong></p><p>Much of networking security has been based on central security processing. Keeping policies in sync at different locations and on different devices has always been challenging. Cisco Defense Orchestrator is a cloud-based security policy management product that is used to establish and maintain a security posture by managing security policies across Cisco security devices.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>With the Defense Orchestrator, we don&#8217;t have to turn a deaf ear to security any longer. We can manage our ASA firewalls, ASA with FirePOWER and also the Umbrella Branch. This tool can configure these devices and check them for compliance. It can also give visibility into the top applications, top attacks, and top risks in your network. It also helps with onboarding new devices and finding errors in the configuration.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>Speak no evil &#8211; The rise of network automation</strong></p><p>Historically we have had very few methods of interacting with our network devices. There was Telnet, SSH, and in some cases HTTP and/or HTTPs, and that was it. That meant that we had to build complex scripts for automation and rely on screen scraping, which is not an efficient method in automating things, as it is error prone.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Based on what I experienced in Vegas, Cisco is taking network automation very seriously. They are both working on automating by using the APIC-EM, but more importantly, they are giving us options. We will be able to interact with our devices through Python, Netconf, YANG, API&#8217;s, or whatever makes sense to us. Options will be provided to us, and then we use what fits our business the best<span class="_Tgc">&#8212;</span>the way it should be. Gone are the days of writing Expect scripts and communicating over Telnet/SSH only.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>This can all seem a little scary, but I assure you that Cisco is not about to abandon all of the network engineers that have come up through their certification paths in the past. There will be paths to follow to become more versed in these technologies such as the Devnet community. Devnet was a huge success this year at Live!</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>This was definitely my best Live so far. I hope I have given you some insight into what is going on and I hope to see both new and old friends next year!</p></div><!-- [DocumentBodyEnd:62f02c64-d304-467c-a431-c05469bdeb50] -->Wed, 03 Aug 2016 15:02:25 GMTbounce@learningnetwork.cisco.comhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2016/08/03/key-takeaways-from-clus20162016-08-03T15:02:25Z1 year 2 weeks ago20https://learningnetwork.cisco.com/blogs/vip-perspectives/comment/key-takeaways-from-clus2016https://learningnetwork.cisco.com/blogs/vip-perspectives/feeds/comments?blogPost=3826DMVPN: The Importance of the Next-Hophttps://learningnetwork.cisco.com/blogs/vip-perspectives/2016/06/30/dmvpn-the-importance-of-the-next-hop
<!-- [DocumentBodyStart:82a8a5c9-b308-4684-b728-78e385a1377d] --><div class="jive-rendered-content"><p><a><img alt="Optical Fiber Explained and Demystified" src="/resources/statics/1277905/DMVPNTheImportanceOfTheNextHop_blog.jpg" style="float: left; padding: 8px 20px 8px 0px;" width="290"/></a></p><h1 style="color: #000000; font-weight: bold;">DMVPN Overview</h1><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Dynamic Multipoint Virtual Private Network (DMVPN) is a cost-efficient, scalable technology used to connect multiple sites together. DMVPN is a solution that comprises three main technologies:</p><ol><li style="font-size: 14px; margin-left: 296px;">Multipoint GRE tunnels</li><li style="font-size: 14px; margin-left: 296px;">NHRP</li><li style="font-size: 14px; margin-left: 296px;">IPsec.</li></ol><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>I will not focus on DMVPN configuration but rather on how Multipoint GRE tunnels and NHRP rely on the next-hop value in the routing table to form tunnels.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h1 style="color: #000000;">Simplifying DMVPN Operation</h1><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>A DMVPN network is comprised of hub and spoke routers. All spoke routers connect to at least one hub router. With this design, DMVPN basically operates in one of two models:</p><ol><li style="font-size: 14px;">hub-and-spoke</li><li style="font-size: 14px;">hub-and-spoke with spoke-to-spoke tunnels.</li></ol><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>With <strong>the hub-and-spoke model</strong>, all traffic passes through the hub router first using static point-to-point GRE tunnels. The hub examines each packet and forwards it to the appropriate spoke router. <strong>The hub-and-spoke model</strong> is also referred to as DMVPN Phase 1.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>The <strong>hub-and-spoke with spoke-to-spoke tunnels</strong> model allows traffic to flow between spokes directly using dynamic multipoint GRE tunnels. This is also referred to as DMVPN Phase 2 and Phase 3.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>NHRP and Multiprotocol GRE (mGRE) are the building blocks of these two models.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2 style="color: #000000;">mGRE</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Traditional GRE tunnels are point-to-point. With point-to-point tunnels there is only one endpoint (destination address) to the tunnel. mGRE tunnels allow for multiple tunnel endpoints to be established dynamically. This allows hub routers to create a tunnel towards each spoke router using a single tunnel interface. It also allows spoke routers to create a tunnel towards other spoke routers using a single tunnel interface.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2 style="color: #000000;">NHRP</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>For DMVPN to work, all of the DMVPN routers need to know who is participating in the DMVPN network. This is because mGRE tunnels do not have a preconfigured destination address. These addresses must be learned through some dynamic means.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>NHRP is responsible for creating Layer 3 to Layer 3 mappings. This is in contrast to ARP in Ethernet networks where it creates a Layer 2 to Layer 3 mapping. ARP maps a MAC address (Layer 2 address) to an IP address (Layer 3 address). NHRP maps the overlay (a Layer 3 address) to the underlay (a Layer 3 address).</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2 style="color: #000000;">Finding the Right Mapping</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>DMVPN is an overlay networking technology. Overlay networks are networks that are built on top of existing networks. In DMVPN, a router has an address that identifies it in the DMVPN network (overlay address) and an address that identifies it in the existing network (underlay address or NBMA address).&nbsp; A tunnel is formed using a DMVPN router&#8217;s underlying address. Figure 1 shows a simple example:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="font-style: italic;"><strong>Figure 1</strong></p><p><a href="/resources/statics/1277905/FIG_v2.jpg"><img alt="FIG.jpg" src="/resources/statics/1277905/FIG_v2.jpg" width="731"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>In this figure, R1 has an overlay address of 172.16.100.1 and an underlay address of 10.0.0.1. Likewise, R2 has an overlay address of 172.16.100.2 and an underlay address of 20.0.0.2. When R1 sends traffic (LAN-to-LAN or routing protocol) to R2&#8217;s overlay address, the original packet will have a source address of R1&#8217;s overlay address. This packet will be tunneled through the underlying network using GRE by adding a second IP header with the source of R1&#8217;s underlay address and the destination of R2&#8217;s underlay address. The underlying network will make forwarding decisions based on this outer header. Figure 2 shows the resultant packet.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="font-style: italic;"><strong>Figure 2</strong></p><p><a href="/resources/statics/1277905/Packet-Header2_v2.jpg"><img alt="Packet-Header2.jpg" src="/resources/statics/1277905/Packet-Header2_v2.jpg" width="766"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>How do R1 and R2 know each other&#8217;s underlay and overlay addresses? In our example, R1 is the NHS, and R2 will send a mapping of its overlay address to its underlay address to R1 using a NHRP register message. R1 now knows to what underlay address to build a tunnel when communicating with R2:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="color: #000000; font-size: 14.6667px; font-family: 'courier new', courier;">172.16.100.2/32 via 172.16.100.2</span></p><p dir="ltr"><span style="font-size: 14.6667px; font-family: 'courier new', courier; color: #000000;"> Tunnel0 created 00:29:38, expire 01:30:21</span></p><p dir="ltr"><span style="font-size: 14.6667px; font-family: 'courier new', courier; color: #000000;"> <span style="color: #ff0000;"><strong>Type: dynamic</strong></span>, Flags: unique registered</span></p><p dir="ltr"><span style="color: #000000; font-size: 14.6667px; font-family: 'courier new', courier;"> NBMA address: 20.0.0.2</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>That takes care of how R1 knows about R2, but how does R2 know about R1? The clients know about the NHS by configuring a static NHRP mapping for the NHS&#8217;s underlay and overlay addresses. On R2, this looks like this:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="color: #000000; font-size: 14.6667px; font-family: 'courier new', courier;">172.16.100.1/32 via 172.16.100.1</span></p><p dir="ltr"><span style="font-size: 14.6667px; font-family: 'courier new', courier; color: #000000;"> Tunnel0 created 00:31:07, never expire</span></p><p dir="ltr"><span style="font-family: 'courier new', courier; color: #000000;"><span style="font-size: 14.6667px;"> </span><span style="color: #ff0000; font-size: 14.6667px; font-weight: bold;">Type: static</span><span style="font-size: 14.6667px;">, Flags:</span></span></p><p dir="ltr"><span style="color: #000000; font-size: 14.6667px; font-family: 'courier new', courier;"> NBMA address: 10.0.0.1</span></p><p><span style="font-size: 14.6667px; font-family: Arial; color: #0070c0;"><br/></span></p><p dir="ltr" style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>In DMVPN, the hub router is configured as the NHS and the spokes are the clients. All spokes register with the hub when they first come up and send periodic registration messages to advertise their existence. The hub stores these registrations so it can forward NHRP resolution requests. Spokes send resolution requests to the hub to build a tunnel with another spoke.&nbsp; How do the spokes know what other spokes exist in the network?</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h1 style="color: #000000;">Routing: Supplying All the Information</h1><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>There are two ways for the spokes to learn of other spokes and form spoke-to-spoke tunnels. First, the hub can send its entire NHRP mapping table to each spoke in periodic messages. This creates two problems:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>1) This creates more control plane traffic as spokes are added or withdrawn from the network, which impacts the solution's ability to scale.</p><p>2) Some spokes may never need to communicate directly. This would be wasted resources on the network because the hub advertises information the spoke does not need. Likewise, the spoke must store or drop information it will not use.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>The alternative way is for a spoke to ask for the mapping whenever it needs to form a spoke-to-spoke tunnel. With this method, the hub only floods information that is relevant to the spoke and the spoke only stores information it needs to forward the traffic. This is done through NHRP resolution messages.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>How do the spokes know when they need to form a spoke-to-spoke tunnel?</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2 style="color: #000000;">The Importance of the Next-Hop</h2><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>DMVPN is powered by the routing table. This is less evident on the hub router, because the spokes announce themselves to it. However, the spokes do not announce themselves to each other. The routing table contains the information about the next-hop router used to reach a prefix. It is this information that triggers tunnel formation.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Let&#8217;s expand on our network from before...</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="font-style: italic;"><strong>Figure 3</strong></p><p><a href="/resources/statics/1277905/MainTopology2_v2.jpg"><img alt="MainTopology2.jpg" src="/resources/statics/1277905/MainTopology2_v2.jpg" width="620"/></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>In Figure 3, R1 is the hub router. Each spoke router has a network behind it in the 192.168.0.0/16 range. These networks contain hosts that need to communicate with each other over the DMVPN network. Routing has already been configured using EIGRP as the protocol that advertises the prefixes into the DMVPN network.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>In DMVPN, all spokes form routing adjacencies with the hub router. Spoke routers do not form routing adjacencies with each other. Thus, all routing information is relayed by the hub. <strong>The different DMVPN models and phases are distinguished by whether or not the next-hop value is preserved when advertised from the hub to the spokes.</strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ul><li style="font-size: 14px;">Phase 1 - Next-hop is not preserved by the hub</li><li style="font-size: 14px;">Phase 2 and 3 - Next-hop is preserved by the hub</li></ul><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>If the topology in Figure 3 is purely a <strong>hub-and-spoke</strong> DMVPN network, R2&#8217;s routing table would look like this:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="color: #000000; font-size: 14.6667px; font-family: 'courier new', courier;">R2#sh ip route eigrp</span></p><p dir="ltr"><span style="font-family: 'courier new', courier; color: #000000;"><span style="font-size: 14.6667px;">D&nbsp;&nbsp;&nbsp; 192.168.10.0/24 [90/27008000] via </span><span style="color: #ff0000; font-size: 14.6667px; font-weight: bold;">172.16.100.1</span><span style="font-size: 14.6667px;">, 00:00:10, Tunnel0</span></span></p><p dir="ltr"><span style="font-family: 'courier new', courier; color: #000000;"><span style="font-size: 14.6667px;">D&nbsp;&nbsp;&nbsp; 192.168.30.0/24 [90/28288000] via </span><span style="color: #ff0000; font-size: 14.6667px; font-weight: bold;">172.16.100.1</span><span style="font-size: 14.6667px;">, 00:00:10, Tunnel0</span></span></p><p dir="ltr"><span style="font-family: 'courier new', courier; color: #000000;"><span style="font-size: 14.6667px;">D&nbsp;&nbsp;&nbsp; 192.168.40.0/24 [90/28288000] via </span><span style="color: #ff0000; font-size: 14.6667px; font-weight: bold;">172.16.100.1</span></span><span style="color: #000000; font-size: 14.6667px; font-family: 'courier new', courier;">, 00:00:10, Tunnel0</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Notice how the next-hop value for each prefix is R1, the hub router. This means whenever R2 sends a packet to one of the 192.168.0.0/16 networks, it will use R1 as the next-hop. This triggers it to look in its NHRP mapping table to find the appropriate underlay address for R1&#8217;s overlay address. The packet will go to the hub. The hub will examine it. Then the hub will forward it to the appropriate destination.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>In order for R2 to build a spoke-to-spoke tunnel, the next-hop value of the received prefixes needs to be the overlay address of the spoke that originated the prefix. So in a <strong>hub-and-spoke with spoke-to-spoke tunnels</strong> model, R2&#8217;s routing table should look like this:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="color: #000000; font-size: 14.6667px; font-family: 'courier new', courier;">R2#sh ip route eigrp</span></p><p dir="ltr"><span style="font-family: 'courier new', courier; color: #000000;"><span style="font-size: 14.6667px;">D&nbsp;&nbsp;&nbsp; 192.168.10.0/24 [90/27008000] via </span><span style="color: #ff0000; font-size: 14.6667px; font-weight: bold;">172.16.100.1</span><span style="font-size: 14.6667px;">, 00:00:06, Tunnel0</span></span></p><p dir="ltr"><span style="font-family: 'courier new', courier; color: #000000;"><span style="font-size: 14.6667px;">D&nbsp;&nbsp;&nbsp; 192.168.30.0/24 [90/28288000] via </span><span style="color: #ff0000; font-size: 14.6667px; font-weight: bold;">172.16.100.3</span><span style="font-size: 14.6667px;">, 00:00:06, Tunnel0</span></span></p><p dir="ltr"><span style="font-family: 'courier new', courier; color: #000000;"><span style="font-size: 14.6667px;">D&nbsp;&nbsp;&nbsp; 192.168.40.0/24 [90/28288000] via </span><span style="color: #ff0000; font-size: 14.6667px; font-weight: bold;">172.16.100.4</span></span><span style="color: #000000; font-size: 14.6667px; font-family: 'courier new', courier;">, 00:00:06, Tunnel0</span></p><p dir="ltr" style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Whenever R2 needs to send traffic to R3&#8217;s 192.168.30.0/24 network, the prefix in its routing table points towards R3&#8217;s overlay address. R2 then looks at its NHRP mapping for the appropriate underlay address for R3 only to find that it does not have an entry. R2 can request mapping information from the hub using an NHRP resolution request. This gets forwarded to R3 who replies directly to R2. The resulting NHRP mapping table on R2 looks like this:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p dir="ltr"><span style="color: #000000; font-size: 14.6667px; font-family: 'courier new', courier;">R2#sh ip nhrp</span></p><p dir="ltr"><span style="font-size: 14.6667px; font-family: 'courier new', courier; color: #000000;">172.16.100.1/32 via 172.16.100.1</span></p><p dir="ltr"><span style="font-size: 14.6667px; font-family: 'courier new', courier; color: #000000;"> Tunnel0 created 00:00:44, never expire</span></p><p dir="ltr"><span style="font-size: 14.6667px; font-family: 'courier new', courier; color: #000000;"> Type: static, Flags: used</span></p><p dir="ltr"><span style="font-size: 14.6667px; font-family: 'courier new', courier; color: #000000;"> NBMA address: 10.0.0.1</span></p><p dir="ltr"><span style="font-size: 14.6667px; font-family: 'courier new', courier; color: #000000;">--- omitted ---</span></p><p dir="ltr"><span style="font-size: 14.6667px; font-family: 'courier new', courier; color: #000000;">172.16.100.3/32 via 172.16.100.3</span></p><p dir="ltr"><span style="font-size: 14.6667px; font-family: 'courier new', courier; color: #000000;"> Tunnel0 created 00:00:29, expire 01:59:30</span></p><p dir="ltr"><span style="font-size: 14.6667px; font-family: 'courier new', courier; color: #000000;"> Type: dynamic, Flags: router used</span></p><p dir="ltr"><span style="color: #000000; font-size: 14.6667px; font-family: 'courier new', courier;"> NBMA address: 30.0.0.3</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h1 style="color: #000000;">Conclusion</h1><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>It is the next-hop value that triggers tunnel creation.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>In DMVPN Phase 1, only hub-and-spoke tunnels exist. The next hop for all spoke-to-spoke traffic must be the hub router. Since all traffic goes through the hub, it is common for the hub to simply flood a default route to the spokes.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>In DMVPN Phase 2 and Phase 3, dynamic spoke-to-spoke tunnels exist. The next-hop for each prefix needs to be the spoke that originated the prefix. This triggers the spokes to resolve the appropriate underlay address and ultimately build the spoke-to-spoke tunnel.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>When designing DMVPN networks, this fact must be kept in mind and proper IGP tuning must be made so these requirements are met. There are also many other optimizations that can be implemented to ease the burden on the hub and spoke routers. I plan on going into details on this in a later blog post.</p></div><!-- [DocumentBodyEnd:82a8a5c9-b308-4684-b728-78e385a1377d] -->Thu, 30 Jun 2016 22:37:48 GMTbounce@learningnetwork.cisco.comhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2016/06/30/dmvpn-the-importance-of-the-next-hop2016-06-30T22:37:48Z1 year 1 month ago290https://learningnetwork.cisco.com/blogs/vip-perspectives/comment/dmvpn-the-importance-of-the-next-hophttps://learningnetwork.cisco.com/blogs/vip-perspectives/feeds/comments?blogPost=3811A Brief History of Network Virtualizationhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2016/06/10/a-brief-histroy-of-network-virtualization
<!-- [DocumentBodyStart:2b12a14d-4175-4d61-b271-4e4de1afcf4d] --><div class="jive-rendered-content"><p><a><img alt="Optical Fiber Explained and Demystified" src="/resources/statics/1274063/ABriefHistoryOfNetworkVirtualization_blog.jpg" style="float: left; padding: 8px 20px 8px 0px;" width="290"/></a></p><p><span style="color: #00000a; font-size: 10.0pt; font-family: 'Arial','sans-serif';"><strong>What is &#8220;virtual&rdquo; &#8211; not reality?</strong></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="margin-bottom: .0001pt;"><span style="font-size: 10.0pt; font-family: 'Arial','sans-serif';">This idea could launch a philosophical discussion. It harkens back to Rene Descartes proving his very being with the proclamation: "I think, therefore I exist" (&#8220;Cogito, ergo sum&rdquo;) and laying the groundwork for further proof of the surrounding material world and the necessary connectivity of "things" (or metaphysics). </span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a class="jive-link-external-small" href="https://en.wikipedia.org/wiki/Meditations_on_First_Philosophy" rel="nofollow" target="_blank">https://en.wikipedia.org/wiki/Meditations_on_First_Philosophy</a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-size: 10.0pt; font-family: 'Arial','sans-serif'; color: #00000a;">Webster's defines &#8220;virtual&rdquo; as "very close to being something without actually being it." </span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-size: 10.0pt; font-family: 'Arial','sans-serif'; color: #00000a;">Virtualization sprang from computing as far back as the 60's describing methods of logical system resource division among different applications in mainframes. It has since grown to encompass a variety of computing concepts, such as software virtualization, database virtualization, storage virtualization, network virtualization, etc. In the early 90&#8217;s, virtual reality (considered by many to be the holy grail of computing) was popularized in the movie "Lawn Mower Man." However, the concept can be traced back to Charles Wheatstone's stereoscope research in 1838, which demonstrated that the brain processes individual two dimensional images as a single three dimensional image, albeit with the aid of a stereoscope. In the present day, think Imax, Google Cardboard, or Oculus Rift.</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a class="jive-link-external-small" href="https://en.wikipedia.org/wiki/Virtualization" rel="nofollow" target="_blank">https://en.wikipedia.org/wiki/Virtualization</a></p><p><a class="jive-link-external-small" href="http://www.vrs.org.uk/virtual-reality/history.html" rel="nofollow" target="_blank">http://www.vrs.org.uk/virtual-reality/history.html</a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="margin-bottom: .0001pt;"><span style="font-size: 10.0pt; font-family: 'Arial','sans-serif';">Network Virtualization is not a concept born yesterday. Consider that in 1981 Dr. David Sincoskie was busy experimenting with segmenting voice over Ethernet broadcast networks with tagging before Radia Perlman had even invented the Spanning Tree Protocol in 1985 to facilitate fault tolerance and redundant paths. It wasn't until 1990 that the IEEE adopted 802.1D, and it wasn&#8217;t until 1998 that 802.1Q was ratified. By the turn of the century, switched networks dominated the landscape, supplanting the reliance on hubs, repeaters, and bridges and making virtual LANs (VLANs) commonplace.</span><span style="font-size: 10.0pt; font-family: 'Arial','sans-serif'; color: #ff3333;"> </span>A LAN without VLANs is virtually unthinkable nowadays.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a class="jive-link-external-small" href="https://standards.ieee.org/findstds/standard/802.1D-1990.html" rel="nofollow" target="_blank">https://standards.ieee.org/findstds/standard/802.1D-1990.html</a></p><p><a class="jive-link-external-small" href="https://www.google.com/url?sa=t&amp;rct=j&amp;q=&amp;esrc=s&amp;source=web&amp;cd=10&amp;ved=0ahUKEwi0_qWu1ZHNAhUMRyYKHWP9CAMQFghTMAk&amp;url=http%3A%2F%2Fsupport.kharkiv.ukrtelecom.ua%2Flib%2F802.1Q-1998.pdf&amp;usg=AFQjCNEogjL25f3b2KP7zg-jg7SEWZ-VaQ&amp;sig2=dsT-rHEOPLk6wXtpjoHXHg&amp;cad=rja" rel="nofollow" target="_blank">IEEE Std 802.1Q-1998 Virtual Bridged Local Area Networks</a></p><p><a class="jive-link-external-small" href="https://en.wikipedia.org/wiki/Virtual_LAN" rel="nofollow" target="_blank">https://en.wikipedia.org/wiki/Virtual_LAN</a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>A Router is Born</strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><span style="font-size: 10.0pt; font-family: 'Arial','sans-serif'; color: #00000a;">Widely considered the first router, BBN developed the Interface Message Processor (IMP) in the late 60's for the ARPANET. Bill Yeager developed a multiprotocol router at Stanford in 1980 while DEC was building "Fuzzballs," or routers supporting the internet's infancy with software developed by David Mills, the creator of Network Time Protocol (NTP) and Exterior Gateway Protocol (EGP). Later, Len Bosack and Sandy Lerner, who had been researchers at Stanford, founded Cisco and produced their first multiprotocol router Advanced Gateway Server (AGS) which shipped in 1986. In 1993 Cisco presented their first successful enterprise multiprotocol router, the 7000 series, and later would begin to supply switches as well.</span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a class="jive-link-external-small" href="http://www.networkworld.com/article/2870329/lan-wan/evolution-of-the-router.html#slide1" rel="nofollow" target="_blank">http://www.networkworld.com/article/2870329/lan-wan/evolution-of-the-router.html#slide1</a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>Virtual Circuits</strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>X.25, Frame Relay and ATM merit a brief mention as these legacy protocols carry either SVC's or PVC's (Switched Virtual Circuits, Permanent Virtual Circuits) typically supplied by providers over purchased dedicated media for WAN connectivity. All are considered packet switching technologies, however X.25 provides SVC's, Frame Relay provides PVC's and ATM may supply either. Although no longer commonly used, in their day these protocols were at the forefront of WAN virtualization.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a class="jive-link-external-small" href="https://en.wikipedia.org/wiki/Packet_switching" rel="nofollow" target="_blank">https://en.wikipedia.org/wiki/Packet_switching</a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>Virtual Interfaces</strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Interfaces derived from software that have no physical properties on their own are of course, virtual.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Loopbacks- There is a long history of loopbacks used in electronics, typically the routing of electronic signals back to the source for testing purposes. In networking the IETF made reference to the reserved address range "127.rrr.rrr.rrr" in 1981 with RFC 790 which also outlined 32 bit address space classes. In 1986 with RFC 990 the address range 127.rrr.rrr.rrr was officially dubbed "loopback". This number would lead to localhost assignment in computer networking, ie, it refers to the tcp/ip protocol stack of your device.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "The class A network number 127 is assigned the "loopback"<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; function, that is, a datagram sent by a higher level protocol<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to a network 127 address should loop back inside the host.&nbsp; No<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; datagram "sent" to a network 127 address should ever appear on</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; any network anywhere."</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>The loopback would eventually be adopted by networking devices as an assignable/addressable virtual interface used for testing, routing, identification, filtering, and so on.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Other virtual interfaces include SVI's, null, tunnel, and subinterfaces, to name a few.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a class="jive-link-external-small" href="https://tools.ietf.org/html/rfc990" rel="nofollow" target="_blank">https://tools.ietf.org/html/rfc990</a></p><p><a class="jive-link-external-small" href="http://www.cisco.com/c/en/us/td/docs/ios/12_4/interface/configuration/guide/inb_virt.html#wp1053140" rel="nofollow" target="_blank">http://www.cisco.com/c/en/us/td/docs/ios/12_4/interface/configuration/guide/inb_virt.html#wp1053140</a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>VPN</strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>The acronym VPN, Virtual Private Network, describes a multitude of techniques used to accomplish a similar idea; a protected tunnel through publicly accessible internet media connecting two or more devices. This could take a variety of forms such as Site-to-Site VPN, SSL VPN,PPTP VPN, L2TP VPN, IPSEC VPN, MPLS VPN, etc.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a class="jive-link-external-small" href="http://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-18/what-is-a-vpn.html" rel="nofollow" target="_blank">http://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-18/what-is-a-vpn.html</a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>VRF</strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>VRF (Virtual Route Forwarding) is used to create separate and private ip routing tables within one or more routers. Consider the routing tables as individual and protected, accessible only by entities that are explicitly members of the routing table. Multiple routing tables are supported within a single router and can contain the same ip address scheme that will not overlap due to the division of routing table space. VRF is most often associated with MPLS, however Cisco has an implementation called VRF-Lite that functions without the need for Multi-Protocol Label Switching. Most manufacturers now ship devices with an&nbsp; interface vrf built in to provide dedicated OOB (Out-of-band) management, keeping the management traffic distinctly separate from the Control and Data Planes.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a class="jive-link-external-small" href="https://en.wikipedia.org/wiki/Virtual_routing_and_forwarding" rel="nofollow" target="_blank">https://en.wikipedia.org/wiki/Virtual_routing_and_forwarding</a></p><p><a class="jive-link-external-small" href="http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/25ew/configuration/guide/conf/vrf.html" rel="nofollow" target="_blank">http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/25ew/configuration/guide/conf/vrf.html</a></p><p><a class="jive-link-external-small" href="http://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/4649-mpls-faq-4649.html" rel="nofollow" target="_blank">http://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/4649-mpls-faq-4649.html</a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>SVI</strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>For switched networks, a Switched Virtual Interface (interface VLAN) is a method of assembling 1 or more layer 2 ports into a broadcast domain bounded by an ip address. This allows for layer 3 processing between switches with similarly configured port members, routing between VLANS, Gateway IP's for clients and layer 3 switch administration.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a class="jive-link-external-small" href="http://www.cisco.com/c/en/us/support/docs/lan-switching/inter-vlan-routing/41260-189.html" rel="nofollow" target="_blank">http://www.cisco.com/c/en/us/support/docs/lan-switching/inter-vlan-routing/41260-189.html</a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>Port Aggregation</strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Combining a number of physical ports into a port-channel has the benefit of increasing the bandwidth of the resulting single logical interface by the sum of its members, limiting the impact of STP, improving redundancy and providing a means for load balancing. The link Aggregation Control Protocol ratified in 2000 by the IEEE as 802.3ad, the open standard, has since become the defacto standard.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a class="jive-link-external-small" href="https://www.google.com/url?sa=t&amp;rct=j&amp;q=&amp;esrc=s&amp;source=web&amp;cd=5&amp;cad=rja&amp;uact=8&amp;ved=0ahUKEwjYx_DVxpPNAhWBOCYKHfMGAg0QFgg8MAQ&amp;url=http%3A%2F%2Fcs.uccs.edu%2F~scold%2Fdoc%2Flinkage%2520aggregation.pdf&amp;usg=AFQjCNFUfCWNWxhw8Mbbf-YO_EwTkgiDgw&amp;sig2=BWRFYiSNYw6QWmZ7vJEfTA&amp;bvm=bv.123664746,d.eWE" rel="nofollow" target="_blank"><cite><span style="font-style: normal;">cs.uccs.edu/~scold/doc/linkage%20aggregation.pdf</span></cite></a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>Physically Two (or more), Logically One</strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>With the various switch stacking techniques available today a number of switches may be grouped together with a single managed ip address thus making two or more fixed switches appear as a single network switch, as in a chassis switch with multiple line cards. Virtualization is carried yet further with techniques such as Virtual Switch System, whereby core switches act as one network element, reducing routing neighbors and providing a loop-free Layer 2 topology, as well as sharing control plane information and data traffic. VSS is a significant stride toward the elimination of Spanning-Tree in a redundant network.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a class="jive-link-external-small" href="http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-virtual-switching-system-1440/prod_qas0900aecd806ed74b.html" rel="nofollow" target="_blank">http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-virtual-switching-system-1440/prod_qas0900aecd806ed74b.html</a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><strong>High Availability</strong></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>High availability is often the goal with network virtualization techniques, aiming to increase operational performance, fault tolerance, reduce downtime and eliminate single points of failure. VRRP, HSRP and GLBP are First Hop Redundancy Protocols designed to keep client gateways less fallible. HA is often improved greatly with virtualization between like devices using active/standby, active/active, failover, and layer 2/layer3 table maintenance mechanisms via virtualized and aggregated links.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a class="jive-link-external-small" href="http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/HA_campus_DG/hacampusdg.html" rel="nofollow" target="_blank">http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/HA_campus_DG/hacampusdg.html</a></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Network virtualization is accomplished with software logically simulating its hardware platform. "It is very close to being something, without actually being it." However, there is an idea near at hand-the complete decoupling of the control and data planes that will offer a centralized view of the network, affectionately referred to as Software Defined Networking.</p></div><!-- [DocumentBodyEnd:2b12a14d-4175-4d61-b271-4e4de1afcf4d] -->virtualizationFri, 10 Jun 2016 20:33:04 GMTbounce@learningnetwork.cisco.comhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2016/06/10/a-brief-histroy-of-network-virtualization2016-06-10T20:33:04Z1 year 2 months ago200https://learningnetwork.cisco.com/blogs/vip-perspectives/comment/a-brief-histroy-of-network-virtualizationhttps://learningnetwork.cisco.com/blogs/vip-perspectives/feeds/comments?blogPost=3796Optical Fiber Explained and Demystifiedhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2016/05/05/optical-fiber-explained-and-demystified
<!-- [DocumentBodyStart:fd83bbb9-b0fe-490e-8220-6ce19a4b1be4] --><div class="jive-rendered-content"><p><a><img alt="Optical Fiber Explained and Demystified" src="/resources/statics/1255180/OpticalFiberExplainedandDemystified_blog.jpg" style="float: left; padding: 8px 20px 8px 0px;" width="290"/></a></p><h1>Introduction</h1><p>In today&#8217;s networks, it is almost impossible to find a network professional who has never been in touch with fiber-based links between switches, routers, or other network devices. The widespread use of fibers makes a lot of sense, since a single strand of fiber can provide very high capacity.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Some of the first commercial fiber links were deployed in the mid-1970&#8217;s and operated at 45 Mbit/sec. Since then, research and development has allowed a single strand of fiber to carry in excess of 100 Terabits/sec. Although these kinds of speeds may not be commercially available today, it proves that fiber-based communication is the best bet we have in terms of providing the ever-rising need of more bandwidth in the future.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>The laws of physics also apply to the world of fiber optic transmission, meaning there is a whole lot of theory behind it. Since I don&#8217;t have unlimited space for this blog, I can&#8217;t go into all the details (and to be honest I think the majority of readers don&#8217;t care &#8211; as long as the link is up, it&#8217;s all good, right?). Instead, I&#8217;ll focus on the more common topics, specifically on the primary differences between multimode and singlemode fibers.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>Types of fibers</h2><p>Overall, there are two types of fiber optic cables available: multimode and singlemode, with both types having a number of subtypes. Multimode fiber cables are generally categorized in five different types:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><ul style="font-size: 14px; list-style-type: disc;"><li><strong>FDDI-grade:</strong> This type was among the first types of fiber cables that became widely deployed for LAN use.</li><li><strong>OM1:</strong> Supports slightly higher bandwidths compared to FDDI-grade cables, allowing slightly longer reach.</li><li><strong>OM2:</strong> The core of the fiber cable was shrunk to 50 microns as opposed to the 62.5 microns used in FDDI/OM1 type cables. This allows better control over light propagation inside the cables allowing longer reach.</li><li><strong>OM3: </strong>This (and OM4) types of cables are optimized for lasers (called VCSEL&#8217;s) and provides even higher bandwidth.</li><li><strong>OM4:</strong> Adds even more bandwidth, allowing longer reaches compared to OM3 fibers.</li></ul><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>The mentioning of bandwidth above is not related to the bandwidth of the circuit sent over the fiber link. It refers to the modal bandwidth, which is a key characteristic of multimode fibers. In short, it is an expression of how much information can be carried at a given wavelength. Going too much into detail is well outside the scope of this blog, but as is almost always the case, higher bandwidth <strong>is</strong> better.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Talking about singlemode, there are two subtypes of singlemode cables available: OS1 and OS2. Both have a core diameter of 8-9 microns. The difference lies in the attenuation profile of the cable, where OS2 cables have considerably lower attenuation than OS1 cables. The applications supported by the two types are identical &#8211; it is a matter of the distance over which they can do it. Typically, OS1 cables are used for internal cabling, while OS2 cables have found their primary use in outdoor applications, such as fibers in the ground. However, OS2 can also be used for internal cabling if desired.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>Link speeds and link length</h2><p>Compared to singlemode fibers, multimode technology is usually cheaper to implement, not so much because of the fiber cable itself, but because multimode transceivers for your switches or routers are cheaper. And here comes the &#8220;but&rdquo;: There is a trade-off &#8211; the supported link length is nowhere near what singlemode transceivers can provide. The following table gives you an idea of the maximum supported length at different speeds on the different available multimode fiber types. I&#8217;ve used various Ethernet speeds and standards (all distances are in meters).</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><table border="1px" class="jiveBorder" jive-data-cell="{&quot;color&quot;:&quot;#575757&quot;,&quot;textAlign&quot;:&quot;left&quot;,&quot;padding&quot;:&quot;2&quot;,&quot;backgroundColor&quot;:&quot;transparent&quot;,&quot;fontFamily&quot;:&quot;arial,helvetica,sans-serif&quot;,&quot;verticalAlign&quot;:&quot;baseline&quot;}" jive-data-header="{&quot;color&quot;:&quot;#FFFFFF&quot;,&quot;backgroundColor&quot;:&quot;#5B9BD5&quot;,&quot;textAlign&quot;:&quot;left&quot;,&quot;padding&quot;:&quot;2&quot;,&quot;fontFamily&quot;:&quot;arial,helvetica,sans-serif&quot;,&quot;verticalAlign&quot;:&quot;baseline&quot;}" style="border: 1px solid #5b9bd5; width: 80%;"><thead><tr><th style="border:1pxpx solid black;border: 1px solid #5b9bd5;background-color: #5b9bd5;width: 250px;padding: 2px;color: #ffffff;text-align: left;" valign="middle"><strong>Link type</strong></th><th style="border:1pxpx solid black;border: 1px solid #5b9bd5;background-color: #5b9bd5;padding: 2px;color: #ffffff;text-align: left;" valign="middle"><strong>FFDI</strong></th><th style="border:1pxpx solid black;border: 1px solid #5b9bd5;background-color: #5b9bd5;padding: 2px;color: #ffffff;text-align: left;" valign="middle"><strong>OM1</strong></th><th style="border:1pxpx solid black;border: 1px solid #5b9bd5;background-color: #5b9bd5;padding: 2px;color: #ffffff;text-align: left;" valign="middle"><strong>OM2</strong></th><th style="border:1pxpx solid black;border: 1px solid #5b9bd5;background-color: #5b9bd5;padding: 2px;color: #ffffff;text-align: left;" valign="middle"><strong>OM3</strong></th><th style="border:1pxpx solid black;border: 1px solid #5b9bd5;background-color: #5b9bd5;padding: 2px;color: #ffffff;text-align: left;" valign="middle"><strong>OM4</strong></th></tr></thead><tbody><tr style="background-color: #deeaf6;"><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">1G (1000Base-SX)</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">220</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">275</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">550</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">1000</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">1000</td></tr><tr><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">10G (10GBase-SR)</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">26</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">33</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">82</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">300</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">400</td></tr><tr style="background-color: #deeaf6;"><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">40G (40GBASE-SR4)</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">-</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">-</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">-</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">100</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">150</td></tr><tr><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">100G (100GBASE-SR10)</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">-</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">-</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">-</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">100</td><td style="border:1pxpx solid black;border: 1px solid #5b9bd5;padding: 2px;">150</td></tr></tbody></table><p><span style="font-size: 10.0pt;"><em>&#8220;-&#8220; means not supported</em></span></p><p><span style="font-size: 10.0pt;"><em><br/></em></span></p><p>The numbers shown in the table are guaranteed to work as per the various Ethernet specifications &#8211; it is likely that real-world implementations can go beyond the stated numbers. Just remember that links exceeding these numbers will be out-of-specification.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>You might also notice that the supported length for 40G and 100G are the same despite the higher bandwidth. The explanation for this is simple: 40GBASE-SR4 transmits the signal using four 10G lanes and 100GBASE-SR10 transmits 10 10G lanes, hence the SR<strong>4</strong> and SR<strong>10</strong> in the standards name.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>For singlemode fiber, you&#8217;ll notice there&#8217;s no difference between OS1 and OS2 cables in terms of supported lengths, but also that there are different standards for each link length.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><table border="1" class="jiveBorder" jive-data-cell="{&quot;color&quot;:&quot;#575757&quot;,&quot;textAlign&quot;:&quot;left&quot;,&quot;padding&quot;:&quot;2&quot;,&quot;backgroundColor&quot;:&quot;transparent&quot;,&quot;fontFamily&quot;:&quot;arial,helvetica,sans-serif&quot;,&quot;verticalAlign&quot;:&quot;baseline&quot;}" jive-data-header="{&quot;color&quot;:&quot;#FFFFFF&quot;,&quot;backgroundColor&quot;:&quot;#5B9BD5&quot;,&quot;textAlign&quot;:&quot;left&quot;,&quot;padding&quot;:&quot;2&quot;,&quot;fontFamily&quot;:&quot;arial,helvetica,sans-serif&quot;,&quot;verticalAlign&quot;:&quot;baseline&quot;}" style="border: 1px solid #5b9bd5; width: 50%;"><thead><tr><th style="border:1px solid black;border: 1px solid #5b9bd5;background-color: #5b9bd5;width: 53%;padding: 2px;color: #ffffff;text-align: left;" valign="middle"><strong>Link type</strong></th><th style="border:1px solid black;border: 1px solid #5b9bd5;background-color: #5b9bd5;padding: 2px;color: #ffffff;text-align: left;" valign="middle"><strong>OS1</strong></th><th style="border:1px solid black;border: 1px solid #5b9bd5;background-color: #5b9bd5;padding: 2px;color: #ffffff;text-align: left;" valign="middle"><strong>OS2</strong></th></tr></thead><tbody><tr><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">1G (1000Base-LX)</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">10 km</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">10 km</td></tr><tr><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">1G (1000Base-EX)</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">40 km</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">40 km</td></tr><tr><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">1G (1000Base-ZX)</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">70 km</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">70 km</td></tr><tr><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">10G (10GBASE-LR)</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">10 km</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">10 km</td></tr><tr><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">10G (10GBASE-ER)</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">40 km</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">40 km</td></tr><tr><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">10G (10GBASE-ZR)</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">80 km</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">80 km</td></tr><tr><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">40G (40GBASE-LR4)</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">10 km</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">10 km</td></tr><tr><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">40G (40GBASE-FR)</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">2 km</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">2 km</td></tr><tr><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">100G (100GBASE-LR4)</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">10 km</td><td style="border:1px solid black;border: 1px solid #5b9bd5;padding: 2px;">10 km</td></tr></tbody></table><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Note the 40GBASE-FR standard, which only supports link lengths of 2 km. This is because this standard transmits the entire 40G signal at a single lane, making it easier to integrate into DWDM systems. It requires lasers that are much more expensive, and it is likely that its primary use is with service providers.</p><p>The extended reach (meaning those exceeding 10 km in supported link length) uses a different wavelength (1550 nm) compared to the &#8220;standard&rdquo; length (1310 nm). This is because the attenuation inside a fiber is a function of the wavelength as illustrated in the graph below:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3774-319485/pastedImage_1.png"><img alt="" class="jive-image image-1" height="344" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3774-319485/pastedImage_1.png" style="max-width:421px; max-" width="421"/></a></p><p><span style="font-size: 10.0pt;"><em><span>Image source: </span><a class="jive-link-external-small" href="http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/white_paper_c11-463661.html" rel="nofollow" target="_blank">http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/white_paper_c11-463661.html</a></em></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>As shown in the graph, advances and innovation in fiber cables over the years have resulted in much lower attenuation/loss compared to what was available in the beginning of the optical era.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Now it is time to dive a bit into why singlemode fiber is superior to multimode fiber, at least when it comes to supported link lengths. As suggested by the name, multimode fiber has multiple modes/propagation paths inside the fiber, which relates to how the light is fed into the fiber. For multimode uses, there are two primary light sources used in transceivers: LED and Vertical Cavity Surface Emitting Laser (VCSEL). Typically, LED&#8217;s are used in 100 Mbit Fast Ethernet transceivers, while VCSELs are used in virtually anything else with a higher link speed. The difference is how the light is emitted from the source. Consider the following illustration:</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3774-319486/pastedImage_3.png"><img alt="" class="jive-image image-2" height="539" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3774-319486/pastedImage_3.png" style="width: auto; height: auto; display: block; margin-left: auto; margin-right: auto;" width="428"/></a></p><p><span style="font-size: 10.0pt;"><em><span>Source: </span><a class="jive-link-external-small" href="http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/white_paper_c11-463661.html" rel="nofollow" target="_blank">http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/white_paper_c11-463661.html</a></em></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>With the large apertures of the LED and VCSEL combined with the large core of the multimode fiber, light emitted from the LED/laser will enter the fiber at several angles. When a light pulse is launched into the fiber, some of the light will travel in the middle of the core, while some light will &#8220;bounce&rdquo; through the cable as illustrated in the following graphic. The smaller aperture you use, will give you better control over the angles and as a result control over the paths.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p align="center" style="text-align: center;"><span style="font-family: 'Times New Roman',serif;"><a href="https://learningnetwork.cisco.com/servlet/JiveServlet/showImage/38-3774-319487/pastedImage_4.png"><img alt="" class="jive-image image-3" height="210" src="https://learningnetwork.cisco.com/servlet/JiveServlet/downloadImage/38-3774-319487/pastedImage_4.png" style="max-width:483px; max-" width="483"/></a> </span></p><p><span style="font-size: 10.0pt;"><em><span>Source: </span><a class="jive-link-external-small" href="http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/white_paper_c11-463677.html" rel="nofollow" target="_blank">http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/white_paper_c11-463677.html</a></em></span></p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>As you can imagine, light that is &#8220;bouncing&rdquo; through the cable (high-order mode) actually travels a longer distance than the light that is sent at the center (low-order mode), meaning that it will take longer before it reaches the end. Even though we are talking something in the order of picoseconds, it can become a problem if the link is long.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Consider the input and output pulses shown in the graphic. When the pulse is sent, the shape of it is nice and clean, while the output pulse is flatter (attenuated) and has been stretched a bit as a result of some of the light travelling a longer distance. The physical layer of the used transmission standard defines how often these light pulses are sent, meaning that each light pulse has a finite time window to reach the other end. If the link is too long, you risk that light following the low-order path of the next light pulse reaching the receiving side before the light following the high-order path of the current light pulse does. As a result, the receiving side will no longer be able to decode the incoming signal, resulting in interface errors (CRC, runts, invalid frames etc.), link flaps, or even no link at all.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>When link speed is increased, the time window between each light pulse is shorter, causing maximum supported link length to decrease. In order to improve on this, multimode fiber used today is of the type &#8220;Graded Index&rdquo;. This means that the core of the fiber gradually changes the refraction index from the center out. At the center, the refraction index is higher than it is at the edge. This is because light travels faster through materials with lower refraction indexes than it does in materials with higher refraction indexes. In the end, light traveling near the edge of the fiber travels faster than light near the center, thereby compensating for the longer path the light has to travel.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Singlemode fiber only has one mode or path of light, so the described phenomenon is not an issue here. The core of a singlemode fiber has a very small diameter. In addition, lasers used in singlemode transceivers have a smaller aperture and are thus able to more precisely focus and shape the beam of light, ensuring that it is only sent in the center of the core. This requires more precise (and powerful) lasers, which is more expensive than their multimode counterparts.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Singlemode fiber also suffers from signal degradation as a result of fiber imperfections and dispersion of the signal (again stretching the light pulse). Different types of fibers can combat this by improving performance of the fiber. One type of fiber performs best around 1310 nm (second window band), while another type is best at 1550 nm (third window, &#8220;C&rdquo; band), while yet another type is optimized for use with DWDM systems.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><h2>Final thoughts</h2><p>I hope this blog has given you some ideas about why singlemode fiber outperforms multimode fiber in terms of achievable link lengths and why singlemode optics are more expensive. Whether to use singlemode or multimode depends on the application and budget constraints.</p><p style="min-height: 8pt; padding: 0px;">&nbsp;</p><p>Hopefully, I&#8217;ve managed to describe relevant characteristics in a way that makes sense to you. As already mentioned, this is in no way the complete story but rather a small chapter. Please feel free to post your comments and questions.</p></div><!-- [DocumentBodyEnd:fd83bbb9-b0fe-490e-8220-6ce19a4b1be4] -->opticalfibercisco_designated_vipvip_blogThu, 05 May 2016 19:16:53 GMTbounce@learningnetwork.cisco.comhttps://learningnetwork.cisco.com/blogs/vip-perspectives/2016/05/05/optical-fiber-explained-and-demystified2016-05-05T19:16:53Z1 year 3 months ago130https://learningnetwork.cisco.com/blogs/vip-perspectives/comment/optical-fiber-explained-and-demystifiedhttps://learningnetwork.cisco.com/blogs/vip-perspectives/feeds/comments?blogPost=3774