1 00:00:05,040 --> 00:00:08,240 Now some good news before we get into the network automation section. 2 00:00:08,250 --> 00:00:16,140 You don't have to learn Python for the CCNA exam that's covered in the Cisco dev net certification. 3 00:00:16,260 --> 00:00:20,310 I took the CCNA and Dev Net Associate exam on the same day. 4 00:00:20,520 --> 00:00:26,550 I've spoken previously about this early in the course, but I'm going to replay parts of that video 5 00:00:26,580 --> 00:00:31,740 in this section just to remind you of my thoughts when I took the exam. 6 00:00:31,770 --> 00:00:39,630 The CCNA exam will test you on topics such as Rest API, JSON formatting that's covered in the automation 7 00:00:39,630 --> 00:00:43,560 and programmability section of the blueprint. 8 00:00:43,800 --> 00:00:48,510 So as an example, make sure that you know how to interpret JSON encoded data. 9 00:00:48,540 --> 00:00:53,820 Make sure that you know how to describe the characteristics of rest based APIs. 10 00:00:53,910 --> 00:01:00,540 So as an example, when I want to get data from a server using a rest API, that's a get. 11 00:01:00,960 --> 00:01:03,780 If I want to delete some data, it's a delete. 12 00:01:03,810 --> 00:01:12,360 Make sure that you know the rest API verbs, but you don't have to write python code using rest APIs. 13 00:01:13,170 --> 00:01:16,380 You don't have to learn Ansible for the exam. 14 00:01:16,410 --> 00:01:19,440 Now in this section, I'm going to show you Python scripts. 15 00:01:19,440 --> 00:01:21,370 I'm going to show you Ansible scripts. 16 00:01:21,390 --> 00:01:25,680 You don't, however, have to learn that for the CCNA exam. 17 00:01:25,680 --> 00:01:31,060 You need to learn that for the dev net exam and the developer certifications. 18 00:01:31,080 --> 00:01:33,690 Now, is it recommended that you learn Python? 19 00:01:33,690 --> 00:01:34,560 Definitely. 20 00:01:34,560 --> 00:01:37,470 If you're interested in getting ahead in your career. 21 00:01:37,500 --> 00:01:38,580 Learn Python. 22 00:01:38,580 --> 00:01:39,630 Learn Ansible. 23 00:01:39,660 --> 00:01:42,150 I've been saying these things for many, many years. 24 00:01:42,180 --> 00:01:47,670 Years ago I was explaining the separation of the control plane and data plane. 25 00:01:48,060 --> 00:01:51,810 You can see this video and YouTube as an example made many years ago. 26 00:01:52,440 --> 00:01:55,460 This stuff has now become mainstream. 27 00:01:55,470 --> 00:02:02,370 It's important that you learn Python and Ansible for the real world and to get ahead in your career. 28 00:02:02,370 --> 00:02:06,690 But for the CCNA exam, you don't have to learn Python scripts. 29 00:02:06,690 --> 00:02:08,520 You don't have to learn Ansible scripts. 30 00:02:08,699 --> 00:02:16,830 Now, if I hear that this has changed that now they testing your coding ability, I'll update this video. 31 00:02:16,830 --> 00:02:22,050 But at the moment, because I haven't heard any new updates, you can assume that you don't have to 32 00:02:22,050 --> 00:02:25,740 learn Python and Ansible code for the exam. 33 00:02:25,740 --> 00:02:27,870 You need to understand the principles. 34 00:02:28,200 --> 00:02:34,950 So as an example here they talk about explaining how automation impacts network management. 35 00:02:35,430 --> 00:02:42,570 Let me tell you, the world is changing with network automation in the same way that we had autonomous 36 00:02:42,570 --> 00:02:47,130 access points in the past and they are now managed using a controller. 37 00:02:47,160 --> 00:02:51,840 The idea here is we're going to have a controller that manages lots of devices. 38 00:02:51,930 --> 00:02:58,440 Now in the first sort of an or software defined networking implementation, the protocol used was open 39 00:02:58,440 --> 00:02:58,980 flow. 40 00:02:59,010 --> 00:03:03,660 There's a big difference between the way open flow did things and the way network automation is done 41 00:03:03,660 --> 00:03:09,930 today in the purest form of open flow, the switches or devices in your network become dumb. 42 00:03:10,410 --> 00:03:16,800 The controller, which would simply be a Linux Ubuntu server as an example, controls the devices in 43 00:03:16,800 --> 00:03:17,670 the network. 44 00:03:17,670 --> 00:03:20,370 They lose their brain. 45 00:03:20,370 --> 00:03:26,700 So in the Q&A they talk about separation of control, plane and data, plane and northbound and southbound 46 00:03:26,700 --> 00:03:27,480 APIs. 47 00:03:27,930 --> 00:03:32,190 As they start, understand the following Where is the brain? 48 00:03:32,190 --> 00:03:37,950 Where is the intelligence for the network and the purest open flow implementation? 49 00:03:37,950 --> 00:03:42,660 The brain was removed from the networking device and put into the controller. 50 00:03:43,050 --> 00:03:49,440 If we had 100 routers or 100 switches in a traditional network, we have 100 brains. 51 00:03:49,440 --> 00:03:53,130 Every router, every switch controls itself. 52 00:03:53,130 --> 00:03:56,370 It has its own data, plane or forwarding plane. 53 00:03:56,370 --> 00:03:59,310 That's how it switches traffic from one interface to another. 54 00:03:59,310 --> 00:04:03,570 It has its own control plane, in other words, its own brain. 55 00:04:03,840 --> 00:04:09,030 When a router using OSPF receives an update, it updates its routing table. 56 00:04:09,030 --> 00:04:15,060 So the RGB routing information base, that's a software based table that's populated with routes learnt 57 00:04:15,060 --> 00:04:16,290 through OSPF. 58 00:04:16,290 --> 00:04:20,279 So the brain is populating the routing table with routes. 59 00:04:20,670 --> 00:04:26,730 So the RGB or routing information base is a software based routing table that's then pushed down into 60 00:04:26,730 --> 00:04:33,090 hardware or into the forwarding plane or data plane, in other words, into the FIB or forwarding information 61 00:04:33,090 --> 00:04:35,460 base, in other words into hardware. 62 00:04:35,460 --> 00:04:39,000 So we have the control plane, which is the brain of the device. 63 00:04:39,120 --> 00:04:42,120 OSPF is populating the routing information base. 64 00:04:42,120 --> 00:04:44,490 The brain determines where traffic is routed. 65 00:04:44,620 --> 00:04:49,260 Same kind of idea with spanning tree spanning tree beeped, user received. 66 00:04:49,260 --> 00:04:53,910 The brain decides once again which ports are forwarding, which ports are going to be blocked. 67 00:04:53,910 --> 00:04:59,580 So the thing to remember is the device has a local intelligence, the brain is on the device. 68 00:04:59,580 --> 00:05:03,930 If we had 100 routers or they would each have their own local. 69 00:05:03,990 --> 00:05:04,620 Brain. 70 00:05:04,620 --> 00:05:12,840 Brain is localized to the device, but in the purest open flow example, the devices became dumb and 71 00:05:12,840 --> 00:05:15,550 we put the brain into the controller. 72 00:05:15,570 --> 00:05:20,400 So the controller, centralized controller was the brain for 100 devices. 73 00:05:20,520 --> 00:05:27,780 That's nice in a way, because the controller is a central device that you can manipulate and then update 74 00:05:27,780 --> 00:05:29,980 the forwarding of 100 devices. 75 00:05:30,000 --> 00:05:35,700 It also gives the centralized device more visibility of the network so you can see the entire network 76 00:05:35,700 --> 00:05:41,460 instead of the router just seeing its own local routing table and not having visibility of the entire 77 00:05:41,460 --> 00:05:42,000 network. 78 00:05:42,030 --> 00:05:45,330 There were advantages with with this kind of model. 79 00:05:45,960 --> 00:05:52,260 OSPF uses the SP algorithm, shortest path, first algorithm, very complex to have a distributed system 80 00:05:52,260 --> 00:05:56,640 that then somehow converges to decide which is the best path in the network. 81 00:05:56,640 --> 00:05:59,940 Much easier to put the intelligence in a centralized controller. 82 00:05:59,970 --> 00:06:05,400 But it didn't work because as an attacker, which device am I going to attack? 83 00:06:05,400 --> 00:06:07,760 I'm going to attack that centralized device. 84 00:06:07,770 --> 00:06:13,260 If I can take out the controller and not only just take out one router or take out 100 routers, so 85 00:06:13,260 --> 00:06:16,830 I basically can destroy your network by just killing the controller. 86 00:06:17,010 --> 00:06:21,960 There were other problems because okay, so we have a centralized device, but what about redundancy? 87 00:06:22,290 --> 00:06:24,570 If this thing dies, your whole network dies. 88 00:06:24,570 --> 00:06:25,850 So that kind of sucks. 89 00:06:25,860 --> 00:06:31,470 So what you're going to do is have more than one controller and now you back to this distributed database 90 00:06:31,470 --> 00:06:33,480 scenario or synchronization issue. 91 00:06:33,510 --> 00:06:40,260 How do I synchronize multiple databases in multiple physical controllers to have a single logical controller? 92 00:06:40,290 --> 00:06:45,360 So there were a lot of other issues with this model became a nightmare. 93 00:06:45,870 --> 00:06:50,190 What happens if the routers lose connectivity to the centralized controller? 94 00:06:50,220 --> 00:06:50,940 Think about it. 95 00:06:50,940 --> 00:06:55,870 The router has its own localized brain in a traditional networking environment. 96 00:06:55,890 --> 00:07:00,690 If it loses connectivity to another router, that's not a problem because he has his own local brain. 97 00:07:00,690 --> 00:07:02,610 That router has its own local brain. 98 00:07:02,610 --> 00:07:07,650 But if you put the brain in the controller and then the routers lose connectivity to the controller 99 00:07:07,650 --> 00:07:10,920 because the link goes down suddenly, what are the routers do? 100 00:07:10,950 --> 00:07:14,710 They have no brain, so the network dies or breaks. 101 00:07:14,730 --> 00:07:18,490 So a lot of problems with the pure open flow environment. 102 00:07:18,510 --> 00:07:24,330 They then came up with this hybrid approach where we had some intelligence on the devices, some intelligence 103 00:07:24,330 --> 00:07:30,780 on the controller, where the controller could override what a router was doing so we could write open 104 00:07:30,780 --> 00:07:34,500 flow rules to the router to override traditional networking. 105 00:07:34,500 --> 00:07:36,420 So the router is an example of switches. 106 00:07:36,420 --> 00:07:41,640 An example would do traditional routing or traditional switching, but then we could create extra rules 107 00:07:41,640 --> 00:07:46,650 here where I could manipulate the flow of traffic from a centralized controller. 108 00:07:46,680 --> 00:07:52,500 Now one of the cool things with the open flow model and the whole idea of a controller is these devices 109 00:07:52,500 --> 00:07:56,490 talk to the controller using what's called a southbound API. 110 00:07:56,520 --> 00:08:01,920 So the controller is sitting over here, talks down to the devices using southbound API. 111 00:08:01,950 --> 00:08:04,260 Notice how I've got my hand up here. 112 00:08:04,290 --> 00:08:06,420 Northbound APIs. 113 00:08:06,420 --> 00:08:07,860 Southbound APIs. 114 00:08:07,860 --> 00:08:09,270 Just think south down. 115 00:08:09,270 --> 00:08:10,170 North up. 116 00:08:10,320 --> 00:08:16,990 So an application developer could write an application, talk to the controller using a northbound API. 117 00:08:17,010 --> 00:08:19,170 Typically, these would be rest APIs. 118 00:08:19,170 --> 00:08:21,480 That's very common today. 119 00:08:21,480 --> 00:08:24,900 And then a protocol would be used on the southbound API. 120 00:08:24,900 --> 00:08:29,910 So the controller would talk down to the routers and switches using some kind of protocol which could 121 00:08:29,910 --> 00:08:30,990 be open flow. 122 00:08:31,230 --> 00:08:33,110 That was the original idea. 123 00:08:33,120 --> 00:08:34,710 Could be SNMP. 124 00:08:34,740 --> 00:08:41,039 Don't forget simple network management protocol being used for years from management stations to networking 125 00:08:41,039 --> 00:08:41,669 devices. 126 00:08:41,669 --> 00:08:44,400 So SNMP could be used in a southbound API. 127 00:08:44,430 --> 00:08:52,350 We could use net conf, we could use rest conf, we could use multiple other options for MPLS BGP. 128 00:08:52,890 --> 00:08:58,830 Basically, there were there are many protocols for I just have an understanding that we could use rest 129 00:08:58,830 --> 00:09:04,770 conf we could use rest APIs actually we could use CLI, we could use SNMP. 130 00:09:05,280 --> 00:09:09,840 Now you don't have to use the rest API of the controller to manipulate devices. 131 00:09:10,410 --> 00:09:15,600 Typically the idea was you, you were an application developer, you used a Python script that wrote 132 00:09:15,600 --> 00:09:20,160 rules to the controller, which then sent it down to the devices. 133 00:09:20,160 --> 00:09:26,820 The advantage of that was this concept of abstraction complex to write rules to devices. 134 00:09:26,820 --> 00:09:28,020 That was what they said. 135 00:09:28,050 --> 00:09:32,220 Much easier to write stuff to a rest API on the controller. 136 00:09:32,220 --> 00:09:35,970 So you would write rules to the controller using the rest API. 137 00:09:36,000 --> 00:09:43,260 So the application uses a high level programming language like Python Easy Rest API and the controller, 138 00:09:43,260 --> 00:09:46,800 which then uses multiple protocols down to the devices. 139 00:09:46,800 --> 00:09:54,630 Open flow net conf bgp ls a whole bunch of weird and wonderful protocols down to the devices. 140 00:09:55,260 --> 00:10:00,000 You as the application developer are being abstracted from the networking devices. 141 00:10:00,000 --> 00:10:00,990 That's the idea. 142 00:10:01,260 --> 00:10:03,860 But you could do away with the. 143 00:10:04,020 --> 00:10:09,050 Controller and just configure the network devices directly using a Python script or Ansible script. 144 00:10:09,080 --> 00:10:15,320 That's what I'm going to show you in the course, because that's a lot easier actually to get started 145 00:10:15,320 --> 00:10:15,920 with. 146 00:10:15,950 --> 00:10:21,260 It's a lot easier to say, okay, let's write a simple Python script that updates something on the router 147 00:10:21,260 --> 00:10:24,230 or pulls information out of the router or switch. 148 00:10:24,260 --> 00:10:31,980 You can mimic this with physical equipment in a lab or in S3 or viral, or even if you if you like. 149 00:10:32,000 --> 00:10:33,590 So I'm going to show you some examples of that. 150 00:10:33,590 --> 00:10:36,410 But just remember, you don't have to learn Python for the exam. 151 00:10:36,530 --> 00:10:42,320 You don't have to learn Python or Ansible programming for the exam, but for the real world, I'd suggest 152 00:10:42,320 --> 00:10:44,780 that you do learn both of those. 153 00:10:44,900 --> 00:10:48,170 So here they talk about separation of control plane and data plane. 154 00:10:48,200 --> 00:10:55,820 Just note, where is the brain local device in the old days, control plane forwarding plane or data 155 00:10:55,820 --> 00:10:57,490 plane was in the device. 156 00:10:57,500 --> 00:11:00,440 So think of the data plane as the forwarding through the A-6. 157 00:11:00,590 --> 00:11:01,730 I've got a router. 158 00:11:01,760 --> 00:11:06,440 Traffic arrives on one interface, it gets switched to another interface. 159 00:11:06,440 --> 00:11:09,860 So data gets sent through the device. 160 00:11:09,860 --> 00:11:14,750 It's switched on the data plane or forwarding plane that still resides in the device. 161 00:11:14,750 --> 00:11:20,720 Typically it's done using A-6, but the control plane or the brain, where does it reside? 162 00:11:20,990 --> 00:11:25,790 Today we still want to have the brain in the device open flow. 163 00:11:25,790 --> 00:11:29,210 The brain was removed and put into a separate controller. 164 00:11:29,480 --> 00:11:30,770 We don't want to do that. 165 00:11:30,770 --> 00:11:33,230 Cisco Devices didn't really support open flow. 166 00:11:33,230 --> 00:11:34,250 They still don't. 167 00:11:34,370 --> 00:11:40,340 The idea is the brain remains on the device, but we can use a centralized controller to configure the 168 00:11:40,340 --> 00:11:41,150 devices. 169 00:11:41,150 --> 00:11:45,980 So rather than making the devices dumb, we still allow them to do their forwarding, still allow them 170 00:11:45,980 --> 00:11:47,240 to have their local brain. 171 00:11:47,240 --> 00:11:53,630 But we can configure the devices either directly or through a controller, which makes it easier to 172 00:11:53,630 --> 00:11:55,250 manage many devices. 173 00:11:55,520 --> 00:11:59,680 So that's one of the central ideas of a controller based network. 174 00:11:59,690 --> 00:12:02,540 Now what I haven't mentioned here is the management plane. 175 00:12:02,990 --> 00:12:06,290 They actually three planes control plane or forwarding plane. 176 00:12:06,290 --> 00:12:07,760 It's like saying router router. 177 00:12:08,300 --> 00:12:10,520 How's the traffic forwarded through the device? 178 00:12:10,520 --> 00:12:16,070 That always remains on the device because we want high speed switching or forwarding on the device brain. 179 00:12:16,070 --> 00:12:17,060 Where does it reside? 180 00:12:17,060 --> 00:12:20,450 Typically resides on the device, but we could have put it into a controller. 181 00:12:20,450 --> 00:12:22,040 Where's the management? 182 00:12:22,130 --> 00:12:23,930 So what's the management plane? 183 00:12:23,930 --> 00:12:26,210 We typically manage a Cisco device. 184 00:12:26,210 --> 00:12:31,210 Using a console or remotely would be telnet bad idea and ssh. 185 00:12:31,220 --> 00:12:34,310 So how do we manage the device now? 186 00:12:34,490 --> 00:12:40,610 US as humans would use one of those interfaces to configure the device, but to manage the device using 187 00:12:40,670 --> 00:12:48,020 a application, we in the old days would use S&P Simple Network Management Protocol is SNMP has issues. 188 00:12:48,050 --> 00:12:54,110 Number one, it's an IP version one or two, insecure, very easy to hack, bad idea to use S&P version 189 00:12:54,110 --> 00:12:54,590 one. 190 00:12:54,590 --> 00:12:56,150 And version two is SNMP. 191 00:12:56,150 --> 00:13:02,420 Version three supports encryption and authentication much better, but S&P is not easy. 192 00:13:02,690 --> 00:13:07,700 The IDs and the way to extract information from a device is difficult. 193 00:13:07,700 --> 00:13:14,600 So the rage today, which has actually been going on for a few years, is to use a API application programming 194 00:13:14,600 --> 00:13:15,230 interface. 195 00:13:15,260 --> 00:13:18,020 Again, rest is one of the most popular. 196 00:13:18,900 --> 00:13:21,300 APIs used all over the place. 197 00:13:21,390 --> 00:13:28,770 So when we transition from being a pure network engineer to doing more programming, the guys from the 198 00:13:28,770 --> 00:13:31,350 programming world are used to rest APIs. 199 00:13:31,350 --> 00:13:34,820 They used all over the place once again in applications. 200 00:13:34,830 --> 00:13:40,110 So when they want to configure network devices, it makes sense that that device has a rest API. 201 00:13:40,440 --> 00:13:45,180 But just be aware that a lot of old devices will not have a rest API. 202 00:13:45,210 --> 00:13:48,870 You need to use a modern Cisco network device to get a rest API. 203 00:13:49,350 --> 00:13:55,080 So just because rest is cool doesn't mean that all devices are going to support rest. 204 00:13:55,290 --> 00:14:02,010 So in the examples that I'm going to show you in this course, which is very much based from my original 205 00:14:02,010 --> 00:14:08,190 Python course, I'm going to show you how to configure the devices using Telnet and SSH because that's 206 00:14:08,190 --> 00:14:10,150 an easy way to get started. 207 00:14:10,170 --> 00:14:11,670 Start with the basics. 208 00:14:12,490 --> 00:14:17,450 At any level, then go and do your definite associate exam. 209 00:14:17,470 --> 00:14:22,510 I highly recommend that you do the definite certification, so get your definite certification so that 210 00:14:22,510 --> 00:14:28,960 you can prove to employers that you are not just a network engineer, but you also understand programming. 211 00:14:29,590 --> 00:14:33,350 Now, as I've said, I've been talking about programming for a long time. 212 00:14:33,370 --> 00:14:36,700 I spoke about open flow more than five years ago. 213 00:14:36,700 --> 00:14:43,430 So the idea is this stuff has been bubbling up in the industry, but now Cisco have formalized it. 214 00:14:43,450 --> 00:14:50,590 So my recommendation is learn Python and Ansible, learn the stuff for the real world, not for the 215 00:14:50,590 --> 00:14:56,260 CCNA, learn it for the real world and for the dev net certification, and go and get your dev net certification 216 00:14:56,260 --> 00:15:00,970 as soon as you can so that you can prove to employers that you're not just a network engineer, but 217 00:15:00,970 --> 00:15:02,380 you also understand programming. 218 00:15:02,560 --> 00:15:08,110 I'm afraid that being a traditional network engineer with no understanding of programming is over. 219 00:15:08,140 --> 00:15:13,210 You will need to learn programming if you want to have a good job in future. 220 00:15:13,240 --> 00:15:18,640 I'm really glad that Cisco have done this, but they've only put 10% of the exam being automation and 221 00:15:18,640 --> 00:15:19,450 programming. 222 00:15:19,570 --> 00:15:23,470 So automation, programmability, 10% of the exam, not very big. 223 00:15:24,160 --> 00:15:27,400 And they use words like explain and compare. 224 00:15:27,430 --> 00:15:31,000 They don't use words like configure or troubleshoot. 225 00:15:31,000 --> 00:15:32,590 So this is a very high level. 226 00:15:32,590 --> 00:15:35,350 This is typical Cisco way of doing it, very high level. 227 00:15:35,440 --> 00:15:41,530 But then perhaps in the next release of the CCNA, it will become more detailed and you'll be asked 228 00:15:41,530 --> 00:15:42,490 more information.