Do Routing The Ip

DAY DA Y ONE: ROUTING THE INTERNET PROTOC PROTOCOL OL This book is intended for network engineers who have either just begun their career in network engineer ing or have worked in an environment where only one routing protocol was used, so they are unfamiliar with the other routing protocols in the Junos ® OS. If you are familiar with how the Junos CLI works, you can follow along with how to configure not only static routing, but the popular routing protocols: RIP, OSPF, IS-IS, iBGP, and eBGP. This book discusses each routing protocol’s unique traits and then shows you how to implement them in the Junos OS for any Juniper Networks device. The authors, both Juniper Ambass adors, draw from their many years of network administration to provid e examples and configuration samples that you will likely enounter in real-world networks. “The network industry is undergoing a revolution whereby the boundaries between server and networ k engin e ngin eer are becom ing blur blurred. red. Now, more mor e than t han ever before , it is imp importa ortant nt for all to have a good grounding in the fundamentals of routing. This Day One book on the fundamentals of routing from Martin Brown and Nick Ryce, along with the entire Day One library as a whole, fills that gap.” Perry Young, Senior VP, Cyber Security Ops, undisclosed firm, JNCIP-SEC/SP JNCIP-SEC/SP/ENT /ENT IT’S DAY ONE AND YOU HAVE A JOB TO DO, SO LEARN HOW TO:  Better understand the different interior gateway protocols protocols  Know the differences between Distance Vector, Path Vector, and Link State protocols  Understand how Administrative Distance affects routing to a subnet  Be able to build a more scalable network topology topology  See how this information relates relates to a live network Juniper Networks Books are singularly focused on network productivity and efficiency. Peruse the complet complete e library at www.juniper.net/books. www.juniper.net/books. Published by Juniper Networks Books ISBN 978-1941441220 52000 9 7 8 1 9 4 1 4 4 1 22 22 0 Junos® OS Fundamentals Series Day One: Routing the Internet Protoc Protocol ol By Martin Brown and Nick Nic k Ryce Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Chapter 1: Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Chapter 2: Routing Protoc oco ol Preference and Type. . . . . . . . . . . . . . . . . . . . . .2 .211 Chapter 3: Ro Route Information Protocol (RIP) . . . . . . . . . . . . . . . . . . . . . . . . . .3 .311 Chapter 4: Open Shortest Path First (OSPF) . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Chapt Ch apter er 5: Inter Intermed media iate te Syst System em to Inter Intermed media iate te Syst System em (IS (IS-I -IS S) . . . . . . . 67 Chapter 6: Redistributing Route Information . . . . . . . . . . . . . . . . . . . . . . . . . 81 Chapter 7: Border Gateway Protcol (BGP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Chapter 8: Route Summarization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 iv © 2015 by Juniper Networks, Inc. All rights reserved. Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Published by Juniper Networks Books Authors: Martin Brown, Nick Ryce Technical Reviewers: Clay Haynes, Perry Young, Victor Gonzales Editor in Chief: Patrick Ames Copyeditor and Proofer: Nancy Koerbel Illustrator: Karen Joice J-Net Community Manager: Julie Wider ISBN: 978-1-936779-22-0 (print) Printed in the USA by Vervante Corporation. ISBN: 978-1-936779-21-3 (ebook) Version History: v1, November 2015 2 3 4 5 6 7 8 9 10 About the Authors: Martin Brown is a Network Security Engineer for a major telco based in the UK, and a Juniper Ambassador with knowledge that covers a broad range of network devices. Martin started his career in IT 20 years ago supporting Macintosh computers, became an MCSE in 1999, and has since progressed to networking, supporting most of the major manufacturers including Cisco, F5, Checkpoint, and of course, Juniper. Nick Ryce is a Senior Network Architect for a major ISP based in Scotland, and a Juniper Ambassador. Nick has over a decade of experience working within the Service Provider industry and has worked with a variety of vendors including Cisco, Nortel, HP, and Juniper. Nick is currently certiﬁed as JNCIE-ENT #232 Authors Acknowledgments: Martin Brown: I would once again like to thank my good friend, Joy Horton, for continuing to be a s ource of inspiration and support whilst writing this book. I would also like to thank all of the Juniper Ambassadors for their words of encouragement, their sense of camaraderie, and for helping me sanity check some of my wording when I really needed it. Finally, I really would like to thank my dad, as his words of “Nothing good will ever come of you playing on that computer” only inspired me to prove him wrong. Nick Ryce: I would like to thank my wife, Jennifer, and my children, Anna and Toby, who have not only supported me while writing this book, but have also supported me in my chosen career, which sometimes means evenings sitting on a Datacentre ﬂoor working away instead of spending time with them. I would also like to thank my fellow Juniper Ambassadors who are a continuous source of inspiration and my technical sounding board. I would especially like to thank Martin for allowing me to contribute to this book and for his continuing guidance and enthusiasm when I realized I may have bitten off more than I could chew. This book is available in a variety of formats at: http://www.juniper.net/dayone . v Welcome to Day One This book is part of a growing library of Day One books, produced and published by Juniper Networks Books. Day One books were conceived to help you get just the information that you need on day one. The series covers Junos OS and Juniper Networks networking essentials with straightforward explanations, step-by-step instructions, and practical examples that are easy to follow. The Day One library also includes a slightly larger and longer suite of This Week books, whose concepts and test bed examples are more similar to a weeklong seminar. You can obtain either series, in multiple formats:  Download a free PDF edition at http://www.juniper.net/dayone.  Get the ebook edition for iPhones and iPads from the iTunes Store. Search for Juniper Networks Books.  Get the ebook edition for any device that runs the Kindle app (Android, Kindle, iPad, PC, or Mac) by opening your device’s Kindle app and going to the Kindle Store. Search for Juniper Networks Books.  Purchase the paper edition at either Vervante Corporation (www. vervante.com) for between $12-$28, depending on page length. Audience This book is intended for network engineers who have just begun their career in network engineering and whilst they are aware of the various routing protocols, they perhaps are unsure of the features each one has to offer. This book is also for network engineers who have had years of experience in supporting live networks but have only had exposure to maybe one or two routing protocols. vi What You Need to Know Before Reading This Book Before reading this book, you should be familiar with the basic administrative functions of the Junos OS, including the ability to work with operational commands and to read, understand, and change conﬁgurations. This book makes a few assumptions about you, the reader:  You have a basic but solid understanding of the Internet Protocol version 4, IPv4.  You have access to a lab with at least the following components: one workstation and a Junosphere account, or one workstation and two of any of the following devices: SRX Series ﬁrewall, EX Series switch, J Series router.. By Reading This Book You Will  Better understand the different interior gateway protocols.  Know the differences between Distance Vector, Path Vector, and Link State protocols.  Understand how Administrative Distance affects routing to a subnet.  Be able to build a more scalable network topology.  See how this information relates to a live network. vii Preface Any company with a network needs a way of sending data from one subnet to another; this holds true not just for the largest corporations but for the smallest start-ups as well. Let’s consider an example. Danny runs a small design company composed only of he and his wife working from their garage. Figure P.1 gives a graphical representation of their LAN. Figure P.1 Example Network Topology As you can see, Danny’s Network has two workstations and a printer connected to an ADSL modem that provides them with Internet access. It’s evident they are using a single subnet for their workstation and printer, so it’s tempting to think that they don’t need to send data from one subnet to another—say from the garage to the house, for example. You can see the Internet to the left of Figure P1, however, and it is one great big network; in fact, Internet is short for Interconnected Networks and these workstations need to be able to communicate with some of the subnets on these networks. viii Routing Table: A database in routers that keep the addresses of how to reach speciﬁc subnets. So although Danny’s company is small, it’s still required to send data to another subnet, and to allow it to do this, the ADSL modem is in fact a router. In order to know how to reach speciﬁc subnets, routers have a special database known as a routing table. This table lists the subnets the router has been told about and will tell the router which IP address or “next hop” to use to connect to that subnet. Default Route: A single location where your subnet sends all trafﬁc for processing into the Internet. In the case of Danny’s network, the routing table on the ADSL modem would consist of what is known as a default route, or a single location where the router simply sends any trafﬁc it receives that is not destined for a printer or other workstation out the ASDL interface and to the ISP, who would then determine what to do with that packet. In Danny’s scenario the router knows that all subnets are accessible via the ADSL interface, but what about a large corporation with multiple branches spread across several countries or even continents? How does the Internet Service Provider know what to do with this packet? The purpose of this book is to describe in detail how a router is able to learn which subnets are accessible through which interfaces by using what is known as Routing Protocols. This Day One book will cover six routing protocols: static routes, RIP, OSPF, IS-IS, iBGP, and eBGP, and it will also detail the three types of routing protocols. The last chapter in this book describes how the number of routes in a routing table can be reduced or summarized. Summarize Networks: How to group networks into a single, larger network. While writing this book, the authors wanted to make the scenarios as realistic as possible, which meant the example topology needed to be a reasonable size, so we used Junosphere. Figure P.2 shows the topology of the network used throughout this book. Most of the devices are vMX routers, however on the Internet Edge there are two vSRX ﬁrewalls, which will be conﬁgured with default static routes at the beginning of the book, and then in later chapters will be conﬁgured to use BGP. You may also notice in Figure P.2 that a large portion of the network uses IP addresses that start with 10.x.x.x and another portion starts with 172.x.x.x. The purpose of this is to demonstrate how to “summarize” networks or group them together to appear as one larger network, the subject of the last chapter of this book. ix Figure P.2 This Book’s Topology NOTE The version of Junos OS software running on the vMX routers is 14.1-20140130_ib_14_1_psd.0 and the version of Junos OS running on the vSRX ﬁrewalls is 12.1I20131108, however most of the commands used in this book will be version neutral, applicable to any version of the Junos OS. If a command is only available in a more recent release, it will be noted. The ﬁrst topic covered in this book isn’t a routing protocol, strictly speaking, as no information is shared between routers. It’s more about how an administrator tells the router how to get to each subnet. That said, it is still a common method in use in many networks today due to its simplicity. So, relax, kick back, and prepare to learn all about static routes. Enjoy the book! Martin Brown and Nick Ryce, Juniper Ambassadors x Information Experience This Day One book is singularly focused on one aspect of networking technology that you might be able to do in one day, but it is not a substitute for Juniper documentation. MORE? It’s highly recommended you go through the technical documentation in order to become fully acquainted with the routing fundamentals of the Junos OS. The Juniper Tech Library is at www.juniper.net/documentation. Use the Pathﬁnder tool on the documentation site to explore and ﬁnd the right information for your needs. Chapter 1 Static Routes Although static routes are not, strictly speaking, a routing protocol, they do nonetheless still perform the same role as OSPF or RIP by telling a router how to reach a speciﬁc subnet. In spite of their drawbacks, they can still be useful in today’s modern networks as they are very simple to implement, and in the case of a failure in another routing protocol, they can be used to temporarily restore connectivity until service is restored. But before you can understand static routes in any depth, a good place to start would be understanding how a router makes a routing decision and how packets arrive on the router’s interface in the ﬁrst place. When a client is assigned an IP address, either manually or automatically by DHCP, the client is also given the IP address of what is known as the default gateway. This default gateway should match the IP address of the router on your subnet. For example, if you examine Figure 1.1, you will see a network consisting of a single router and two workstations. Workstation A has the IP address of 10.1.0.2, and Workstation B has the IP address of 10.2.0.2. Figure 1.1 Single Router LAN 12 Day One: Routing the Internet Protocol Interfaces: Physical and logical channels on the router that deﬁne how data is transmitted to and received from lower layers in the protocol stack. The router vMX0 in this diagram has two interfaces. The interface on the same subnet as Workstation A has the IP address of 10.1.0.1, and the interface on the same subnet as Workstation B has the IP address of 10.2.0.1. When Workstation A was assigned its IP address it was told that its default gateway is 10.1.0.1, and similarly, when Workstation B was assigned its address, it was told its default gateway is 10.2.0.1.. LAN Traﬃc Flow Let’s imagine that Workstation A needs to contact Workstation B. By using the subnet mask, Workstation A knows that Workstation B is on a different subnet so therefore will forward the packet to the default gateway who will then forward it on to Workstation B. The eleven-step process by which this is achieved is as follows: 1. Workstation A decides it needs to forward the packet to the default gateway. Figure 1.2 LAN Traﬃc Flow 2. When data is sent on a local subnet, the MAC addresses of the devices are used as source and destination addresses, as opposed to using the IP address. Figure 1.3 shows a simpliﬁed frame. A packet becomes a frame when the source and destination MAC addresses are added to a packet that already contains source and destination IP addresses. Figure 1.3 Example of a Simpliﬁed Frame Chapter 1: Static Routes ARP: https://en.wikipedia.org/ wiki/Address_Resolution_ Protocol 3. To ﬁnd the MAC address of Router A, Workstation A sends an ARP request on to the LAN asking who has been assigned the IP address 10.1.0.1 and what their MAC address is. 4. vMX0 responds stating that its MAC address is aa.aa.aa.aa.aa.aa and makes a note that this came from IP address 10.1.0.2, which is associated with MAC address 11.11.11.11.11.11. Figure 1.4 Example of a Simpliﬁed Frame 5. Workstation A puts the packet into a frame, sets the destination MAC address as aa.aa.aa.aa.aa.aa. 6. vMX0 receives the frame, looks at the packet inside and sees that the destination IP address is 10.2.0.2. 7. vMX0 looks at its connected interfaces and determines on which interface Workstation B resides. A media access control addres s (MAC addres s) is a unique identiﬁer assigned to network inter faces for communications on the physical networ k segment. https://en.wikipedia .org/w iki/ MAC_address 8. As workstation B is on the local subnet, vMX0 will communicate with it using the MAC address. vMX0 therefore sends an ARP request. 9. Workstation B responds stating its MAC address is 22.22.22.22.22.22 and makes a note that this came from IP address 10.2.0.1, which is associated with MAC address bb.bb.bb.bb.bb.bb. 13 14 Day One: Routing the Internet Protocol Figure 1.5 10. vMX0 puts the packet into a frame and forwards it using the destination MAC address of 22.22.22.22.22.22. Figure 1.6 11. Should Workstation B need to respond to Workstation A, then the same process is followed, however there would be no need to send ARP requests as all devices know the relevant MAC addresses. You may notice that Router A has two MAC addresses, aa.aa.aa.aa.aa. aa and bb.bb.bb.bb.bb.bb. That’s because each interface has its own separate MAC address. In our scenario vMX0 knew how to get to Workstation B because it was on a subnet that was directly connected to vMX0. But what happens if a second router is added in the network path in-between Chapter 1: Static Routes workstations? Figure 1.7 shows an example of this, where Workstation A is located on the same subnet as before, but Workstation C is on Subnet 10.10.1.0 with an address of 10.10.1.2 and the default gateway is 10.10.1.1 on subnet 10.10.1.0 with an address of 10.10.1.2 and the default gateway is 10.10.1.1. Figure 1.7 Two Routers Between Workstations Should workstation A wish to communicate with workstation C, the process will begin as before, workstation A sends the frame to vMX0, however vMX0 looks at its connected interfaces and cannot match the destination address to any of its connected subnets. vMX0 will therefore drop the packet. Packet loss occurs when one or more packets of data travelling across a computer network fail to reach their destination: https://en.wikipedia. org/wiki/Packet_loss. You can test this in Junos OS simply by using the ping command. Normally, when you ping a device from Junos OS, you specify the destination address of the ping and Junos OS will automatically use the outgoing interface IP address as the source address. So, if you ping 10.2.0.3 from vMX0, you should see a response like this: [email protected]> ping 10.2.0.3 PING 10.2.0.3 (10.2.0.3): 56 data bytes 64 bytes from 10.2.0.3: icmp_seq=0 ttl=64 time=1.843 ms 64 bytes from 10.2.0.3: icmp_seq=1 ttl=64 time=2.295 ms 64 bytes from 10.2.0.3: icmp_seq=2 ttl=64 time=2.445 ms 64 bytes from 10.2.0.3: icmp_seq=3 ttl=64 time=4.673 ms 64 bytes from 10.2.0.3: icmp_seq=4 ttl=64 time=2.574 ms ^C --- 10.2.0.3 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.843/2.766/4.673/0.985 ms Junos OS also permits you to specify the source address of the ping instead of automatically using the outgoing interface, so if the command ping 10.2.0.3 source 10.1.0.1 is used, you would see no response and cancelling the ping would show dropped packets as follows: 15 16 Day One: Routing the Internet Protocol [email protected]> ping 10.2.0.3 source 10.1.0.1 PING 10.2.0.3 (10.2.0.3): 56 data bytes ^C --- 10.2.0.3 ping statistics --7 packets transmitted, 0 packets received, 100% packet loss But built into Junos OS is a great utility that allows you to view trafﬁc as it enters or leaves an interface by entering the monitor traffic interface command. Normally this command would actually see the trafﬁc reaching vMX2, but in this case, however, vMX2 would look at the source and see that it doesn’t know how to reach that subnet, so it would silently drop the packet. Let’s look: [email protected]> monitor traffic interface ge-0/0/0.0 verbose output suppressed, use or for full protocol decode Address resolution is ON. Use to avoid any reverse lookup delay. Address resolution timeout is 4s. Listening on ge-0/0/0.0, capture size 96 bytes Reverse lookup for 10.2.0.3 failed (check DNS reachability). Other reverse lookup failures will not be reported. Use to avoid reverse lookups on IP addresses. tra 02:03:06.273992 In IP 10.1.0.1 > 10.2.0.3: ICMP echo request, ength 64 02:03:07.280064 In IP 10.1.0.1 > 10.2.0.3: ICMP echo request, ength 64 02:03:08.220650 In IP 10.1.0.1 > 10.2.0.3: ICMP echo request, ength 64 02:03:09.228902 In IP 10.1.0.1 > 10.2.0.3: ICMP echo request, ength 64 02:03:10.240288 In IP 10.1.0.1 > 10.2.0.3: ICMP echo request, ength 64 02:03:11.248993 In IP 10.1.0.1 > 10.2.0.3: ICMP echo request, ength 64 ^C 6 packets received by filter 0 packets dropped by kernel CAUTION id 7184, seq 0, l id 7184, seq 1, l id 7184, seq 2, l id 7184, seq 3, l id 7184, seq 4, l id 7184, seq 5, l Although the monitor trafﬁc interface command can be very useful, don’t use it in a live environment without applying a ﬁlter. By using a ﬁlter you can ensure that only the desired trafﬁc is captured; if a ﬁlter is not used, then it can place an unnecessary CPU overhead on the router and cause potential issues where live trafﬁc could be disrupted. To resolve the issue vMX0 needs learn that to reach the subnet that Workstation C resides on, it should forward the packet to vMX2, or what is more commonly known as the next hop. In computer networking, a hop is one portion of the path between source and destination. Data packets pass through bridges, routers and gateways on the way. Each time packets are passed to the next device, a hop occurs. https://en.wikipedia.org/wiki/Hop_(networking) Chapter 1: Static Routes The Next Hop Once vMX0 has been told how to reach Workstation C’s subnet, vMX2 then needs to be told how to reach Workstation A, as was shown during the ping 10.2.0.3 source 10.1.0.1 command. It’s all very well for vMX0 knowing how to get to that subnet, but vMX2 also needs to know how to return the trafﬁc. In fact this very scenario is what routing protocols were developed for, to advertise subnets to other routers on the network so those routers will in turn know what next hops to use to reach those subnets. This is known as advertising routes. The Drawbacks of Static Routes As mentioned earlier, static routes are not a routing protocol per se, but they do a similar job – they tell a router the next hop to use to reach a particular subnet. They are simple to use, and that makes them popular, however, they do have a few draw backs. The ﬁrst is that they need to be manually conﬁgured on routers. This may not seem like much of an issue in the above scenario, but what about the topology in Figure P.2 where there are seven routers, two ﬁrewalls and eleven subnets with multiple paths? At some point the administrator needs to decide when using static routes has too much of an administrative overhead. The second issue with using static routes is that the router would blindly forward trafﬁc, meaning that if you added a route that was incorrect, the router would still forward the trafﬁc to the next hop, using up bandwidth and causing the router at the next hop to perform unnecessary processing. If an interface connected to the next hop associated with a static route does go down, this static route disappears from the routing table, so while the router will drop the packet, it does not prevent other routers from sending it to the packet in the ﬁrst place. If Figure 1.2 is used as an example, let’s say that the interface connected to Subnet 10.10.1.0/24 went down, the Router vMX0 would not know this and would continue to send trafﬁc. NOTE The other routing protocols in this book are dynamic and as such would have told vMX0 that this subnet was no longer reachable. 17 18 Day One: Routing the Internet Protocol Conﬁguring Static Routes Static routes are added to a Junos OS device conﬁguration under the Routing-Options hierarchy, as opposed to the routing protocols in this book, which are added under the Protocols hierarchy. If you look back at the topology in Figure 1.2, a route needs to be added to vMX0 stating that to get to Subnet 10.10.1.0/24 the nexthop 10.2.0.3 should be used: [edit] [email protected]# set routing-options static route 10.10.1.0/24 next-hop 10.2.0.3 Next, a route needs to be added to vMX2, telling the router that subnet 10.1.0.0/24 is reachable via the next-hop 10.2.0.1: [edit] [email protected]# set routing-options static route 10.1.0.0/24 next-hop 10.2.0.1 Now if a ping is sent from vMX0 to 10.10.1.1, with a source address of 10.1.0.1, there should be a response: [email protected]> ping 10.10.1.1 source 10.1.0.1 PING 10.10.1.1 (10.10.1.1): 56 data bytes 64 bytes from 10.10.1.1: icmp_seq=0 ttl=64 time=2.037 ms 64 bytes from 10.10.1.1: icmp_seq=1 ttl=64 time=3.583 ms 64 bytes from 10.10.1.1: icmp_seq=2 ttl=64 time=2.989 ms 64 bytes from 10.10.1.1: icmp_seq=3 ttl=64 time=2.571 ms ^C --- 10.10.1.1 ping statistics --4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.037/2.795/3.583/0.566 ms As you can see the ping is successful, which veriﬁes there is end-to-end connectivity on this small network. Conﬁguring Default Static Routes In Figure P.1 (in the Preface) the example network was a single router connected to the Internet. This is exactly the type of network where a static route would be ideal, and one where a default static route is the best solution. The way the router would process the packets it receives would be to look at the destination address and if the destination address is on the local network, which in Figure P.1 is 192.168.0.0/24, it would send it to the local device. Should the destination be any other subnet, then the router would automatically send it out to the Internet. The command to do this on a Junos OS ADSL router would simply be: set routing-options static route 0.0.0.0/0 next-hop at-0/0/0.0 Chapter 1: Static Routes In this case, instead of specifying an IP address as the next-hop, an interface is speciﬁed instead, which should make sense to you, because ADSL is a point-to-point link and trafﬁc sent on that link can only reach one device. Junos OS also allows an engineer to specify a default route to an IP address, in a branch ofﬁce for example, so that the router knows all non-local trafﬁc would be sent across a WAN link. Some engineers, however, use the default route instead of conﬁguring so many individual routes, which can cause problems, as the following example illustrates. In this example, both vMX0 and vMX2 will be conﬁgured with a default static route to each other by using the following commands: [edit] [email protected]# set routing-options static route 0.0.0.0/0 next-hop 10.2.0.3 [edit] [email protected]# set routing-options static route 0.0.0.0/0 next-hop 10.2.0.1 This should work and indeed, when a ping is sent, all subnets respond. But look what happens if a ping is sent to an address that is not on any of the connected interfaces on either router. For example, here is the output from vMX2 with a ping sent to 10.3.0.1: [email protected]> traceroute 10.3.0.1 traceroute to 10.3.0.1 (10.3.0.1), 30 hops max, 40 byte packets 1 10.2.0.1 (10.2.0.1) 125.765 ms 3.121 ms 1.409 ms 2 10.2.0.3 (10.2.0.3) 2.767 ms 1.396 ms 1.605 ms 3 10.2.0.1 (10.2.0.1) 3.508 ms 2.263 ms 2.158 ms 4 10.2.0.3 (10.2.0.3) 3.047 ms 2.288 ms 3.266 ms 5 10.2.0.1 (10.2.0.1) 3.053 ms 3.109 ms 2.879 ms 6 10.2.0.3 (10.2.0.3) 3.241 ms 2.988 ms 2.963 ms 7 10.2.0.1 (10.2.0.1) 3.573 ms 3.932 ms 4.847 ms 8 10.2.0.3 (10.2.0.3) 3.817 ms 3.990 ms 3.543 ms 9 10.2.0.1 (10.2.0.1) 4.434 ms 5.059 ms 6.655 ms 10 10.2.0.3 (10.2.0.3) 5.070 ms 4.920 ms 6.229 ms 11 10.2.0.1 (10.2.0.1) 6.032 ms 5.873 ms 7.300 ms 12 10.2.0.3 (10.2.0.3) 5.741 ms 5.894 ms 6.687 ms 13 10.2.0.1 (10.2.0.1) 7.755 ms 7.915 ms 8.287 ms 14 10.2.0.3 (10.2.0.3) 6.720 ms 6.893 ms 6.471 ms 15 10.2.0.1 (10.2.0.1) 8.070 ms 7.806 ms 7.210 ms 16 10.2.0.3 (10.2.0.3) 7.442 ms 8.339 ms 9.782 ms 17 10.2.0.1 (10.2.0.1) 9.401 ms 10.207 ms 11.348 ms 18 10.2.0.3 (10.2.0.3) 8.250 ms 8.161 ms 8.825 ms 19 10.2.0.1 (10.2.0.1) 9.408 ms 9.189 ms 8.518 ms 20 10.2.0.3 (10.2.0.3) 9.010 ms 8.810 ms 8.615 ms 21 10.2.0.1 (10.2.0.1) 9.181 ms 10.719 ms 9.627 ms 22 10.2.0.3 (10.2.0.3) 13.223 ms 10.706 ms 10.190 ms 23 10.2.0.1 (10.2.0.1) 11.118 ms 10.985 ms 10.621 ms 24 10.2.0.3 (10.2.0.3) 11.370 ms 10.772 ms 11.130 ms 25 10.2.0.1 (10.2.0.1) 11.451 ms 10.610 ms 10.337 ms 26 10.2.0.3 (10.2.0.3) 11.284 ms 11.457 ms 10.346 ms 27 10.2.0.1 (10.2.0.1) 10.617 ms 11.410 ms 11.122 ms 28 10.2.0.3 (10.2.0.3) 10.328 ms 10.672 ms 10.898 ms 19 20 Day One: Routing the Internet Protocol 29 30 10.2.0.1 (10.2.0.1) 10.2.0.3 (10.2.0.3) Routing Loop: An error occurs in the operation of the routing algor ithm , and as a result, in a group of nodes, the path to a particul ar destination 11.293 ms 12.966 ms 11.170 ms 12.253 ms 12.824 ms 11.515 ms You can quickly see that even though there are only two routers in this subnet, there are thirty hops. And if you examine each hop you will notice that the addresses are 10.2.0.1 and 10.2.0.3 and then back to 10.2.0.1. This is known as a routing loop, where each router is sending the packet back to the other, and although there are thirty hops shown here (this is a limit set by traceroute), IP packets tend to have a time to live (TTL) of 255, which means the packet would have 255 hops before it expires. forms a loop. https://en. wikipedia.org/wiki/Routing_ loop_problem So an address was used that didn’t exist on the network, and one could argue that this is unlikely in a real network. But what if the trafﬁc was destined for 10.10.0.0/24 and that interface is down? vMX2 won’t be able to reach that subnet and so would send the trafﬁc back to vMX0. At this point, your link between vMX0 and vMX2 is now congested. Summary Although static routes are a very basic way of advertising routes across a network, they can still be very useful on a small network, they are fairly straightforward to implement, and easy to understand. By understanding static routes better we can apply this knowledge to the dynamic routing protocols so that we get a better feel for what they are trying to achieve. When it comes to default static routes, care should be taken to use them only where appropriate and one must never put default static routes on two devices that are facing each other, as doing so can bring a small network to a halt. The main place a static route would be used on almost any network is on an Internet facing router, where, without BGP, the administrator assumes that any trafﬁc that is not advertised within the LAN or WAN be on the Internet somewhere. The next chapter provides an overview of the types of routing protocols, before we begin to look at the individual protocols themselves. Chapter 2 Routing Protocol Preference and Type When businesses expand, their networks need to expand, too. If your company is currently running a protocol that will not be able to cope with a future expansion, the routing protocol needs to be migrated to one that can cope with increased capacity. Theoretically speaking, if your network size currently consists of forty routers, it is fairly safe to assume that it would take approximately ﬁve minutes to remove the old routing protocol and add the new one, thus taking 3 hours and 20 minutes to complete the operation. Unfortunately, as soon as the administrative engineer removes the old routing protocol, network connectivity is lost, therefore the engineer needs to physically visit each router and conﬁgure each device using the local console cable, an operation that could take upwards of four hours or more, especially if an issue is found along the way. As you no doubt agree, this is an unacceptable amount of downtime, even if the expansion is made during the evening hours. To assist in situations like this, the Junos OS allows you to run multiple routing protocols on the same router at the same time. The administrative engineer can simply add the new routing protocol, then once all the routers have been updated the process of removing the old protocol can begin. In theory, a router running the Junos OS can run all of the routing protocols at the same time. But in the real world this is unlikely, as it would only serve to increase memory and CPU usage. So it is fairly common to never have more than two protocols running concurrently, mostly because, with multiple routing protocols running at the same time, the issue becomes which protocol should the router believe? 22 Day One: Routing the Internet Protocol For example, suppose that RIP is advertising that subnet 10.1.1.0/24 is accessible via the next-hop 192.168.0.1, but OSPF is advertising that the same subnet is accessible via the next-hop 192.168.0.254. Which next hop should the router use? Administr ative Distance: An arbitrar y numerical value assigned to a routing protocol , a static route, or a directlyconnected route based on its perceiv ed quality of routing . https://en.wikipedia .org/wi ki/ Administr ative_d istance Table 2.1 To resolve this issue, each routing protocol is given what is known as an administrative distance, a number ranging from 1 to 255, in which the lower the number the more believable the routing protocol is to the device. Therefore, if a router running the Junos OS is running two routing protocols, then in the case where a router has two competing routes, the router will simply look at the administrative distance and choose the one with the lowest number. Table 2.1 lists the routing protocols covered in this book in order of appearance. You may notice that static routes, which were covered in Chapter 1, have an administrative distance of just 1. This means that if an administrator added a static route to a destination, it would immediately override any matching route from, say, RIP or OSPF, even if that route information is incorrect . Administrative Distances for Routing Protocols Protocol Default Administrative Distance Static Routes 5 RIP 100 OSPF 10 IS-IS Level 1 15 IS-IS Level 2 18 BGP 170 ADs and Static Routes As Table 2.1 indicates, these are default administrative distances, and they can be modiﬁed so that one protocol is preferred over another. For example, if a static route was conﬁgured as follows: [edit] [email protected]# set routing-options static route 10.10.1.0/24 next-hop 10.2.0.3 125 Then the administrative distance of that route would be set at 125, which is higher than RIP, OSPF, and IS-IS, meaning that the router wouldn’t consider using that route unless one of the other routing protocols stopped advertising it ﬁrst. An administrator could also elect to add two default static routes to a router like this: Chapter 2: Routing Protocol Preference and Type [edit] [email protected]# set routing-options static route 0.0.0.0/0 next-hop 10.2.0.3 1 [edit] [email protected]# set routing-options static route 0.0.0.0/0 next-hop 10.3.0.2 250 With this conﬁguration, the router will always use the next hop of 10.2.0.3 as the default route as this has an AD of 1, however if the interface on subnet 10.2.0.0/24 goes down, then the router will withdraw the route and will immediately begin using the next hop of 10.3.0.2 as the default route, thereby providing some redundancy in the event of a failure. Route Preference by Longest Match In addition to using the administrative distance, routers can also use the longest preﬁx to ﬁnd the most reliable route; in other words, the router will compare the subnet it is trying to reach with all the routers in its routing table. The route that matches the most number of bits is the best route. Let’s brieﬂy explain the most number of bits, using the subnet 10.168.0.0/16, that will convert into binary. The most important thing to note is the /16, which means the ﬁrst 16 bits of this IP address are important and the remaining 16 bits will be ignored , therefore the last two octets will be all zeroes. So the Subnet 10.168.0.0/16 in binary will appear as follows: 10.168.0.0 Now, let’s suppose that the router was to look at the routing table and it identiﬁed the following routes: 192.168.0.0/1 6 10.0.0.0/8 10.10.0.0/16 10.168.192.0/ 24 172.16.0.0/24 0.0.0.0/0 *[RIP/100] 00:17:24, metric 2, > to 172.23.3.1 via ge-0/0/0.0 *[RIP/100] 00:17:58, metric 2, > to 172.23.7.2 via ge-0/0/2.0 [RIP/100] 00:17:58, metric 2, > to 10.20.0.1 via ge-0/0/3.0 *[RIP/100] 00:17:58, metric 2, > to 172.23.3.1 via ge-0/0/0.0 *[RIP/100] 00:17:58, metric 2, > to 172.23.3.1 via ge-0/0/0.0 *[RIP/100] 00:17:58, metric 2, > to 1.1.1.1 via ge-0/0/4.0 tag 0 tag 0 tag 0 tag 0 tag 0 tag 0 You should notice that the ﬁrst and ﬁfth routes aren’t even close, and these can be discounted. The last route, 0.0.0.0/0 is a default route, meaning it does not match anything else in the routing table, so the router should use this route. But let’s put this in the maybe pile for a moment. 23 24 Day One: Routing the Internet Protocol All the other routes begin with 10, therefore they are possible matches. To conﬁrm which one would be the better route, they should be converted into binary before comparing, as shown in Figure 2.1: Figure 2.1 Route Converted Into Binary The subnet required had a /16 preﬁx; these octets are highlighted. For there to be a match, the binary numbers should be the same in the octet and in the ﬁrst box. This is the case. In the second box it is obvious that the subnet 10.10.0.0/16 doesn’t match, therefore this can be discounted, too. Route 10.0.0.0/8 is interesting, however. Although the second octet doesn’t match, the route is only a /8 preﬁx. This means only the ﬁrst octet needs to match. This one is also a possible route. Finally, the route to 10.168.192.0/24 needs to be taken into consideration. With this route both the ﬁrst and second octets match. This route, however, is a /24 preﬁx, which means the third octet needs to be taken into account as well. As the example subnet was a /16, the last 16 octets were all zeroes and this means this route does not match. In the end, there can only be one winning route. Out of the six routes in the routing table, there are only two that are viable options: 0.0.0.0/0 and 10.0.0.0/8. As the 10.0.0.0/8 has one matching octet, this is the route the router would choose to forward the packet to the 10.168.0.0/16 subnet. Chapter 2: Routing Protocol Preference and Type Protocol Types It goes without saying that all of the routing protocols in this book operate in completely different ways. The types of routing protocol can be broken down into four main groups, however: Distance Vector, Link State, Path Vector, and the fourth, a hybrid protocol developed by Cisco Systems known as EIGRP, which is not covered in this Day One book. Looking at Table 2.2, it is evident that RIP is the only distance vecto protocol. Several years ago there were more distance vector protocols in use, though RIP is the only protocol to stand the test of time. Both IS-IS and OSPF are link-state protocols. Table 2.2 Routing Protocol Types Distance Vector Protocols : A distance-vect or routing protocol is one of the two major classes of intra-domain routing protocols, the other major class being the link-state protocol. https://en.wikipedia.org/wiki/ Distance-vector_routing_ protocol Protocol Protocol Type RIP Distance Vector OSPF Link State IS-IS Link State eBGP Path Vector iBGP Path Vector Distance vector protocols work in a very simple way – by counting the number of hops between the source and destination addresses. Where there are multiple paths between the source and destination, the path with the shortest number of hops is the preferred route. Figure 2.2 shows an example of how a distance vector protocol chooses the preferred route and it also shows a weakness in its design. In this example the workstation wishes to communicate with the server. There are two paths to take, one crosses a 2Mb serial link directly between the two routers, and the other uses 10Gb links that cross two more routers. 25 26 Day One: Routing the Internet Protocol Figure 2.2 Distance Vector Preferred Path Distance vector protocols compare these paths and they will see that there are two hops one way and four hops the other, and although you can see that the 10Gb path is obviously the best as far as the distance vector protocol is concerned, the two-hop path is the shortest, so the device running the Junos OS will use that instead. If this was a LAN and all links were 100Mb or 1Gb, then a distance vector protocol would make the correct choice. The only real downsides in this situation would be that distance vector protocols don’t scale very well, and in the event of link failures are slow to converge. Link-state routing protocols are one of the two main classes of routing protocols used in packet switching networks for comp uter communications, the other being distance -vector routing proto cols. https://en.wikipedia .org/ wiki/Link-state_routing_ protocol SPF: Dijkstra's algorithm is an algorithm for ﬁndin g the shorte st paths between nodes in a graph, https://en.wikipedia .org/ wiki/Dijkstra%27s_algorithm On the other hand, OSPF and IS-IS are link state protocols and they take into account something other than distance: speed. Link state protocols refer to this particular metric as cost, and what these protocols do is calculate the speed of all the links along all the paths and then decide which path has the lowest cost. When link state protocols calculate the lowest cost, they run what is known as the shortest path ﬁrst algorithm or SPF. This algorithm, developed by a Dutch computer scientist named Edsger Dijkstra, is quite complex but can be simpliﬁed. Figure 2.3 shows a map with several points on it. Each point is assigned a letter and is connected to another point. If you imagine for a moment that you are at point A, the algorithm begins by stating that the cost to you is always 0. Chapter 2: Routing Protocol Preference and Type Figure 2.3 SPF Algorithm Simpliﬁed The next step is to discover whether or not you have neighbors, and if so what the cost is to get to them. In this example, the neighbors are B and C and the cost to them is 5 and 10, respectively. This information is then saved to a database called the link state database. Once this is done, you then ask your neighbors who their neighbors are, and the respective cost to them, and this information is also placed into the link state database. This process continues until you know each point on the map and the costs between them. Once done, the algorithm begins to calculate the lowest cost between each point, for example the cost between A and D would be 5 + 1 or a total of 6. While this information is being calculated, a router places this data into a second database known as the candidate database. Finally, when the algorithm is complete, you should have a complete map of every point and detail of the lowest cost path to each point, and in the case of a router the data is moved to a third database known as the SPF database, which can be used as a rapid means of ﬁnding the lowest cost path without running the algorithm again. As an example, if point A needs to reach point F, by looking at the cost of each link you can see that if the path was A-C-F then the cost would be 60, however, if the path was A-B-D-G-I-H-F, the path would in fact have a cost of 18, therefore, although it has more hops, this least-direct path would in fact be the best. If the example used in Figure 2.4 is changed so that the routers now use a link state routing protocol, you can see that instead of using the slowest link with only two hops, the link state protocol will use the four hop path with the much higher link speed . 27 28 Day One: Routing the Internet Protocol Figure 2.4 Link State Preferred Path On the other hand, path vector protocols work slightly differently due to the size of the networks they operate on, speciﬁcally the Internet. BGP Best Path A path vector protocol is a BGP is a third category of routing protocol. In a way, it’s very similar to RIP in that it uses a metric similar to hops to ﬁnd the best route, but instead of using hops or distance it uses what is known as autonomous systems, which are referred to as paths. For this reason, BGP is known as a path vector protocol . computer network routing protocol which maintains the path information that gets updated dynamically. https://en.wikipedia .org/wi ki/ Path_vector_protocol . BGP does not advertise the speed of each link connecting each router in the way that OSPF and IS-IS do, but then put this into context – BGP is used to advertise routes that make up the Internet. When a network has as many subnets as the Internet contains, then in reality knowing the speed of individual links will not help in choosing the best path. In fact, the extra processing involved by knowing the account link speeds will slow the router down considerably, thus negating any speed increase that may be gained by knowing what link speeds are. Although BGP is covered in great detail in Chapter 7, a brief overview is given here as an introduction and to provide a comparison against distance vector and link state protocols. BGP ﬁnds the best route because ISPs, service providers, telephone companies, and other organisations with extensive Internet connectiv- Chapter 2: Routing Protocol Preference and Type ity are given a number called an AS or Autonomous System number. This number is applied to all routers in their networks. BGP routers exchange information about what subnets are in their own AS with routers that are in neighboring ASs. In turn, those neighbors inform their neighbors of those subnets, while also sending information about subnets they have knowledge of back to the original AS. The end result is that each BGP router has a database known as the BGP table that lists every subnet on the Internet and to which AS they belong. From this a map can be built that details through which AS trafﬁc must pass before reaching any given subnet. Once the BGP table is complete, BGP can run the best path algorithm and place the subnets into the routing table based on the shortest number of ASs the packet must traverse. Using Figure 2.5 as an example, you see that ACME Company is in AS1 and subnet 9.9.9.0/24 is in AS9. There are two possible paths to AS9 from AS1: one via AS2, AS10, AS20, and AS30, and the other via AS3, AS15, and AS25. By using the best path algorithm, the border router in AS1 will see that the path via AS3, AS15, and AS25 is the shortest and will therefore use this to reach that subnet. Figure 2.5 BGP Best Path 29 30 Day One: Routing the Internet Protocol Summary When the question “What is the best type of routing protocol to use on my network?” is asked, the answer is, “It depends on how big your network is and how it connects to the outside world.” Smaller networks consisting of only 10 subnets are more suited to distance vector, whereas larger WAN’s with hundreds of subnets across multiple sites are more suited to link state. Finally, if your company has multiple web servers, you may be running a path vector protocol. There are, of course, several occasions where a company may be running several types, such as during an acquisition, for example, or a company may run a link state protocol at its HQ and run distance vector in branches. The next few chapters discuss each protocol in depth and will hopefully allow you to make a more informed decision as to which protocol is more appropriate given a certain circumstance. Chapter 3 Route Information Protocol (RIP) In the networking world, RIP is quite an old routing protocol. It has endured because of its simplicity, despite its apparent drawbacks, because it does what it was designed to do: advertise routes to other routers with a minimum of fuss. There are in fact three versions of RIP, v1 (v1) and v2 (v2) were designed for IPv4, and RIPNG, which is designed for IPv6. MORE? IPv6 will not be covered in this book, however anyone wishing to study RIPNG can ﬁnd more great information at the Juniper TechLibrary: https://www.juniper.net/documentation/en_US/ junos14.2/information-products/pathway-pages/conﬁg-guide-routing/conﬁg-guide-routing-ripng.html . RIP v1 and RIP v2 are covered, however, and it’s important to know the differences between them. But regardless of which version is in use on a network, all of them have a limitation that can affect the decision to deploy it in a live environment — the maximum router width within the LAN. Figure 3.1 shows an example network where routers are connected to each other in a chain. 32 Day One: Routing the Internet Protocol Figure 3.1 RIP Route to Inﬁnity In Figure 3.1, Router A is at one end of the chain and at the other end is Subnet 192.168.17.0/24. There are exactly sixteen routers between Router A and the subnet and this poses a problem as the metric data within a RIP update packet is stored in a 4-bit ﬁeld. This means the maximum number of values in this ﬁeld is sixteen. In addition to the sixteen-value limitation, when RIP was being created the designers built in a way for RIP to be able to withdraw a route; this meant that one of these sixteen values was reserved for this purpose. As RIP is a distance vector protocol, its metric is hops, which in turn means the maximum metric for RIP is ﬁfteen. When the metric reaches sixteen, this is classed by RIP as inﬁnity and RIP withdraws the route. In summary, the maximum router width in a network using RIP is ﬁfteen and as the diagram in Figure 3.1 shows, sixteen hops after Router A, Router A will never be able to reach Subnet 192.168.17.0/24 and in turn, the router connected to that subnet won’t be able to reach the subnet behind Router A. RIP Versions The differences between RIP v1 and v2 are quite substantial, so much so that you would be hard pressed to ﬁnd a LAN still running v1. The reason for new versioning was a rapid growth in corporate LANs and the realization that there was only a ﬁnite supply of available IP addresses. During the 1990s, IP addresses were issued to companies in their A, B, and C classes. Whole ranges were provided, for example, Class C block consisting of 254 addresses would be issued even if the company only required 10 addresses. Not long afterwards, the authorities who Chapter 3: Route Information Protocol (RIP) issued these addresses realized that this was a waste and a decision was made to move from what was known as classful to classless addresses. With classless addresses, a Class A block, which would normally provide 16777214 addresses, could be divided into subnets, which for example, could contain 254 addresses, or a Class C network could be divided into eight subnets, providing each customer with 30 client addresses. One of the major differences between RIP v1 and RIP v2 is that RIP v1 is not aware of these classless addresses whereas RIP v2 is. An example of why this could cause problems in a network is shown in Figure 3.2. In Figure 3.2 there are three routers. The networks attached to Routers A and C are Class A subnets, both starting with 10.x.x.x, whereas the networks connecting them through Router B are Class C networks. Router B also has a third subnet connected to it which is a client. Figure 3.2 Classless Networks in RIP V1 When the client wishes to communicate with the server, Router B will receive the packet and the lookup on its routing table to see the next hop. The issue is, with RIP v1 the router will only see the network 10.0.0.0/8 and two possible next hops, Router A or Router C. Sometimes the packet will be sent the right way – but that doesn’t make for a reliable network. When the classless subnets are connected to the same router, then RIP v1 doesn’t have an issue. The issue occurs when the routing advertisements are sent to a neighbor, and this advertisement will be sent as a classful advertisement and not as a classless subnet. RIP v2 doesn’t suffer from this issue, and as most networks use classless subnets now, it makes it all but impossible to use RIP v1 in any modern network. Another major difference between RIP v1 and v2 is the way advertisements are sent. RIP v1 sends advertisements as broadcasts, which 33 34 Day One: Routing the Internet Protocol means every device on the network receives the update, including clients and servers, whether they want to receive them or not. This increases the amount of trafﬁc on the network and could cause delays on the clients and servers as they attempted to process then discard the broadcast. RIP v2 updates are sent as multicast packets, which means they are only sent to devices that subscribe to those updates, which would usually be routers or Layer 3 switches; however, very occasionally, an administrator may set a workstation or a server to receive RIP updates if they had multiple network adapters so the server would know through which adapter a packet should be sent. Conﬁguring RIP Figure 3.3 details the topology that will be used in this section about conﬁguring RIP. Figure 3.3 RIP Topology There are three routers each connected to each other via 172.23.x.x subnets. Router vMX3 is also connected to subnet 10.10.2.0/24 and vMX4 is connected to subnet 10.5.0.0/24. Both of these subnets need to be advertised into RIP so that router vMX6 can reach them. RIP updates, however, should only be sent between these routers and not sent out to the interfaces connected to subnets 10.10.2.0/24 and 10.5.0.0/24. While it may not seem like an issue at ﬁrst, sending updates out of an interface to which no RIP neighbor is connected after all would mean RIP would just multicast the packets out without any device responding. The reality is that attackers can exploit this misconﬁguration, and Chapter 3: Route Information Protocol (RIP) as such inject false routes into, or gain knowledge of, the subnets in use on a corporate network or even access the network resources across the WAN. The second issue with sending updates out of an unnecessary interface is that it requires bandwidth, even though this is going to affect a serial link more. When updates are prevented from being sent out of an interface it is known as making the interface a passive interface. The conﬁguration of RIP is very different when compared to the other routing protocols covered in this book because Junos OS requires you to create a group and then assign interfaces to that group. As you shall see later on in this book, the other protocols assign interfaces to include in advertisements in a different way. The ﬁrst router to be conﬁgured is vMX3. As mentioned in the last paragraph, a group needs to be created, and in this case the group will be given the name RIPGROUP. After the group name, the neighbor option tells RIP which interfaces to include in the updates to neighbors. The last command ends with the option send none. This option tells RIP not to send updates out of that interface but to include it in advertisements: set protocols rip group RIPGROUP neighbor ge-0/0/0.0 set protocols rip group RIPGROUP neighbor ge-0/0/1.0 send none set protocols rip group RIPGROUP neighbor ge-0/0/2.0 Similar commands will be added to vMX4. In this case it just so happens the subnet 10.5.0.0/24 is connected to ge-0/0/1.0, therefore the send none option will be included after this interface, too: set protocols rip group RIPGROUP neighbor ge-0/0/0.0 set protocols rip group RIPGROUP neighbor ge-0/0/1.0 send none set protocols rip group RIPGROUP neighbor ge-0/0/2.0 Router vMX6 only has two interfaces in the RIP domain and one passive interface, therefore the conﬁguration for these is as follows: set protocols rip group RIPGROUP neighbor ge-0/0/0.0 set protocols rip group RIPGROUP neighbor ge-0/0/1.0 set protocols rip group RIPGROUP neighbor ge-0/0/2.0 send none Once the conﬁguration is complete, the best way to check that advertisements are being sent between routers is to use the show rip neighbor command: [email protected]> show rip neighbor Local Source Neighbor State Address ------------ ------ge-0/0/0.0 Up 172.23.3.1 ge-0/0/1.0 Up 10.10.2.2 ge-0/0/2.0 Up 172.23.1.1 Destination Address ----------224.0.0.9 zero-len 224.0.0.9 Send Mode ---mcast none mcast Receive Mode ------both both both In Met --1 1 1 35 36 Day One: Routing the Internet Protocol This command lists the interface, whether the interface is up or down, and the source address of advertisements sent out to interfaces that would be the unicast address of that interface and the destination address, which is in this case is the multicast address RIP uses to send advertisements. The Send Mode tells you how the updates are being sent, for example, by multicast or by broadcast, while the Receive Mode lets the administrator know which version RIP can receive, and the last column is the metric assigned to that interface, which would typically be 1, but under special circumstances can be increased by conﬁguring a policy to make an interface less favourable to RIP. You may notice in the output for interface ge-0/0/1.0 that the destination address is set as zero-len and the send mode is set as none. This means that this interface is a passive interface, so no updates are sent out of it, although it can still receive updates. The requirement of having to assign interfaces to a group is not the only difference RIP has compared to the other routing protocols. By default, when RIP is enabled, it will send and receive updates, however the updates it sends will be empty, because by default, RIP will not advertise anything. As an example, if you were to look at the routing table by using the show route command, you would see that there are no routes present: [email protected]> show route protocol rip inet.0: 18 destinations, 21 routes (18 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 224.0.0.9/32 *[RIP/100] 00:01:06, metric 1 MultiRecv To resolve this issue, a policy statement needs to be created that says if a subnet is either directly connected, or if it comes from a RIP advertisement from another router, then the router creates a match. Let’s try this policy-statement: set policy-options policy-statement RIP term 1 from protocol direct set policy-options policy-statement RIP term 1 from protocol rip set policy-options policy-statement RIP then accept Once the router ﬁnds a match, it informs RIP that those subnets match the statement, and RIP then exports these subnets as RIP advertisements: set protocols rip group RIPGROUP export RIP Once this has been committed and the show route command has been run once more, routes should be visible in the routing table: [email protected]> show route protocol rip inet.0: 15 destinations, 19 routes (15 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both Chapter 3: Route Information Protocol (RIP) 10.10.2.0/24 10.10.3.0/24 10.233.240.0/ 20 172.23.1.0/24 224.0.0.9/32 *[RIP/100] 00:17:24, > to 172.23.3.1 via *[RIP/100] 00:17:58, > to 172.23.7.2 via [RIP/100] 00:17:58, > to 172.23.3.1 via to 172.23.7.2 via *[RIP/100] 00:17:58, to 172.23.3.1 via > to 172.23.7.2 via *[RIP/100] 00:14:24, MultiRecv metric 2, tag ge-0/0/0.0 metric 2, tag ge-0/0/2.0 metric 2, tag ge-0/0/0.0 ge-0/0/2.0 metric 2, tag ge-0/0/0.0 ge-0/0/2.0 metric 1 0 0 0 0 It is interesting to note that there is a subnet 10.233.240.0/20 being advertised by RIP. These are the IP addresses of management interfaces of the vMX routers that were added to the routers automatically by Junosphere in this book’s lab. Because the policy statement said to match directly connected subnets, and these interfaces are directly connected, RIP advertised them, too. One ﬁnal test, of course, is to initiate a ping across the network. In this instance, vMX6 will ping vMX3’s interface in subnet 10.10.2.0/24: [email protected]> ping 10.10.2.2 PING 10.10.2.2 (10.10.2.2): 56 data bytes 64 bytes from 10.10.2.2: icmp_seq=0 ttl=64 time=7.327 ms 64 bytes from 10.10.2.2: icmp_seq=1 ttl=64 time=2.560 ms 64 bytes from 10.10.2.2: icmp_seq=2 ttl=64 time=28.062 ms 64 bytes from 10.10.2.2: icmp_seq=3 ttl=64 time=145.958 ms ^C --- 10.10.2.2 ping statistics --4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.560/45.977/145.958/58.515 ms Conﬁguring a Version Speciﬁc RIP Regardless of how outdated RIP v1 is and how unlikely it is to ﬁnd this version working on a modern network, it does not mean you won’t ever ﬁnd it, and as such, by default, the Junos OS does allow RIP to receive v1 and v2 updates. By default, if RIP receives a neighbor update in v1, it will send updates to that neighbor as v1. Within the Junos OS it is possible to set RIP to send updates as v1 or v2 only, and to only listen for v1 or v2 updates. The purpose of this is to allow for backwards compatibility with older devices that happen to still be in use. The Junos OS also allows an administrator to tell RIP to send v2 updates as broadcasts, as opposed to multicasts – it is unlikely this option would be used, but it is included in order to be compliant with the RIP RFC. In order to demonstrate what this looks like in the Junos OS, routers vMX3 and vMX4 will be conﬁgured to send updates to each other as v1 updates. To achieve this the command begins as if an interface was being added, after which the keyword send would be added followed 37 38 Day One: Routing the Internet Protocol by the desired option. By using the context sensitive help ( ? ), it is possible to see what these options are. (One of these options, none, was used earlier when the interface was made passive.) [edit] [email protected]# set protocols rip group RIPGROUP neighbor ge-0/0/0.0 send ? Possible completions: broadcast Broadcast RIPv2 packets (RIPv1 compatible) multicast Multicast RIPv2 packets none Do not send RIP updates version-1 Broadcast RIPv1 packets The available options mean: broadcast, which would mean RIP v2 updates would be sent as broadcast, multicast, which is the default, and version-1, which means the updates would be sent as RIP v1 only. In this case the version-1 option would be used. So the command is: set protocols rip group RIPGROUP neighbor ge-0/0/0.0 send version-1 Next, let’s conﬁgured it to listen only for v1 updates, meaning it would not subscribe to multicast updates for RIP. The command is the same as before, however, this time the keyword receive is used: [edit] [email protected]# set protocols rip group RIPGROUP neighbor ge-0/0/0.0 receive ? Possible completions: both Accept both RIPv1 and RIPv2 packets none Do not receive RIP packets version-1 Accept RIPv1 packets only version-2 Accept only RIPv2 packets The options in this case are to listen for both, none, and either version-1 or version-2. In this case the version-1 option is speciﬁed. Once this has been committed it is possible to see what effect it has had by using the show rip neighbor command: [edit] [email protected]# set protocols rip group RIPGROUP neighbor ge-0/0/0.0 receive version-1 [edit] [email protected]# commit commit complete [edit] [email protected]# run show rip Local Neighbor State -----------ge-0/0/0.0 Up ge-0/0/1.0 Up ge-0/0/2.0 Up neighbor Source Address ------172.23.3.1 10.10.2.2 172.23.1.1 Destination Address ----------172.23.3.255 zero-len 224.0.0.9 Send Mode ---v1 none mcast Receive Mode ------v1 only both both In Met --1 1 1 As you can see, the destination address has changed from the multicast address to the broadcast address for the subnet, in addition the modes are showing as “v1.” If the option was then changed to broadcast, this should also be reﬂected in the show rip neighbor command as the send mode would change to broadcast: Chapter 3: Route Information Protocol (RIP) [edit] [email protected]# set protocols rip group RIPGROUP neighbor ge-0/0/0.0 send broadcast [edit] [email protected]# commit commit complete [edit] [email protected]# run show rip Local Neighbor State -----------ge-0/0/0.0 Up ge-0/0/1.0 Up ge-0/0/2.0 Up neighbor Source Address ------172.23.3.1 10.10.2.2 172.23.1.1 Destination Address ----------172.23.3.255 zero-len 224.0.0.9 Send Mode ---bcast none mcast Receive Mode ------v1 only both both In Met --1 1 1 RIP Timers Once RIP learns a route it is just a matter of time before that route will not be available, either due to maintenance, network migration, or even failure, meaning that the subnet is unreachable. No matter the cause, RIP has two ways of withdrawing routes from the routing table. The ﬁrst method, mentioned brieﬂy earlier, is that the advertising router advertises that subnet with a metric of 16, which means all other routers will withdraw the route from their routing table. The second method is by the use of timers. More on RIP and Timers: The RIP uses three timers to maintain a stable network. Routing Information Protocol (RIP) is one of the oldest  Once a route is installed in the routing table, it needs to be refreshed at a regular interval. If the route has not been refreshed within a certain amount of time, then it is marked as invalid. This is known as route-timeout . The default value is 180 seconds, however, the administrator can adjust this to 30 seconds for faster convergence, or increase it to 360 seconds for slow links where updates could be dropped.  The Holddown timer is a period of time that occurs either after the route has been marked as invalid, or when the metric is set as 16 and before it is ﬁnally withdrawn from the routing table. The invalid route is held in the routing table during this period so updates of this invalid route can be passed to neighbors. The default value is 120 seconds but can be changed to a value between 10 and 180 seconds.  The frequency with which updates are sent to neighbors is what is known as the update-interval . This timer is set at 30 seconds by default but it can be changed so that the updates occur as often as every 10 seconds, or can be slowed down so they only occur every 60 seconds. distance-vector routing protocol s that employ the hop count as a routing metric. https://en.wikipedia .org/ wiki/Routing_Information_ Protocol . 39 40 Day One: Routing the Internet Protocol CAUTION Juniper recommends that these timers are left set at their default settings because unless they are set exactly the same for all neighbors on a subnet, routes could ﬂap, causing delays and downtime. The following conﬁguration examples are provided for the reader’s interest and education. Conﬁguring RIP Timers There are several places within the conﬁguration hierarchy where RIP timers can be changed. The ﬁrst is directly under the RIP conﬁguration itself, and by changing these settings, these timers affect all groups on all interfaces: set protocols rip route-timeout 30 set protocols rip update-interval 10 set protocols rip holddown 10 The next place you can change RIP timers is under the group itself. Note that when making changes under the group, the holddown timer cannot be changed (therefore the holddown timer must be changed under the RIP hierarchy): set protocols rip group RIPGROUP update-interval 10 set protocols rip group RIPGROUP route-timeout 30 The last location is under the neighbor itself. When making the change here, all neighbors on that subnet must have the same conﬁguration changes made, otherwise loss of service can occur: set protocols rip group RIPGROUP neighbor ge-0/0/0.0 update-interval 10 set protocols rip group RIPGROUP neighbor ge-0/0/0.0 route-timeout 30 Routing Loop Prevention Split Horizon: Split-horizon route adverti sement is a method of preventing routing loops in distance-vector routing protocol s by prohibiti ng a router from advertising a route back onto the interface from which it was learned. https://en.wikipedia .org/wi ki/ Split_ horizon _rou te_ adverti sement In order for full reachability to occur on a network, all routers in the network must have an exact copy of the same database. This means that when RIP receives an update, by default, this update is automatically sent out to all neighbors. However, there is one exception – RIP will never send an update from the same interface on which it was received – that’s called a split horizon. If RIP did not have this mechanism then it would be possible that neighbors would think that a subnet advertised in that update was reachable through the router that was simply forwarding the update, and as such, if that subnet was unreachable via the original advertising router, the original router would forward the packet to the advertising router, which would forward it back to the original router, thus causing a loop. Chapter 3: Route Information Protocol (RIP) Under normal circumstances this would never need to be turned off, however if the router was a hub connected to a point-to-multipoint frame relay link, or was an SRX device in a HQ connected to multiple branch SRX devices via VPN links, then this would need to be disabled. It’s done like this: set protocols rip group RIPGROUP neighbor ge-0/0/0.0 interface-type p2mp For any other situation, split horizon should be left enabled . RIP Authentication When the initial RIP conﬁguration was performed, some of the interfaces were set as passive interfaces to prevent RIP updates being sent out on unwanted interfaces, thus offering some protection against an attacker gaining information. But you should give consideration to the possibility of an attack taking place on the inside on your subnets where RIP updates are sent. To protect against this, RIP can be conﬁgured to only send updates to neighbors it trusts, and to build this trust, updates can be conﬁgured with an authentication key. This key can be sent as plain text, which could in theory be compromised considering the attacker is already on the inside and could therefore listen for packets carrying the key. Or the key could be sent as an MD5 key, meaning the key is hashed, therefore encrypted, so should an attacker see the packet the key would not be compromised. Conﬁguring RIP Authentication Enabling RIP authentication is relatively simple because it is done globally rather than on a per-interface level, but note that if the Junos OS has multiple RIP groups this change does affect all groups . Conﬁguring the Junos OS to use either plain text or MD5 authentication is simply a matter of using the option simple or md5 after the authentication-type keyword. In this case, routers vMX4 and vMX6 will be conﬁgured to use simple authentication with a password of ITSSECRET: set protocols rip authentication-type simple set protocols rip authentication-key ITSSECRET For a moment let’s check on what would happen during a mis-conﬁguration, let’s say router vMX3 is conﬁgured to use MD5 authentication: set protocols rip authentication-type md5 set protocols rip authentication-key ITSSECRET Once committed, let’s check to see everything is working as expected. Use the show route protocol rip command: 41 42 Day One: Routing the Internet Protocol [email protected]> show route protocol rip inet.0: 11 destinations, 13 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 224.0.0.9/32 *[RIP/100] 00:01:09, metric 1 MultiRecv As you can see, vMX3 is not showing any routes advertised by RIP. When faced with such an issue an administrator needs more information to ﬁnd exactly what’s wrong – and the Junos OS provides an option to debug a particular service and save the output to a ﬁle. To do this, use the traceoptions keyword under the relevant service along with the necessary options. In this case, the output would be saved to a ﬁle named RIPTRACE. The size of the ﬁle will be set as 100000 bits and it would be possible to view this as ASCII text, so anyone who logs into the Junos OS would be able to read it. The last option, flag, tells the Junos OS which components of this service to debug, for example, you could just watch for authentication events or received updates. In this case, the option all is used to include everything: set set set set protocols protocols protocols protocols rip rip rip rip traceoptions traceoptions traceoptions traceoptions file file file flag RIPTRACE size 100000 world-readable all While an administrator could keep entering show log RIPTRACE, if the output is verbose the log ﬁle can grow to quite a size, therefore the better option would be to use monitor start RIPTRACE, which displays the output in the CLI session in real time. The following output was taken from such a scenario and the section highlighted in bold tells why it isn’t receiving updates: Jun 6 05:20:37.473228 task_job_create_ background: create prio 1 job “RIPv2 process rcvd response packet” for task RIPv2 Jun 6 05:20:37.473282 background dispatch running job “RIPv2 process rcvd response packet” for task RIPv2 Jun 6 05:20:37.473301 received response: sender 172.23.3.2, command 2, v1, mbz: 0; 11 routes. Jun 6 05:20:37.473313 Failed last rte on validity of fields 0 Jun 6 05:20:37.473346 RPD_RIP_AUTH_UPDATE: Update with invalid authentication from 172.23.3.2 (ge-0/0/0.0) Jun 6 05:20:37.473363 task_job_delete: delete background job “RIPv2 process rcvd response packet” for task RIPv2 Jun 6 05:20:37.473607 background dispatch completed job “RIPv2 process rcvd response packet” for task RIPv2 CAUTION While the traceoptions command can be useful, it is important to bear in mind that this command can ﬁll the storage on the device running the Junos OS and could lead to high CPU usage. So once you have identiﬁed and corrected the cause, the traceoptions should be deleted as soon as it’s convenient. Chapter 3: Route Information Protocol (RIP) In this case, the show rip statistics command can also be used. The following output shows that there have been 11 authentication failures in total, three of which were in the last minute, meaning that this wasn’t an initial issue before authentication was enabled on all routers, but now is an issue: [email protected]> show rip statistics RIPv2 info: port 520; holddown 120s. rts learned rts held down rqsts dropped 0 4 0 resps dropped 0 ge-0/0/0.0: 0 routes learned; 6 routes advertised; timeout 180s; update interval 30s Counter Total Last 5 min Last minute ----------------- ----------- ----------Updates Sent 359 10 2 Triggered Updates Sent 10 1 1 Responses Sent 0 0 0 Bad Messages 0 0 0 RIPv1 Updates Received 1126 20 3 RIPv1 Bad Route Entries 0 0 0 RIPv1 Updates Ignored 0 0 0 RIPv2 Updates Received 23 0 0 RIPv2 Bad Route Entries 0 0 0 RIPv2 Updates Ignored 0 0 0 Authentication Failures RIP Requests Received RIP Requests Ignored none 11 3 0 0 10 3 1 0 0 0 0 0 After correcting the authentication type on vMX3, the router should immediately begin receiving updates once more, and the routing table should display all routes again quite quickly: [edit] [email protected]# set protocols rip authentication-type simple [edit] [email protected]# commit commit complete [edit] [email protected]# run show route protocol rip inet.0: 14 destinations, 17 routes (14 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.5.0.0/24 10.10.3.0/24 10.233.240.0/ 20 172.23.7.0/24 224.0.0.9/32 *[RIP/100] 00:02:48, > to 172.23.3.2 via *[RIP/100] 00:02:45, > to 172.23.1.2 via [RIP/100] 00:02:48, to 172.23.3.2 via > to 172.23.1.2 via *[RIP/100] 00:02:48, > to 172.23.3.2 via to 172.23.1.2 via *[RIP/100] 00:02:48, MultiRecv metric 2, tag ge-0/0/0.0 metric 2, tag ge-0/0/2.0 metric 2, tag ge-0/0/0.0 ge-0/0/2.0 metric 2, tag ge-0/0/0.0 ge-0/0/2.0 metric 1 0 0 0 0 43 44 Day One: Routing the Internet Protocol Summary RIP can be an ideal protocol for small networks; as long as the network isn’t wider than 16 routers, RIP would work. In the real world, however, when a network has more than 20 subnets the administrator should consider a more suitable alternative. The next chapter discusses a protocol that can scale to a level not yet considered when RIP was conceived; nevertheless, RIP can still play an important part in modern networks and in yours. Chapter 4 Open Shortest Path First (OSPF) OSPF is probably the most popular routing protocol in use today because it is scalable and offers rapid convergence. The only drawback, compared to RIP, is that it is slightly more complex to conﬁgure and in order to achieve the high level of scalability it needs to be conﬁgured correctly. Link state advertisements: communicate the router’s local routing topology to all other local routers in the same OSPF area. https://en.wikipedia. org/ wiki/Link-state_ advertis ement As mentioned in Chapter 1, OSPF is a link state protocol . It uses the SPF algorithm to determine the best or shortest path. Before the SPF algorithm can be run, however, the router needs to learn what other routers and subnets are on the same network as it is, and the way it achieves this is by using l ink state advertisements (LSAs). In fact, a router uses several LSA types to populate the link state database. The ﬁrst LSA type, router or LSA type 1 , is used to identify which routers are on the network and which links and which networks are connected to those routers. The second LSA type, network or LSA type 2 , is generated by what is known as the designated router or DR. When there are multiple routers on the same subnet, to save processing cycles one of the routers is made a DR. The purpose of the DR is to reduce and centralize the trafﬁc that is exchanged between routers on that subnet, so all routers communicate their presence with the DR, and the DR then sends the information about routers on that network to all routers. In addition to a DR, OSPF also designates a second router as a backup designated router (BDR). The purpose of this router is to take over should the DR fail. The DR and BDR are decided by a process when the administrator has set a priority on the routers in a LAN segment, and the router with the highest priority becomes the DR and the router with the second highest becomes the BDR. If all routers have the same priority, then the router 46 Day One: Routing the Internet Protocol with the highest router ID becomes the DR. In the case of point-topoint networks, for example, where two routers are connected via a serial link, then no DR election process takes place. LSA types 1 and 2 always stay within their area, so therefore summary or type 3 LSAs are created by Area Border Routers (ABRs) and are sent between OSPF areas instead. These LSAs are a summary of the networks in the areas to which they are attached, for example, if the ABR was in Area 0 and Area 1, then it would summarize the network in Area 0 and send these via an LSA type 3 into Area 1 and at the same time summarize the networks in Area 1 and send those as a type 3 LSA into Area 0. With type 3 LSAs, the ABRs establish themselves as the advertising router instead of passing on the details of the original advertising router. Sometimes a company may run more than one routing protocol on its network, maybe because of a recent acquisition or because it is in the middle of a migration, but in either case, while the two protocols are running there is a need for each protocol to share the routes it’s learnt with the other. This is known as redistributing . When OSPF imports routes from another protocol, this other protocol is known as an autonomous system (AS) and the router that is performing the redistribution is known as an autonomous system boundary router (ASBR). The purpose of type 4 and 5 LSAs are to advertise the routes learned from the other routing protocol to other routers. Type 4 LSAs are a summary of these routes, similar to the type 3 LSAs, and type 5 LSAs are the complete list of the routes. Table 4.1 summarizes the various types of LSAs, their names, and descriptions of their purposes. Table 4.1 OSPF LSA Types LSA Type LSA Name Description 1 Router These advertise the routers, links, and networks that are in that area. 2 Network Created by a DR as a means of reducing the communication between routers on that subnet. This LSA contains information about that particular network. 3 Summary A summary of type 1 LSAs that are sent between areas by ABRs. 4 Summary ASBR A summary of type 5 LSAs sent between areas. 5 AS Network Networks learned from an external protocol, such as RIP or IS-IS, that have been redistributed into OSPF. 6 Multicast OSPF Obsolete, as multicast is advertised by another protocol, PIM. 7 NSSA Summary Type 5 LSAs are allowed to leave a not so stubby area – which is covered in more depth in the upcoming section Types of OSPF Areas. Chapter 4: Open Shortest Path First (OSPF) Creating a Scalable Network Remember that RIP has a maximum router width of 15 routers. OSPF doesn’t suffer from the same drawback. In fact, an OSPF domain can consist of hundreds routers, and the only limitation is that the maximum metric for OSPF is 65,535 for routes learned via type 1 and type 2 LSAs, and 16,777,215 for routes learned from type 3 and type 4 LSAs. NOTE OSPF Areas: An OSPF network is divide d into areas that are logical groupi ngs of hosts and network s. An area includes its router having interfaces connected to the network. https://en.wikipedia .org/ wiki/Open_Shortest_Path_ First#Area_types Like RIP, OSPF can use these maximum metrics, also known as LSInﬁnity, to withdraw a route from the routing table. By advertising the route with this metric, other routers know that the route is no longer accessible, so they will withdraw it immediately. The key to OSPF’s scalability is the use of what is known as areas. This is a way of dividing up the network into smaller clusters of routers so that during a change in the topology, for example if a link goes down or if a new interface is created, the change is advertised across the network causing the SPF algorithm to run on every router. Note that if the network consists of a large number of routers, the amount of processing involved could slow the routers down, which in turn could have an impact on network trafﬁc. However, if the OSPF domain is divided into smaller segments then the processing required during the topology change is restricted to t hat smaller segment only. Other areas know that subnets in that area are reachable through the same ABR and as long as these ABRs remain up, then there is no need to run the algorithm in the adjoining area. One restriction with areas is that all areas must be directly connected to an area with the number 0.0.0.0, shortened in text to area 0 also known as the backbone area. Figure 4.1 shows an example of an OSPF domain with Area 1 and 2 directly connected to Area 0. Figure 4.1 Example OSPF Domain 47 48 Day One: Routing the Internet Protocol In Figure 4.1, each area is connected to Area 0 via two redundant ABRs. A RIP domain is connected to Area 2. An ASBR connects the RIP domain to the OSPF domain. As a rough guide, an optimal area should consist of between 90 and 100 routers. Above this number you should start considering creating an additional area. In contrast, the beneﬁt of splitting areas is not felt if the area contains less than 50 routers. NOTE Areas consisting of more than 300 routers can be found, however, these tend to contain powerful high-end routers. Conﬁguring OSPF The conﬁguration will be performed on router vMX0 ﬁrst. These set commands indicate which interfaces to use and the areas to which they belong: set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 VMX1 uses similar commands to vMX0 as it just so happens that the same interfaces are in use: set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 Once the conﬁguration has been committed, vMX1 should immediately begin negotiations with vMX0 to become neighbors. You can check on the progress of the negotiations by issuing the show ospf neighbor command, such as in the following output: [email protected]> show ospf neighbor Address Interface 10.4.0.2 ge-0/0/0.0 10.3.0.1 ge-0/0/1.0 10.5.0.2 ge-0/0/2.0 State Loading ExStart Full ID 2.0.0.1 1.0.0.0 1.0.0.4 Pri 128 128 128 Dead 38 38 30 The output would tell an administrator the following:  The Address column is the destination IP address this router uses to communicate with this neighbor.  The Interface column tells the administrator though which interface connectivity to the neighbor is achieved.  The State column details the state of the neighborship. Full means negotiation has ﬁnished and each router has exchanged databases and they agree the information matches, whereas Loading means the database is currently being loaded, and Chapter 4: Open Shortest Path First (OSPF) ExStart means the routers are about to begin exchanging their databases. Another state that is seen on serial links is 2way, but if 2way is seen on an Ethernet link, then it usually means the routers are unable to negotiate successfully and there’s an issue.  The ID ﬁeld details the ID of the neighboring router. This ID is taken from the physical interface with the lowest IP address. If the router has a loopback interface, then the ID is the IP address of the loopback interface. The ID can also be set manually as you will see later in this OSPF chapter.  The y column is short for priority and is used to determine which router on the subnet is a DR. The higher the priority the more preferred the router is to become a DR. If the priority is set to 0, the router will never become a DR.  The last ﬁeld, Dead , is the dead timer which tells the router how long to wait before it declares the neighbor dead should that neighbor stop communicating. This timer should keep resetting itself to 40 every time it receives a keep-alive message from the neighbor. Changing this interval is discussed later on in this chapter. When the conﬁguration is applied to vMX2, the same commands can be used, however vMX2 has two interfaces through which no OSPF neighbors connect, but the subnets connected to these interfaces still need to be advertised across the OSPF domain. For the same reasons as preventing RIP from sending updates out of an interface, to prevent OSPF from sending multicast packets out of an interface, the set protocols ospf area interface command can be followed using the keyword passive: set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 passive Router vMX4 has two interfaces that are in the RIP domain and therefore these should also be designated as passive interfaces. set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 passive set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 passive Testing the OSPF Conﬁguration The easiest way to check the conﬁguration is to look at the routing table to see if the routes have been learned. Use the show route protocol ospf command. If this is run from router vMX2, which is the router at the furthest edge of the OSPF domain, and interfaces from the opposite edge of the OSPF domain appear in the list, then this is a sure sign that all routers are learning all subnets. Let’s see: 49 50 Day One: Routing the Internet Protocol [edit] [email protected]> show route protocol ospf inet.0: 24 destinations, 33 routes (24 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.1.0.0/24 10.3.0.0/24 10.4.0.0/24 10.5.0.0/24 172.23.3.0/24 172.23.7.0/24 224.0.0.5/32 *[OSPF/10] 02:57:21, metric 2 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 02:57:21, metric 2 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 02:57:16, metric 3 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 02:57:16, metric 3 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 02:56:16, metric 4 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 02:56:16, metric 4 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 02:58:19, metric 1 MultiRecv The router at the opposing edge is vMX4 and its connected subnets are 172.23.3.0/24 and 172.23.7.0/24, and sure enough, these appear in the routing table. The ﬁnal test of course would be to ping interface ge-0/0/2.0 of vMX4 from router vMX2: [email protected]> ping 172.23.7.1 PING 172.23.7.1 (172.23.7.1): 56 data bytes 64 bytes from 172.23.7.1: icmp_seq=0 ttl=62 time=18.283 ms 64 bytes from 172.23.7.1: icmp_seq=1 ttl=62 time=6.272 ms 64 bytes from 172.23.7.1: icmp_seq=2 ttl=62 time=5.212 ms 64 bytes from 172.23.7.1: icmp_seq=3 ttl=62 time=8.157 ms 64 bytes from 172.23.7.1: icmp_seq=4 ttl=62 time=6.311 ms ^C --- 172.23.7.1 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 5.212/8.847/18.283/4.812 ms As you can see, received is a reply indicating full connectivity. OSPF Reference Bandwidth One thing that needs to be taken into account while performing the basic OSPF conﬁguration is the speed of the interfaces. OSPF gives a default cost of 1 to interfaces that are 100Mb/s or more. This means that if there are two paths and one crosses a single router but uses 100Mb/s links, and the second crosses three routers but uses 10Gb/s links, OSPF will actually choose the slowest path. To correct this, the reference bandwidth needs to be set on all routers in the OSPF domain. While you could choose the speed of your current fastest link as the reference bandwidth, it is better to think about future link speeds and set the reference to be higher. Let’s run the show route protocol ospf command to see the reference bandwidth with the routers using in our example topology: Chapter 4: Open Shortest Path First (OSPF) [email protected]> show route protocol ospf inet.0: 23 destinations, 26 routes (23 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.3.0.0/24 10.4.0.0/24 10.5.0.0/24 172.23.3.0/24 172.23.7.0/24 224.0.0.5/32 *[OSPF/10] 00:15:43, metric 2 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:01:11, metric 3 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:01:11, metric 3 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:01:11, metric 4 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:01:11, metric 4 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 05:34:02, metric 1 MultiRecv You can see that the metric to 10.3.0.0/24 is 2 and the metric to 172.23.7.0/24 is 4. Let’s set the reference bandwidth to 1000g by adding the following on every router: set protocols ospf reference-bandwidth 1000g If you look at the routing table, you’ll see that the metric to 10.3.0.0/24 is now 2000 and the metric to 172.23.7.0/24 is now 4000: [email protected]> show route protocol ospf inet.0: 23 destinations, 26 routes (23 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.3.0.0/24 10.4.0.0/24 10.5.0.0/24 172.23.3.0/24 172.23.7.0/24 224.0.0.5/32 MultiRecv *[OSPF/10] 00:01:37, metric 2000 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:01:37, metric 3000 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:01:37, metric 3000 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:01:37, metric 4000 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:01:37, metric 4000 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 07:29:22, metric 1 Types of OSPF Areas Earlier in this chapter the backbone area was discussed, and it was explained that each area that is not a backbone area must be directly connected to a backbone area . Well, in addition to the backbone area and normal areas, there are also four other areas that can play an important part in an OSPF domain. These areas are based on a common theme of trying to reduce the amount of LSA’s entering the area, and as such, reducing the size of the database for the routers in that area. 51 52 Day One: Routing the Internet Protocol The ﬁrst area is a stub area. Stub areas do not allow type 4 and type 5 LSAs to be sent into or across an area. Instead, a default route to the ABR is created. These stub areas can help reduce the size of t he database. The size of the database can be reduced even further still, however, by the use of totally stubby areas. With totally stubby areas, type 3 LSAs, together with type 4 and type 5 areas, are also replaced with a default route to the ABR, making for a much smaller database. One issue with stub and totally stubby areas is that not only do the ABRs not allow those types 4 and type 5 LSAs into an area, ABRs also won’t allow those LSA types out, meaning that it would not be possible to import routes from another routing protocol into an area as the LSA types that advertise these external routes are type 4 and type 5. Therefore, not so stubby areas (NSSAs) resolve this issue by converting what would usually be an LSA type 5 into an LSA type 7, which are then allowed into and out of a stub area. The last type of area is known as the not so stubby totally stubby area . This area performs the same role as the NSSA with the difference that routes coming into the NSSA from the backbone area are summarized into a default route. Conﬁguring OSPF Area Types For this scenario, our topology will be changed so that routers vMX2 and interface ge-0/0/2.0 of vMX0 are in Area 1. Interface ge-0/0/1.0 of vMX0 and interface ge-0/0/1.0 of vMX1 are in Area 0, and vMX4 and interface ge-0/0/2.0 of vMX1 are in Area 2, as all are shown in Figure 4.2. For the purposes of showing how type 4 LSAs are affected by conﬁguring area types, RIP has been redistributed into OSPF ( redistribution is covered in more detail in Chapter 6). By using the show ospf database command on router vMX4, you can see what LSAs the router has received: Chapter 4: Open Shortest Path First (OSPF) Figure 4.2 OSPF Areas and RIP [email protected]> show ospf database OSPF database, Area 0.0.0.1 Type ID Adv Rtr Router 1.0.0.0 1.0.0.0 Router *1.0.0.2 1.0.0.2 Network *10.2.0.3 1.0.0.2 Summary 10.3.0.0 1.0.0.0 Summary 10.4.0.0 1.0.0.0 Summary 10.5.0.0 1.0.0.0 Summary 172.23.3.0 1.0.0.0 Summary 172.23.7.0 1.0.0.0 ASBRSum 1.0.0.4 1.0.0.0 OSPF AS SCOPE link state database Type ID Adv Rtr Extern 10.10.3.0 1.0.0.4 Extern 10.233.240.0 1.0.0.4 Extern 172.23.1.0 1.0.0.4 Extern 192.168.1.0 1.0.0.4 Extern 192.168.1.2 1.0.0.4 Extern 192.168.1.3 1.0.0.4 Extern 192.168.1.4 1.0.0.4 Seq 0x80000004 0x80000004 0x80000001 0x80000003 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 Age 18 17 17 17 17 17 17 17 17 Opt 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 Cksum Len 0x5dc8 36 0xf805 60 0xf72c 32 0xa37 28 0x3521 28 0x292c 28 0x2091 28 0xf3b9 28 0xa4b9 28 Seq 0x80000001 0x80000002 0x80000002 0x80000001 0x80000002 0x80000001 0x80000001 Age 1681 890 298 1681 594 1681 1681 Opt 0x22 0x22 0x22 0x22 0x22 0x22 0x22 Cksum Len 0xd7bc 36 0xbe18 36 0xdd8 36 0x370a 36 0x211d 36 0x1925 36 0xf2e 36 You can see the router and network LSA received from the other routers in area 1. You can also see the summary LSAs with the Adv Rtr column (or advertising router) changed to be the ABR. In the type column, ASBRSum are the type 4 LSAs, and the LSAs with the type set as External are type 5, and they detail the routes learnt from RIP. Next, let’s set Area 1 as a stub area. This change should be done on all routers in that area. As the routes come from various sources, OSPF wouldn’t know which metric would be the correct one to use, so all 53 54 Day One: Routing the Internet Protocol metrics are removed. To correct this, the default-metric option is used to inform OSPF which metric to apply to these routes. Without the default-metric keyword, the routes will not appear in the routing table: [edit] [email protected]# set protocols ospf area 1 stub default-metric 100 [edit] [email protected]# set protocols ospf area 1 stub NOTE The default-metric option need only be added to the ABR. Other routers in the area just need to be told they are in a stub area. Now, if you look at the database, the change is very subtle, but the type 4 LSA has disappeared from the list: [email protected]> show ospf database OSPF database, Area 0.0.0.1 Type ID Adv Rtr Router 1.0.0.0 1.0.0.0 Router *1.0.0.2 1.0.0.2 Network *10.2.0.3 1.0.0.2 Summary 10.3.0.0 1.0.0.0 Summary 10.4.0.0 1.0.0.0 Summary 10.5.0.0 1.0.0.0 Summary 172.23.3.0 1.0.0.0 Summary 172.23.7.0 1.0.0.0 OSPF AS SCOPE link state database Type ID Adv Rtr Extern 10.10.3.0 1.0.0.4 Extern 10.233.240.0 1.0.0.4 Extern 172.23.1.0 1.0.0.4 Extern 192.168.1.0 1.0.0.4 Extern 192.168.1.2 1.0.0.4 Extern 192.168.1.3 1.0.0.4 Extern 192.168.1.4 1.0.0.4 Seq 0x80000004 0x80000003 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 Age 133 132 132 176 176 176 176 176 Opt 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 Cksum Len 0x7bac 36 0x19e7 60 0x1610 32 0x2c19 28 0x5305 28 0x4710 28 0x3e75 28 0x129d 28 Seq 0x80000001 0x80000002 0x80000002 0x80000002 0x80000002 0x80000001 0x80000002 Age 2205 1414 822 231 1118 2205 527 Opt 0x22 0x22 0x22 0x22 0x22 0x22 0x22 Cksum Len 0xd7bc 36 0xbe18 36 0xdd8 36 0x350b 36 0x211d 36 0x1925 36 0xd2f 36 If you were to look at the routing table, you would see that the routes from RIP are now showing as a single default route to 0.0.0.0/0: [email protected]# run show route protocol ospf inet.0: 19 destinations, 22 routes (19 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 10.3.0.0/24 10.4.0.0/24 10.5.0.0/24 172.23.3.0/24 172.23.7.0/24 *[OSPF/10] 00:00:12, metric 1100 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:21:54, metric 2000 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:21:54, metric 3000 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:21:54, metric 3000 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:21:12, metric 4000 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:21:12, metric 4000 Chapter 4: Open Shortest Path First (OSPF) 224.0.0.5/32 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:22:51, metric 1 MultiRecv Note that Area 1 can also be changed into a totally stubby area by adding the keyword no-summaries just before the default-metric option at the end of the previous command. This change need only be applied to ABRs, which in this case is vMX0: [edit] [email protected]# set protocols ospf area 1 stub no-summaries default-metric 100 After committing this change, the OSPF database appears very different with all summary LSAs removed: [email protected]> run show ospf database OSPF database, Area 0.0.0.1 Type ID Adv Rtr Router 1.0.0.0 1.0.0.0 Router *1.0.0.2 1.0.0.2 Network 10.2.0.1 1.0.0.0 OSPF AS SCOPE link state database Type ID Adv Rtr Extern 10.10.3.0 1.0.0.4 Extern 10.233.240.0 1.0.0.4 Extern 172.23.1.0 1.0.0.4 Extern 192.168.1.0 1.0.0.4 Extern 192.168.1.2 1.0.0.4 Extern 192.168.1.3 1.0.0.4 Extern 192.168.1.4 1.0.0.4 Seq 0x80000007 0x80000008 0x80000001 Age 47 7 47 Opt 0x20 0x20 0x20 Cksum Len 0x61c5 36 0xfa03 60 0x3eeb 32 Seq 0x80000001 0x80000002 0x80000002 0x80000002 0x80000002 0x80000001 0x80000002 Age 2576 1785 1193 602 1489 2576 898 Opt 0x22 0x22 0x22 0x22 0x22 0x22 0x22 Cksum Len 0xd7bc 36 0xbe18 36 0xdd8 36 0x350b 36 0x211d 36 0x1925 36 0xd2f 36 The routing table on vMX2 also looks very different with OSPF showing a single default route: [email protected]> show route protocol ospf inet.0: 13 destinations, 15 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 224.0.0.5/32 *[OSPF/10] 00:05:58, metric 1100 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 11:08:23, metric 1 MultiRecv As you witnessed with stub areas, the ABR replaces the LSA type 4 with a default route. NSSA, or not so stubby areas, were created to allow redistribution of another routing protocol into OSPF via a stub area. This is done by replacing type 5 LSAs with a type 7 LSA. In this next scenario, Area 2 will be made into an NSSA. Area 1 will be changed back to a stub area. As with stub areas, the default-metric option needs to be included. With NSSAs, the default-lsa option must also be included to tell the router to generate a default route. 55 56 Day One: Routing the Internet Protocol Without it, the router will not add the default route to the routing table: [edit] [email protected]# set protocols ospf area 2 nssa default-lsa default-metric 100 [edit] [email protected]# set protocols ospf area 2 nssa Once committed, a default route is injected into area 2 which can be seen by looking at the routing table on router vMX4: [email protected]> show route protocol ospf inet.0: 24 destinations, 29 routes (24 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 10.2.0.0/24 10.3.0.0/24 10.4.0.0/24 10.10.1.0/24 10.10.2.0/24 224.0.0.5/32 *[OSPF/150] 00:00:16, metric 1100, tag 0 > to 10.5.0.1 via ge-0/0/1.0 *[OSPF/10] 00:00:16, metric 3000 > to 10.5.0.1 via ge-0/0/1.0 *[OSPF/10] 00:00:16, metric 2000 > to 10.5.0.1 via ge-0/0/1.0 *[OSPF/10] 00:00:16, metric 2000 > to 10.5.0.1 via ge-0/0/1.0 *[OSPF/10] 00:00:16, metric 4000 > to 10.5.0.1 via ge-0/0/1.0 *[OSPF/10] 00:00:16, metric 4000 > to 10.5.0.1 via ge-0/0/1.0 *[OSPF/10] 01:17:58, metric 1 MultiRecv If Area 2 is made into a not so stubby totally stubby area by adding the no-summaries option, the results are similar to totally stubby areas in that all OSPF routes external to the area are summarized into a single default route: [edit] [email protected]# set protocols ospf area 0.0.0.2 nssa no-summaries default-lsa defaultmetric 100 [email protected]> show route protocol ospf inet.0: 21 destinations, 24 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 224.0.0.5/32 *[OSPF/10] 00:00:07, metric 1100 > to 10.5.0.1 via ge-0/0/1.0 *[OSPF/10] 01:16:06, metric 1 MultiRecv Just as important, however, is that Area 1 is still receiving details of routes learned via RIP – meaning the LSAs are being allowed out of Area 2: Chapter 4: Open Shortest Path First (OSPF) [email protected]> show route protocol ospf inet.0: 19 destinations, 22 routes (19 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 10.3.0.0/24 10.4.0.0/24 10.5.0.0/24 172.23.3.0/24 172.23.7.0/24 224.0.0.5/32 MORE? *[OSPF/10] 00:27:32, metric 1100 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:27:32, metric 2000 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:27:32, metric 3000 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:27:32, metric 3000 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:03:06, metric 4000 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:03:06, metric 4000 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 01:06:48, metric 1 MultiRecv There’s lots of great information on stub and NSSAs within Juniper’s technical documentation: http://www.juniper.net/documentation/en_ US/junos14.2/topics/topic-map/ospf-stub-and-not-so-stubby-areas. html. OSPF Security The purpose of OSPF security is to prevent unauthorized persons from attaching a rogue device to the network and injecting bad routing information into it. OSPF security is only used to authenticate OSPF neighbors. What it does not do is encrypt the routing information exchanged between neighbors. There are three types of authentication methods OSPF can use to authenticate its neighbors:  The ﬁrst is none, which is the method currently being used.  The second is simple-password, which means the password is sent between neighbors using a plain-text password.  The third is MD5, where the password sent is encrypted using a hashing algorithm. OSPF authentication is conﬁgured on a per interface basis, therefore it is completely possible to have a situation where the same OSPF domain routers in one subnet are authenticated using MD5 and in another subnet there is no authentication. In the topology used throughout this chapter, Figure 4.3 illustrates this scenario: between vMX0 and vMX2 there is no authentication, 57 58 Day One: Routing the Internet Protocol between vMX0 and vMX1 OSPF MD5 authentication is being used, and ﬁnally, the interfaces connecting vMX1 and vMX4 are using a simple password to authenticate. Figure 4.3 OSPF Authentication Types Although using simple-passwords is allowed in the Junos OS, this option was only included to comply with the OSPF standard and for backwards compatibility with older devices where performance could be affected by hashing passwords. As such, it is not recommended to use on a live network environment. It’s been included here in the conﬁguration examples so you can see how this differs from conﬁguring MD5 authentication. Conﬁguring OSPF Security To keep this section simple, these OSPF authentication examples will be conﬁgured per Figure 4.3. No changes need to be applied to the link connecting vMX0 and vMX2. The interfaces connecting vMX1 and vMX4, however, do need to be enabled for simple password authentication. This is done with the following conﬁguration: [edit] [email protected]# set protocols ospf area 2 interface ge-0/0/2.0 authentication simplepassword secretpd Chapter 4: Open Shortest Path First (OSPF) [edit] [email protected]# set protocols ospf area 2 interface ge-0/0/1.0 authentication simplepassword secretpd There is one limitation to using simple password authentication and that is that the password must be eight characters or less. If the above conﬁguration was attempted with the password secretpassword , the following error would appear during the commit: [edit] [email protected]# commit [edit protocols ospf area 0.0.0.2 interface ge-0/0/2.0] ‘authentication’ ospf password is longer than 8 characters error: configuration check-out failed If you use the now familiar show ospf neighbor command, you should see that the routers are still neighbors, meaning they have passed the authentication checks. Next, routers vMX0 and vMX1 need to be conﬁgured for MD5 authentication, which enables a few more options for the administrator. The conﬁguration begins as it does for the simple password, aside from changing the option from simple-password to md5, after which the administrator needs to specify a key between 0 and 255. This key number allows the administrator to assign multiple passwords to the interface (useful if an administrator wishes to change the passwords on the interfaces). Instead of deleting the old password and creating a new one, thereby risking losing connectivity, the administrator can just create a new key number and new password. The administrator can also specify the date and time when the new key should be used, as you can see here with the possible completions: [edit] [email protected]# set protocols ospf area 0 interface ge-0/0/1.0 authentication md5 0 ? Possible completions: key MD5 authenticatio n key value start-time Start time for key transmission (YYYY-MM-DD.HH :MM) After this new key comes into effect, the old passwords can be deleted. In this scenario, routers vMX0 and vMX1 will use key 0 with no start time. The password of secretpassword will be used to illustrate that a longer password can be used: set protocols ospf area 0.0.0.0 interface ge/0/1.0 authentication md5 0 key secretpassword The best method to conﬁrm these routers are authenticating correctly is to use the show ospf neighbor command. If the neighbors were showing as 2way, then it would be obvious there is a problem with authentication. In addition, you can use the show ospf overview command, and this command is covered in the next section. 59 60 Day One: Routing the Internet Protocol OSPF Router IDs Each router in the OSPF domain needs a unique router ID associated with it so it is identiﬁable to its neighbors, but also so when it appears in the database all other routers on the network know which subnets are associated with that ID. As mentioned earlier, this ID is generated from the lowest IP address of all interfaces that are up. The issue with this is that when an interface goes down the ID can change, and as such the database needs updating and all routers in that area need to run the SPF algorithm once more. As an example, the output generated by the show interfaces terse command on a router with three interfaces that are up is: show interfaces terse Interface ge-0/0/0.0 ge-0/0/1.0 ge-0/0/2.0 Admin up up up Link up up up Proto inet inet inet Local 10.0.1.1/24 192.168.0.1/24 172.23.7.1/24 Remote From the three interfaces, interface ge-0/0/0.0 has the lowest IP address with 10.0.1.1. Should this interface go down, then the interface with the second lowest IP address, which is ge-0/0/2.0, will be used for the router ID, in which case the ID would become 172.23.7.1. There are alternatives. One is to use a loopback interface because the loopback interface address will have a higher priority than the physical interface addresses. If an engineer creates an additional loopback interface when performing testing, then the same issue can arise. Another option would be to specify the ID manually, which overrides the IDs from both the physical and loopback interfaces. No matter where the ID is sourced, the current ID of the router can be found by running the show ospf overview command: [email protected]> show ospf overview Instance: master Router ID: 10.1.0.1 Route table index: 0 LSA refresh time: 50 minutes Area: 0.0.0.0 Stub type: Not Stub Authenticatio n Type: None Area border routers: 0, AS boundary routers: 2 Neighbors Up (in full state): 2 Topology: default (ID 0) Prefix export count: 0 Full SPF runs: 20 SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3 Backup SPF: Not Needed This command can be very useful when performing diagnostics as it also shows the areas attached to the router, the area type, the authentication type if used, how many neighbors the router has, and the LSA Chapter 4: Open Shortest Path First (OSPF) refresh time, which is how often the router will refresh the database with new LSAs to ensure the LSA database matches those on other routers in that area. The ID is set with the following command and the commit takes effect after the dead timer has reached 0: set routing-options router-id 1.0.0.0 If the ID is set manually, it cannot use an address that begins with a zero. If this is attempted, then the following error will be displayed during a commit: [edit] [email protected]# commit [edit routing-options router-id] ‘router-id 0.0.0.1’ address invalid for routerid error: configuration check-out failed [edit] [email protected]# run show ospf overview | match Router | match ID Router ID: 1.0.0.0 Once a valid ID has been entered, running the command lists the new address: show ospf overview [edit] [email protected]# run show ospf overview | match Router | match ID Router ID: 1.0.0.0 It is also recommended to conﬁrm that the neighbors see the change in the ID with the show ospf neighbors command: [edit] [email protected]# run show ospf neighbor Address Interface 10.4.0.2 ge-0/0/0.0 10.3.0.1 ge-0/0/1.0 10.5.0.2 ge-0/0/2.0 State Full Full Full ID 10.4.0.2 Pri 128 1.0.0.0 128 10.5.0.2 128 Dead 33 37 31 OSPF Timers To help make OSPF converge faster, OSPF utilizes timers similar to the way RIP does. The Hello timer determines how often routers send a hello packet out of the interface to other routers. The time period needs to match on all routers on the subnet, otherwise they will appear to be stuck in ExStart in the neighbor table. The default timer on Ethernet networks and serial links is set to 10 seconds, or 30 seconds for frame relay. Frame relay networks also have a timer called the Poll interval, because frame relay networks are typically non-broadcast, meaning the traditional method of ﬁnding neighbors by using multicast will not work. With frame relay networks, the administrator needs to add the neighbor manually. The poll interval determines how often the router 61 62 Day One: Routing the Internet Protocol should send a message to the neighbor in order to form an adjacency. By default, this is set to 120 seconds. When a router sends LSAs to its neighbors, it expects to receive a r eply from its neighbor stating it received the LSA. If the router does not receive a reply within a certain amount of time, the router will resend the LSA. This is known as the LSA retransmission interval and by default this is set to ﬁve seconds. The Dead interval is a period of time where the router has not received a hello packet from a neighbor and as such determines that the neighbor is down. For example, if vMX1 did not receive a hello packet from vMX0 for 40 seconds by default, then vMX1 would remove vMX0 from its neighbor table. The dead timer is typically four times the hello timer and on frame relay networks the dead timer is by default 120 seconds. Finally, the purpose of the Transit delay is to increase the age of a link state update packet as it’s sent out of an interface. This is set by default to one second and ideally should never be changed. Conﬁguring OSPF Timers Similar to authentication, timers are changed on a per interface basis. The following commands set the dead timer on vMX1’s interface connected to vMX0 to 4 seconds, the hello interval to 1 second and the LSA retransmission interval to 2 seconds: [edit] [email protected]# set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 retransmit-interval 2 [edit] [email protected]# set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 hello-interval 1 [edit] [email protected]# set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 dead-interval 4 Unfortunately, after committing this conﬁguration, vMX0 was removed from the neighbor table of vMX1 because it did not respond within the dead timer of 4 seconds (the hello timer on vMX0 is still set to 10 seconds): [email protected]> show ospf neighbor Address Interface 10.5.0.2 ge-0/0/2.0 State Full ID 1.0.0.4 Pri 128 Dead 36 After setting the timers of vMX0 to match vMX1, the neighborship is restored: [edit] [email protected]# set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 retransmit-interval 2 Chapter 4: Open Shortest Path First (OSPF) [edit] [email protected]# set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 hello-interval 1 [edit] [email protected]# set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 dead-interval 4 And let’s verify neighbors: [email protected]> show ospf neighbor Address Interface 10.3.0.1 ge-0/0/1.0 10.5.0.2 ge-0/0/2.0 State Full Full ID 1.0.0.0 1.0.0.4 Pri 128 128 Dead 3 34 Notice how under the dead column the number is now 3 compared to 34 for the connection to vMX4. Should router vMX0 suddenly fail for whatever reason, vMX1 would remove it from the neighbor table very quickly. Discontiguous OSPF Areas Occasionally a situation may arise where you have no choice but to connect a non-backbone OSPF area to an area other than Area 0, such as in the case of an acquisition or merger. In this case it becomes necessary to break the OSPF Area 0 rule. To do this an engineer can use what is known as a virtual link. Figure 4.4 shows an example of what is known as a discontiguous area where Area 80 needs to cross Area 1 to reach Area 0. Figure 4.4 OSPF Virtual Links 63 64 Day One: Routing the Internet Protocol With a virtual link a tunnel is created across the area that is between Area 0 and the new area that is cut off from Area 0, in Figure 4.4 the tunnel would cross Area 1. The conﬁguration to allow this is placed on the ABRs of the area that is to be crossed. The routers inside Area 80 wouldn’t know they were crossing a tunnel; as far as they are aware, they are directly connected to Area 0. If the routers are conﬁgured as in Figure 4.4, but without the virtual link, and you look at the routing table on router vMX2, you would observe that vMX0’s interface in subnet 10.3.0.0/24 appears in the routing table, but no other routes are discovered: [email protected]> show route protocol ospf inet.0: 13 destinations, 15 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.3.0.0/24 224.0.0.5/32 *[OSPF/10] 00:03:52, metric 2 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 05:22:11, metric 1 MultiRecv To resolve this issue, the set protocols ospf area 0 virtual-link command is used in the routers vMX0 and vMX1. After neighbor-id the administrator is required to add the router ID of the ABR at the other end of the tunnel, for example, for router vMX0, you would specify the ID of vMX1 and for vMX1 you would enter the ID for vMX0. The ﬁnal part of the command tells the router which area the tunnel transits: [edit] [email protected]# set protocols ospf area 0 virtual-link neighbor-id 1.0.0.1 transit-area 0.0.0.1 [edit] [email protected]# set protocols ospf area 0 virtual-link neighbor-id 1.0.0.0 transit-area 0.0.0.1 Now, let’s look at the routing table on vMX2, and you should see all routes discovered as advertised via OSPF: [email protected]> show route protocol ospf inet.0: 23 destinations, 26 routes (23 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.3.0.0/24 10.4.0.0/24 10.5.0.0/24 172.23.3.0/24 172.23.7.0/24 224.0.0.5/32 *[OSPF/10] 00:15:43, metric 2 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:01:11, metric 3 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:01:11, metric 3 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:01:11, metric 4 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 00:01:11, metric 4 > to 10.2.0.1 via ge-0/0/0.0 *[OSPF/10] 05:34:02, metric 1 MultiRecv Chapter 4: Open Shortest Path First (OSPF) Finally, if the show ospf neighbors command were to be run, an additional neighbor will appear in the list with the same ID as the ABR in area 0 but instead showing the outgoing interface as vl-1.0.0.1. This interface is the virtual link between routers vMX0 and vMX1: [email protected]> show ospf neighbor Address Interface 10.3.0.2 ge-0/0/1.0 10.2.0.3 ge-0/0/2.0 10.3.0.2 vl-1.0.0.1 State Full Full Full ID 1.0.0.1 1.0.0.2 1.0.0.1 Pri 128 128 0 Dead 37 36 35 OSPF Overload Function OSPF overload function: If the time elapsed after the OSPF instance is enabled is less than the speciﬁed timeout, overload mode is set. http://www.juniper.net/ documentation/en_US/ junos12.3/top ics/concept / ospf-overload-functionoverview.html The last OSPF feature before moving onto IS-IS is something called the OSPF overload function. This feature is something you probably wouldn’t run too often, but it can be quite useful. It makes the router appear that it is overloaded to other routers on the network, and as such can no longer participate in normal routing on the network. There are two situations in which an administrator may want to use this function. The ﬁrst is when the administrator would like the router to receive routes, but not to participate in routing itself, for example, when a router is being used for analysis of network trafﬁc. The second situation is when the administrator is performing maintenance and doesn’t want the router to be used as a transit router, but wants the router to remain up so it can be brought into service much sooner. The command that enables overload is added to the whole OSPF routing process. It is not possible to set this command for a particular area only. The command also allows the administrator to specify a time out period. If no timeout option is set, then the overload is set until the conﬁguration is removed. The timeout period can be set from 60 seconds to 1800 seconds. The default is 0. Once the command is added, the router still advertises routes it has learned, except that the metric will be set to 65535 or inﬁnite, meaning the neighbors will still receive the routes, but will mark them as inaccessible, and as a result they will not be entered into their local routing tables. The command to enable overload is as follows. In this case, the timeout is set to 180 seconds, which means in 3 minutes the router will return to normal operation: set protocols ospf overload timeout 180 65 66 Day One: Routing the Internet Protocol Summary OSPF is a popular protocol amongst network engineers. The scalability of this protocol means a network administrator may never need to migrate to another protocol. The only downside is that it is more complex to implement compared to RIP or static routes. The key to OSPF’s scalability lies with its use of areas. Understanding the use of areas will become useful during the next chapter when you look at a protocol that can scale to a size beyond the capabilities of OSPF. This chapter shared some useful information about the Junos OS and OSPF, however, if you are interested, further information can be found at the Juniper TechLibrary and readers might start at this OSPF pathway page: https://www.juniper.net/techpubs/en_US/junos14.1/ information-products/pathway-pages/conﬁg-guide-routing/conﬁgguide-ospf.html. Also, follow these examples in your own lab if you can. It greatly aids in the learning process. Chapter 5 Intermediate System to Intermediate System (IS-IS) Like OSPF, IS-IS is also a link state routing protocol . It uses the same SPF algorithm and is scalable, even more so than OSPF. However, IS-IS has a very different history than OSPF and that is because it was never designed to advertise IP subnets, and was in fact designed for another routed protocol, called OSI . Internet Protocol: The principal communicationsprotocol in the Internet protocol suite for relaying datagrams across network bou ndaries: https://en.wikipedia .org/ wiki/Internet_Protocol Back in the early 1990s, a company called Digital Equipment Corporation (DEC), developed and standardized the OSI protocol. At the same time, the IETF developed another protocol called the Internet Protocol, or IP. These protocols were in direct competition with each other, and not knowing which to support service providers had both protocols running on their networks. IP obviously became the dominant protocol, although it was discovered that OSI did have a useful feature in that the packets it sends across the network, known as Protocol Data Units (PDUs) are comprised of Type Length Value (TLVs). These TLVs can be used to exchange routing information, usually IP, but OSI was very easily adapted to advertise IPv6 routing information. So, the one major difference between IS-IS and other routing protocols is that IS-IS does not use IP as the transport protocol, and instead uses OSI. So any router that uses IS-IS to advertise routes must have OSI enabled, and an address conﬁgured, which is another major difference compared to IP. With IP, each interface is given an address in a different subnet, while with OSI the router as a whole is given a single address, usually to the loopback interface. The address in OSI is made up of several components, rather like an IP address is divided into the network address and host address, but unlike IP, the OSI address is made up of four parts: 68 Day One: Routing the Internet Protocol 1. AFI : Authority and Format Indicator. This identiﬁes the type of device this address is assigned to. For routers, this will always be set as 49. 2. Area ID: This part is similar to IPv4 subnet addresses. Routers in the same level will use the same area ID. Levels will be explained in the following Conﬁguring IS-IS section. 3. System ID: Similar to an IPv4 host address. Each router must have a unique number. This cannot be all 0s but can be hexadecimal. 4. N-selector: Always set as 00. Figure 5.1 shows an example of an OSI address where the address has been assigned to a router in Area 1 with an address of 0001.0001.00001. Figure 5.1 OSI Address Conﬁguring IS-IS Figure 5.2 shows the topology of the network that will be used in this conﬁguration example. Figure 5.2 IS-IS Topology Chapter 5: Intermediate System to Intermediate System (IS-IS) As shown in Figure 5.2, IS-IS neighborships are formed between routers vMX3, vMX2, vMX5, and vMX6, however the subnet between routers vMX3 and vMX6 is part of the RIP domain that will later be redistributed into IS-IS, therefore these interfaces will not send hello PDUs. The ﬁrst step is to assign an OSI address to each router. Each router is in area 0001 and the address assigned to the interface is loopback 0.0 and the /32 IP address will be assigned to this interface. In addition, OSI needs to be enabled on each interface that sends PDUs. The ﬁrst router to be conﬁgured is vMX2: set set set set set interfaces interfaces interfaces interfaces interfaces lo0 unit lo0 unit ge-0/0/0 ge-0/0/1 ge-0/0/2 0 family inet address 192.168.1.1/32 0 family iso address 49.0001.0001.0001.0001.00 unit 0 family iso unit 0 family iso unit 0 family iso Next, router vMX3 is given a different /32 address and a different OSI address: set set set set set interfaces interfaces interfaces interfaces interfaces lo0 unit lo0 unit ge-0/0/0 ge-0/0/1 ge-0/0/2 0 family inet address 192.168.1.2/32 0 family iso address 49.0001.0001.0001.0002.00 unit 0 family iso unit 0 family iso unit 0 family iso Now vMX5 is conﬁgured as follows: set set set set interfaces interfaces interfaces interfaces lo0 unit lo0 unit ge-0/0/0 ge-0/0/1 0 family inet address 192.168.1.3/24 0 family iso address 49.0001.0001.0001.0003.00 unit 0 family iso unit 0 family iso And vMX6 is given the OSI System ID of 0001.0001.0004: set set set set set interfaces interfaces interfaces interfaces interfaces lo0 unit lo0 unit ge-0/0/0 ge-0/0/1 ge-0/0/2 0 family inet address 192.168.1.4/24 0 family iso address 49.0001.0001.0001.0004.00 unit 0 family iso unit 0 family iso unit 0 family iso Now, all routers have been given an address and OSI is enabled on all interfaces, so let’s tell IS-IS which interfaces to advertise and which not to send hello PDUs out of. Similar to RIP and OSPF, the passive option tells IS-IS not to send hello PDUs out of that interface. Router vMX2’s interface ge-0/0/0.0 is part of the OSPF domain, therefore set this as passive: set set set set protocols protocols protocols protocols isis isis isis isis interface interface interface interface ge-0/0/0.0 passive ge-0/0/1.0 ge-0/0/2.0 lo0.0 Interfaces ge-0/0/0.0 and ge-0/0/2.0 on router vMX3 are part of the RIP domain, therefore these too are set as passive: 69 70 Day One: Routing the Internet Protocol set set set set protocols protocols protocols protocols isis isis isis isis interface interface interface interface ge-0/0/0.0 passive ge-0/0/1.0 ge-0/0/2.0 passive lo0.0 Router vMX5 only has two interfaces and it is totally in the IS-IS domain. Therefore it has no passive interfaces: set protocols isis interface ge-0/0/0.0 set protocols isis interface ge-0/0/1.0 set protocols isis interface lo0.0 Finally, router vMX6, like vMX3, has two interfaces in the RIP domain, ge-0/0/0.0 and ge-0/0/1.0, therefore these are set as passive: set set set set protocols protocols protocols protocols isis isis isis isis interface interface interface interface ge-0/0/0.0 passive ge-0/0/1.0 passive ge-0/0/2.0 lo0.0 Once the conﬁguration has been committed, you need to check whether the routers are negotiating successfully. Whereas OSPF calls routers neighbors that have negotiated successfully, in IS-IS they are known as adjacencies and use show IS-IS adjacency command to show what routers have formed adjacencies. Here is the output from when this command was run on router vMX2 prior to it forming an adjacency with vMX3: [email protected]> show isis adjacency Interface System ge-0/0/2.0 VMX5 ge-0/0/2.0 VMX5 L State 1 Up 2 Up Hold (secs) SNPA 7 0:5:86:71:ed: 1 8 0:5:86:71:ed: 1 By using the show route protocol IS-IS command, you can see that the routing table has been populated with routes learned through IS-IS: [email protected]> show route protocol isis inet.0: 23 destinations, 27 routes (23 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.3.0/24 172.23.1.0/24 172.23.3.0/24 172.23.7.0/24 192.168.1.0/24 192.168.1.2/32 192.168.1.3/32 192.168.1.4/32 *[IS-IS/15] 00:06:00, metric 20 > to 10.10.1.2 via ge-0/0/2.0 *[IS-IS/15] 00:00:05, metric 20 > to 10.10.2.2 via ge-0/0/1.0 *[IS-IS/15] 00:00:05, metric 20 > to 10.10.2.2 via ge-0/0/1.0 *[IS-IS/15] 00:06:00, metric 30 > to 10.10.1.2 via ge-0/0/2.0 *[IS-IS/15] 00:02:57, metric 10 > to 10.10.2.2 via ge-0/0/1.0 *[IS-IS/15] 00:02:57, metric 10 > to 10.10.2.2 via ge-0/0/1.0 *[IS-IS/15] 00:06:00, metric 10 > to 10.10.1.2 via ge-0/0/2.0 *[IS-IS/15] 00:06:00, metric 20 > to 10.10.1.2 via ge-0/0/2.0 iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) Chapter 5: Intermediate System to Intermediate System (IS-IS) Then best practice is to send a simple ping from router vMX3 to one of vMX6’s interfaces. A reply will prove connectivity is working as expected, and as shown below, all is ﬁne: [email protected]> ping 172.23.7.2 PING 172.23.7.2 (172.23.7.2): 56 data bytes 64 bytes from 172.23.7.2: icmp_seq=0 ttl=63 time=14.644 ms 64 bytes from 172.23.7.2: icmp_seq=1 ttl=63 time=4.951 ms 64 bytes from 172.23.7.2: icmp_seq=2 ttl=63 time=4.533 ms ^C --- 172.23.7.2 ping statistics --3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.533/8.043/14.644/4.671 ms IS-IS Areas Like OSPF, IS-IS can scale to a considerable size, a size beyond that of OSPF and some say a size that can rival BGP. It achieves this scalability in the same way via the use of areas. IS-IS areas are slightly different from OSPF in that IS-IS uses levels to designate which areas are the backbone and which are not backbone. With IS-IS, there are two levels. Any routers that are designated as level 1 are non-backbone area routers. Level 2 is the backbone area, similar to OSPF area 0.0.0.0. Level 2 areas should be contiguous. Levels are assigned on a per-interface basis and any router that has one interface set as Level 2, and another set as Level 1, is an ABR, similar to OSPF. Figure 5.3 illustrates an example IS-IS domain with multiple routers in Level 2 and three ABRs with Level 1 routers attached, Areas X, Y, and Z, purely to illustrate that these are areas separate unto themselves. Figure 5.3 An Example of IS-IS Levels 71 72 Day One: Routing the Internet Protocol Conﬁguring IS-IS Areas Figure 5.4 shows how the routers will be conﬁgured. Router vMX3 is a Level 1 router in Area 2. Router vMX6 is a Level 1 router in Area 3, and routers vMX2 and vMX5 will be ABRs. Figure 5.4 The Conﬁguration Topology for IS-IS By default, both Levels 1 and 2 are enabled on all interfaces that form an adjacency. Therefore, to set an interface as part of Level 2, instead of enabling Level 2, you need to disable Level 1. And likewise, to set an interface to be part of Level 1, you need to disable Level 2. Router vMX2 is an ABR and interface ge-0/0/1.0 will be a Level 1 interface and interface ge-0/0/2.0 will be a Level 2 interface. The commands to conﬁgure the router this way are: set protocols isis interface ge-0/0/1.0 level 2 disable set protocols isis interface ge-0/0/2.0 level 1 disable Router vMX3 only has one interface forming an adjacency and it is a Level 1 interface: set protocols isis interface ge-0/0/1.0 level 2 disable As router vMX5 is an ABR, one of its interfaces is set with Level 2 disabled and the other is set with level 1 disabled: set protocols isis interface ge-0/0/0.0 level 2 disable set protocols isis interface ge-0/0/1.0 level 1 disable Router vMX6 is similar to vMX3 in that it too only has one interface forming an adjacency so Level 2 is disabled: set protocols isis interface ge-0/0/2.0 level 2 disable Chapter 5: Intermediate System to Intermediate System (IS-IS) Now that the conﬁguration has been committed on all routers, the simplest but most reliable test is to send a ping and then look at the routing table. And as you can see, there is an issue. Router vMX6 can only see one route coming from router vMX5: [email protected]> show route protocol isis inet.0: 13 destinations, 15 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.3/3 2 *[IS-IS/15] 00:06:53, metric 10 > to 10.10.3.1 via ge-0/0/2.0 This issue was caused because the areas in the addresses were not changed. IS-IS sees that there are two Level 1 areas but they all have the same area in the address, which confuses IS-IS. To resolve this issue, the addresses need to be changed. The ABRs need their areas to be set to the Level 1 area they are adjoining. Router vMX2 is adjoining Area 2: set interfaces lo0 unit 0 family iso address 49.0002.0001.0001.0001.00 Router vMX is wholly within Area 2: set interfaces lo0 unit 0 family iso address 49.0002.0001.0001.0002.00 The second ABR is router vMX5. This is adjoining area 3: set interfaces lo0 unit 0 family iso address 49.0003.0001.0001.0003.00 Finally, router vMX6 is completely in Area 3: set interfaces lo0 unit 0 family iso address 49.0003.0001.0001.0004.00 Once the conﬁguration has been committed, the routing table should now have one more route and that is a default route. Areas help make IS-IS scalable by summarizing all routes going into an area as a single default route. The routers inside the area only need to know that to reach a subnet that’s not listed in the routing table they just need to forward their packet to the ABR who has a complete routing table: [email protected]> show route protocol isis inet.0: 14 destinations, 16 routes (14 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 192.168.1.3/3 2 *[IS-IS/15] 00:02:28, metric 10 > to 10.10.3.1 via ge-0/0/2.0 *[IS-IS/15] 00:55:15, metric 10 > to 10.10.3.1 via ge-0/0/2.0 iso.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) Now, if router vMX6 pings router vMX3’s ge-0/0/0.0 interface, router vMX6 should receive a successful reply: 73 74 Day One: Routing the Internet Protocol [email protected]> ping 172.23.3.1 PING 172.23.3.1 (172.23.3.1): 56 data bytes 64 bytes from 172.23.3.1: icmp_seq=0 ttl=62 time=154.905 ms 64 bytes from 172.23.3.1: icmp_seq=1 ttl=62 time=74.607 ms 64 bytes from 172.23.3.1: icmp_seq=2 ttl=62 time=136.593 ms 64 bytes from 172.23.3.1: icmp_seq=3 ttl=62 time=7.078 ms ^C --- 172.23.3.1 ping statistics --4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 7.078/93.296/154.905/57.994 ms IS-IS Security Hello PDUs: Delivered as a unit among peer entitie s of a network and that may contain control information, such as address information, or user data. https://en.wikipedia .org/ wiki/Protocol_data_unit Similar to RIP and OSPF, an IS-IS administrator can prevent unauthorized persons from forming an adjacency with an IS-IS router by enabling security. IS-IS only enables security on the hello PDUs as opposed to every advertisement. If the adjacent router doesn’t send a correctly authenticated hello, then the router simply won’t form an adjacency with it. With IS-IS, the password used for authentication can be 255 characters in length and as long as you put the password in quotation marks, the password can even contain spaces. Like RIP and OSPF, IS-IS can use a plain text password and MD5 hashing to authenticate, but also adds the option to use SHA hashing, too. Conﬁguring IS-IS Security To enable plain text and MD5 authentication, the hello-authentication-type option is used after specifying the relevant level on which you wish to enable authentication. In this case, MD5 authentication is used in the Level 1, Area 2, with the password set to THIS-ISAPASSWORD. The ﬁrst router to be conﬁgured is vMX2 and vMX3 will be left without authentication, temporarily, to show what effect this has on the adjacency: set protocols isis interface ge-0/0/1.0 level 1 hello-authentication-key THISISAPASSWORD set protocols isis interface ge-0/0/1.0 level 1 hello-authentication-type md5 Now run the show IS-IS adjacency command, and you should see from the output that the state of router vMX3 is Down but there is no reason why: [email protected]# run show isis adjacency Interface System ge-0/0/1.0 VMX3 ge-0/0/2.0 VMX5 L State 1 Down 2 Up Hold (secs) SNPA 0 0:5:86:71:17: 1 21 0:5:86:71:73: 1 Chapter 5: Intermediate System to Intermediate System (IS-IS) If the extensive option is added to the end of the command, however, then you can clearly see that the reason for the down adjacency is because of a bad Hello. The hello is bad because it has no authentication and that is not what vMX2 expects: [email protected]# run show isis adjacency VMX3 extensive VMX3 Interface: ge-0/0/1.0, Level: 1, State: Down, Expires in 0 secs Priority: 64, Up/Down transitions: 2, Last transition: 00:00:35 ago Circuit type: 1, Speaks: IP, IPv6, MAC address: 0:5:86:71:17:1 Topologies: Unicast Restart capable: Yes, Adjacency advertisement : Advertise LAN id: VMX2.02, IP addresses: 10.10.2.2 Transition log: When State Event Down reason Thu Jun 11 11:43:40 Up Seenself Thu Jun 11 11:44:27 Down Error Bad Hello So once the same commands are added to vMX3, the adjacency is restored: set protocols isis interface ge-0/0/1.0 level 1 hello-authentication-key THISISAPASSWORD set protocols isis interface ge-0/0/1.0 level 1 hello-authentication-type md5 As mentioned earlier, IS-IS has an option for both MD5 and SHA authentication, the latter being a more secure method. SHA authentication cannot be enabled by using the hello-authentication-type command and instead needs to be enabled with a key-chain. Key chains have an advantage over just setting the adjacency’s type, in that the administrator can conﬁgure options such as setting different authentication keys and then setting the date when that key is valid, thereby allowing the administrator to migrate to new keys on a regular basis without causing any downtime. It is still possible to use MD5 authentication from a key chain, however it is not possible to use plain text. In this next scenario, two key chains will be conﬁgured: key 1 uses MD5 with the password set as “THIS-ISSECRET,” and key 2 uses SHA and the password is “THISISSECRETTOO”. Key 1 is set to start at 16:00 on June 10th 2015 and key 2 begins on September 2nd 2015 at midnight: set security authentication-key-chains set security authentication-key-chains 10.16:00 set security authentication-key-chains set security authentication-key-chains CHAIN key 2 secret THISISSECRETTOO set security authentication-key-chains 2.00:00 set security authentication-key-chains set security authentication-key-chains enhanced key-chain ISIS-KEY-CHAIN key 1 secret THISISSECRET key-chain ISIS-KEY-CHAIN key 1 start-time 2015-06key-chain ISIS-KEY-CHAIN key 1 algorithm md5 key-chain ISIS-KEYkey-chain ISIS-KEY-CHAIN key 2 start-time 2015-9key-chain ISIS-KEY-CHAIN key 2 algorithm hmac-sha-1 key-chain ISIS-KEY-CHAIN key 2 options isis- 75 76 Day One: Routing the Internet Protocol NOTE If SHA authentication is to be used, the isis-enhanced option must be enabled, too. If it isn’t enabled, the Junos OS will not allow you to commit the conﬁguration and will warn you. All that remains to be done is to apply these keys to the relevant interfaces. In this scenario, authentication is enabled on the Level 2 backbone between routers vMX2 and vMX5, leaving the Level 1 authentication in place between vMX2 and vMX3 (just to prove that both authentication types can be used on the same router at the same time). Router vMX2’s Level 2 interface is ge-0/0/2.0: set protocols isis interface ge-0/0/2.0 level 2 hello-authentication-key-chain ISIS-KEYCHAIN And router vMX5’s Level 2 interface is ge-0/0/1.0: set protocols isis interface ge-0/0/1.0 level 2 hello-authentication-key-chain ISIS-KEYCHAIN After committing the conﬁguration, the adjacency should be checked to prove the routers are authenticating each other correctly: [email protected]# run show isis adjacency brief Interface System L State ge-0/0/0.0 VMX6 1 Up ge-0/0/1.0 VMX2 2 Up Hold (secs) SNPA 6 0:5:86:71:98:2 6 0:5:86:71:9a:2 IS-IS Reference Bandwidth Like OSPF, IS-IS can use a reference bandwidth as the metric divided by the speed of the interface. Unlike OSPF, by default, IS-IS does not use a reference bandwidth and instead gives each interface a metric of 10. This means that all routes in the routing table will show a metric of 10, 20, 30 and so on depending on how many hops away the subnet is. By running the show route protocol IS-IS command, you can see the metrics: [email protected]> show route protocol isis inet.0: 22 destinations, 27 routes (22 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.3.0/24 172.23.1.0/24 172.23.3.0/24 172.23.7.0/24 192.168.1.0/24 192.168.1.2/32 *[IS-IS/18] 00:06:00, metric 20 > to 10.10.1.2 via ge-0/0/2.0 *[IS-IS/15] 00:00:05, metric 20 > to 10.10.2.2 via ge-0/0/1.0 *[IS-IS/15] 00:00:05, metric 20 > to 10.10.2.2 via ge-0/0/1.0 *[IS-IS/18] 00:06:00, metric 30 > to 10.10.1.2 via ge-0/0/2.0 *[IS-IS/15] 00:02:57, metric 10 > to 10.10.2.2 via ge-0/0/1.0 *[IS-IS/15] 00:02:57, metric 10 > to 10.10.2.2 via ge-0/0/1.0 Chapter 5: Intermediate System to Intermediate System (IS-IS) 192.168.1.3/3 2 192.168.1.4/3 2 *[IS-IS/18] 00:06:00, metric 10 > to 10.10.1.2 via ge-0/0/2.0 *[IS-IS/18] 00:06:00, metric 20 > to 10.10.1.2 via ge-0/0/2.0 In reality, this default setting makes IS-IS’s behavior similar to that of RIP, using hops to determine the best route. Instead of using the default behavior, it is better to set a reference bandwidth. The reference-bandwidth option needs to be set on all routers in the IS-IS domain and should ideally be set to a higher interface speed than is currently running on the network to allow for future prooﬁng. In this instance, the reference bandwidth is set to 100Gb/s, like this: set reference-bandwidth 100g Once this setting has been added and committed to all routers, the metrics in the routing table should look bigger, for example, before the reference bandwidth was added the route to subnet 10.10.3.0/24 had a metric of 20. Once the reference bandwidth was added, the metric increased to 126: [email protected]> show route protocol isis inet.0: 22 destinations, 27 routes (22 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.3.0/24 172.23.1.0/24 172.23.3.0/24 172.23.7.0/24 192.168.1.0/2 4 192.168.1.2/3 2 192.168.1.3/3 2 192.168.1.4/3 2 *[IS-IS/18] 00:00:35, metric 126 > to 10.10.1.2 via ge-0/0/2.0 *[IS-IS/15] 00:00:29, metric 126 > to 10.10.2.2 via ge-0/0/1.0 *[IS-IS/15] 00:00:29, metric 126 > to 10.10.2.2 via ge-0/0/1.0 *[IS-IS/18] 00:00:34, metric 126 > to 10.10.1.2 via ge-0/0/2.0 *[IS-IS/15] 00:00:35, metric 63 > to 10.10.2.2 via ge-0/0/1.0 *[IS-IS/15] 00:00:35, metric 63 > to 10.10.2.2 via ge-0/0/1.0 *[IS-IS/18] 00:00:35, metric 63 > to 10.10.1.2 via ge-0/0/2.0 *[IS-IS/18] 00:00:34, metric 126 > to 10.10.1.2 via ge-0/0/2.0 IS-IS Timers Like OSPF and RIP, IS-IS also allows an administrator to adjust the timers that help IS-IS decide when a router has lost an adjacency. There are two timers of note that can assist with this.  To determine how often a hello PDU is sent out of the conﬁgured interfaces, an administrator can conﬁgure a hello-interval. This setting can be set from 1 to 20,000 seconds. The default setting is 3 seconds. 77 78 Day One: Routing the Internet Protocol  The second timer is the hold-time option, which determines how long the router should wait after not receiving a hello before it declares the adjacent router down. This can be set from 3 to 65,535 seconds and has a default setting of 9. Interestingly, if both the hold time and hello interval timers are set to 1, Interestingly, then the hello PDUs are sent every 333 milliseconds allowing for much faster route removal and an alternative route being found. Conﬁguring IS-IS Timers Before changing the timers ti mers on your production networks, networ ks, it’s a good idea to remember that this change is made at a time of day when any potential outage won’t affect anyone. To check what the timers are currently curre ntly set to, use the show IS-IS interface command along with the extensive option option.. In the following example, the command was run on router vMX2 and the output shows that the hello interval is set to 3.000 s and the hold time is 9 s. This command also shows that level 1 on this interface is disabled: [email protected]# run show isis interface ge-0/0/2.0 extensive IS-IS interface database: ge-0/0/2.0 Index: 332, State: 0x6, Circuit id: 0x3, Circuit type: 2 LSP interval: 100 ms, CSNP interval: 10 s, Loose Hello padding Adjacency advertisement: Advertise Level 1 Adjacencies: 0, Priority: 64, Metric: 63 Disabled Level 2 Adjacencies: 1, Priority: 64, Metric: 63 Hello Interval: 3.000 s, Hold Time: 9 s Designated Router: VMX2.03 (us) In this next scenario, the level 2 interfaces are set with a sub-second hello interval. The ﬁrst router is vMX2: vMX2: set protocols isis interface ge-0/0/2.0 level 2 hello-interval 1 set protocols isis interface ge-0/0/2.0 level 2 hold-time 1 Then the same commands are set on router vMX5: set protocols isis interface ge-0/0/1.0 level 2 hello-interval 1 set protocols isis interface ge-0/0/1.0 level 2 hold-time 1 By running the show IS-IS interface command again, you can see that the hello interval is now 0.333 s: [email protected]# run show isis interface ge-0/0/2.0 extensive IS-IS interface database: ge-0/0/2.0 Index: 332, State: 0x6, Circuit id: 0x3, Circuit type: 2 LSP interval: 100 ms, CSNP interval: 10 s, Loose Hello padding Chapter 5: Intermediate System to Intermediate System (IS-IS (IS-IS)) Adjacency advertisement: Advertise Level 1 Adjacencies: 0, Priority: 64, Metric: 63 Disabled Level 2 Adjacencies: 1, Priority: 64, Metric: 63 Hello Interval: 0.333 s, Hold Time: 1 s Designated Router: VMX2.03 (us) Summary Typically, IS-IS is used by service providers and not in corporate LANs. Its sheer scalability and faster convergence meet the demands of this type of network. There is of course no reason why IS-IS can’t be used by a company and for companies with many hundreds of subnets, IS-IS is a better choice. Some say IS-IS can scale to a size that rivals BGP whereas OSPF can never scale to that level. After reading this chapter you should have a much better understanding of the alternative protocol to OSPF whilst reafﬁrming your understanding of areas. This may also help you later in your career if you ﬁnd yourself working for a service servi ce provider. provider. This brings us to the end of the last interior gateway protocol (IGP) covered in this book. The next protocol, BGP, BGP, which is discussed in Chapter 7, is considered an exterior gateway protocol (EGP). But before moving to BGP you need to look at how protocols can share routes with each other by a method called redistribution and this is the subject of the next chapter chapt er,, Chapter 6. Here, both IS-IS and OSPF are conﬁgured so they are both operating in a single network. 79 80 Day One: Routing the Internet Protocol Chapter 6 Redistributing Route Information In an ideal world, a corporate network would be running a single routing protocol. The choice of protocol is usually based on s uch requirements as scalability or the experience of the administrators when the network was ﬁrst built. But what happens if two companies merge, or if a large company acquires a smaller company and the two entities use different protocols? There needs to be a way of sharing routing information between these organizations, at least until the organizations can agree on a standard protocol. In mergers it is often just a matter of time until this occurs, once management and personnel get settled. The method used to merge networks is called redistribution. Let us imagine for a moment that ACME, a corporation running IS-IS, decides to acquire EMCA, who is using OSPF. Once the acquisition is complete, IT management decides to join the networks of the two companies by using a temporary serial link until a more permanent MPLS solution can be arranged. Figure 6.1 illustrates this redistribution scenario. 82 Day One: Routing the Internet Protocol Figure 6.1 Redistribution Example In this case, routers A, B, and C can communicate without issue, as can routers D, E, F, G, and H. Routers C and D can also ping each other across the serial link, but router A certainly can’t ping router G. The best solution in this case would be to enable IS-IS on router C’s serial interface and then tell it to redistribute IS-IS into OSPF and OSPF into IS-IS. Assuming this was successful, all routers would have complete visibility of both LANs. Routing Loops Chapter 1 demonstrated how a routing loop can be caused by adding default static routes on two devices opposing each other. Similarly, it is also possible to inadvertently cause a routing loop while performing route redistribution. Figure 6.2 shows an example of a network where, if redistribution were enabled, it could cause a routing loop. In this case, the routing loop would be caused by the administrative distances of each protocol: RIP and OSPF. In Figure 6.2, Router 2 would advertise the loopback interface from Router 1 into OSPF, and Router 3 would do the same. These advertisements would be sent to Routers 4 and 5, which would then get back to Routers 2 and 3. If Router 5 wished to send a packer to Router 1’s loopback interface, it would look in its routing table and see that Router 3 is the next hop, so forwards the packet accordingly. Router 3 receives the packet and sees two possible routes, the ﬁrst being to Router 2 and the second is back via Router 5, through 4, and to 2. As the administrative distance of OSPF is lower than that of RIP, Router 3 decides that the route via Router 5 is the best. Once the packet gets to Router 2, however, Router 2 sees two possible routes Chapter 6: Redistributing Route Information Figure 6.2 Redistributing RIP Into OSPF also, and because the administrative distance of OSPF is less than that of RIP, it sends the packet back to Router 4. The screen capture of a traceroute in Figure 6.3 shows the issue redistribution has caused – the packet goes round and round the network until the TTL expires: Figure 6.3 Traceroute Routing Loop There are two ways to correct this issue. The ﬁrst is to tag the advertisement before redistributing it and tell the other ASBR to ignore any advertisements that carry that tag. The other method is to tell OSPF to use a higher administrative distance for routes learned from another routing protocol. For example, the AD for RIP is 100, and the AD for OSPF is 10, therefore by making the AD for routes OSPF had learned from RIP, 150, this would prevent the routing loop. 83 84 Day One: Routing the Internet Protocol The default behavior in the Junos OS is to set an administrative distance (AD) of 150 to routes OSPF has redistributed, or external routes. IS-IS will set an AD of 160 to Level 1 external routes, and an AD of 165 to Level 2 external routes. RIP cannot distinguish between internal or external routes, therefore it has the single AD of 100. By setting the ADs for external routes by default, like this, devices running the Junos OS should in theory never suffer from routing loops caused by route redistribution. Redistribution Between OSPF and RIP In order to redistribute between routing protocols in the Junos OS, a policy statement must be created to tell the OS which routes should be exported from one protocol to another. In the following example, OSPF is redistributed into RIP and RIP is redistributed into OSPF. The aim of this exercise is to allow router vMX0 to be able to ping a router vMX3’s interface in subnet 172.23.1.0. Let’s run the show route protocol ospf command on router vMX0. Subnets 172.23.3.0/24 and 172.23.7.0/24 should be seen as these are advertised from vMX4 through OSPF: [email protected]> show route protocol ospf inet.0: 17 destinations, 19 routes (17 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.4.0.0/24 10.5.0.0/24 10.10.1.0/24 10.10.2.0/24 172.23.3.0/24 172.23.7.0/24 224.0.0.5/32 *[OSPF/10] 00:07:38, metric 2000 > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/10] 00:07:38, metric 2000 > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/10] 00:07:44, metric 2000 > to 10.2.0.3 via ge-0/0/2.0 *[OSPF/10] 00:07:44, metric 2000 > to 10.2.0.3 via ge-0/0/2.0 *[OSPF/10] 00:00:08, metric 3000 > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/10] 00:00:08, metric 3000 > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/10] 00:56:28, metric 1 MultiRecv CAUTION It is important to remember the limitations of RIP. OSPF can scale to a large number of subnets, whereas RIP cannot. If the number of subnets advertised by OSPF is excessive then you should look either at summarizing the routes or migrate RIP to OSPF without performing any redistribution. In order to create the policy statement to tell OSPF to advertise routes received from RIP, use the following conﬁgurations. In this instance, the policy statement will be given the name RIP-TO-OSPF: Chapter 6: Redistributing Route Information set policy-options policy-statement RIP-TO-OSPF term 1 from protocol rip set policy-options policy-statement RIP-TO-OSPF then accept When RIP was ﬁrst conﬁgured, a policy statement was created in order to tell RIP which subnets would be exported. As this statement already exists, it’s possible just to tell RIP to include OSPF routes, too: set policy-options policy-statement RIP term 1 from protocol ospf Finally, the policy statement needs to be added under the OSPF conﬁguration: set protocols ospf export RIP-TO-OSPF Once the conﬁguration has been committed, router vMX0 should be able to see the subnet 172.23.1.0/24 in its routing table. Let’s check: [email protected]> show route protocol ospf 172.23.1.0 inet.0: 24 destinations, 27 routes (24 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.23.1.0/24 *[OSPF/150] 00:00:12, metric 2, tag 0 > to 10.3.0.2 via ge-0/0/1.0 And vMX0 should now also be able to ping interface ge-0/0/2.0 on router vMX3: [email protected]> ping 172.23.1.1 PING 172.23.1.1 (172.23.1.1): 56 data bytes 64 bytes from 172.23.1.1: icmp_seq=0 ttl=62 time=23.157 ms 64 bytes from 172.23.1.1: icmp_seq=1 ttl=62 time=4.387 ms 64 bytes from 172.23.1.1: icmp_seq=2 ttl=62 time=4.524 ms 64 bytes from 172.23.1.1: icmp_seq=3 ttl=62 time=3.996 ms ^C --- 172.23.1.1 ping statistics --4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.996/9.016/23.157/8.167 ms Redistribution Between OSPF and IS-IS Redistribution between OSPF and IS-IS is similar to redistribution between OSPF and RIP, where a policy statement must be created and assigned to the protocol. In this case the ASBR is router vMX2. If router vMX0 attempts to ping interface ge-0/0/0.0 on router vMX5, the ping should fail: [email protected]> ping 10.10.3.1 PING 10.10.3.1 (10.10.3.1): 56 data bytes ^C --- 10.10.3.1 ping statistics --- 6 packets transmitted, 0 packets received, 100% packet loss As this would be a two-way redistribution and because no policy statement currently exists, two policy statements need to be created. The ﬁrst statement will be applied to the OSPF conﬁguration: 85 86 Day One: Routing the Internet Protocol set policy-options policy-statement ISIS-TO-OSPF term 1 from protocol isis set policy-options policy-statement ISIS-TO-OSPF then accept And this second policy statement will be applied to the IS-IS conﬁguration: set policy-options policy-statement OSPF-TO-ISIS term 1 from protocol ospf set policy-options policy-statement OSPF-TO-ISIS then accept These policy statements are then applied to the protocol conﬁguration as follows: set protocols ospf export ISIS-TO-OSPF set protocols isis export OSPF-TO-ISIS Once things has been committed, router vMX0 should now be able to ping interface ge-0/0/0.0 on router vMX5: [email protected]> ping 10.10.3.1 PING 10.10.3.1 (10.10.3.1): 56 data 64 bytes from 10.10.3.1: icmp_seq=0 64 bytes from 10.10.3.1: icmp_seq=1 64 bytes from 10.10.3.1: icmp_seq=2 64 bytes from 10.10.3.1: icmp_seq=3 64 bytes from 10.10.3.1: icmp_seq=4 ^C --- 10.10.3.1 ping statistics --- bytes ttl=63 ttl=63 ttl=63 ttl=63 ttl=63 time=4.817 time=4.841 time=5.747 time=4.142 time=6.485 ms ms ms ms ms 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.142/5.206/6.485/0.818 ms Redistribution Between RIP and IS-IS As with the redistribution between OSPF and RIP, it is perfectly acceptable to reuse the same policy statement RIP already uses. In this instance, however, rather than put IS-IS under the same term as RIP and direct, a second term has been created and IS-IS has been placed under this instead. As long as there is the then accept statement at the very end of the policy statement, then this will work, too. One reason to create this as a second term is to help keep it tidy, and to allow the administrator to see at a glance that a protocol is being redistributed. This conﬁguration will be applied to both vMX3 and vMX6 as these are both ASBRs between the RIP and IS-IS domains. The ﬁrst command adds the second term to the policy statement RIP is currently using: set policy-options policy-statement RIP term 2 from protocol isis Once the RIP policy statement has been modiﬁed, a new policy statement that will be applied to the IS-IS conﬁguration should be created: set policy-options policy-statement RIP-TO-ISIS term 1 from protocol rip set policy-options policy-statement RIP-TO-ISIS then accept Finally IS-IS is then told to use this policy statement: set protocols isis export RIP-TO-ISIS Chapter 6: Redistributing Route Information In theory, even before the commands to redistribute between RIP and IS-IS were committed, all routers should have been able to see all subnets as routers vMX2 and vMX4 were redistributing between IS-IS and OSPF and between OSPF and RIP. What happens, however, if an interface goes down? By redistributing between these processes, too, the network should have full redundancy. To prove this, interface ge0/0/0.0 on router vMX2 will be disabled. First, if traceroute were to be run from vMX0 to router vMX5s interface in subnet 10.10.1.2, the packet should go via router vMX2 as this is the best path: [email protected]> traceroute 10.10.1.2 traceroute to 10.10.1.2 (10.10.1.2), 30 hops max, 40 byte packets 1 10.2.0.3 (10.2.0.3) 2.813 ms 1.773 ms 1.238 ms 2 10.10.1.2 (10.10.1.2) 3.897 ms 3.536 ms 3.518 ms The interface between vMX0 and vMX2 is then disabled by using the following command: set interfaces ge-0/0/0.0 disable After a brief pause to allow the route to be withdrawn, traceroute is run once more to the same address. This time the packet traverses routers vMX1, vMX4, vMX3, and vMX2: [email protected]> traceroute 10.10.1.2 traceroute to 10.10.1.2 (10.10.1.2), 30 hops max, 40 byte packets 1 10.3.0.2 (10.3.0.2) 1.673 ms 1.557 ms 1.211 ms 2 10.5.0.2 (10.5.0.2) 1.958 ms 1.659 ms 2.345 ms 3 172.23.3.1 (172.23.3.1) 8.090 ms 2.908 ms 3.335 ms 4 10.10.2.1 (10.10.2.1) 7.119 ms 4.644 ms 5.151 ms 5 10.10.1.2 (10.10.1.2) 5.828 ms 5.396 ms 4.431 ms Filtering Routes During Redistribution The conﬁguration covered in the previous section would, of course, redistribute every route between protocols, meaning every subnet was accessible from every part of the network. Imagine for a moment that this was not a desirable result and that there were some subnets you didn’t want to redistribute. By utilizing the same policy statement, in addition to a preﬁx-list, it is possible to ﬁlter out individual subnets so that they aren’t redistributed. In this section, the subnet 172.23.1.0/24 will be ﬁltered by the ASBRs so that routers vMX0 and vMX1 and the two VSRX ﬁrewalls will not be able to reach that subnet. Before this is done, however, router vMX0 should be checked to see if it does have reachability to that subnet: [email protected]> show route protocol ospf inet.0: 25 destinations, 29 routes (25 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 87 88 Day One: Routing the Internet Protocol 10.4.0.0/24 10.5.0.0/24 10.10.1.0/24 10.10.2.0/24 10.10.3.0/24 10.233.240.0/20 172.23.1.0/24 172.23.3.0/24 172.23.7.0/24 192.168.1.0/24 192.168.1.1/32 192.168.1.2/32 192.168.1.3/32 192.168.1.4/32 224.0.0.5/32 *[OSPF/10] 00:14:00, metric 2000 > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/10] 00:14:00, metric 2000 > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/150] 00:13:09, metric 2, tag > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/150] 00:13:14, metric 2, tag > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/150] 00:12:48, metric 2, tag > to 10.3.0.2 via ge-0/0/1.0 [OSPF/150] 00:13:14, metric 0, tag > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/150] 00:13:14, metric 2, tag > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/10] 00:13:14, metric 3000 > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/10] 00:13:14, metric 3000 > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/150] 00:13:14, metric 2, tag > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/150] 00:13:09, metric 2, tag > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/150] 00:13:14, metric 2, tag > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/150] 00:12:48, metric 2, tag > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/150] 00:12:08, metric 2, tag > to 10.3.0.2 via ge-0/0/1.0 *[OSPF/10] 00:15:29, metric 1 MultiRecv 0 0 0 0 0 0 0 0 0 0 In the previous sections, a policy statement was created and assigned to the OSPF conﬁguration. The ﬁrst router these changes will be made to is vMX2. The conﬁguration of the existing policy statement is as follows: policy-statement ISIS-TO-OSPF { term 1 { from { protocol isis; } then accept; } This policy statement can be easily modiﬁed by adding extra “terms.” Before this is done, however, a preﬁx list needs to be created that will identity which subnets are to be ﬁltered. The name of this preﬁx list will be ONESEVENTWOTWENTYTHREEONE and it will match the subnet 172.23.1.0/24: set policy-options prefix-list ONESEVENTWOTWENTYTHREEONE 172.23.1.0/24 Now that the preﬁx list has been created, it can be added to t he policy statement. Policy statements operate from the top down. As soon as the policy statement ﬁnds a match, it stops processing, and if it doesn’t Chapter 6: Redistributing Route Information ﬁnd a match then it automatically rejects. In this case, if the ﬁlter was applied to the next “term” then the policy statement will still allow this route, through, and therefore the preﬁx list needs to be applied to Term 1, then within Term 1 a reject will be set. NOTE There are in fact two ways of specifying which routes should be ﬁltered, the ﬁrst is using the preﬁx-list as described here, and the second is using a route-ﬁlter, which will be covered in Chapter 9, where routes will be ﬁltered and summarized instead: set policy-options policy-statement ISIS-TO-OSPF term 1 from prefixlist ONESEVENTWOTWENTYTHREEONE set policy-options policy-statement ISIS-TO-OSPF term 1 then reject If this were to be committed now, this policy would reject all routes because of the implicit reject, therefore a second term needs to be created that matches just the protocol. The accept term already at the end of the policy statement will ensure that routes other than the one ﬁltered in Term 1, are now accepted: set policy-options policy-statement ISIS-TO-OSPF term 2 from protocol isis Once this is committed, router vMX0 will be able to reach this subnet, because there are two ASBRs. So these ﬁlters need to be applied to vMX4, too. In this case, the ﬁlter needs to be applied on the policy statement that redistributes RIP into OSPF. The existing policy statement is conﬁgured as follows: policy-statement RIP-TO-OSPF { term 1 { from { protocol rip; } then accept; } The ﬁrst thing that should be done is to create the preﬁx list. In this case it will be given the same name as on router vMX2: set policy-options prefix-list ONESEVENTWOTWENTYTHREEONE 172.23.1.0/24 And, as before, this should be added to Term 1 and a reject should be applied: set policy-options policy-statement RIP-TO-OSPF term 1 from prefixlist ONESEVENTWOTWENTYTHREEONE set policy-options policy-statement RIP-TO-OSPF term 1 then reject Finally, a second term needs to be created so that the other routes are accepted: set policy-options policy-statement RIP-TO-OSPF term 2 from protocol rip 89 90 Day One: Routing the Internet Protocol If vMX0 starts to ping vMX3’s ge-0/0/2.0 interface while the conﬁguration is committed to router vMX4, you should see that the route is very quickly withdrawn by OSPF. In this case, the Junos OS warns us that there was no route to the host: [email protected]> ping 172.23.1.1 PING 172.23.1.1 (172.23.1.1): 56 data bytes 64 bytes from 172.23.1.1: icmp_seq=0 ttl=62 time=10.478 ms 64 bytes from 172.23.1.1: icmp_seq=10 ttl=62 time=5.307 ms 64 bytes from 172.23.1.1: icmp_seq=11 ttl=62 time=9.757 ms ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host As a ﬁnal check, just by looking at the routing table, it should be apparent that this route has disappeared, meaning the ﬁlter was successful: [email protected]> show route protocol ospf | match 172.23 172.23.3.0/24 *[OSPF/10] 00:20:21, metric 3000 172.23.7.0/24 *[OSPF/10] 00:20:21, metric 3000 Summary While running a single protocol on a LAN is ideal, this is not always possible and as such this chapter has demonstrated that it is possible to run two, three, or even four routing protocols on a LAN at the same time should the need arise. Aside from being used during an acquisition or merger, redistribution is typically used when a corporate LAN grows beyond its existing routing protocol. An administrator can enable the new routing protocol on a router by router basis and redistribute between the new and the old protocol until the migration is complete. Junos is ideal in this case as the administrator has an easy means to rollback the conﬁguration should something go wrong during a migration. In addition the Junos OS runs each protocol in its own process thereby protecting the network device should something happen to one of the processes, this means the network largely remains accessible. The next chapter covers the most scalable protocol available on any network today. The scalability is such that it is capable of advertising almost every single subnet that exists in the world, with the exception of those in the private address ranges. This protocol is BGP. Chapter 7 Border Gateway Protcol (BGP) The previous chapters in this Day One book have explored interior gateway protocols (IGPs). Let’s now move on to exterior gateway protocols (EGPs). So much has been written already about BGP that it is hard to add a unique introduction to one of world’s most popular protocols. It literally runs the world’s networks! NOTE Do not confuse EGP with the 1980s EGP3 that was deﬁned in RFC 827. EGP in this book refers to BGP4 (Border Gateway Protocol). BGP4 is a routing protocol that operates between networks that are under different administrative control. This is what makes BGP4 an exterior gateway protocol as it operates between Autonomous Systems (ASs). Border Gateway Protocol (BGP) is a standardize d exterior gateway protocol designed to e xchange routing and reachabili ty information between autonomo us systems (ASs) on the Internet . https://en.wikipedia .org/ wiki/Border_Gateway_ Protocol . BGP is an exterior gateway protocol that allows the exchange of routing information between routers in different autonomous systems (ASs). Routing information includes the complete route to each destination. BGP uses this information to maintain a Routing Information Base (RIB), which allows it to remove routing loops and to enforce policy decisions at an AS level. 92 Day One: Routing the Internet Protocol BGP allows for policy-based routing. You can use routing policies to choose among multiple paths to a destination and to control the redistribution of routing information. An AS is deﬁned as a group of IP networks operated by one or more network operators that has a single, clearly deﬁned routing policy. The Transmission Control Protocol (TCP) is a core protocol of the Internet Protocol Suite . It originated in the initial network implementation in which it complemented the Internet Protocol (IP). https://en.wikipedia .org/w iki/ Transmission_Control_ Protocol. If you look back at Chapter 2, Table 2.2, you can see that BGP (both iBGP and eBGP) is a path vector routing protocol that uses the uniqueness of AS numbers to help detect any loops. BGP uses additional attributes to describe the path to preﬁxes, also known as reachability information. These attributes are discussed later in this chapter. One of the main differences of BGP as a routing protocol compared to other IGPs in this book is that BGP uses the Transmission Control Protocol (TCP) for its transporting reliability. This means that there is no need for periodic route updates – quite handy since the current BGP Global IPv4 routing table is ~542,000 preﬁxes! With the lack of periodic updates, BGP still needs to conﬁrm that other ASs are still reachable and functional. This is resolved by the use of keepalive packets. Now, before drilling down into the Junos OS examples, let’s ﬁrst discuss routing attributes. BGP Route Attributes BGP uses additional attributes and route reachability to describe the path to preﬁxes. This is referred to as Next Layer Reachability Information (NLRI). Below are the categories into which all BGP route attributes fall. There are also examples of BGP path attributes on each category, as well as a short explanation:  Well-known mandatory: Must be present in all update messages and must be supported by all BGP speakers. AS Path, Next-hop, Origin.  Well-known discretionary: May be present in update messages and must be supported by all BGP speakers. Local Preference, Atomic Aggregate.  Optional transitive: May not be recognized by all BGP speakers. If not recognized it is still expected to be propagated to other neighbors. Community, Aggregator. Chapter 7: Border Gateway Protcol (BGP)  Optional nontransitive: May not be recognized by all BGP speakers. Attribute not propagated to other neighbors. Multi Exit Descriminator (MED). BGP Path Attributes Let’s examine some of these path attributes a bit further. AS Path Attribute The mandatory attribute AS Path lists the ASs that are traversed when forwarding to the associated NLRI as shown in Figure 7.1. Figure 7.1 An AS Path Attribute The AS Path Attribute shows the sequence of ASs a route has traversed. It is used for loop detection and path metrics where the length of the path is used for the path selection. 93 94 Day One: Routing the Internet Protocol Loop Detection Figure 7.2 Loop Detection Attribute You can see here in Figure 7.2 that 92.1.0.0/16 is not accepted by AS30 due it having AS40 in its path. Next Hop Figure 7.3 Next Hop Attribute Chapter 7: Border Gateway Protcol (BGP) The next hop AS attribute shows the IP address to reach the next AS. From the viewpoint of AS15, you can see the following: [email protected]> show route protocol bgp inet.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 90.1.0.0/16 91.1.0.0/16 92.1.0.0/16 *[BGP/170] 00:40:49, localpref 100 AS path: 20 40 I, validation-sta te: unverified > to 10.0.0.2 via ge-0/0/0.0 [BGP/170] 00:40:49, localpref 100 AS path: 30 40 I, validation-sta te: unverified > to 10.0.0.6 via ge-0/0/1.0 *[BGP/170] 00:49:35, localpref 100 AS path: 20 I, validation-stat e: unverified > to 10.0.0.2 via ge-0/0/0.0 *[BGP/170] 00:50:10, localpref 100 AS path: 30 I, validation-stat e: unverified > to 10.0.0.6 via ge-0/0/1.0 So AS15 can see 90.1.0.0/ via two paths. One path via 10.0.0.2, which is AS20, and the other path via 10.0.0.6, which is AS30. The next-hop attribute is well known and mandatory in BGP. Local Preference The local preference attribute is used to advertise to iBGP neighbors on how to leave their AS. It is a well-known discretionary attribute and is kept within the AS. The higher the local preference the more desirable the path. Origin The origin code is used to identify the original source of a route being learned. It can be one of the following: 90.1.0.0/16  I – IGP  E – EGP  ? – Unknown/Incomplete *[BGP/170] 00:40:49, localpref 100 AS path: 20 40 I, validation-state: unverified > to 10.0.0.2 via ge-0/0/0.0 A BGP speaker prefers origins in the following order: IGP / EGP / Unknown/Incomplete. Origin is a well known mandatory attribute. 95 96 Day One: Routing the Internet Protocol Multi Exit Discriminator The multi exit discriminator (MED) is an optional non-transitive attribute and some BGP speakers may not understand or even use the attribute. MED is also kept within the AS it was advertised to and will not transit any further. Here’s an example: [email protected]> show route protocol bgp inet.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 90.1.0.0/16 *[BGP/170] 00:01:07, MED 10, localpref 100 AS path: 40 I, validation-sta te: unverified > to 10.0.0.10 via ge-0/0/0.0 The lower the MED the more preferred the path, should all other decisions with BGP path selection process be equal (more on BGP path selection next). Community BGP communities allow for the tagging of multiple routes that may share one or more characteristics. These tags can be used to allow upstream devices to apply speciﬁc routing policies within their AS. The common format is LOCAL-AS:xx, where xx is represented as two 16 bit integers as per RFC1998. Community is an optional transitive attribute. BGP Path Selection Tutorial The Junos OS BGP path selection algorithm is slightly different from other vendors (who all have their own slant of path selection). This book only describes the Juniper path selection process so as not to muddy the waters. NOTE For interop issues, you should consult the documentation of your device’s vendor. When a BGP router is presented with a preﬁx that has more than one route to it, the Junos OS route selection process is st arted and it operates on the following logic: 1. Can the next hop be resolved? 2. Prefers the path with the highest local preference 3. Prefers the path with the shortest AS path length 4. Prefers the path with the lowest origin value Chapter 7: Border Gateway Protcol (BGP) 5. Prefers the path with lower MED value 6. Prefers paths learned by eBGP over iBGP 7. Prefers paths with lowest IGP metric 8. Prefers paths with shortest cluster length 9. Prefers routes from peer with lowest router ID 10. Prefers routes from peer with lowest peer ID The last two points can be removed if you activate multipath. Enabling the multipath option allows routes for the same preﬁx that have passed the ﬁrst eight steps to be installed onto the route table. MORE? For more on the multipath option, see the Juniper TechLibrary: http:// www.juniper.net/techpubs/en_US/junos12.1/topics/reference/conﬁguration-statement/multipath-edit-protocols-bgp.html. Having digested all that, let’s take a look at BGP path selection using the topology shown in Figure 7.4. Figure 7.4 BGP Path Selection Example Figure 7.4 has four routers within AS15 and two external ASs, 65500, and 65501, announcing 192.0.2.0/24, and 203.0.113.0/24, respectively. OSPF is running between them and the loopbacks are also announced. There is a full mesh of iBGP sessions between all four routers within AS15. To calculate the amount of iBGP sessions you need a full mesh that uses the following calculation: N(N-1)/2 and applied to the above 4(4-1)/2 = 6. So let’s have a look at R3 and R4 to see the routes that the external ASs are announcing: 97 98 Day One: Routing the Internet Protocol [email protected]> show bgp summary Groups: 2 Peers: 5 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 6 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/ Dwn State|#Active/Received/Accepted/Damped... 90.1.0.1 15 227 227 0 0 1:40:57 0/0/0/0 0/0/0/0 91.1.0.1 15 176 177 0 0 1:19:04 0/0/0/0 0/0/0/0 92.1.0.1 15 187 186 0 0 1:23:11 0/2/2/0 0/0/0/0 198.51.100.6 65500 56 53 0 0 23:01 1/2/2/0 0/0/0/0 198.51.100.10 65501 96 96 0 0 41:42 1/2/2/0 0/0/0/0 From R3 you can see that AS 65500 and 65001 are both sending two routes that have been accepted but only one route from each AS has been made active. You can also see the two routes via the iBGP session with 92.1.0.1, but neither are the active routes. This is due to the best path selection preferring eBGP over iBGP in Step 6 of the selection process. Now, let’s have a look at why only one route from each session is active: [email protected]> show route receive-protocol bgp 198.51.100.6 inet.0: 20 destinations, 25 routes (20 active, 0 holddown, 2 hidden) Prefix Nexthop MED Lclpref AS path 192.0.2.0/24 198.51.100.6 65500 65501 I * 203.0.113.0/24 198.51.100.6 65500 I [email protected]> show route receive-protocol bgp 198.51.100.10 inet.0: 20 destinations, 25 routes (20 active, 0 holddown, 2 hidden) Prefix Nexthop MED Lclpref AS path * 192.0.2.0/24 203.0.113.0/2 4 198.51.100.10 198.51.100.10 65501 I 65501 65500 I If you look closely you can see that both ASs are sending 192.0.2.0/24 and 203.0.113.0/24, but only one route is selected as active (denoted by the *). If you also look at the AS Path you can see that each external AS is announcing their locally originated route plus the other AS’s locally originated route. If you look back at Figure 7.3 you can see where the connection to each AS is, and you can see R3 has direct connections to each external AS. This means that in the BGP best path selection process this made it Step 3 (prefers the path with the shortest AS Path length). It makes good sense, as there would be no point getting to 203.0.113.0/24 via 65501 when you can see it directly from 65500, and the same is true of 192.0.2.0/24 being seen via 65500 when you can see it directly via 65501. Why add an extra AS to traverse! Let’s have a look at R4: Chapter 7: Border Gateway Protcol (BGP) [email protected]> show bgp summary Groups: 2 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 4 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active /Received/ Accepted/Damped... 90.1.0.1 15 253 256 0 0 1:54:01 0/0/0/0 0/0/0/0 91.1.0.1 15 246 247 0 0 1:50:45 0/0/0/0 0/0/0/0 93.1.0.1 15 253 254 0 0 1:53:53 0/2/2/0 0/0/0/0 198.51.100.1 65500 103 102 0 0 45:07 2/2/2/0 0/0/0/0 Now in this output you can see that R4 is receiving two routes (boldface): from iBGP (AS15) and eBGP (AS65500). You already know that eBGP is preferred over iBGP, so it makes sense that the active routes (routes installed to the Forwarding Information BASW – FIB) are installed from the routes accepted from AS6500. Let’s have a look at the routes learned from AS65500: [email protected]> show route receive-protocol bgp 198.51.100.1 inet.0: 15 destinations, 17 routes (15 active, 0 holddown, 2 hidden) Prefix Nexthop MED Lclpref AS path * 192.0.2.0/24 198.51.100.1 65500 65501 I * 203.0.113.0/24 198.51. 100.1 65500 I You can see here that R4 has received and accepted the two routes and has made them active in the FIB, which is great. As R4 only has one external eBGP connection, you are seeing both routes via AS65500 with 192.0.2.0/24 transiting through to AS65501. So now, both the eBGP facing routers (R3 and R4) receive the same routes, and since there is a full mesh iBGP setup between all the routers in AS15, they should all be able to see the two external preﬁxes. Or can they? Let’s have a look at R2 to conﬁrm: [email protected]> show bgp summary Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 4 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/R eceived/ Accepted/Damped... 90.1.0.1 15 325 326 0 0 2:26:22 0/0/0/0 0/0/0/0 92.1.0.1 93.1.0.1 15 15 286 283 286 283 0 0 0 0 2:08:35 0/2/2/0 2:07:36 0/2/2/0 0/0/0/0 0/0/0/0 Here, both R3 and R4 have sent two routes, which have been received and accepted, but they haven’t become active. Let’s do some debugging to see why, starting at R2: [email protected]> show route receive-protocol bgp 92.1.0.1 inet.0: 13 destinations, 15 routes (11 active, 0 holddown, 4 hidden) 99 100 Day One: Routing the Internet Protocol Hmm, it’s not showing us any routes, but from the output (boldface) you can see that four routes are hidden. Could these be the two routes from R3 and from R4? Let’s investigate: [email protected]> show route receive-protocol bgp 92.1.0.1 hidden inet.0: 13 destinations, 15 routes (11 active, 0 holddown, 4 hidden) Prefix Nexthop MED Lclpref AS path 192.0.2.0/24 198.51.100.1 100 65500 65501 I 203.0.113.0/2 4 198.51.100.1 100 65500 I [email protected]> show route receive-protocol bgp 93.1.0.1 hidden inet.0: 13 destinations, 15 routes (11 active, 0 holddown, 4 hidden) Prefix Nexthop MED Lclpref AS path 192.0.2.0/24 198.51.100.10 100 65501 I 203.0.113.0/2 4 198.51.100.6 100 65500 I The missing routes are found, but why are they hidden? The AS paths look correct, and the next hop and the Origin attributes all look okay. Let’s look at one of the hidden routes in a bit more detail using the extensive option: [email protected]> show route 192.0.2.0/24 hidden extensive inet.0: 13 destinations, 15 routes (11 active, 0 holddown, 4 hidden) 192.0.2.0/24 (2 entries, 0 announced) BGP Preference: 170/-101 Next hop type: Unusable Address: 0x92854a4 Next-hop reference count: 4 State: Local AS: 15 Peer AS: 15 Age: 1:12:13 Validation State: unverified Task: BGP_15.92.1.0.1+179 AS path: 65500 65501 I Aggregator: 65501 192.0.2.1 Accepted Localpref: 100 Router ID: 92.1.0.1 Indirect next hops: 1 Protocol next hop: 198.51.100.1 BGP Indirect next hop: 0x0 - INH Session ID: 0x0 Preference: 170/-101 Next hop type: Unusable Address: 0x92854a4 Next-hop reference count: 4 State: Local AS: 15 Peer AS: 15 Age: 1:39:30 Validation State: unverified Task: BGP_15.93.1.0.1+179 AS path: 65501 I Aggregator: 65501 192.0.2.1 Accepted Localpref: 100 Router ID: 93.1.0.1 Indirect next hops: 1 Protocol next hop: 198.51.100.10 Indirect next hop: 0x0 - INH Session ID: 0x0 Chapter 7: Border Gateway Protcol (BGP) So you can see the routes from both R3 and R4, but both are saying the next hop is unusable!? Let’s double-check this: [email protected]> show route 198.51.100.1 [email protected]> show route 198.51.100.10 [email protected]> The next hops that both R3 and R4 are advertising are not in the routing table. How do you ﬁx this? Let’s jump back to R4 and see what can be done: [email protected]> show route 198.51.100.1 inet.0: 15 destinations, 17 routes (15 active, 0 holddown, 2 hidden) + = Active Route, - = Last Active, * = Both 198.51.100.0/ 30 *[Direct/0] 01:32:08 > via ge-0/0/2.0 Here, R4 does have a route to 198.51.100.1. That makes sense, as both routes are active on this router, allowing them to be announced back to R2. So how does R2, and presumably all the other routers in AS15, know about this directly connected interface and also the two directly connected interfaces on R3? Static routes can be added (remember Chapter 1?) across all the routers in AS15 but this seems a bit cumbersome and not very scalable. Let’s look at a routing protocol, like OSPF, and passively add the interface into OSPF and see what happens on R2: [edit] [email protected]# set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 [edit] [email protected]# commit commit complete Now to check out R2: [[email protected]> show bgp summary Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 4 2 0 0 0 0 Peer AS InPkt Ou tPkt OutQ Fla ps Last Up/Dwn State|#Active/ Received/Accepted/Damped... 90.1.0.1 15 394 395 0 0 2:57:53 0/0/0/0 0/0/0/0 92.1.0.1 15 354 355 0 0 2:40:06 2/2/2/0 0/0/0/0 93.1.0.1 15 351 352 0 0 2:39:07 0/2/2/ 0/0/0/0 [email protected]2> show route receive-protocol bgp 92.1.0.1 inet.0: 14 destinations, 16 routes (14 active, 0 holddown, 2 hidden) Prefix Nexthop MED Lclpref AS path * 192.0.2.0/24 198.51.100.1 100 65500 65501 I * 203.0.113.0/24 198.51.100.1 100 65500 I 101 102 Day One: Routing the Internet Protocol Great! Both routes are now active but two routes are still hidden and it still needs the external interfaces on R3 added into OSPF. Let’s do this and then see how this affects R2: [email protected]> show bgp summary Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State inet.0 3 2 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Received/Accepted/Damped... 90.1.0.1 15 405 406 0 0 3:02:48 92.1.0.1 15 366 366 0 0 2:45:01 93.1.0.1 15 362 363 0 0 2:44:02 Pending 0 Up/Dwn State|#Active/ 0/0/0/0 0/1/1/0 2/2/2/0 0/0/0/0 0/0/0/0 0/0/0/0 Fantastic! The active routes from R3 can be seen now, which makes sense because looking at the BGP best path selection steps you can see that they have been selected because:  192.0.2.0/24 is selected as active from R3 because it is a shorter AS Path length than R4.  203.0.113.0/24 is selected as active from R3 because it is a lower IGP metric from R2 to R3 than R2 to R4. The more careful reader may have spotted that there is only receiving one route from R4 instead of an earlier two. Why would that be? Let’s have a look back on R4: [email protected]> show bgp summary Groups: 2 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed inet.0 4 2 0 0 Peer AS InPkt OutPkt OutQ Accepted/Damped... 90.1.0.1 15 1886 1887 91.1.0.1 15 1886 1888 93.1.0.1 15 1886 1889 198.51.100.2 65500 89 88 History Damp State Pending 0 0 Flaps Last Up/Dwn State|#Active/R eceived/ 0 0 0 0 1 1 0 0 10:41:22 0/0/0/0 13:07:38 0/0/0/0 14:14:25 1/2/2/0 38:35 1/2/2/0 0/0/0/0 0/0/0/0 0/0/0/0 0/0/0/0 You can see that there is one learned route from AS65500 and one from our iBGP neighbor, R3. Let’s have a look at the routes and why there is one active from each peer: [email protected]> show route protocol bgp inet.0: 19 destinations, 21 routes (19 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.0.2.0/24 203.0.113.0/24 *[BGP/170] 01:08:53, localpref 100, from 93.1.0.1 AS path: 65501 I, validation-st ate: unverified > to 10.0.0.5 via ge-0/0/2.0 [BGP/170] 01:08:49, localpref 100 AS path: 65500 65501 I, validation-stat e: unverified > to 198.51.100.2 via ge-0/0/3.0 *[BGP/170] 01:25:59, localpref 100 AS path: 65500 I, validation-st ate: unverified > to 198.51.100.2 via ge-0/0/3.0 Chapter 7: Border Gateway Protcol (BGP) [BGP/170] 01:26:45, localpref 100, from 93.1.0.1 AS path: 65500 I, validation-sta te: unverified > to 10.0.0.5 via ge-0/0/2.0 Here you can see that each route has two paths. BGP best path has selected both active routes due to their shortest AS Path length. However, iBGP does not prepend its own AS when making the calculation, and that is why 192.02.0/24 is preferred via 65501 with the next hop being R3. Now does this explain why R4 is only sending one route to R2 or doesn’t it? Let’s investigate iBGP to ﬁnd out. iBGP At the beginning of this chapter eBGP was noted as external and iBGP as being internal . External peers (according to peers within an AS) establish links via eBGP. The router then takes these routes and advertises them internally within the AS with other BGP-speaking peers with iBGP. One of the fundamental differences between iBGP and eBGP is that to avoid routing loops iBGP does not advertise routes learned from other iBGP neighbors. Fully Meshed: A mesh network whose nodes are all connected to each other is a fully connected network . https://en.wikipedia .org/wi ki/ Mesh_networking . For this reason, BGP cannot propagate routes throughout an AS by passing them from one router to another. Instead, BGP requires that all internal peers be fully meshed so that any route advertised by one router is advertised to all peers within the AS. And this explains why R2 is only seeing one preﬁx from R4 because it has learned one route from eBGP (which is advertised to R2) and one route from iBGP (which is not advertised to avoid routing loops). This means that our topology is working as expected. Scaling iBGP The topology that has been used in the AS is a full mesh BGP that is manageable, but what if there were ﬁfty routers within the AS? Using the calculation, you can see that ﬁfty routers would require 50(501)/2=1225 BGP peering sessions. That’s a lot of time and effort to put into the network to build it full mesh! What if there was a way to scale the amount of routers within your network but not be held up by setting up a full mesh network? MORE? Thankfully there are two ways to scale your iBGP: route reﬂectors and confederations. The implementation of these two methodologies is outside the scope of this Day One book, but further information can 103 104 Day One: Routing the Internet Protocol be found at the Juniper TechLibrary: http://www.juniper.net/documentation/en_US/junos15.1/topics/concept/routing-protocol-bgp-securityroute-reﬂector-understanding.html; and at, http://www.juniper.net/ documentation/en_US/junos13.1/topics/topic-map/bgp-confederations.html Let’s look at scaling BGP and how to resolve the next-hop issue by adding external links. Is this really scalable by adding all these link subnets to our IGP? Probably not, so let’s see what we can do about that. The reason the external links were added to our IGP was to activate routes within our AS that couldn’t resolve the next hop. A quick reminder is here: [email protected]> show route 192.0.2.0/24 hidden extensive inet.0: 13 destinations, 15 routes (11 active, 0 holddown, 4 hidden) 192.0.2.0/24 (2 entries, 0 announced) BGP Preference: 170/-101 Next hop type: Unusable Address: 0x92854a4 Next-hop reference count: 4 State: Local AS: 15 Peer AS: 15 Age: 1:12:13 Validation State: unverified Task: BGP_15.92.1.0.1+179 AS path: 65500 65501 I Aggregator: 65501 192.0.2.1 Accepted Localpref: 100 Router ID: 92.1.0.1 Indirect next hops: 1 Protocol next hop: 198.51.100.1 BGP Indirect next hop: 0x0 - INH Session ID: 0x0 Preference: 170/-101 Next hop type: Unusable Address: 0x92854a4 Next-hop reference count: 4 State: Local AS: 15 Peer AS: 15 Age: 1:39:30 Validation State: unverified Task: BGP_15.93.1.0.1+179 AS path: 65501 I Aggregator: 65501 192.0.2.1 Accepted Localpref: 100 Router ID: 93.1.0.1 Indirect next hops: 1 Protocol next hop: 198.51.100.10 Indirect next hop: 0x0 - INH Session ID: 0x0 So the next hop to 198.51.100.1 and 198.51.100.10 is unusable because it’s not in the IGP, so what can you do to resolve this? Let’s have a look at R2 and show OSPF: Chapter 7: Border Gateway Protcol (BGP) [email protected]> show route protocol ospf inet.0: 18 destinations, 19 routes (18 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.4/30 10.0.0.12/30 90.1.0.1/32 92.1.0.1/32 93.1.0.1/32 198.51.100.0/ 30 198.51.100.4/ 30 198.51.100.8/ 30 224.0.0.5/32 *[OSPF/10] 20:09:34, metric 2 > to 10.0.0.2 via ge-0/0/2.0 *[OSPF/10] 02:26:11, metric 2 > to 10.0.0.9 via ge-0/0/1.0 *[OSPF/10] 02:26:11, metric 1 > to 10.0.0.9 via ge-0/0/1.0 *[OSPF/10] 02:26:11, metric 2 > to 10.0.0.9 via ge-0/0/1.0 to 10.0.0.2 via ge-0/0/2.0 *[OSPF/10] 20:09:34, metric 1 > to 10.0.0.2 via ge-0/0/2.0 *[OSPF/10] 02:26:11, metric 3 > to 10.0.0.9 via ge-0/0/1.0 to 10.0.0.2 via ge-0/0/2.0 *[OSPF/10] 09:35:13, metric 2 > to 10.0.0.2 via ge-0/0/2.0 *[OSPF/10] 09:35:13, metric 2 > to 10.0.0.2 via ge-0/0/2.0 *[OSPF/10] 23:44:42, metric 1 MultiRecv From R2’s output you can see the link subnets between OSPF neighbors and you can also see the loopback interfaces of the other routers within the AS, which is handy because they are the IPs that we are establishing our iBGP sessions to and from. What if the next-hop addresses could be changed to that of the router which learned the route? That would allow the AS to scale without adding additional routes into the IGP. Let’s have a go! First, roll back the changes on R3 and R4 and see things are back to accepting routes but not activating them from R2: [email protected]> show bgp summary Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed inet.0 4 0 0 Peer AS InPkt OutPkt Received/Accepted/Damped... 90.1.0.1 15 3190 3192 92.1.0.1 15 3043 3046 93.1.0.1 15 3183 3194 History Damp State 0 OutQ 0 0 0 Pending 0 0 Flaps Last Up/Dwn State|#Active / 0 1d 0:04:53 0/0/0/0 1 22:58:10 0/2/2/0 0 1d 0:05:02 0/2/2/0 0/0/0/0 0/0/0/0 0/0/0/0 That takes us back to an earlier point in this chapter, before adding the interfaces to OSPF, so let’s jump on to R4 and see how to set the eBGP learned routes to be advertised to our iBGP neighbors with the next hop of R4’s loopback interface. It may sound daunting but it’s really simple because from the standpoint of R4, it is exporting routes to the other iBGP neighbors. So let’s create a policy and apply it as an export to our iBGP neighbors: 105 106 Day One: Routing the Internet Protocol [email protected]# set policy-options policy-statem ent NEXT-HOP-SELF then accept next-hop self [edit] [email protected]# set protocols bgp group internal export NEXT-HOP-SELF [edit] [email protected]# commit commit complete [edit] [email protected]# show protocols bgp group internal type internal; local-address 92.1.0.1; export NEXT-HOP-SELF; peer-as 15; local-as 15; neighbor 90.1.0.1 { description R1; } neighbor 91.1.0.1 { description R2; } neighbor 93.1.0.1 { description R3; } And let’s let’s see if the desired result is on R2: [email protected]> show bgp summary Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed inet.0 4 2 0 Peer AS InPkt OutPkt OutQ Accepted/Damped... 90.1.0.1 15 3222 3228 0 92.1.0.1 15 3076 3081 0 93.1.0.1 15 3214 3230 0 History Damp State Pending 0 0 0 Flaps Last Up/Dwn State|#Active /Received/ 0 1 0 1d 0:18:57 0/0/0/0 23:12:14 2/2/2/0 1d 0:19:06 0/2/2/0 0/0/0/0 0/0/0/0 0/0/0/0 Looking good so far. Let’s Let’s have a look at the routes received: r eceived: [email protected]> show route receive-protocol bgp 92.1.0.1 detail inet.0: 15 destinations, 17 route s (15 active, 0 holddown, 2 hidden) * 192.0.2.0/24 (2 entries, 1 announced) Accepted Nexthop: 92.1.0.1 Localpref: 100 AS path: 65500 65501 I Aggregator: 65501 192.0.2.1 * 203.0.113.0/24 (2 entries, 1 announced) Accepted Nexthop: 92.1.0.1 Localpref: 100 AS path: 65500 I Aggregator: 65500 203.0.113.1 Fantastic! You can see that the next-hop address address for both routes is now the loopback of R4. All that’s left to do is add the next-hop policy to R3 and you should be back to having an active route from R4 and R3 on router R2: Chapter 7: Bord Border er Gateway Protcol (BGP) [email protected]> show bgp summary [email protected]> show Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 3 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active / Received/Accepted/Damped... 90.1.0.1 15 3248 3255 0 0 1d 0:31:05 0/0/0/0 0/0/0/0 92.1.0.1 15 3104 3108 0 1 23:24:22 0/1/1/0 0/0/0/0 93.1.0.1 15 3247 3257 0 0 1d 0:31:14 2/2/2/0 0/0/0/0 Awesome! You are now seeing one route received recei ved from R4 and two routes received and activated from R2, which is the same as when there were the two external ext ernal links in OSPF, OSPF, but this time there the re are two less /30 link subnets in the IGP! From this last example you can see that a routing policy was used to achieve our objective. Routing policies can be very powerful and can help us achieve many objectives, obj ectives, so s o let’s look at them further. BGP Routing Policy Junos routing policy is both fast and and granular so it could could have a Day One book to itself. In the meantime, this chapter covers some some basics to give you a taste of what it can do. Further exploration is advised to the reader. Let’s continue from the previous example where wher e a next-hop self policy was used to affect routing decisions within the AS. But now let’s expand on that further and have a look at manipulating both ingress and egress trafﬁc. traf ﬁc. To To do this, look at the import policy to affect routing routi ng decisions on how trafﬁc exits our AS and also the export policies that affect routing decisions on trafﬁc destined to our AS . Figure 7.5 repeats Figure 7.4 for your convenience. Figure 7.5 This Section’s Network Topology 107 108 Day One: Routing the Internet Protocol The network AS15 has been assigned 10.0.0.0/24 by the Acme Inernet Registry, hurrah! Let’s announce it to our transit providers! pro viders! On R3 and R4 create an export policy as follows: [email protected]# show | compare [edit policy-options] + policy-statem ent ANNOUNCE-OUR- RANGE { + term announce-aggre gate-route { + from { + protocol aggregate; + route-filter 10.0.0.0/24 exact; + } + then accept; + } + } Let’s have a look at our BGP group to see what it looks like now: [email protected]# show protocols bgp group external type external; log-updown; export ANNOUNCE-OUR-RANGE; local-as 15; neighbor 198.51.100.10 { peer-as 65501; } neighbor 198.51.100.6 { peer-as 65500; } Great. Let’ Let’ss see if it is announcing to the transits: [email protected]> show route advertising-protocol bgp 198.51.100.6 inet.0: 20 destinations, 23 routes (20 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 192.0.2.0/24 Self 65501 I [email protected]> show route advertising-protocol bgp 198.51.100.10 inet.0: 20 destinations, 23 routes (20 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 203.0.113.0/2 4 Self 65500 I Hmmm, that’s not right. The 10.0.0.0/24 range is not being announced and what’s what’s more, it seems to be transiting our transits! BGP policy has an implicit accept, acce pt, so watch out! You don’t want to be one of those people that mistakenly announces the Internet from their AS! Let’s append a reject to the policy and see how that looks. Hopefully, after that, that , you can ﬁgure out why the 10.0.0.0/24 range isn’t being announced: [email protected]# edit policy-options policy-statement ANNOUNCE-OUR-RANGE [edit policy-options policy-statement ANNOUNCE-OUR-RANGE] [email protected]# set term REJECT then reject [edit policy-options policy-statement ANNOUNCE-OUR-RANGE] Chapter 7: Border Gateway Protcol (BGP) [email protected]# show | compare [edit policy-options policy-statement ANNOUNCE-OUR-RANGE] term announce-aggreg ate-route { ... } + term REJECT { + then reject; + } [edit policy-options policy-statement ANNOUNCE-OUR-RANGE] [email protected]# commit and-quit commit complete Exiting configuration mode [email protected]> show route advertising-protocol bgp 198.51.100.10 [email protected]> show route advertising-protocol bgp 198.51.100.6 Great, it’s no longer transiting the transits announcements but it still isn’t announcing the range. Can it see the route for the range in the routing table? Let’s check: [email protected]> show route 10.0.0.0/24 inet.0: 20 destinations, 23 routes (20 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/30 10.0.0.2/32 10.0.0.4/30 10.0.0.5/32 10.0.0.8/30 10.0.0.12/30 *[Direct/0] 00:56:39 > via ge-0/0/1.0 *[Local/0] 00:56:40 Local via ge-0/0/1.0 *[Direct/0] 00:56:39 > via ge-0/0/2.0 *[Local/0] 00:56:40 Local via ge-0/0/2.0 *[OSPF/10] 00:04:16, metric 2 > to 10.0.0.1 via ge-0/0/1.0 *[OSPF/10] 00:55:46, metric 2 > to 10.0.0.6 via ge-0/0/2.0 Ah ha. The aggregate route was not added in the routing options. Because the ANNOUNCE-OUR-RANGE policy was very speciﬁc, it needs to be from the aggregate protocol and match the ﬁlter 10.0.0.0/24 exactly. That’s why it hasn’t been announced. Also, it has inhibited more speciﬁcs from within 10.0.0.0/24. So let’s get this ﬁxed and check again: [email protected]# set routing-options aggregate route 10/24 [edit] [email protected]# commit commit complete [edit] [email protected]# exit Exiting configuration mode [email protected]> show route advertising-protocol bgp 198.51.100.6 inet.0: 21 destinations, 24 routes (21 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.0.0.0/24 Self I 109 110 Day One: Routing the Internet Protocol [email protected]> show route advertising-protocol bgp 198.51.100.10 inet.0: 21 destinations, 24 route s (21 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.0.0.0/24 Self I The network is now announcing the range! Add the same conﬁguration to R4 (not shown here) and you can see that the range is also being advertised correctly, as shown here with the output of AS65500: [email protected]> show bgp summary Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed inet.0 4 2 0 Peer AS InPkt OutPkt Dwn State|#Active/ Received//Accepted/Damped... 198.51.100.1 15 155 163 198.51.100.5 15 155 163 198.51.100.14 65501 156 156 History Damp State 0 OutQ 0 0 0 0 Flaps Last Up/ 1 1 0 Pending 0 40:26 0/1/1/0 41:04 1/1/1/0 1:09:24 1/2/2/0 0/0/0/0 0/0/0/0 0/0/0/0 Both the AS15 routers are announcing the 10.0.0.0/24 range, with only one route being active due to the BGP best path selection. You can also see AS65501 announcing the /24 and it’s locally originated /24. You can also see that R3 (198.51.100.5) has been selected as the best path for 10.0.0.0/24. What if you wanted to change this? Let’s have a look at some of the ways you could do it. First if you look at the BGP best path selection process you can see that there are some things within our control (AS-PATH length and MED ) and some things you cannot control (ISP’s local preference of our route). So, let’s have a look at MED ﬁrst. At the moment R3 (198.51.100.5) is the active path for 10.0.0.0/24. What happens if you use MED to make R4 become the active path: [email protected]# show | compare [edit policy-options policy-statement ANNOUNCE-OUR-RANGE term announce-aggregate-route then] + metric 10; [edit] [email protected]# commit commit complete You may be wondering why we went on to R3 rather than R4 to make our MED change? This is because if a MED is not explicitly set, the value is the equivalent to zero, and the lower the MED the more preferred the route. Let’s see if that has managed to change which router is now advertising the best path: Chapter 7: Border Gateway Protcol (BGP) [email protected]> show bgp summary Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 4 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/ Dwn State|#Active/ Received/Accepted/Damped... 198.51.100.1 15 727 726 0 10 27:10 1/1/1/0 0/0/0/0 198.51.100.5 15 2183 2204 0 2 1:59:26 0/1/1/0 0/0/0/0 198.51.100.14 65501 1395 1383 0 5 1:58:31 1/2/2/0 0/0/0/0 Excellent. R4 is now the active path for 10.0.0.0/24. Let’s have a look at the route itself to see if the MED value has been sent by R3: [email protected]> show route 10.0.0.0/24 inet.0: 12 destinations, 14 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/24 *[BGP/170] 00:26:56, localpref 100 AS path: 15 I, validation-st ate: unverified > to 198.51.100.1 via ge-0/0/1.0 [BGP/170] 00:01:10, MED 10, localpref 100 AS path: 15 I, validation-state: unverified > to 198.51.100.5 via ge-0/0/3.0 [BGP/170] 00:27:07, localpref 100 AS path: 65501 15 I, validation-sta te: unverified > to 198.51.100.14 via ge-0/0/2.0 Here you can see that R4 is the active route (denoted by the *). You can now also see that the second path, in boldface, has a MED of 10 set, which has been taken into account in the path selection, and you can see that AS65501 is sending the advertised route to AS65500 but this isn’t selected due to AS Path length (AS65501 then AS15). So let’s think about how you can affect the way that AS65500 sees and selects the route from R4, but then also propagates this to our other external ASs. Hopefully, you have ﬁgured out that if you can manipulate the AS Path length then you can affect the routing decision of not only your directly connected neighbor but also peers connected upstream, since AS Path shows the number of ASs the path traverses. Let’s see if it can be artiﬁcially inﬂated and have both AS6500 and AS65501 have the best path as R4, with AS65501 choosing to go via AS65500: [email protected]# show | compare [edit policy-options policy-statement ANNOUNCE-OUR-RANGE term announce-aggregate-route then] + as-path-prepen d “15 15 15”; [edit] [email protected]# commit commit complete 111 112 Day One: Routing the Internet Protocol Let’s see how this change has affected the path selection: [email protected]> show Groups: 1 Peers: 3 Table Tot inet.0 3 Peer AS Dwn State|#Active/ 198.51.100.1 15 198.51.100.5 15 198.51.100.1465 501 bgp summary Down peers: 0 Paths Act Paths Suppressed 2 0 0 InPkt OutPkt OutQ Received/Accepted/Damped... 762 761 0 2216 2236 0 1431 1417 0 History Damp State 0 Flaps 11 2 5 Pending 0 Last Up/ 10:30 1/1/1/0 2:14:17 0/1/1/0 2:13:22 1/1/1/0 0/0/0/0 0/0/0/0 0/0/0/0 So R4 is still the preferred route but also note that AS65501 is no longer sending two routes but only one. This is due to AS65501 seeing that the best path to 10.0.0.0/24 is via AS65500, so no point in advertising the route back to it! Let’s have a look at AS65501 to see how the path manipulation has worked: [email protected]> show bgp summary Groups: 1 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 3 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/ Dwn State|#Active/ Received/Accepted/Damped... 198.51.100.9 15 2206 2296 0 9 15:59 0/1/1/0 0/0/0/0 198.51.100.13 65500 310 321 0 5 2:18:0 0 2/2/2/0 0/0/0/0 And here AS14 is sending one route but it is not active and AS65500 is sending two routes, which are 10.0.0.0/24 from R4 and AS65500’s locally originated route, but let’s have a more in-depth look: [email protected]> show route 10/24 inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.0/24 *[BGP/170] 00:17:33, localpref 100 AS path: 65500 15 I, validation-st ate: unverified > to 198.51.100.13 via ge-0/0/2.0 [BGP/170] 00:07:38, MED 10, localpref 100 AS path: 15 15 15 15 I, validation-state: unverified > to 198.51.100.9 via ge-0/0/1.0 So you can see that 10.0.0.0/24 is active via AS65500 and you can see that the route from R3 has four times AS15s in its advertised path. Hang on, we only set three times AS15 in our export policy, so why are there four? This is due to using the as-path-prepend which takes what you have set in the policy and prepends it to the announcement which already includes what AS it is coming from. So, that’s how you can affect trafﬁc coming into your AS (ingress). Let’s now see how you can manipulate your trafﬁc heading out of your AS (egress). Chapter 7: Border Gateway Protcol (BGP) AS65500 and AS65501 are now sending a default route, as well as their locally originated route, so one can reach the rest of the Internet. Why isn’t trafﬁc sent destined to the Internet via AS65501? Let’s have a look at 0.0.0.0/0 from the perspective of R3 and R4: [email protected]> show route 0/0 inet.0: 21 destinations, 26 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[BGP/170] 00:05:05, localpref 100 AS path: 65501 I, validation-stat e: unverified > to 198.51.100.10 via ge-0/0/3.0 [BGP/170] 00:02:31, localpref 100 AS path: 65500 I, validation-stat e: unverified > to 198.51.100.6 via ge-0/0/4.0 [BGP/170] 00:02:31, localpref 100, from 92.1.0.1 AS path: 65500 I, validation-stat e: unverified > to 10.0.0.6 via ge-0/0/2.0 Here, R3 is seeing a default route from AS65500, AS65501, and also via R4 (AS65500) using iBGP. Let’s have a look at R4 now: [email protected]> show route 0/0 inet.0: 20 destinations, 23 routes (20 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[BGP/170] 00:05:28, localpref 100 AS path: 65500 I, validation-stat e: unverified > to 198.51.100.2 via ge-0/0/3.0 [BGP/170] 00:08:01, localpref 100, from 93.1.0.1 AS path: 65501 I, validation-stat e: unverified > to 10.0.0.5 via ge-0/0/2.0 And R4 is seeing the default route from AS65500 and R3 (AS65501) via iBGP, and as you already know from the BGP best path selection process, eBGP is preferred over iBGP in any tie-breaker. You might also notice that the paths have a local preference of 100 associated with them, even though they have set a local preference. This is due to the default local preference for BGP learned routes being set at 100. With local preference, the higher the value the more preferred the route is, so let’s get back onto R3 and write an import policy to set the local preference to 200: [edit protocols bgp group external neighbor 198.51.100.10] + import SET-LOCALPREF-2 00; [edit policy-options] + policy-stateme nt SET-LOCALPREF- 200 { + then { + local-preferen ce 200; + accept; + } + } [edit] [email protected]# commit 113 114 Day One: Routing the Internet Protocol So after setting the local preference for routes learned via neighbor 198.51.100.10 (AS65501) to have a local preference of 200, let’s see how that has affected the routing table: [email protected]> show bgp summary Groups: 2 Peers: 5 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State inet.0 6 3 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/ Dwn State|#Active/ Received/Accepted/Damped... 90.1.0.1 15 306 321 0 8 1:54:17 91.1.0.1 15 749 749 0 1 11:46:41 92.1.0.1 15 182 178 0 4 1:16:33 198.51.100.6 65500 385 384 0 2 2:51:51 198.51.100.10 65501 115 111 0 9 48:54 Pending 0 0/0/0/0 Active 0/0/0/0 0/3/3/0 3/3/3/0 0/0/0/0 0/0/0/0 0/0/0/0 0/0/0/0 Oops. It looks like the local preference for all routes learned from AS65501 was set, which includes AS65500’s locally originated route, which was not desired: [email protected]> show route protocol bgp inet.0: 21 destinations, 24 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 192.0.2.0/24 203.0.113.0/24 *[BGP/170] 00:20:07, localpref 200 AS path: 65501 I, validation-sta te: unverified > to 198.51.100.10 via ge-0/0/3.0 [BGP/170] 00:17:33, localpref 100 AS path: 65500 I, validation-sta te: unverified > to 198.51.100.6 via ge-0/0/4.0 *[BGP/170] 00:51:47, localpref 200 AS path: 65501 I, validation-sta te: unverified > to 198.51.100.10 via ge-0/0/3.0 [BGP/170] 02:53:48, localpref 100 AS path: 65500 65501 I, validation-st ate: unverified > to 198.51.100.6 via ge-0/0/4.0 *[BGP/170] 00:51:47, localpref 200 AS path: 65501 65500 I, validation-st ate: unverified > to 198.51.100.10 via ge-0/0/3.0 [BGP/170] 02:54:44, localpref 100 AS path: 65500 I, validation-sta te: unverified > to 198.51.100.6 via ge-0/0/4.0 Let’s use the power of the Junos OS routing policy to ﬁx this and only set the local preference for 0/0 learned from AS65501: [email protected]# show | compare [edit policy-options policy-statement SET-LOCALPREF-200] + from { + route-filter 0.0.0.0/0 exact; + } [edit] [email protected]# commit With the addition of the patch, the policy is now very speciﬁc. It looks like this: Chapter 7: Bord Border er Gateway Protcol (BGP) [email protected]# show policy-options policy-statement SET-LOCALPREF-200 from { route-filter 0.0.0.0/0 exact; } then { local-preferen ce 200; accept; } This policy now says that if the route is exactly 0.0.0.0/0 0.0.0.0/0 then it will set the local preference to 200. As BGP policy has an implicit accept, any routes that do not match 0.0.0.0/0 will still be accepted but with the default local pref of 100. Let’s see how this looks now: [email protected]> show route protocol bgp inet.0: 21 destinations, 25 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 192.0.2.0/24 203.0.113.0/2 4 *[BGP/170] 00:30:04, localpref 200 AS path: 65501 I, validation-stat e: unverified > to 198.51.100.10 via ge-0/0/3.0 [BGP/170] 00:27:30, localpref 100 AS path: 65500 I, validation-stat e: unverified > to 198.51.100.6 via ge-0/0/4.0 *[BGP/170] 01:01:44, localpref 100 AS path: 65501 I, validation-stat e: unverified > to 198.51.100.10 via ge-0/0/3.0 [BGP/170] 03:03:45, localpref 100 AS path: 65500 65501 I, validation-sta te: unverified > to 198.51.100.6 via ge-0/0/4.0 *[BGP/170] 03:04:41, localpref 100 AS path: 65500 I, validation-stat e: unverified > to 198.51.100.6 via ge-0/0/4.0 [BGP/170] 00:08:14, localpref 100, from 92.1.0.1 AS path: 65500 I, validation-stat e: unverified > to 10.0.0.6 via ge-0/0/2.0 [BGP/170] 01:01:44, localpref 100 AS path: 65501 65500 I, validation-sta te: unverified > to 198.51.100.10 via ge-0/0/3.0 Fantastic. The network is preferring 0.0.0.0/0 from AS65501 and all other routes are at their default. R4 also shows that it is preferring the path for f or 0.0.0.0/0 from AS65501, going via R3 who has advertised it via iBGP: [email protected]> show route protocol bgp inet.0: 20 destinations, 23 routes (20 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[BGP/170] 00:18:12, localpref 200, from 93.1.0.1 AS path: 65501 I, validation-stat e: unverified > to 10.0.0.5 via ge-0/0/2.0 [BGP/170] 00:30:51, localpref 100 AS path: 65500 I, validation-stat e: unverified > to 198.51.100.2 via ge-0/0/3.0 115 116 Day One: Routing the Internet Protocol So, trafﬁc has been affected. Note how it exits AS15 using the local local preference and is manipulated manipulated into how it enters the AS. Looking at the small amount of conﬁguration taken to achieve this, you can see how powerful the Junos OS route policy can be, especially when tied into BGP BGP.. Summary You have made it to the end of the BGP chapter cha pter and the rather rat her in-depth tutorial! No matter how much BGP is explained, explanations explanations only seem to scratch the surface of this powerful protocol. In this tutorial you have learned the differences diffe rences between betwee n iBGP and eBGP, eBGP, best path computation, and how you can manipulate how the outside world views your preﬁxes. Through the use of some simple routing policy you have also been able to control how trafﬁc exits the AS. The Junos OS with its very granular routing policy allows the user to leverage the true power and scale of BGP with what can be considered some very simple simpl e CLI commands. It’s I t’s no surprise that due to BGP’s maturity as a protocol and it’ it’ss scalability that it has also been used for the likes of VPLS, L2VPN, and EVPN, which allows it to carry MAC address information within its BGP updates. Some great information on BGP can be found at the following links on Wikipedia and at the Juniper’s Juniper ’s TechLibrar TechLibrary: y: https://en.wikipedia.org/w https://en.wik ipedia.org/wiki/Border_Ga iki/Border_Gateway_Protocol teway_Protocol http://www.juniper.net/techpubs/en_US/junos15.1/information-products/pathway-pages/conﬁg-gui ucts/pathway-p ages/conﬁg-guide-routing/con de-routing/conﬁg-guide-routin ﬁg-guide-routing-bgp. g-bgp. html Also recommended are the following books: http://www.juniper.net/us/en/training/jnbooks/oreilly-juniper-library/ junos-enterprise-routing/ http://www.ciscopress.com/store/routing-tcp-ip-vo http://www.ciscopress.com/sto re/routing-tcp-ip-volume-ii-ccie-profeslume-ii-ccie-professional-development-9781578700899 Chapter 8 Route Summarizati Summarization on If, for a moment, we were to compare routers to PCs in terms of memory usage, PCs have an advantage in that more memory can usually be quite easily purchased and installed. Routers, on the other ot her hand, do not have virtual virtu al memory. Memory can be expanded, but it’s usually at a premium and even eve n then, on a live network, the administrator needs to ﬁnd downtime to install it. Memory management on a router is very critical and potential issues should be identiﬁed and corrected before they become serious. The purpose of routers is to route data between subnets. The router needs to know which subnets to have reachability to because if the router receives a packet with a destination the router is not aware of, the router will drop the packet. And every route the router is aware of needs to be stored in the routing table, so the more routes that are in the t he routing table the more memory is consumed. To To put this into perspective for a moment, if the entire BGP table from the Internet I nternet was loaded l oaded into a router, the BGP database would consume over 1.7GB 1. 7GB of memory. If a router on a corporate LAN has 1GB RAM, the router simply would not have enough memory. 118 Day One: Routing the Internet Protocol In the case of Internet routes being redistributed into a corporate network, under normal circumstances, the default route of 0.0.0.0/0 is advertised into the LAN so that routers do not need to know every subnet that is available on the Internet, a router just needs to know that if a particular subnet is not in its routing table, then it should send the packet to the default route. Corporate networks, on the other hand, are different, and often have hundreds or thousands of subnets where each router needs to know how to reach each individual subnet. This means the memory on each router is now being ﬁlled with those routes. Summarization is a means of compressing the routing table and by using summarization, multiple networks can be joined so they appear in the routing table as a single subnet instead of as multiple entries. Figure 8.1 shows an example of multiple subnets being summarized. In this case there are six routers. Routers A through E are each attached to a network that begins 10.10.x.x. The link between routers E and F uses subnet 172.23.7.0/24. Figure 8.1 Summarizing Four Subnets into a Single Route In this situation, router F could have a default route to router E, however that would mean that all trafﬁc is sent to router E, whether router E has the route in its routing table or not. If summarization were to be used, then instead of creating a default route, the 10.10.x.x networks could be made into the single network 10.10.0.0/21. With summarization, the administrator would use simple bit matching to determine which common bits are in use with each subnet. The bit matching should be as long as possible, which in Figure 9.1 is 21 bits. When router F receives a packet destined for one of the subnets that Chapter 8: Route Summarization 10.10.0.0/21 covers, it will immediately forward it to router E. Should the subnet not be covered by that route, for example 10.10.100.0/24, then router F will discard the packet. Although Figure 8.1 is a small LAN and therefore would not beneﬁt from summarization, a multi-national corporation with ofﬁces in the U.S., Europe, and the Middle East might. In this situation, the ofﬁces in the U.S. could use subnets beginning with 10.100.x.x, whereas Europe could use 10.150.x.x, and the Middle East could use networks beginning 10.200.x.x. The routers that connect, say, the U.S. to the WAN could then summarize the routes to 10.100.0.0/x. This way the routers in Europe and the Middle East will receive a single route instead of potentially hundreds of routes. The amount of subnets could increase substantially if each subnet was a /25 or less. Conﬁguring Route Summarization In the following scenario, the ASBRs, which are routers vMX2 and vMX4, will be conﬁgured to take three subnets that are advertised by IS-IS and summarize them into a single subnet. Before this can be done, it is important to realize that if a subnet is directly connected to a router – for example subnets 10.10.1.0/24 and 10.10.2.0/24 are directly connected to router vMX2 – then these subnets will not be summarized and will still be advertised as separate subnets by OSPF. In order to work around this limitation, three new IP addresses have been added to the loopback interface of router vMX6. These have therefore created three new subnets and as IS-IS has already been conﬁgured to advertise subnets connected to interface lo0.0, so these should automatically start appearing in the routing table of all routers in the LAN: [email protected]> show interfaces terse lo0.0 Interface Admin Link Proto lo0.0 up up inet iso Local Remote 10.20.1.1/24 10.20.2.1/24 10.20.3.1/24 192.168.1.4 --> 0/0 49.0003.0001.0 001.0004 Figure 8.2 gives a graphical representation of what this scenario achieves. The three subnets from router vMX6 are summarized to a single route, 10.20.0.0/22. At the same time, the three subnets from router vMX6 are then ﬁltered to prevent these separate subnets from being advertised to routers vMX0 and vMX1 in the OSPF domain. 119 120 Day One: Routing the Internet Protocol Figure 8.2 Summarizing Routes from Router vMX6 For the purposes of this scenario, router vMX1 will be used to test whether the summarization has worked successfully and to test reachability, and if the show route 10.20.0.0/16 command were to be run on this router, the subnets should be listed twice, once as a /24 and once as a /32, as these subnets were added to the loopback interface and as such OSPF treats these as host routes. Let’s check: [email protected]> show route 10.20.0.0/16 inet.0: 29 destinations, 32 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.20.1.0/24 10.20.1.1/32 10.20.2.0/24 10.20.2.1/32 10.20.3.0/24 *[OSPF/150] 00:00:31, metric 2, > to 10.5.0.2 via ge-0/0/2.0 *[OSPF/150] 00:00:31, metric 2, > to 10.5.0.2 via ge-0/0/2.0 *[OSPF/150] 00:00:31, metric 2, > to 10.5.0.2 via ge-0/0/2.0 *[OSPF/150] 00:00:31, metric 2, > to 10.5.0.2 via ge-0/0/2.0 *[OSPF/150] 00:00:31, metric 2, tag 0 tag 0 tag 0 tag 0 tag 0 Chapter 8: Route Summarization 10.20.3.1/32 > to 10.5.0.2 via ge-0/0/2.0 *[OSPF/150] 00:00:31, metric 2, tag 0 > to 10.5.0.2 via ge-0/0/2.0 Router vMX1 should also be able to ping one of the IP addresses too, in this case 10.20.1.1: [email protected]> ping 10.20.1.1 PING 10.20.1.1 (10.20.1.1): 56 data bytes 64 bytes from 10.20.1.1: icmp_seq=0 ttl=63 time=4.105 ms 64 bytes from 10.20.1.1: icmp_seq=1 ttl=63 time=3.881 ms 64 bytes from 10.20.1.1: icmp_seq=2 ttl=63 time=5.666 ms 64 bytes from 10.20.1.1: icmp_seq=3 ttl=63 time=4.346 ms ^C --- 10.20.1.1 ping statistics --4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.881/4.500/5.666/0.693 ms In order to perform summarization, two things need to be added to the conﬁguration. The ﬁrst is what is known as an aggregate route. This tells the Junos OS what the routes will be summarized to. In this case, the IP addresses added on router vMX6 can be summarized to a single route – 10.20.0.0/22: set routing-options aggregate route 10.20.0.0/22 While it is possible to summarize these routes to 10.20.0.0/16, it’s considered best practice to use the longest match possible so that the router isn’t processing unnecessary trafﬁc. For example, if someone attempted to send a packet to 10.20.5.1, by using a /22 preﬁx, the packet would be dropped by the router, whereas with a /16 preﬁx, the router would need to process the packet and forward it to the ASBR. This would affect each router in the path of the packet all for t he ASBR to discard the packet anyway. Once the aggregate router has been created, the routing protocol needs to be told to export this route to neighbors. This is done by using the same policy statement that was created when performing redistribution. As with redistribution, the policy statement works from the top down and stops once there is a match, therefore the term to tell OSPF to redistribute the aggregate route should ideally be added ﬁrst. In this scenario, the changes will ﬁrst be made on router vMX4. The policy statement in use on vMX4 currently is: [edit] [email protected]# show policy-options policy-statement RIP-TO-OSPF term 1 { from { protocol rip; prefix-list ONESEVENTWOTWEN TYTHREEONE; } then reject; } 121 122 Day One: Routing the Internet Protocol term 2 { from protocol rip; } then accept; As the policy statement is using numbered terms, it would be ideal to change Term 2 to Term 3, and the term currently numbered 1 to Term 2. The new term will then be added as Term 1, just to keep things tidy: rename policy-options policy-statement RIP-TO-OSPF term 2 to term 3 rename policy-options policy-statement RIP-TO-OSPF term 1 to term 2 After a quick check to see if the terms have been renumbered correctly, Term 1 can then be recreated with a new rule: [edit] [email protected]# show policy-options policy-statement RIP-TO-OSPF term 2 { from { protocol rip; prefix-list ONESEVENTWOTWE NTYTHREEONE; } then reject; } term 3 { from protocol rip; } then accept; The new term is really just redistributing from the protocol aggregate to OSPF, therefore the term needs to specify to match routes from protocol aggregate and to match the subnet speciﬁed when added the routing option, which in this case is 10.20.0.0/22. Finally, an accept has been added at the end of this term, although in theory, the accept at the end of the policy statement should already accept this term: set policy-options policy-statement RIP-TO-OSPF term 1 from protocol aggregate set policy-options policy-statement RIP-TO-OSPF term 1 from routefilter 10.20.0.0/22 exact set policy-options policy-statement RIP-TO-OSPF term 1 then accept Once this is added, if the policy statement is viewed, it’s interesting to see that the new term has been added after Term 3. When a policy statement is numbered, the Junos OS only sees this as a label as opposed to a numerical value, so in reality this term could have been called summarize, but in the case of this scenario, the numbering convention was retained: [email protected]# show policy-options policy-statement RIP-TO-OSPF term 2 { from { protocol rip; prefix-list ONESEVENTWOTWE NTYTHREEONE; } then reject; } Chapter 8: Route Summarization term 3 { from protocol rip; } term 1 { from { protocol aggregate; route-filter 10.20.0.0/22 exact; } then accept; } then accept; In order to move Term 1 up the list, the insert command is used. In order to move Term 1 to before Term 2, the following command is applied: insert policy-options policy-statement RIP-TO-OSPF term 1 before term 2 The policy statement should now appear in the correct order: [edit] [email protected]# show policy-options policy-statement RIP-TO-OSPF term 1 { from { protocol aggregate; route-filter 10.20.0.0/22 exact; } then accept; } term 2 { from { protocol rip; prefix-list ONESEVENTWOTW ENTYTHREEONE; } then reject; } term 3 { from protocol rip; } then accept; Router vMX4 has now been conﬁgured, but as there are two ASBRs, the summarization won’t be effective in decreasing the size of the routing table, therefore the same conﬁguration should be applied to vMX2. The command to add the aggregate route should be the same on both ASBRs: set routing-options aggregate route 10.20.0.0/22 The policy statement on router vMX2 is called IS-IS-TO-OSPF as opposed to RIP-TO-OSPF on vMX4. The ﬁrst step is to rename the terms to match those changes made on vMX4. Although in theory the terms could be given different names, it is better to keep naming conventions common across your network, as it helps when it comes to supporting it later on: 123 124 Day One: Routing the Internet Protocol rename policy-options policy-statement ISIS-TO-OSPF term 2 to term 3 rename policy-options policy-statement ISIS-TO-OSPF term 1 to term 2 Once the terms have been renamed, the new term is created: set policy-options policy-statement ISIS-TO-OSPF term 1 from protocol aggregate set policy-options policy-statement ISIS-TO-OSPF term 1 from routefilter 10.20.0.0/22 exact set policy-options policy-statement ISIS-TO-OSPF term 1 then accept Finally, the new term is inserted before what is now term 2: insert policy-options policy-statement ISIS-TO-OSPF insert term 1 before term 2 Once the conﬁguration has been committed, the routing table on vMX1 can be checked to conﬁrm the new aggregate route has been added (bold in the output). What is also unexpected is that the routes, even though they have been summarized, are still appearing in the routing table. Instead of decreasing the size of the routing table, it has instead increased it: [email protected]> show route 10.20.0.0/16 inet.0: 31 destinations, 34 routes (31 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.20.0.0/22 10.20.1.0/24 10.20.1.1/32 10.20.2.0/24 10.20.2.1/32 10.20.3.0/24 10.20.3.1/32 *[OSPF/150] 00:04:38, metric 0, tag 0 > to 10.3.0.1 via ge-0/0/1.0 *[OSPF/150] 00:08:51, metric 2, > to 10.5.0.2 via ge-0/0/2.0 *[OSPF/150] 00:08:51, metric 2, > to 10.5.0.2 via ge-0/0/2.0 *[OSPF/150] 00:08:51, metric 2, > to 10.5.0.2 via ge-0/0/2.0 *[OSPF/150] 00:08:51, metric 2, > to 10.5.0.2 via ge-0/0/2.0 *[OSPF/150] 00:08:51, metric 2, > to 10.5.0.2 via ge-0/0/2.0 *[OSPF/150] 00:08:51, metric 2, > to 10.5.0.2 via ge-0/0/2.0 tag 0 tag 0 tag 0 tag 0 tag 0 tag 0 To prevent these subnets from being advertised, a ﬁlter should be applied to the ASBRs. In this case, the ﬁlter is ﬁrst applied to router vMX2. The issue is that there are now three terms that need renaming, therefore, instead of renaming them, the term will simply be called 0.5: set policy-options policy-statement ISIS-TO-OSPF term 0.5 from protocol isis As you may recall, in Chapter 6 the term to ﬁlter the router included a prefix-list. The conﬁguration in this scenario uses a different method of specifying which routes to suppress – a route-filter. By using a route ﬁlter, there is no need to create a preﬁx list before creating the policy statement, in addition the exact, orlonger, and longer keywords can be used to determine whether to match just that subnet, or subnets that begin the same, or ones that don’t begin the same but match the rest of the subnet. Chapter 8: Route Summarization NOTE The best resource to learn more about route ﬁlters is from Juniper’s Tech Library. You can read more about route ﬁlters at the following URL: http://www.juniper.net/techpubs/en_US/junos15.1/topics/ usage-guidelines/policy-conﬁguring-route-lists-for-use-in-routingpolicy-match-conditions.html. In this scenario, you don’t want to suppress 10.20.0.0/22 but you do want to suppress routes that are longer than this: 10.20.1.0/24, 10.20.2.0/24, and 10.20.3.0/24, therefore the route-filter command is followed with the keyword longer: set policy-options policy-statement ISIS-TO-OSPF term 0.5 from routefilter 10.20.0.0/22 longer set policy-options policy-statement ISIS-TO-OSPF term 0.5 then reject Here, Term 0.5 is inserted before Term 1: insert policy-options policy-statement ISIS-TO-OSPF insert term 0.5 before term 1 Once done, the same rules can be applied to router vMX4 and the term inserted before term 1: set policy-options policy-statement RIP-TO-OSPF term 0.5 from protocol rip set policy-options policy-statement RIP-TO-OSPF term 0.5 from routefilter 10.20.0.0/22 longer set policy-options policy-statement RIP-TO-OSPF term 0.5 then reject insert policy-options policy-statement RIP-TO-OSPF term 0.5 before term 1 After committing these changes, router vMX1’s routing table should be checked once more to ensure that the route 10.20.0.0/22 is present, but the individual /24 routes are not: [email protected]> show route 10.20.0.0/16 inet.0: 25 destinations, 28 routes (25 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.20.0.0/22 *[OSPF/150] 00:05:57, metric 0, tag 0 > to 10.3.0.1 via ge-0/0/1.0 Finally, a ping to one of the subnets should prove that routes from vMX1 to vMX6 have not been suppressed inadvertently: [email protected]> ping 10.20.1.1 PING 10.20.1.1 (10.20.1.1): 56 data bytes 64 bytes from 10.20.1.1: icmp_seq=0 ttl=63 time=5.421 ms 64 bytes from 10.20.1.1: icmp_seq=1 ttl=63 time=6.610 ms 64 bytes from 10.20.1.1: icmp_seq=2 ttl=63 time=4.341 ms 64 bytes from 10.20.1.1: icmp_seq=3 ttl=63 time=6.751 ms ^C --- 10.20.1.1 ping statistics --4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.341/5.781/6.751/0.979 ms 125

Rating
Date

March 2019
Size

3.6MB
Views

7,079
Categories

Router (Computing) Routing Ip Address Internet Protocols Computer Network

Preview only show first 6 pages with water mark for full document please download

Transcript

Junos® OS Fundamentals Series

DAY ONE: ROUTING THE INTERNET
PROTOCOL

This networking fundamentals book
describes how a Junos device is able
to forward a packet between networks
using either static routes or any of five
popular routing protocols: RIP, OSPF,
IS-IS, iBGP, and eBGP. Learn how to
route the Internet Protocol in a day.

By Martin Brown & Nick Ryce

DAY ONE: ROUTING THE INTERNET PROTOCOL

This book is intended for network engineers who have either just begun their career in
network engineering or have worked in an environment where only one routing protocol
was used, so they are unfamiliar with the other routing protocols in the Junos ® OS.
If you are familiar with how the Junos CLI works, you can follow along with how to configure not only static routing, but the popular routing protocols: RIP, OSPF, IS-IS, iBGP,
and eBGP. This book discusses each routing protocol’s unique traits and then shows
you how to implement them in the Junos OS for any Juniper Networks device.
The authors, both Juniper Ambassadors, draw from their many years of network administration to provide examples and configuration samples that you will likely enounter in
real-world networks.
“The network industry is undergoing a revolution whereby the boundaries between server
and network engineer are becoming blurred. Now, more than ever before, it is important
for all to have a good grounding in the fundamentals of routing. This Day One book on the
fundamentals of routing from Martin Brown and Nick Ryce, along with the entire Day One
library as a whole, fills that gap.”
Perry Young, Senior VP, Cyber Security Ops, undisclosed firm, JNCIP-SEC/SP/ENT

IT’S DAY ONE AND YOU HAVE A JOB TO DO, SO LEARN HOW TO:
Better understand the different interior gateway protocols
Know the differences between Distance Vector, Path Vector, and Link State protocols
Understand how Administrative Distance affects routing to a subnet
Be able to build a more scalable network topology
See how this information relates to a live network

Juniper Networks Books are singularly focused on network productivity and efficiency.
Peruse the complete library at www.juniper.net/books.
Published by Juniper Networks Books
ISBN 978-1941441220

9 781941 441220

52000

Junos® OS Fundamentals Series

Day One: Routing the Internet Protocol

By Martin Brown and Nick Ryce

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Chapter 1: Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chapter 2: Routing Protocol Preference and Type. . . . . . . . . . . . . . . . . . . . . . 21
Chapter 3: Route Information Protocol (RIP) . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Chapter 4: Open Shortest Path First (OSPF). . . . . . . . . . . . . . . . . . . . . . . . . . 45
Chapter 5: Intermediate System to Intermediate System (IS-IS). . . . . . . . 67
Chapter 6: Redistributing Route Information . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Chapter 7: Border Gateway Protcol (BGP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Chapter 8: Route Summarization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

as his words of “Nothing good will ever come of you playing on that computer” only inspired me to prove him wrong. I would also like to thank my fellow Juniper Ambassadors who are a continuous source of inspiration and my technical sounding board. Juniper Networks assumes no responsibility for any inaccuracies in this document. Nick is currently certified as JNCIE-ENT #232 Authors Acknowledgments: Martin Brown: I would once again like to thank my good friend. Published by Juniper Networks Books Authors: Martin Brown. November 2015 2 3 4 5 6 7 8 9 10 About the Authors: Martin Brown is a Network Security Engineer for a major telco based in the UK. and my children. Inc. for continuing to be a source of inspiration and support whilst writing this book. and for helping me sanity check some of my wording when I really needed it. F5. Nick Ryce is a Senior Network Architect for a major ISP based in Scotland.net/dayone. who have not only supported me while writing this book. Martin started his career in IT 20 years ago supporting Macintosh computers. their sense of camaraderie. Nick Ryce Technical Reviewers: Clay Haynes. and has since progressed to networking. and JunosE are trademarks of Juniper Networks. The Juniper Networks Logo. supporting most of the major manufacturers including Cisco.juniper. Junos. Juniper. in the United States and other countries. Juniper Networks. Inc. I would especially like to thank Martin for allowing me to contribute to this book and for his continuing guidance and enthusiasm when I realized I may have bitten off more than I could chew. and Juniper. HP. Perry Young. iv © 2015 by Juniper Networks. or registered service marks are the property of their respective owners. Finally. and a Juniper Ambassador. or otherwise revise this publication without notice. This book is available in a variety of formats at: http://www. transfer. and a Juniper Ambassador with knowledge that covers a broad range of network devices. Joy Horton. which sometimes means evenings sitting on a Datacentre floor working away instead of spending time with them. the Junos logo. but have also supported me in my chosen career. Jennifer. and ScreenOS are registered trademarks of Juniper Networks. and of course. All rights reserved. I really would like to thank my dad. became an MCSE in 1999. Anna and Toby. NetScreen. registered trademarks. . Nortel. Steel-Belted Radius. ISBN: 978-1-936779-21-3 (ebook) Version History: v1. modify. Juniper Networks reserves the right to change. Checkpoint. Nick has over a decade of experience working within the Service Provider industry and has worked with a variety of vendors including Cisco. service marks. Nick Ryce: I would like to thank my wife. I would also like to thank all of the Juniper Ambassadors for their words of encouragement. All other trademarks. Inc. Victor Gonzales Editor in Chief: Patrick Ames Copyeditor and Proofer: Nancy Koerbel Illustrator: Karen Joice J-Net Community Manager: Julie Wider ISBN: 978-1-936779-22-0 (print) Printed in the USA by Vervante Corporation.

Search for Juniper Networks Books. whose concepts and test bed examples are more similar to a weeklong seminar. iPad. The Day One library also includes a slightly larger and longer suite of This Week books.net/dayone. v Welcome to Day One This book is part of a growing library of Day One books. Day One books were conceived to help you get just the information that you need on day one. and practical examples that are easy to follow. produced and published by Juniper Networks Books. This book is also for network engineers who have had years of experience in supporting live networks but have only had exposure to maybe one or two routing protocols. Get the ebook edition for iPhones and iPads from the iTunes Store. vervante. step-by-step instructions. Audience This book is intended for network engineers who have just begun their career in network engineering and whilst they are aware of the various routing protocols. Kindle. Get the ebook edition for any device that runs the Kindle app (Android.com) for between $12-$28. they perhaps are unsure of the features each one has to offer. The series covers Junos OS and Juniper Networks networking essentials with straightforward explanations. Purchase the paper edition at either Vervante Corporation (www. in multiple formats: Download a free PDF edition at http://www. Search for Juniper Networks Books. depending on page length. You can obtain either series.juniper. or Mac) by opening your device’s Kindle app and going to the Kindle Store. PC. .

. Know the differences between Distance Vector. and change configurations. vi What You Need to Know Before Reading This Book Before reading this book. understand. Path Vector. or one workstation and two of any of the following devices: SRX Series firewall. Understand how Administrative Distance affects routing to a subnet. You have access to a lab with at least the following components: one workstation and a Junosphere account. J Series router. and Link State protocols. you should be familiar with the basic administrative functions of the Junos OS. By Reading This Book You Will Better understand the different interior gateway protocols. See how this information relates to a live network. Be able to build a more scalable network topology. This book makes a few assumptions about you. the reader: You have a basic but solid understanding of the Internet Protocol version 4. including the ability to work with operational commands and to read. IPv4.. EX Series switch.

1 gives a graphical representation of their LAN. . vii Preface Any company with a network needs a way of sending data from one subnet to another. Figure P. for example. Danny runs a small design company composed only of he and his wife working from their garage. It’s evident they are using a single subnet for their workstation and printer.1 Example Network Topology As you can see. Let’s consider an example. You can see the Internet to the left of Figure P1. Danny’s Network has two workstations and a printer connected to an ADSL modem that provides them with Internet access. and it is one great big network. Internet is short for Interconnected Networks and these workstations need to be able to communicate with some of the subnets on these networks. Figure P. so it’s tempting to think that they don’t need to send data from one subnet to another—say from the garage to the house. however. in fact. this holds true not just for the largest corporations but for the smallest start-ups as well.

and to allow it to do this. In the case of Danny’s network. the subject of the last chapter of this book. the authors wanted to make the scenarios as realistic as possible. which will be configured with default static routes at the beginning of the book. The last chapter in this book describes how the number of routes in a routing table can be reduced or summarized. The purpose of this is to demonstrate how to “summarize” networks or group them together to appear as one larger network. so we used Junosphere. Default Route: A single location where your subnet sends all traffic for processing into the Internet. routers have a special database known as a routing table. . So although Danny’s company is small.x. Summarize Networks: How to group networks into a single. In order to know how to reach specific subnets. iBGP. RIP. Most of the devices are vMX routers. the ADSL modem is in fact a router.x. and it will also detail the three types of routing protocols. but what about a large corporation with multiple branches spread across several countries or even continents? How does the Internet Service Provider know what to do with this packet? The purpose of this book is to describe in detail how a router is able to learn which subnets are accessible through which interfaces by using what is known as Routing Protocols.x. the routing table on the ADSL modem would consist of what is known as a default route. who would then determine what to do with that packet.2 that a large portion of the network uses IP addresses that start with 10. This table lists the subnets the router has been told about and will tell the router which IP address or “next hop” to use to connect to that subnet. however on the Internet Edge there are two vSRX firewalls. While writing this book. larger network. You may also notice in Figure P. In Danny’s scenario the router knows that all subnets are accessible via the ADSL interface. IS-IS.x. or a single location where the router simply sends any traffic it receives that is not destined for a printer or other workstation out the ASDL interface and to the ISP. Figure P.2 shows the topology of the network used throughout this book. it’s still required to send data to another subnet.x and another portion starts with 172. This Day One book will cover six routing protocols: static routes. which meant the example topology needed to be a reasonable size. and eBGP. OSPF. and then in later chapters will be configured to use BGP.x. viii Routing Table: A database in routers that keep the addresses of how to reach specific subnets.

and prepare to learn all about static routes. kick back. If a command is only available in a more recent release. It’s more about how an administrator tells the router how to get to each subnet.2 This Book’s Topology NOTE The version of Junos OS software running on the vMX routers is 14.1-20140130_ib_14_1_psd. however most of the commands used in this book will be version neutral. The first topic covered in this book isn’t a routing protocol.1I20131108. strictly speaking. applicable to any version of the Junos OS. it will be noted. So. it is still a common method in use in many networks today due to its simplicity. Enjoy the book! Martin Brown and Nick Ryce. Juniper Ambassadors . relax. ix Figure P. That said. as no information is shared between routers.0 and the version of Junos OS running on the vSRX firewalls is 12.

Use the Pathfinder tool on the documentation site to explore and find the right information for your needs.juniper. MORE? It’s highly recommended you go through the technical documentation in order to become fully acquainted with the routing fundamentals of the Junos OS. The Juniper Tech Library is at www. x Information Experience This Day One book is singularly focused on one aspect of networking technology that you might be able to do in one day.net/documentation. but it is not a substitute for Juniper documentation. .

1 Single Router LAN . Figure 1. if you examine Figure 1.2. a routing protocol.0. This default gateway should match the IP address of the router on your subnet.1. they do nonetheless still perform the same role as OSPF or RIP by telling a router how to reach a specific subnet. When a client is assigned an IP address. and in the case of a failure in another routing protocol. For example. In spite of their drawbacks. and Workstation B has the IP address of 10. they can still be useful in today’s modern networks as they are very simple to implement.0. either manually or automatically by DHCP. a good place to start would be understanding how a router makes a routing decision and how packets arrive on the router’s interface in the first place.2. the client is also given the IP address of what is known as the default gateway. they can be used to temporarily restore connectivity until service is restored.Chapter 1 Static Routes Although static routes are not.2. But before you can understand static routes in any depth.1. you will see a network consisting of a single router and two workstations. Workstation A has the IP address of 10. strictly speaking.

1. Figure 1. The eleven-step process by which this is achieved is as follows: 1. The router vMX0 in this diagram has two interfaces. Workstation A decides it needs to forward the packet to the default gateway. When data is sent on a local subnet.0.0. When Workstation A was assigned its IP address it was told that its default gateway is 10.1. when Workstation B was assigned its address. Figure 1. 12 Day One: Routing the Internet Protocol Interfaces: Physical and logical channels on the router that define how data is transmitted to and received from lower layers in the protocol stack.3 Example of a Simplified Frame . the MAC addresses of the devices are used as source and destination addresses.2 LAN Traffic Flow 2. and the interface on the same subnet as Workstation B has the IP address of 10. LAN Traffic Flow Let’s imagine that Workstation A needs to contact Workstation B.0. A packet becomes a frame when the source and destination MAC addresses are added to a packet that already contains source and destination IP addresses. Workstation A knows that Workstation B is on a different subnet so therefore will forward the packet to the default gateway who will then forward it on to Workstation B.1. Figure 1. and similarly. as opposed to using the IP address.1. The interface on the same subnet as Workstation A has the IP address of 10. it was told its default gateway is 10.1. By using the subnet mask.3 shows a simplified frame..2.2.0.1.

13 .1. looks at the packet inside and sees that the destination IP address is 10.11.22.bb. vMX0 therefore sends an ARP request.11. vMX0 receives the frame.bb. 4. Workstation A sends an ARP request on to the LAN asking who has been assigned the IP address 10.aa.wikipedia.aa. Workstation A puts the packet into a frame.bb.1. vMX0 responds stating that its MAC address is aa. ARP: https://en.aa. which is associated with MAC address bb.aa.aa. To find the MAC address of Router A. https://en.1.11. 6.22. As workstation B is on the local subnet.aa. 7. 9. Figure 1. vMX0 looks at its connected interfaces and determines on which interface Workstation B resides.aa.0.2.aa.4 Example of a Simplified Frame 5.11.2.0.0.2.bb.wikipedia.org/wiki/ MAC_address 8. Workstation B responds stating its MAC address is 22. which is associated with MAC address 11.aa.2. vMX0 will communicate with it using the MAC address.22 and makes a note that this came from IP address 10.1 and what their MAC address is.0.22. A media access control address (MAC address) is a unique identifier assigned to network interfaces for communications on the physical network segment.aa and makes a note that this came from IP address 10. sets the destination MAC address as aa.bb.11.org/ wiki/Address_Resolution_ Protocol Chapter 1: Static Routes 3.22.

22. vMX0 puts the packet into a frame and forwards it using the destination MAC address of 22.22.6 11. aa and bb.aa.22.bb. then the same process is followed.aa. That’s because each interface has its own separate MAC address. however there would be no need to send ARP requests as all devices know the relevant MAC addresses. In our scenario vMX0 knew how to get to Workstation B because it was on a subnet that was directly connected to vMX0. But what happens if a second router is added in the network path in-between . 14 Day One: Routing the Internet Protocol Figure 1.5 10. aa.22. You may notice that Router A has two MAC addresses.22.bb.bb.aa.bb. Figure 1. Should Workstation B need to respond to Workstation A.aa.bb.

Figure 1. you should see a response like this: [email protected]> ping 10.0 with an address of 10.1 is used.10.0.10.2.1.445 ms 64 bytes from 10.2 and the default gateway is 10.1 on subnet 10.843 ms 64 bytes from 10.0 with an address of 10.1. when you ping a device from Junos OS.1.2.0.2. you specify the destination address of the ping and Junos OS will automatically use the outgoing interface IP address as the source address.2.2.7 shows an example of this.2. workstation A sends the frame to vMX0.2.0.985 ms Junos OS also permits you to specify the source address of the ping instead of automatically using the outgoing interface. but Workstation C is on Subnet 10.10. Packet loss occurs when one or more packets of data travelling across a computer network fail to reach their destination: https://en.0.3: icmp_seq=4 ttl=64 time=2.3): 56 data bytes 64 bytes from 10.3: icmp_seq=2 ttl=64 time=2.1. Chapter 1: Static Routes workstations? Figure 1.766/4.574 ms ^C --- 10.0.2.2.10.3 (10.2 and the default gateway is 10. the process will begin as before.1.0.10.2.673/0.3 ping statistics --5 packets transmitted. 0% packet loss round-trip min/avg/max/stddev = 1.3 source 10.3 PING 10.0.673 ms 64 bytes from 10. if you ping 10. So. however vMX0 looks at its connected interfaces and cannot match the destination address to any of its connected subnets.0.7 Two Routers Between Workstations Should workstation A wish to communicate with workstation C.1.3: icmp_seq=1 ttl=64 time=2.295 ms 64 bytes from 10. vMX0 will therefore drop the packet. org/wiki/Packet_loss.2.0.843/2.3 from vMX0. 5 packets received. so if the command ping 10. you would see no response and cancelling the ping would show dropped packets as follows: 15 .10.0.0. where Workstation A is located on the same subnet as before.wikipedia.1.3: icmp_seq=3 ttl=64 time=4.0.1.3: icmp_seq=0 ttl=64 time=1. You can test this in Junos OS simply by using the ping command. Normally.

2. id 7184.1. l ength 64 02:03:09. seq 3.3: ICMP echo request. To resolve the issue vMX0 needs learn that to reach the subnet that Workstation C resides on. don’t use it in a live environment without applying a filter. Data packets pass through bridges.0. id 7184. In computer networking. 16 Day One: Routing the Internet Protocol [email protected]> ping 10. then it can place an unnecessary CPU overhead on the router and cause potential issues where live traffic could be disrupted.3 (10.0. 0 packets received.0. it should forward the packet to vMX2. seq 1.0. however.1.1.3 source 10.0. l ength 64 02:03:07. 100% packet loss But built into Junos OS is a great utility that allows you to view traffic as it enters or leaves an interface by entering the monitor traffic interface <interface name> command.0.0.2.0. seq 5. Use <no-resolve> to avoid reverse lookups on IP addresses. l ength 64 02:03:08.273992 In IP 10. l ength 64 02:03:11.280064 In IP 10.3 ping statistics --7 packets transmitted.org/wiki/Hop_(networking) .0.1 > 10.0. By using a filter you can ensure that only the desired traffic is captured.3: ICMP echo request.2. id 7184.1.0. id 7184.1.0. capture size 96 bytes Reverse lookup for 10. seq 4.3: ICMP echo request.0.1.0 verbose output suppressed.1 > 10.2. Address resolution timeout is 4s. Normally this command would actually see the traffic reaching vMX2. a hop is one portion of the path between source and destination.3: ICMP echo request. tra 02:03:06.1 > 10.2. seq 2.220650 In IP 10.0. Each time packets are passed to the next device.228902 In IP 10. Use <no-resolve> to avoid any reverse lookup delay. id 7184.248993 In IP 10. or what is more commonly known as the next hop. Other reverse lookup failures will not be reported.2.2.1 > 10.wikipedia. use <detail> or <extensive> for full protocol decode Address resolution is ON. l ength 64 02:03:10.0.1.3: ICMP echo request. l ength 64 ^C 6 packets received by filter 0 packets dropped by kernel CAUTION Although the monitor traffic interface command can be very useful. but in this case. https://en.0.0.240288 In IP 10. so it would silently drop the packet. id 7184. vMX2 would look at the source and see that it doesn’t know how to reach that subnet.0. a hop occurs.3 failed (check DNS reachability).3: ICMP echo request.1 > 10. routers and gateways on the way.0.1 > 10.1 PING 10.2. if a filter is not used. Listening on ge-0/0/0. Let’s look: [email protected]> monitor traffic interface ge-0/0/0.2.2.2. seq 0.3): 56 data bytes ^C --- 10.

2 is used as an example. this static route disappears from the routing table. and that makes them popular. Chapter 1: Static Routes The Next Hop Once vMX0 has been told how to reach Workstation C’s subnet. 17 . meaning that if you added a route that was incorrect. it does not prevent other routers from sending it to the packet in the first place. It’s all very well for vMX0 knowing how to get to that subnet. This is known as advertising routes. they do have a few draw backs. as was shown during the ping 10. If an interface connected to the next hop associated with a static route does go down. the Router vMX0 would not know this and would continue to send traffic. using up bandwidth and causing the router at the next hop to perform unnecessary processing. however. but what about the topology in Figure P.2 where there are seven routers.2. static routes are not a routing protocol per se. but they do a similar job – they tell a router the next hop to use to reach a particular subnet. If Figure 1.10. The second issue with using static routes is that the router would blindly forward traffic. NOTE The other routing protocols in this book are dynamic and as such would have told vMX0 that this subnet was no longer reachable.3 source 10.1. In fact this very scenario is what routing protocols were developed for.1 command.1. let’s say that the interface connected to Subnet 10. the router would still forward the traffic to the next hop. They are simple to use. vMX2 then needs to be told how to reach Workstation A. The first is that they need to be manually configured on routers.0.0/24 went down.0. The Drawbacks of Static Routes As mentioned earlier. to advertise subnets to other routers on the network so those routers will in turn know what next hops to use to reach those subnets. so while the router will drop the packet. two firewalls and eleven subnets with multiple paths? At some point the administrator needs to decide when using static routes has too much of an administrative overhead. but vMX2 also needs to know how to return the traffic. This may not seem like much of an issue in the above scenario.

a route needs to be added to vMX0 stating that to get to Subnet 10. which verifies there is end-to-end connectivity on this small network. with a source address of 10.168.1 ping statistics --4 packets transmitted.1 (in the Preface) the example network was a single router connected to the Internet.0.1.1: [edit] [email protected]# set routing-options static route 10.1.0.10.1: icmp_seq=1 ttl=64 time=3.2. This is exactly the type of network where a static route would be ideal.1 (10.0/24 the nexthop 10.0/24.2. The way the router would process the packets it receives would be to look at the destination address and if the destination address is on the local network.989 ms 64 bytes from 10. The command to do this on a Junos OS ADSL router would simply be: set routing-options static route 0.1.1): 56 data bytes 64 bytes from 10.1. then the router would automatically send it out to the Internet.1.2.1: icmp_seq=0 ttl=64 time=2.10.1: icmp_seq=2 ttl=64 time=2.1 PING 10. there should be a response: [email protected]> ping 10.1.0.1: icmp_seq=3 ttl=64 time=2.1.1.0.0.1.0/24 next-hop 10.795/3.0.037 ms 64 bytes from 10.566 ms As you can see the ping is successful. telling the router that subnet 10. which in Figure P.583/0.1 source 10.2.0. it would send it to the local device.10. 0% packet loss round-trip min/avg/max/stddev = 2.10. as opposed to the routing protocols in this book.1.0. a route needs to be added to vMX2.0/0 next-hop at-0/0/0.0.1 Now if a ping is sent from vMX0 to 10.3 should be used: [edit] [email protected]# set routing-options static route 10. Should the destination be any other subnet.0. 4 packets received.1 is 192.0/24 is reachable via the next-hop 10.0/24 next-hop 10.10.583 ms 64 bytes from 10.1.2.10.10.1. Configuring Default Static Routes In Figure P.10. and one where a default static route is the best solution. If you look back at the topology in Figure 1.0 . which are added under the Protocols hierarchy.037/2.1.1.10.10.0.1.1. 18 Day One: Routing the Internet Protocol Configuring Static Routes Static routes are added to a Junos OS device configuration under the Routing-Options hierarchy.10.571 ms ^C --- 10.3 Next.1.

0.3) 3.1 (10.3) 10.0.0.0.3 (10.121 ms 1.893 ms 6.2.706 ms 10.3) 3.988 ms 2.3 (10.806 ms 7.3 (10.2.1 (10.755 ms 7.0. when a ping is sent.0.409 ms 2 10.1 (10.3 (10.621 ms 24 10.2.1 (10.2.1: [email protected]> traceroute 10.741 ms 5.2.2.1 (10.2.2.1 (10.2.109 ms 2.284 ms 11.627 ms 22 10.2.615 ms 21 10.0.241 ms 2.915 ms 8.0.825 ms 19 10.0.339 ms 9.442 ms 8. so that the router knows all non-local traffic would be sent across a WAN link.070 ms 4.3) 11.0.0.2.610 ms 10.2.672 ms 10.266 ms 5 10.2.687 ms 13 10.2.229 ms 11 10.0.772 ms 11.2.210 ms 16 10.032 ms 5.0.2.3) 8.370 ms 10.0.3 (10.0.451 ms 10.1) 9.1 (10.263 ms 2.573 ms 3.1 (10.3.3 [edit] [email protected]# set routing-options static route 0.0. which can cause problems.2. use the default route instead of configuring so many individual routes.3) 13.990 ms 3. all subnets respond.2.0.401 ms 10.0.1) 9.471 ms 15 10.189 ms 8.2.059 ms 6.158 ms 4 10.337 ms 26 10.782 ms 17 10. Some engineers.288 ms 3.3.2.0.2.223 ms 10.1) 4.2.2.0.0.0.0.0.719 ms 9.3) 3.0.2. For example.0.2.847 ms 8 10. In this example.207 ms 11.2.1 (10.2.0.122 ms 28 10.181 ms 10.2.2.300 ms 12 10.161 ms 8.328 ms 10.3) 2.0.2. Junos OS also allows an engineer to specify a default route to an IP address.0. 40 byte packets 1 10.1) 3.1) 10.0.898 ms 19 .767 ms 1.0.0.2.0.2.1) 3.932 ms 4.2.1 (10.2.2.1) 8.2.3 (10.2.0. here is the output from vMX2 with a ping sent to 10.0.1). instead of specifying an IP address as the next-hop.0.0.3 (10.2.396 ms 1.3.0.0.1 (10.1) 11.765 ms 3.3) 9.0. 30 hops max.1 traceroute to 10.0. because ADSL is a point-to-point link and traffic sent on that link can only reach one device.3 (10.1) 6.410 ms 11.0.3 (10.3) 5.2.3 (10.518 ms 20 10. in a branch office for example. both vMX0 and vMX2 will be configured with a default static route to each other by using the following commands: [edit] [email protected]# set routing-options static route 0.070 ms 7.0.1 (10.0.2.3 (10.2.963 ms 7 10.617 ms 11.1) 7.0.0.0/0 next-hop 10.1) 125.2.1 (10.655 ms 10 10.0.0.0.873 ms 7. an interface is specified instead.0.508 ms 2.0.3) 7.2.879 ms 6 10.2.0. however.2.0.053 ms 3.3) 6.2.0.457 ms 10.3 (10.3) 11.250 ms 8.985 ms 10.3.0/0 next-hop 10.0.543 ms 9 10.118 ms 10. But look what happens if a ping is sent to an address that is not on any of the connected interfaces on either router. Chapter 1: Static Routes In this case.0.810 ms 8.817 ms 3.190 ms 23 10.0. which should make sense to you.894 ms 6.720 ms 6.3 (10.1 (10.2.1 This should work and indeed.1) 9.346 ms 27 10.1 (10.2.2.1) 3.0.2.2.0.2.434 ms 5.010 ms 8.3) 5.2.2.2.348 ms 18 10.605 ms 3 10.0.0.2.0.0.047 ms 2.0.287 ms 14 10.130 ms 25 10. as the following example illustrates.2.2.920 ms 6.3 (10.0.408 ms 9.0.1) 11.

in a group of nodes. At this point. And if you examine each hop you will notice that the addresses are 10.0.0/24 and that interface is down? vMX2 won’t be able to reach that subnet and so would send the traffic back to vMX0.0. 20 Day One: Routing the Internet Protocol 29 10.1 and 10.10. and easy to understand. . So an address was used that didn’t exist on the network.2. which means the packet would have 255 hops before it expires. where. The next chapter provides an overview of the types of routing protocols. there are thirty hops. This is known as a routing loop. your link between vMX0 and vMX2 is now congested.2.2. they are fairly straightforward to implement. the administrator assumes that any traffic that is not advertised within the LAN or WAN be on the Internet somewhere.2. without BGP. The main place a static route would be used on almost any network is on an Internet facing router.2.3 (10.966 ms 12. and although there are thirty hops shown here (this is a limit set by traceroute). the path to a particular destination forms a loop.3) 12. When it comes to default static routes. and as a result.0.0. as doing so can bring a small network to a halt.0.1.170 ms 12.1) 11.0. wikipedia. where each router is sending the packet back to the other.0.2.0.org/wiki/Routing_ loop_problem You can quickly see that even though there are only two routers in this subnet. Summary Although static routes are a very basic way of advertising routes across a network. before we begin to look at the individual protocols themselves.515 ms Routing Loop: An error occurs in the operation of the routing algorithm. IP packets tend to have a time to live (TTL) of 255.253 ms 11. But what if the traffic was destined for 10.824 ms 30 10.3 and then back to 10.293 ms 11.2. care should be taken to use them only where appropriate and one must never put default static routes on two devices that are facing each other.1 (10. they can still be very useful on a small network. By understanding static routes better we can apply this knowledge to the dynamic routing protocols so that we get a better feel for what they are trying to achieve. and one could argue that this is unlikely in a real network. https://en.

this is an unacceptable amount of downtime. their networks need to expand. So it is fairly common to never have more than two protocols running concurrently.Chapter 2 Routing Protocol Preference and Type When businesses expand. therefore the engineer needs to physically visit each router and configure each device using the local console cable. In theory. the issue becomes which protocol should the router believe? . an operation that could take upwards of four hours or more. as soon as the administrative engineer removes the old routing protocol. To assist in situations like this. As you no doubt agree. network connectivity is lost. even if the expansion is made during the evening hours. Unfortunately. The administrative engineer can simply add the new routing protocol. then once all the routers have been updated the process of removing the old protocol can begin. the Junos OS allows you to run multiple routing protocols on the same router at the same time. with multiple routing protocols running at the same time. But in the real world this is unlikely. Theoretically speaking. if your network size currently consists of forty routers. the routing protocol needs to be migrated to one that can cope with increased capacity. If your company is currently running a protocol that will not be able to cope with a future expansion. it is fairly safe to assume that it would take approximately five minutes to remove the old routing protocol and add the new one. as it would only serve to increase memory and CPU usage. especially if an issue is found along the way. too. mostly because. thus taking 3 hours and 20 minutes to complete the operation. a router running the Junos OS can run all of the routing protocols at the same time.

a static route. meaning that the router wouldn’t consider using that route unless one of the other routing protocols stopped advertising it first.3 125 Then the administrative distance of that route would be set at 125.2. the router will simply look at the administrative distance and choose the one with the lowest number. if a router running the Junos OS is running two routing protocols. if a static route was configured as follows: [edit] [email protected]# set routing-options static route 10. 22 Day One: Routing the Internet Protocol For example.0. and they can be modified so that one protocol is preferred over another.org/wiki/ Administrative_distance To resolve this issue.1. which were covered in Chapter 1.1 Administrative Distances for Routing Protocols Protocol Default Administrative Distance Static Routes 5 RIP 100 OSPF 10 IS-IS Level 1 15 IS-IS Level 2 18 BGP 170 ADs and Static Routes As Table 2.168. have an administrative distance of just 1. For example. This means that if an administrator added a static route to a destination. and IS-IS.1. Therefore. a number ranging from 1 to 255. An administrator could also elect to add two default static routes to a router like this: . it would immediately override any matching route from. say. RIP or OSPF. You may notice that static routes. but OSPF is advertising that the same subnet is accessible via the next-hop 192. or a directlyconnected route based on its perceived quality of routing.1. these are default administrative distances. which is higher than RIP.wikipedia. then in the case where a router has two competing routes.1 lists the routing protocols covered in this book in order of appearance.0. OSPF.168.0.1. https://en.0/24 is accessible via the next-hop 192. suppose that RIP is advertising that subnet 10. Which next hop should the router use? Administrative Distance: An arbitrary numerical value assigned to a routing protocol. each routing protocol is given what is known as an administrative distance. Table 2.0/24 next-hop 10. Table 2.1 indicates. in which the lower the number the more believable the routing protocol is to the device.254.10. even if that route information is incorrect.

0 10.10.0/16 *[RIP/100] 00:17:24. and these can be discounted.0 10.0/16 [RIP/100] 00:17:58. Let’s briefly explain the most number of bits.1.3 as the default route as this has an AD of 1.0.1 via ge-0/0/4.0. The last route.0/24 *[RIP/100] 00:17:58. The route that matches the most number of bits is the best route. that will convert into binary.0. Chapter 2: Routing Protocol Preference and Type [edit] [email protected]# set routing-options static route 0.2 via ge-0/0/2. tag 0 > to 172.168. metric 2.23.1 via ge-0/0/3.23. The most important thing to note is the /16. 23 .1 via ge-0/0/0.23.3. thereby providing some redundancy in the event of a failure.192.2.0/0 is a default route.168. tag 0 > to 10.0.0. 0. tag 0 > to 172. metric 2. so the router should use this route.3.0.0/0 next-hop 10.0.0. metric 2.0. metric 2. routers can also use the longest prefix to find the most reliable route.0.0.0.0.0. the router will compare the subnet it is trying to reach with all the routers in its routing table.1.0. metric 2.3 1 [edit] [email protected]# set routing-options static route 0. using the subnet 10.0. in other words. let’s suppose that the router was to look at the routing table and it identified the following routes: 192.0.0/16.0/0 *[RIP/100] 00:17:58.3.0/0 next-hop 10.20.0/8 *[RIP/100] 00:17:58.0.0 172.0. meaning it does not match anything else in the routing table.168.2 as the default route.7.0/24 *[RIP/100] 00:17:58. therefore the last two octets will be all zeroes.0.23.0.168.2 250 With this configuration. So the Subnet 10. tag 0 > to 172. metric 2. But let’s put this in the maybe pile for a moment.0 Now.3.0 You should notice that the first and fifth routes aren’t even close.1 via ge-0/0/0.1 via ge-0/0/0.0 10. tag 0 > to 172. the router will always use the next hop of 10. Route Preference by Longest Match In addition to using the administrative distance. then the router will withdraw the route and will immediately begin using the next hop of 10.0/16 in binary will appear as follows: 10.16.0 0.2. however if the interface on subnet 10.0.2.0/24 goes down. tag 0 > to 1.3.168. which means the first 16 bits of this IP address are important and the remaining 16 bits will be ignored.

This is the case. This one is also a possible route.0/8 is interesting.192. In the second box it is obvious that the subnet 10.0.0/16 doesn’t match.0. For there to be a match. In the end.0. these octets are highlighted. the route is only a /8 prefix. Route 10. as shown in Figure 2. Finally. this is the route the router would choose to forward the packet to the 10. however. the binary numbers should be the same in the octet and in the first box.0. As the example subnet was a /16. therefore they are possible matches. With this route both the first and second octets match. the last 16 octets were all zeroes and this means this route does not match.0. therefore this can be discounted.1 Route Converted Into Binary The subnet required had a /16 prefix.0. which means the third octet needs to be taken into account as well. Out of the six routes in the routing table. 24 Day One: Routing the Internet Protocol All the other routes begin with 10.0/8 has one matching octet. too.0. is a /24 prefix.0.0/0 and 10.1: Figure 2. Although the second octet doesn’t match. there can only be one winning route.10.168. As the 10. the route to 10.0. however.168. To confirm which one would be the better route.0/16 subnet.0/8. there are only two that are viable options: 0.0.0/24 needs to be taken into consideration. This route. they should be converted into binary before comparing. . This means only the first octet needs to match.

There are two paths to take. 25 . In this example the workstation wishes to communicate with the server. and the fourth. Chapter 2: Routing Protocol Preference and Type Protocol Types It goes without saying that all of the routing protocols in this book operate in completely different ways. Figure 2. however: Distance Vector. though RIP is the only protocol to stand the test of time. Both IS-IS and OSPF are link-state protocols. The types of routing protocol can be broken down into four main groups. which is not covered in this Day One book.wikipedia. one crosses a 2Mb serial link directly between the two routers. and the other uses 10Gb links that cross two more routers. Link State.2 shows an example of how a distance vector protocol chooses the preferred route and it also shows a weakness in its design. Path Vector.2. the path with the shortest number of hops is the preferred route. Where there are multiple paths between the source and destination. https://en. the other major class being the link-state protocol.2 Routing Protocol Types Distance Vector Protocols : A distance-vector routing protocol is one of the two major classes of intra-domain routing protocols. Several years ago there were more distance vector protocols in use. a hybrid protocol developed by Cisco Systems known as EIGRP. Looking at Table 2. it is evident that RIP is the only distance vecto protocol.org/wiki/ Distance-vector_routing_ protocol Protocol Protocol Type RIP Distance Vector OSPF Link State IS-IS Link State eBGP Path Vector iBGP Path Vector Distance vector protocols work in a very simple way – by counting the number of hops between the source and destination addresses. Table 2.

2 Distance Vector Preferred Path Distance vector protocols compare these paths and they will see that there are two hops one way and four hops the other. https://en. When link state protocols calculate the lowest cost. the algorithm begins by stating that the cost to you is always 0. developed by a Dutch computer scientist named Edsger Dijkstra.org/ wiki/Dijkstra%27s_algorithm On the other hand. Link-state routing protocols are one of the two main classes of routing protocols used in packet switching networks for computer communications.org/ wiki/Link-state_routing_ protocol SPF: Dijkstra's algorithm is an algorithm for finding the shortest paths between nodes in a graph. If you imagine for a moment that you are at point A. the other being distance-vector routing protocols. is quite complex but can be simplified.wikipedia. . and what these protocols do is calculate the speed of all the links along all the paths and then decide which path has the lowest cost. then a distance vector protocol would make the correct choice. they run what is known as the shortest path first algorithm or SPF. and although you can see that the 10Gb path is obviously the best as far as the distance vector protocol is concerned.wikipedia. Link state protocols refer to this particular metric as cost. https://en. 26 Day One: Routing the Internet Protocol Figure 2. Figure 2. The only real downsides in this situation would be that distance vector protocols don’t scale very well.3 shows a map with several points on it. and in the event of link failures are slow to converge. the two-hop path is the shortest. This algorithm. so the device running the Junos OS will use that instead. OSPF and IS-IS are link state protocols and they take into account something other than distance: speed. If this was a LAN and all links were 100Mb or 1Gb. Each point is assigned a letter and is connected to another point.

Chapter 2: Routing Protocol Preference and Type Figure 2. Once done. As an example. and the respective cost to them. if the path was A-B-D-G-I-H-F. the neighbors are B and C and the cost to them is 5 and 10. and if so what the cost is to get to them. for example the cost between A and D would be 5 + 1 or a total of 6. Finally. respectively. although it has more hops. and in the case of a router the data is moved to a third database known as the SPF database. this least-direct path would in fact be the best. which can be used as a rapid means of finding the lowest cost path without running the algorithm again. In this example. therefore. if point A needs to reach point F. by looking at the cost of each link you can see that if the path was A-C-F then the cost would be 60. however. While this information is being calculated.4 is changed so that the routers now use a link state routing protocol. a router places this data into a second database known as the candidate database. Once this is done.3 SPF Algorithm Simplified The next step is to discover whether or not you have neighbors. the link state protocol will use the four hop path with the much higher link speed. you then ask your neighbors who their neighbors are. This process continues until you know each point on the map and the costs between them. the path would in fact have a cost of 18. and this information is also placed into the link state database. If the example used in Figure 2. you can see that instead of using the slowest link with only two hops. the algorithm begins to calculate the lowest cost between each point. when the algorithm is complete. you should have a complete map of every point and detail of the lowest cost path to each point. 27 . This information is then saved to a database called the link state database.

specifically the Internet. path vector protocols work slightly differently due to the size of the networks they operate on.org/wiki/ Path_vector_protocol. the extra processing involved by knowing the account link speeds will slow the router down considerably. When a network has as many subnets as the Internet contains. 28 Day One: Routing the Internet Protocol Figure 2. but then put this into context – BGP is used to advertise routes that make up the Internet. https://en. BGP does not advertise the speed of each link connecting each router in the way that OSPF and IS-IS do.4 Link State Preferred Path On the other hand. BGP Best Path A path vector protocol is a computer network routing protocol which maintains the path information that gets updated dynamically.wikipedia. thus negating any speed increase that may be gained by knowing what link speeds are. BGP is known as a path vector protocol. In a way. and other organisations with extensive Internet connectiv- . In fact. BGP is a third category of routing protocol. telephone companies. For this reason. a brief overview is given here as an introduction and to provide a comparison against distance vector and link state protocols. it’s very similar to RIP in that it uses a metric similar to hops to find the best route. then in reality knowing the speed of individual links will not help in choosing the best path. Although BGP is covered in great detail in Chapter 7. BGP finds the best route because ISPs. but instead of using hops or distance it uses what is known as autonomous systems. which are referred to as paths. service providers.

the border router in AS1 will see that the path via AS3. you see that ACME Company is in AS1 and subnet 9. The end result is that each BGP router has a database known as the BGP table that lists every subnet on the Internet and to which AS they belong. Chapter 2: Routing Protocol Preference and Type ity are given a number called an AS or Autonomous System number. BGP routers exchange information about what subnets are in their own AS with routers that are in neighboring ASs. and the other via AS3. This number is applied to all routers in their networks. Using Figure 2. There are two possible paths to AS9 from AS1: one via AS2. and AS25. AS10. AS15. By using the best path algorithm. while also sending information about subnets they have knowledge of back to the original AS. Once the BGP table is complete.9. those neighbors inform their neighbors of those subnets. From this a map can be built that details through which AS traffic must pass before reaching any given subnet. In turn. AS20.5 BGP Best Path 29 .0/24 is in AS9. Figure 2.5 as an example.9. AS15. and AS25 is the shortest and will therefore use this to reach that subnet. BGP can run the best path algorithm and place the subnets into the routing table based on the shortest number of ASs the packet must traverse. and AS30.

” Smaller networks consisting of only 10 subnets are more suited to distance vector. There are. if your company has multiple web servers. such as during an acquisition. The next few chapters discuss each protocol in depth and will hopefully allow you to make a more informed decision as to which protocol is more appropriate given a certain circumstance. the answer is. several occasions where a company may be running several types. 30 Day One: Routing the Internet Protocol Summary When the question “What is the best type of routing protocol to use on my network?” is asked. of course. “It depends on how big your network is and how it connects to the outside world. Finally. . or a company may run a link state protocol at its HQ and run distance vector in branches. you may be running a path vector protocol. whereas larger WAN’s with hundreds of subnets across multiple sites are more suited to link state. for example.

RIP is quite an old routing protocol.Chapter 3 Route Information Protocol (RIP) In the networking world. and RIPNG.1 shows an example network where routers are connected to each other in a chain. There are in fact three versions of RIP. which is designed for IPv6. however anyone wishing to study RIPNG can find more great information at the Juniper TechLibrary: https://www. Figure 3. all of them have a limitation that can affect the decision to deploy it in a live environment — the maximum router width within the LAN. however.juniper.net/documentation/en_US/ junos14. and it’s important to know the differences between them. v1 (v1) and v2 (v2) were designed for IPv4. RIP v1 and RIP v2 are covered. MORE? IPv6 will not be covered in this book.2/information-products/pathway-pages/config-guide-routing/config-guide-routing-ripng. because it does what it was designed to do: advertise routes to other routers with a minimum of fuss. despite its apparent drawbacks.html . . It has endured because of its simplicity. But regardless of which version is in use on a network.

the maximum router width in a network using RIP is fifteen and as the diagram in Figure 3. There are exactly sixteen routers between Router A and the subnet and this poses a problem as the metric data within a RIP update packet is stored in a 4-bit field. so much so that you would be hard pressed to find a LAN still running v1. The reason for new versioning was a rapid growth in corporate LANs and the realization that there was only a finite supply of available IP addresses.1 shows.168.0/24. the authorities who .17. When the metric reaches sixteen. the router connected to that subnet won’t be able to reach the subnet behind Router A. During the 1990s. As RIP is a distance vector protocol. IP addresses were issued to companies in their A. Router A will never be able to reach Subnet 192. sixteen hops after Router A. for example. B.168. Router A is at one end of the chain and at the other end is Subnet 192. which in turn means the maximum metric for RIP is fifteen. its metric is hops.1. 32 Day One: Routing the Internet Protocol Figure 3.17.0/24 and in turn.1 RIP Route to Infinity In Figure 3. Not long afterwards. this meant that one of these sixteen values was reserved for this purpose. In addition to the sixteen-value limitation. Class C block consisting of 254 addresses would be issued even if the company only required 10 addresses. This means the maximum number of values in this field is sixteen. when RIP was being created the designers built in a way for RIP to be able to withdraw a route. RIP Versions The differences between RIP v1 and v2 are quite substantial. and C classes. In summary. Whole ranges were provided. this is classed by RIP as infinity and RIP withdraws the route.

Figure 3. and as most networks use classless subnets now. which would normally provide 16777214 addresses. Router B also has a third subnet connected to it which is a client.0. An example of why this could cause problems in a network is shown in Figure 3. Another major difference between RIP v1 and v2 is the way advertisements are sent. In Figure 3. or a Class C network could be divided into eight subnets. Router A or Router C.2 there are three routers. whereas the networks connecting them through Router B are Class C networks. a Class A block.0/8 and two possible next hops. The issue occurs when the routing advertisements are sent to a neighbor. both starting with 10. then RIP v1 doesn’t have an issue.0. When the classless subnets are connected to the same router.x. and this advertisement will be sent as a classful advertisement and not as a classless subnet. with RIP v1 the router will only see the network 10. The issue is. One of the major differences between RIP v1 and RIP v2 is that RIP v1 is not aware of these classless addresses whereas RIP v2 is. it makes it all but impossible to use RIP v1 in any modern network.2 Classless Networks in RIP V1 When the client wishes to communicate with the server. which 33 . Sometimes the packet will be sent the right way – but that doesn’t make for a reliable network. providing each customer with 30 client addresses. Chapter 3: Route Information Protocol (RIP) issued these addresses realized that this was a waste and a decision was made to move from what was known as classful to classless addresses. which for example. RIP v1 sends advertisements as broadcasts. With classless addresses.x. could contain 254 addresses.2. The networks attached to Routers A and C are Class A subnets. could be divided into subnets. Router B will receive the packet and the lookup on its routing table to see the next hop.x. RIP v2 doesn’t suffer from this issue.

which would usually be routers or Layer 3 switches. should only be sent between these routers and not sent out to the interfaces connected to subnets 10. and .0.x subnets.2. Router vMX3 is also connected to subnet 10. 34 Day One: Routing the Internet Protocol means every device on the network receives the update.x.0/24 and 10. RIP v2 updates are sent as multicast packets.5.2. While it may not seem like an issue at first.5. which means they are only sent to devices that subscribe to those updates. This increases the amount of traffic on the network and could cause delays on the clients and servers as they attempted to process then discard the broadcast. whether they want to receive them or not. however.3 details the topology that will be used in this section about configuring RIP. very occasionally.0/24. Both of these subnets need to be advertised into RIP so that router vMX6 can reach them. The reality is that attackers can exploit this misconfiguration.23. RIP updates.0/24.10.0/24 and vMX4 is connected to subnet 10. sending updates out of an interface to which no RIP neighbor is connected after all would mean RIP would just multicast the packets out without any device responding. Figure 3.0. however. Configuring RIP Figure 3.10. an administrator may set a workstation or a server to receive RIP updates if they had multiple network adapters so the server would know through which adapter a packet should be sent.3 RIP Topology There are three routers each connected to each other via 172. including clients and servers.

the best way to check that advertisements are being sent between routers is to use the show rip neighbor command: [email protected]> show rip neighbor Local Source Destination Send Receive In Neighbor State Address Address Mode Mode Met -------- ----- ------- ----------- ---- ------- --ge-0/0/0. the neighbor option tells RIP which interfaces to include in the updates to neighbors.0. The second issue with sending updates out of an unnecessary interface is that it requires bandwidth.0.9 mcast both 1 ge-0/0/1. the other protocols assign interfaces to include in advertisements in a different way.0. As mentioned in the last paragraph. a group needs to be created.0 send none set protocols rip group RIPGROUP neighbor ge-0/0/2.2. As you shall see later on in this book. In this case it just so happens the subnet 10.0 Up 10.0 send none Once the configuration is complete.2 zero-len none both 1 ge-0/0/2.0 set protocols rip group RIPGROUP neighbor ge-0/0/1.1 224.0.0 send none set protocols rip group RIPGROUP neighbor ge-0/0/2.23. the subnets in use on a corporate network or even access the network resources across the WAN.3. and in this case the group will be given the name RIPGROUP. The configuration of RIP is very different when compared to the other routing protocols covered in this book because Junos OS requires you to create a group and then assign interfaces to that group.0 Similar commands will be added to vMX4.0 Up 172. After the group name.1.0.0 Up 172. or gain knowledge of. The first router to be configured is vMX3. This option tells RIP not to send updates out of that interface but to include it in advertisements: set protocols rip group RIPGROUP neighbor ge-0/0/0.23. When updates are prevented from being sent out of an interface it is known as making the interface a passive interface.0 set protocols rip group RIPGROUP neighbor ge-0/0/1.0.10. Chapter 3: Route Information Protocol (RIP) as such inject false routes into.1 224.0 set protocols rip group RIPGROUP neighbor ge-0/0/1. therefore the send none option will be included after this interface.5.0 set protocols rip group RIPGROUP neighbor ge-0/0/2. even though this is going to affect a serial link more.0 Router vMX6 only has two interfaces in the RIP domain and one passive interface. The last command ends with the option send none.0/24 is connected to ge-0/0/1. too: set protocols rip group RIPGROUP neighbor ge-0/0/0.9 mcast both 1 35 . therefore the configuration for these is as follows: set protocols rip group RIPGROUP neighbor ge-0/0/0.

or if it comes from a RIP advertisement from another router. You may notice in the output for interface ge-0/0/1. whether the interface is up or down.0: 15 destinations. 36 Day One: Routing the Internet Protocol This command lists the interface. As an example. The requirement of having to assign interfaces to a group is not the only difference RIP has compared to the other routing protocols. The Send Mode tells you how the updates are being sent. This means that this interface is a passive interface. while the Receive Mode lets the administrator know which version RIP can receive. and RIP then exports these subnets as RIP advertisements: set protocols rip group RIPGROUP export RIP Once this has been committed and the show route command has been run once more. 0 hidden) + = Active Route. * = Both . * = Both 224. then the router creates a match.0 that the destination address is set as zero-len and the send mode is set as none. but under special circumstances can be increased by configuring a policy to make an interface less favourable to RIP.0: 18 destinations. and the source address of advertisements sent out to interfaces that would be the unicast address of that interface and the destination address. because by default. metric 1 MultiRecv To resolve this issue. Let’s try this policy-statement: set policy-options policy-statement RIP term 1 from protocol direct set policy-options policy-statement RIP term 1 from protocol rip set policy-options policy-statement RIP then accept Once the router finds a match. it will send and receive updates. By default. 0 holddown. - = Last Active. however the updates it sends will be empty. 19 routes (15 active. it informs RIP that those subnets match the statement.0. 21 routes (18 active. which would typically be 1. - = Last Active. 0 holddown. RIP will not advertise anything. and the last column is the metric assigned to that interface. you would see that there are no routes present: [email protected]> show route protocol rip inet. a policy statement needs to be created that says if a subnet is either directly connected. which is in this case is the multicast address RIP uses to send advertisements. 0 hidden) + = Active Route.9/32 *[RIP/100] 00:01:06. although it can still receive updates. so no updates are sent out of it. routes should be visible in the routing table: [email protected]> show route protocol rip inet. by multicast or by broadcast. if you were to look at the routing table by using the show route command. for example.0. when RIP is enabled.

233.0 to 172.0/24: [email protected]> ping 10. tag 0 > to 172. of course. by default. and these interfaces are directly connected.2: icmp_seq=1 ttl=64 time=2.0/20 [RIP/100] 00:17:58.2.7.10.2.560 ms 64 bytes from 10.2.2: icmp_seq=2 ttl=64 time=28.0/24 *[RIP/100] 00:17:58.0/24 *[RIP/100] 00:17:24. 0% packet loss round-trip min/avg/max/stddev = 2. it does not mean you won’t ever find it.0 > to 172.10.0/24 *[RIP/100] 00:17:58. tag 0 > to 172.2.2: icmp_seq=0 ttl=64 time=7.3.10.2.1. The Junos OS also allows an administrator to tell RIP to send v2 updates as broadcasts.3.1 via ge-0/0/0.10. and as such. is to initiate a ping across the network.10.3. tag 0 > to 172.23.0 172.977/145.10. it will send updates to that neighbor as v1. These are the IP addresses of management interfaces of the vMX routers that were added to the routers automatically by Junosphere in this book’s lab. metric 2. 4 packets received. the Junos OS does allow RIP to receive v1 and v2 updates.0 224.2. metric 2.0.23. In order to demonstrate what this looks like in the Junos OS. In this instance.327 ms 64 bytes from 10.233.23.2: icmp_seq=3 ttl=64 time=145.2): 56 data bytes 64 bytes from 10.0 10. if RIP receives a neighbor update in v1.2.3.958 ms ^C --- 10.2. tag 0 to 172.1 via ge-0/0/0.0.240. metric 2.2 PING 10. but it is included in order to be compliant with the RIP RFC. Chapter 3: Route Information Protocol (RIP) 10.10. metric 2.0 10.23.10.23.0/20 being advertised by RIP.9/32 *[RIP/100] 00:14:24. as opposed to multicasts – it is unlikely this option would be used. To achieve this the command begins as if an interface was being added. vMX6 will ping vMX3’s interface in subnet 10.062 ms 64 bytes from 10.7.240.2 via ge-0/0/2. routers vMX3 and vMX4 will be configured to send updates to each other as v1 updates. Because the policy statement said to match directly connected subnets.1 via ge-0/0/0.2 (10.2 ping statistics --4 packets transmitted.560/45. metric 1 MultiRecv It is interesting to note that there is a subnet 10. By default.2. Within the Junos OS it is possible to set RIP to send updates as v1 or v2 only. and to only listen for v1 or v2 updates. The purpose of this is to allow for backwards compatibility with older devices that happen to still be in use.515 ms Configuring a Version Specific RIP Regardless of how outdated RIP v1 is and how unlikely it is to find this version working on a modern network.2.23.23. One final test.2 via ge-0/0/2.7.10.10.2 via ge-0/0/2.10. too. RIP advertised them. after which the keyword send would be added followed 37 .958/58.

multicast.1.0 Up 172.23.0. 38 Day One: Routing the Internet Protocol by the desired option.3.23. however. (One of these options. none.9 mcast both 1 As you can see.0 send ? Possible completions: broadcast Broadcast RIPv2 packets (RIPv1 compatible) multicast Multicast RIPv2 packets none Do not send RIP updates version-1 Broadcast RIPv1 packets The available options mean: broadcast. it is possible to see what these options are. which is the default. In this case the version-1 option is specified.10.23. and version-1.2.) [edit] [email protected]# set protocols rip group RIPGROUP neighbor ge-0/0/0.255 v1 v1 only 1 ge-0/0/1. this time the keyword receive is used: [edit] [email protected]# set protocols rip group RIPGROUP neighbor ge-0/0/0.2 zero-len none both 1 ge-0/0/2. So the command is: set protocols rip group RIPGROUP neighbor ge-0/0/0.0 receive version-1 [edit] [email protected]# commit commit complete [edit] [email protected]# run show rip neighbor Local Source Destination Send Receive In Neighbor State Address Address Mode Mode Met -------- ----- ------- ----------- ---- ------- --ge-0/0/0. meaning it would not subscribe to multicast updates for RIP. this should also be reflected in the show rip neighbor command as the send mode would change to broadcast: .0.3. which means the updates would be sent as RIP v1 only.0 Up 10. was used earlier when the interface was made passive. none.0 send version-1 Next. In this case the version-1 option would be used. and either version-1 or version-2.1 172. Once this has been committed it is possible to see what effect it has had by using the show rip neighbor command: [edit] [email protected]# set protocols rip group RIPGROUP neighbor ge-0/0/0.0 Up 172.” If the option was then changed to broadcast. in addition the modes are showing as “v1. let’s configured it to listen only for v1 updates.0 receive ? Possible completions: both Accept both RIPv1 and RIPv2 packets none Do not receive RIP packets version-1 Accept RIPv1 packets only version-2 Accept only RIPv2 packets The options in this case are to listen for both. the destination address has changed from the multicast address to the broadcast address for the subnet. which would mean RIP v2 updates would be sent as broadcast. The command is the same as before.1 224. By using the context sensitive help ( ? ).

mentioned briefly earlier. network migration.0.23.0. RIP uses three timers to maintain a stable network. Chapter 3: Route Information Protocol (RIP) [edit] [email protected]# set protocols rip group RIPGROUP neighbor ge-0/0/0.1. The invalid route is held in the routing table during this period so updates of this invalid route can be passed to neighbors. No matter the cause.wikipedia. it needs to be refreshed at a regular interval. however.0 Up 172.3.255 bcast v1 only 1 ge-0/0/1.3. This timer is set at 30 seconds by default but it can be changed so that the updates occur as often as every 10 seconds. or even failure.0 Up 10.9 mcast both 1 RIP Timers Once RIP learns a route it is just a matter of time before that route will not be available. The frequency with which updates are sent to neighbors is what is known as the update-interval.2 zero-len none both 1 ge-0/0/2. https://en. The first method. then it is marked as invalid. The default value is 180 seconds. This is known as route-timeout. is that the advertising router advertises that subnet with a metric of 16.0 Up 172. which means all other routers will withdraw the route from their routing table. The Holddown timer is a period of time that occurs either after the route has been marked as invalid. the administrator can adjust this to 30 seconds for faster convergence.1 172. either due to maintenance. The second method is by the use of timers.1 224. 39 . or increase it to 360 seconds for slow links where updates could be dropped.org/ wiki/Routing_Information_ Protocol . Once a route is installed in the routing table. or when the metric is set as 16 and before it is finally withdrawn from the routing table.23. RIP has two ways of withdrawing routes from the routing table.23.10. or can be slowed down so they only occur every 60 seconds. If the route has not been refreshed within a certain amount of time. The default value is 120 seconds but can be changed to a value between 10 and 180 seconds. More on RIP and Timers: The Routing Information Protocol (RIP) is one of the oldest distance-vector routing protocols that employ the hop count as a routing metric.0 send broadcast [edit] [email protected]# commit commit complete [edit] [email protected]# run show rip neighbor Local Source Destination Send Receive In Neighbor State Address Address Mode Mode Met -------- ----- ------- ----------- ---- ------- --ge-0/0/0. meaning that the subnet is unreachable.2.

If RIP did not have this mechanism then it would be possible that neighbors would think that a subnet advertised in that update was reachable through the router that was simply forwarding the update. This means that when RIP receives an update. However. thus causing a loop. 40 Day One: Routing the Internet Protocol CAUTION Juniper recommends that these timers are left set at their default settings because unless they are set exactly the same for all neighbors on a subnet.wikipedia. this update is automatically sent out to all neighbors. When making the change here. the original router would forward the packet to the advertising router. and as such. these timers affect all groups on all interfaces: set protocols rip route-timeout 30 set protocols rip update-interval 10 set protocols rip holddown 10 The next place you can change RIP timers is under the group itself. all neighbors on that subnet must have the same configuration changes made. The first is directly under the RIP configuration itself. causing delays and downtime.0 update-interval 10 set protocols rip group RIPGROUP neighbor ge-0/0/0.org/wiki/ Split_horizon_route_ advertisement In order for full reachability to occur on a network. Configuring RIP Timers There are several places within the configuration hierarchy where RIP timers can be changed. by default. https://en. all routers in the network must have an exact copy of the same database. otherwise loss of service can occur: set protocols rip group RIPGROUP neighbor ge-0/0/0.0 route-timeout 30 Routing Loop Prevention Split Horizon: Split-horizon route advertisement is a method of preventing routing loops in distance-vector routing protocols by prohibiting a router from advertising a route back onto the interface from which it was learned. if that subnet was unreachable via the original advertising router. routes could flap. the holddown timer cannot be changed (therefore the holddown timer must be changed under the RIP hierarchy): set protocols rip group RIPGROUP update-interval 10 set protocols rip group RIPGROUP route-timeout 30 The last location is under the neighbor itself. and by changing these settings. The following configuration examples are provided for the reader’s interest and education. which would forward it back to the original router. . Note that when making changes under the group. there is one exception – RIP will never send an update from the same interface on which it was received – that’s called a split horizon.

Configuring the Junos OS to use either plain text or MD5 authentication is simply a matter of using the option simple or md5 after the authentication-type keyword. thus offering some protection against an attacker gaining information. therefore encrypted. Or the key could be sent as an MD5 key. Use the show route protocol rip command: 41 . Chapter 3: Route Information Protocol (RIP) Under normal circumstances this would never need to be turned off. It’s done like this: set protocols rip group RIPGROUP neighbor ge-0/0/0. which could in theory be compromised considering the attacker is already on the inside and could therefore listen for packets carrying the key. RIP Authentication When the initial RIP configuration was performed. but note that if the Junos OS has multiple RIP groups this change does affect all groups. meaning the key is hashed. RIP can be configured to only send updates to neighbors it trusts. updates can be configured with an authentication key. Configuring RIP Authentication Enabling RIP authentication is relatively simple because it is done globally rather than on a per-interface level. however if the router was a hub connected to a point-to-multipoint frame relay link. In this case. But you should give consideration to the possibility of an attack taking place on the inside on your subnets where RIP updates are sent. split horizon should be left enabled. then this would need to be disabled. let’s check to see everything is working as expected. let’s say router vMX3 is configured to use MD5 authentication: set protocols rip authentication-type md5 set protocols rip authentication-key ITSSECRET Once committed. and to build this trust. some of the interfaces were set as passive interfaces to prevent RIP updates being sent out on unwanted interfaces.0 interface-type p2mp For any other situation. routers vMX4 and vMX6 will be configured to use simple authentication with a password of ITSSECRET: set protocols rip authentication-type simple set protocols rip authentication-key ITSSECRET For a moment let’s check on what would happen during a mis-configuration. so should an attacker see the packet the key would not be compromised. or was an SRX device in a HQ connected to multiple branch SRX devices via VPN links. To protect against this. This key can be sent as plain text.

flag.23. 11 routes. So once you have identified and corrected the cause. you could just watch for authentication events or received updates. the option all is used to include everything: set protocols rip traceoptions file RIPTRACE set protocols rip traceoptions file size 100000 set protocols rip traceoptions file world-readable set protocols rip traceoptions flag all While an administrator could keep entering show log RIPTRACE. which displays the output in the CLI session in real time. tells the Junos OS which components of this service to debug. The size of the file will be set as 100000 bits and it would be possible to view this as ASCII text. The following output was taken from such a scenario and the section highlighted in bold tells why it isn’t receiving updates: Jun 6 05:20:37. it is important to bear in mind that this command can fill the storage on the device running the Junos OS and could lead to high CPU usage. if the output is verbose the log file can grow to quite a size.0.473363 task_job_delete: delete background job “RIPv2 process rcvd response packet” for task RIPv2 Jun 6 05:20:37.2.9/32 *[RIP/100] 00:01:09.473346 RPD_RIP_AUTH_UPDATE: Update with invalid authentication from 172.3. vMX3 is not showing any routes advertised by RIP.0. 0 holddown.0: 11 destinations. v1.473228 task_job_create_ background: create prio 1 job “RIPv2 process rcvd response packet” for task RIPv2 Jun 6 05:20:37.473301 received response: sender 172. the traceoptions should be deleted as soon as it’s convenient. . therefore the better option would be to use monitor start RIPTRACE. In this case.473282 background dispatch running job “RIPv2 process rcvd response packet” for task RIPv2 Jun 6 05:20:37. for example. - = Last Active. 13 routes (11 active.0) Jun 6 05:20:37.2 (ge-0/0/0.3. use the traceoptions keyword under the relevant service along with the necessary options. metric 1 MultiRecv As you can see. 0 hidden) + = Active Route. The last option. so anyone who logs into the Junos OS would be able to read it. 42 Day One: Routing the Internet Protocol [email protected]> show route protocol rip inet. the output would be saved to a file named RIPTRACE.23. * = Both 224. command 2.473313 Failed last rte on validity of fields 0 Jun 6 05:20:37. Jun 6 05:20:37.473607 background dispatch completed job “RIPv2 process rcvd response packet” for task RIPv2 CAUTION While the traceoptions command can be useful. When faced with such an issue an administrator needs more information to find exactly what’s wrong – and the Junos OS provides an option to debug a particular service and save the output to a file. To do this. mbz: 0. In this case.

0 hidden) + = Active Route.0. * = Both 10.233. and the routing table should display all routes again quite quickly: [edit] [email protected]# set protocols rip authentication-type simple [edit] [email protected]# commit commit complete [edit] [email protected]# run show route protocol rip inet. metric 2.23.3.0: 14 destinations. metric 2.23. - = Last Active.3. tag 0 > to 172.23.3.2 via ge-0/0/0. the show rip statistics command can also be used. rts learned rts held down rqsts dropped resps dropped 0 4 0 0 ge-0/0/0.0/20 [RIP/100] 00:02:48.9/32 *[RIP/100] 00:02:48.23.0 10.0/24 *[RIP/100] 00:02:48.0/24 *[RIP/100] 00:02:48.10.23.0 > to 172. Chapter 3: Route Information Protocol (RIP) In this case. the router should immediately begin receiving updates once more. metric 1 MultiRecv 43 . update interval 30s Counter Total Last 5 min Last minute ------- ----------- ----------- ----------Updates Sent 359 10 2 Triggered Updates Sent 10 1 1 Responses Sent 0 0 0 Bad Messages 0 0 0 RIPv1 Updates Received 1126 20 3 RIPv1 Bad Route Entries 0 0 0 RIPv1 Updates Ignored 0 0 0 RIPv2 Updates Received 23 0 0 RIPv2 Bad Route Entries 0 0 0 RIPv2 Updates Ignored 0 0 0 Authentication Failures 11 10 3 RIP Requests Received 3 1 0 RIP Requests Ignored 0 0 0 none 0 0 0 After correcting the authentication type on vMX3.1.0/24 *[RIP/100] 00:02:45.240. but now is an issue: [email protected]> show rip statistics RIPv2 info: port 520.23.1.2 via ge-0/0/2.0. timeout 180s. 17 routes (14 active.0 to 172. 0 holddown.5.1.3.2 via ge-0/0/2.0 224.2 via ge-0/0/0. meaning that this wasn’t an initial issue before authentication was enabled on all routers.7.2 via ge-0/0/0. metric 2. 6 routes advertised.0: 0 routes learned.23. tag 0 > to 172. tag 0 to 172. The following output shows that there have been 11 authentication failures in total.0 10.0 172.2 via ge-0/0/2. three of which were in the last minute. tag 0 > to 172. holddown 120s. metric 2.0.

RIP would work. nevertheless. The next chapter discusses a protocol that can scale to a level not yet considered when RIP was conceived. 44 Day One: Routing the Internet Protocol Summary RIP can be an ideal protocol for small networks. RIP can still play an important part in modern networks and in yours. In the real world. when a network has more than 20 subnets the administrator should consider a more suitable alternative. however. as long as the network isn’t wider than 16 routers. .

https://en. and the DR then sends the information about routers on that network to all routers.org/ wiki/Link-state_ advertisement As mentioned in Chapter 1. The first LSA type. is that it is slightly more complex to configure and in order to achieve the high level of scalability it needs to be configured correctly. The purpose of this router is to take over should the DR fail. The DR and BDR are decided by a process when the administrator has set a priority on the routers in a LAN segment. so all routers communicate their presence with the DR. the router needs to learn what other routers and subnets are on the same network as it is. to save processing cycles one of the routers is made a DR. OSPF is a link state protocol. The only drawback. In addition to a DR. The purpose of the DR is to reduce and centralize the traffic that is exchanged between routers on that subnet. then the router . a router uses several LSA types to populate the link state database. When there are multiple routers on the same subnet. is used to identify which routers are on the network and which links and which networks are connected to those routers. network or LSA type 2. In fact. however.Chapter 4 Open Shortest Path First (OSPF) OSPF is probably the most popular routing protocol in use today because it is scalable and offers rapid convergence. OSPF also designates a second router as a backup designated router (BDR). router or LSA type 1. is generated by what is known as the designated router or DR. It uses the SPF algorithm to determine the best or shortest path. If all routers have the same priority.wikipedia. and the router with the highest priority becomes the DR and the router with the second highest becomes the BDR. and the way it achieves this is by using link state advertisements (LSAs). compared to RIP. The second LSA type. Link state advertisements: communicate the router’s local routing topology to all other local routers in the same OSPF area. Before the SPF algorithm can be run.

7 NSSA Summary Type 5 LSAs are allowed to leave a not so stubby area – which is covered in more depth in the upcoming section Types of OSPF Areas. 3 Summary A summary of type 1 LSAs that are sent between areas by ABRs. that have been redistributed into OSPF. but in either case. 4 Summary ASBR A summary of type 5 LSAs sent between areas. With type 3 LSAs. where two routers are connected via a serial link. 46 Day One: Routing the Internet Protocol with the highest router ID becomes the DR. When OSPF imports routes from another protocol.1 OSPF LSA Types LSA Type LSA Name Description 1 Router These advertise the routers. Type 4 LSAs are a summary of these routes. as multicast is advertised by another protocol. This LSA contains information about that particular network. such as RIP or IS-IS. while the two protocols are running there is a need for each protocol to share the routes it’s learnt with the other. then it would summarize the network in Area 0 and send these via an LSA type 3 into Area 1 and at the same time summarize the networks in Area 1 and send those as a type 3 LSA into Area 0. Sometimes a company may run more than one routing protocol on its network. if the ABR was in Area 0 and Area 1. In the case of point-topoint networks. This is known as redistributing. for example. similar to the type 3 LSAs. maybe because of a recent acquisition or because it is in the middle of a migration. the ABRs establish themselves as the advertising router instead of passing on the details of the original advertising router. links. so therefore summary or type 3 LSAs are created by Area Border Routers (ABRs) and are sent between OSPF areas instead. Table 4. Table 4. their names. and descriptions of their purposes. for example. and networks that are in that area. and type 5 LSAs are the complete list of the routes. . 2 Network Created by a DR as a means of reducing the communication between routers on that subnet. 5 AS Network Networks learned from an external protocol. this other protocol is known as an autonomous system (AS) and the router that is performing the redistribution is known as an autonomous system boundary router (ASBR). PIM.1 summarizes the various types of LSAs. The purpose of type 4 and 5 LSAs are to advertise the routes learned from the other routing protocol to other routers. 6 Multicast OSPF Obsolete. then no DR election process takes place. LSA types 1 and 2 always stay within their area. These LSAs are a summary of the networks in the areas to which they are attached.

OSPF doesn’t suffer from the same drawback. so they will withdraw it immediately. The key to OSPF’s scalability is the use of what is known as areas. One restriction with areas is that all areas must be directly connected to an area with the number 0.535 for routes learned via type 1 and type 2 LSAs. and 16.org/ wiki/Open_Shortest_Path_ First#Area_types Like RIP. An area includes its router having interfaces connected to the network. and the only limitation is that the maximum metric for OSPF is 65.215 for routes learned from type 3 and type 4 LSAs. for example if a link goes down or if a new interface is created.0. However.0. Note that if the network consists of a large number of routers. if the OSPF domain is divided into smaller segments then the processing required during the topology change is restricted to that smaller segment only.0. By advertising the route with this metric. the change is advertised across the network causing the SPF algorithm to run on every router. Figure 4. NOTE OSPF Areas: An OSPF network is divided into areas that are logical groupings of hosts and networks. This is a way of dividing up the network into smaller clusters of routers so that during a change in the topology.777. the amount of processing involved could slow the routers down. then there is no need to run the algorithm in the adjoining area.1 shows an example of an OSPF domain with Area 1 and 2 directly connected to Area 0. to withdraw a route from the routing table. which in turn could have an impact on network traffic.wikipedia. Figure 4. Chapter 4: Open Shortest Path First (OSPF) Creating a Scalable Network Remember that RIP has a maximum router width of 15 routers. shortened in text to area 0 also known as the backbone area. In fact.1 Example OSPF Domain 47 . an OSPF domain can consist of hundreds routers. https://en. other routers know that the route is no longer accessible. OSPF can use these maximum metrics. also known as LSInfinity. Other areas know that subnets in that area are reachable through the same ABR and as long as these ABRs remain up.

2 ge-0/0/2.0 VMX1 uses similar commands to vMX0 as it just so happens that the same interfaces are in use: set protocols ospf area 0.0.0.0 ExStart 1.0.0.0. An ASBR connects the RIP domain to the OSPF domain. These set commands indicate which interfaces to use and the areas to which they belong: set protocols ospf area 0. Full means negotiation has finished and each router has exchanged databases and they agree the information matches.3.0.0.4 128 30 The output would tell an administrator the following: The Address column is the destination IP address this router uses to communicate with this neighbor.0 set protocols ospf area 0. The State column details the state of the neighborship. You can check on the progress of the negotiations by issuing the show ospf neighbor command.0 128 38 10.0.0 interface ge-0/0/1.0 interface ge-0/0/0. such as in the following output: [email protected]> show ospf neighbor Address Interface State ID Pri Dead 10. Above this number you should start considering creating an additional area.0 Loading 2.0 Once the configuration has been committed.0. Configuring OSPF The configuration will be performed on router vMX0 first. the benefit of splitting areas is not felt if the area contains less than 50 routers.1. these tend to contain powerful high-end routers. an optimal area should consist of between 90 and 100 routers.0.0.0.0.1 128 38 10.4. and .0.0 Full 1.0.0.5.0 interface ge-0/0/1.0. however. each area is connected to Area 0 via two redundant ABRs.2 ge-0/0/0.0 set protocols ospf area 0. The Interface column tells the administrator though which interface connectivity to the neighbor is achieved.0 interface ge-0/0/2. A RIP domain is connected to Area 2. 48 Day One: Routing the Internet Protocol In Figure 4. As a rough guide.0. vMX1 should immediately begin negotiations with vMX0 to become neighbors.0. NOTE Areas consisting of more than 300 routers can be found.0 set protocols ospf area 0.1 ge-0/0/1.0 interface ge-0/0/2.0 interface ge-0/0/0. In contrast.0 set protocols ospf area 0.0. whereas Loading means the database is currently being loaded.0.

Another state that is seen on serial links is 2way. Use the show route protocol ospf command. is the dead timer which tells the router how long to wait before it declares the neighbor dead should that neighbor stop communicating. The y column is short for priority and is used to determine which router on the subnet is a DR. This ID is taken from the physical interface with the lowest IP address. This timer should keep resetting itself to 40 every time it receives a keep-alive message from the neighbor.0.0 passive set protocols ospf area 0. For the same reasons as preventing RIP from sending updates out of an interface.0.0 interface ge-0/0/1. If the priority is set to 0. however vMX2 has two interfaces through which no OSPF neighbors connect.0. then it usually means the routers are unable to negotiate successfully and there’s an issue.0 passive Testing the OSPF Configuration The easiest way to check the configuration is to look at the routing table to see if the routes have been learned.0 set protocols ospf area 0. If this is run from router vMX2.0 interface ge-0/0/2. then the ID is the IP address of the loopback interface. The higher the priority the more preferred the router is to become a DR. If the router has a loopback interface. and interfaces from the opposite edge of the OSPF domain appear in the list. Let’s see: 49 . the router will never become a DR. but the subnets connected to these interfaces still need to be advertised across the OSPF domain. The ID can also be set manually as you will see later in this OSPF chapter.0.0 interface ge-0/0/0.0 passive set protocols ospf area 0.0.0 passive Router vMX4 has two interfaces that are in the RIP domain and therefore these should also be designated as passive interfaces.0 interface ge-0/0/2. Chapter 4: Open Shortest Path First (OSPF) ExStart means the routers are about to begin exchanging their databases. Dead.0.0.0 set protocols ospf area 0. The last field.0. the set protocols ospf area <area number> interface <interface> command can be followed using the keyword passive: set protocols ospf area 0.0. to prevent OSPF from sending multicast packets out of an interface. Changing this interval is discussed later on in this chapter.0. the same commands can be used. which is the router at the furthest edge of the OSPF domain. set protocols ospf area 0. The ID field details the ID of the neighboring router.0 interface ge-0/0/0.0. then this is a sure sign that all routers are learning all subnets.0. but if 2way is seen on an Ethernet link.0 interface ge-0/0/1. When the configuration is applied to vMX2.

1: icmp_seq=4 ttl=62 time=6. metric 4 > to 10.0 of vMX4 from router vMX2: [email protected]> ping 172.2.7.0.0 224. OSPF will actually choose the slowest path. metric 4 > to 10.0/24 *[OSPF/10] 02:57:21.157 ms 64 bytes from 172. 5 packets received.7.0 172. This means that if there are two paths and one crosses a single router but uses 100Mb/s links.5/32 *[OSPF/10] 02:58:19.1 ping statistics --5 packets transmitted.0. metric 3 > to 10.1: icmp_seq=1 ttl=62 time=6.1: icmp_seq=0 ttl=62 time=18.1 via ge-0/0/0.7.23.7.1 via ge-0/0/0.1 via ge-0/0/0. 0 hidden) + = Active Route.0.0 10. these appear in the routing table. OSPF Reference Bandwidth One thing that needs to be taken into account while performing the basic OSPF configuration is the speed of the interfaces.23. Let’s run the show route protocol ospf command to see the reference bandwidth with the routers using in our example topology: .0.7.23. it is better to think about future link speeds and set the reference to be higher.23.3.0.0: 24 destinations.1: icmp_seq=2 ttl=62 time=5. - = Last Active.23.1): 56 data bytes 64 bytes from 172.23.0/24 *[OSPF/10] 02:56:16.7. 0 holddown.23.0 10.7.3.212 ms 64 bytes from 172.0.0/24 *[OSPF/10] 02:57:21.23.0 10.2. received is a reply indicating full connectivity.0/24.283/4.2. The final test of course would be to ping interface ge-0/0/2. and the second crosses three routers but uses 10Gb/s links. metric 2 > to 10.0/24 *[OSPF/10] 02:57:16. 50 Day One: Routing the Internet Protocol [edit] [email protected]> show route protocol ospf inet.23.1.847/18.272 ms 64 bytes from 172.1: icmp_seq=3 ttl=62 time=8.23.1 PING 172. While you could choose the speed of your current fastest link as the reference bandwidth.1 via ge-0/0/0.0/24 and 172. * = Both 10.1 via ge-0/0/0.283 ms 64 bytes from 172.7. 33 routes (24 active.311 ms ^C --- 172.0. metric 2 > to 10.4.23.23.0/24 *[OSPF/10] 02:57:16.0 172.23.7.0.0/24 *[OSPF/10] 02:56:16.3.0.1 via ge-0/0/0. the reference bandwidth needs to be set on all routers in the OSPF domain. OSPF gives a default cost of 1 to interfaces that are 100Mb/s or more.2.0.212/8.812 ms As you can see. 0% packet loss round-trip min/avg/max/stddev = 5. To correct this.0.7.2. metric 3 > to 10.0. metric 1 MultiRecv The router at the opposing edge is vMX4 and its connected subnets are 172.5.2.7. and sure enough.1 (172.

metric 4000 > to 10.2.0/24 *[OSPF/10] 00:01:37.0.0.0.0. metric 3 > to 10. * = Both 10.0 224.0.0 172.0/24 is 4. 26 routes (23 active. metric 4 > to 10.3.0/24 is 2 and the metric to 172.0.23.2. metric 2 > to 10.0 10.2.0: 23 destinations.0 172.2.5/32 *[OSPF/10] 07:29:22.0/24 is now 4000: [email protected]> show route protocol ospf inet.1 via ge-0/0/0. metric 3000 > to 10.3. metric 3000 > to 10.0 10. in addition to the backbone area and normal areas.0/24 *[OSPF/10] 00:01:37. there are also four other areas that can play an important part in an OSPF domain.2. 0 hidden) + = Active Route. metric 1 MultiRecv You can see that the metric to 10.3.7.23.0. and as such. and it was explained that each area that is not a backbone area must be directly connected to a backbone area.23.0/24 is now 2000 and the metric to 172.0.3.5.7.1 via ge-0/0/0. 0 holddown.7.0 10. These areas are based on a common theme of trying to reduce the amount of LSA’s entering the area. 26 routes (23 active. 0 holddown.0/24 *[OSPF/10] 00:01:37.0 172.0.0. Well.0.0.23.0.4. metric 4 > to 10.3.3.1 via ge-0/0/0.0.0.2. - = Last Active.0 172. 0 hidden) + = Active Route.2.0 224.1 via ge-0/0/0. Chapter 4: Open Shortest Path First (OSPF) [email protected]> show route protocol ospf inet.5/32 *[OSPF/10] 05:34:02. metric 1 MultiRecv Types of OSPF Areas Earlier in this chapter the backbone area was discussed.1 via ge-0/0/0.0/24 *[OSPF/10] 00:15:43.0/24 *[OSPF/10] 00:01:11.0/24 *[OSPF/10] 00:01:37.0.1 via ge-0/0/0.0.2.0. you’ll see that the metric to 10.0/24 *[OSPF/10] 00:01:11. 51 . reducing the size of the database for the routers in that area.1 via ge-0/0/0.0.0. metric 2000 > to 10.7. Let’s set the reference bandwidth to 1000g by adding the following on every router: set protocols ospf reference-bandwidth 1000g If you look at the routing table.0/24 *[OSPF/10] 00:01:11.4.2.5.0 10.1 via ge-0/0/0. metric 4000 > to 10.1 via ge-0/0/0.0: 23 destinations.0.1 via ge-0/0/0. * = Both 10. - = Last Active.0.23.0/24 *[OSPF/10] 00:01:11.0/24 *[OSPF/10] 00:01:37.23.2. metric 3 > to 10.

Configuring OSPF Area Types For this scenario. For the purposes of showing how type 4 LSAs are affected by configuring area types. as all are shown in Figure 4. Interface ge-0/0/1.0 of vMX0 are in Area 1. Stub areas do not allow type 4 and type 5 LSAs to be sent into or across an area. Instead. This area performs the same role as the NSSA with the difference that routes coming into the NSSA from the backbone area are summarized into a default route. meaning that it would not be possible to import routes from another routing protocol into an area as the LSA types that advertise these external routes are type 4 and type 5. The size of the database can be reduced even further still. and vMX4 and interface ge-0/0/2. however. RIP has been redistributed into OSPF (redistribution is covered in more detail in Chapter 6). you can see what LSAs the router has received: . Therefore. a default route to the ABR is created. The last type of area is known as the not so stubby totally stubby area. our topology will be changed so that routers vMX2 and interface ge-0/0/2.0 of vMX1 are in Area 0. which are then allowed into and out of a stub area. by the use of totally stubby areas. not so stubby areas (NSSAs) resolve this issue by converting what would usually be an LSA type 5 into an LSA type 7. making for a much smaller database. are also replaced with a default route to the ABR. These stub areas can help reduce the size of the database. type 3 LSAs. together with type 4 and type 5 areas. 52 Day One: Routing the Internet Protocol The first area is a stub area. ABRs also won’t allow those LSA types out.2. By using the show ospf database command on router vMX4. With totally stubby areas. One issue with stub and totally stubby areas is that not only do the ABRs not allow those types 4 and type 5 LSAs into an area.0 of vMX1 are in Area 2.0 of vMX0 and interface ge-0/0/1.

0.0. As the routes come from various sources.0. Figure 4.0.0.0.4 0x80000001 1681 0x22 0x370a 36 Extern 192.0. Next.0.168. ASBRSum are the type 4 LSAs. OSPF wouldn’t know which metric would be the correct one to use.0.0.4 0x80000002 594 0x22 0x211d 36 Extern 192.0 1.0.0.1.4 0x80000001 1681 0x22 0xd7bc 36 Extern 10.0 1.23.4 0x80000002 890 0x22 0xbe18 36 Extern 172.0.10.0. Area 0.0.0.0.4 0x80000002 298 0x22 0xdd8 36 Extern 192.0 0x80000003 17 0x22 0xa37 28 Summary 10.0.0.0.0.0.0.0 1. and they detail the routes learnt from RIP.0.0.0 0x80000001 17 0x22 0x292c 28 Summary 172.5.1.0 0x80000001 17 0x22 0x3521 28 Summary 10.0.0 1.4 0x80000001 1681 0x22 0xf2e 36 You can see the router and network LSA received from the other routers in area 1.23.0.0.7.168.3 1.0 1.0.0 0x80000001 17 0x22 0x2091 28 Summary 172.4 1.0.4. so all 53 .1.0.1.233.2 1.4 0x80000001 1681 0x22 0x1925 36 Extern 192.0. let’s set Area 1 as a stub area.23.0 1.0.0.4 1.0.1 Type ID Adv Rtr Seq Age Opt Cksum Len Router 1. In the type column.0 1.240.0 1.2 0x80000004 17 0x22 0xf805 60 Network *10.3 1.0.0 1.2 0x80000001 17 0x22 0xf72c 32 Summary 10.2 Chapter 4: Open Shortest Path First (OSPF) OSPF Areas and RIP [email protected]> show ospf database OSPF database.0.0.2 1.0 0x80000004 18 0x22 0x5dc8 36 Router *1. and the LSAs with the type set as External are type 5.0.1.0.3.0 0x80000001 17 0x22 0xf3b9 28 ASBRSum 1.168.3. This change should be done on all routers in that area.3.0.0.0 0x80000001 17 0x22 0xa4b9 28 OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern 10.168.2.0.0.0 1. You can also see the summary LSAs with the Adv Rtr column (or advertising router) changed to be the ABR.

168.0.5.2.0. the default-metric option is used to inform OSPF which metric to apply to these routes.3 1.0 1.0 1.3.1 Type ID Adv Rtr Seq Age Opt Cksum Len Router 1.0.1 via ge-0/0/0.0/24 *[OSPF/10] 00:21:12.0.0 10.0.0.0 0x80000004 133 0x20 0x7bac 36 Router *1.0 0x80000001 176 0x20 0x129d 28 OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern 10.0.23.0 0x80000001 176 0x20 0x3e75 28 Summary 172.2 1.0.0.0.0: 19 destinations.0.23. metric 4000 . 54 Day One: Routing the Internet Protocol metrics are removed. Area 0.2 0x80000003 132 0x20 0x19e7 60 Network *10.0.1. you would see that the routes from RIP are now showing as a single default route to 0.0.1.0/0 *[OSPF/10] 00:00:12.0 1.0 1.0.7.0.0 0x80000001 176 0x20 0x5305 28 Summary 10. Without the default-metric keyword.0.0.0.4 0x80000002 527 0x22 0xd2f 36 If you were to look at the routing table.0/24 *[OSPF/10] 00:21:54. metric 3000 > to 10.4 0x80000001 2205 0x22 0xd7bc 36 Extern 10.0. Now.1.0.0.1 via ge-0/0/0.2. Other routers in the area just need to be told they are in a stub area.1 via ge-0/0/0.3.0. 22 routes (19 active.1.10.0.3.4 0x80000002 1414 0x22 0xbe18 36 Extern 172.0.0.0.2.0.2.0/0: [email protected]# run show route protocol ospf inet.0. 0 hidden) + = Active Route.0.4 0x80000002 822 0x22 0xdd8 36 Extern 192.7. if you look at the database.0/24 *[OSPF/10] 00:21:54.4.0 10.0.2.0.0.168. metric 1100 > to 10. the routes will not appear in the routing table: [edit] [email protected]# set protocols ospf area 1 stub default-metric 100 [edit] [email protected]# set protocols ospf area 1 stub NOTE The default-metric option need only be added to the ABR.4 0x80000001 2205 0x22 0x1925 36 Extern 192.0 0x80000001 176 0x20 0x2c19 28 Summary 10.0/24 *[OSPF/10] 00:21:54. * = Both 0.240.168.0.23.0.0 1.1 via ge-0/0/0. - = Last Active. To correct this.0.0 172.0.2 1.0.0.233. but the type 4 LSA has disappeared from the list: [email protected]> show ospf database OSPF database.1 via ge-0/0/0.0 1.4 1.0.4.0.0. metric 4000 > to 10. metric 2000 > to 10.2.0.2 0x80000001 132 0x20 0x1610 32 Summary 10.23. the change is very subtle.5.3.0.0.0/24 *[OSPF/10] 00:21:12.0.0.0.0.0 1.3 1. metric 3000 > to 10.0 1.0 1.23.3.4 0x80000002 231 0x22 0x350b 36 Extern 192. 0 holddown.1.4 0x80000002 1118 0x22 0x211d 36 Extern 192.0 172.0 0x80000001 176 0x20 0x4710 28 Summary 172.0.0.0 1.168.0.0 10.0.

0.4 0x80000001 2576 0x22 0x1925 36 Extern 192.4 0x80000002 898 0x22 0xd2f 36 The routing table on vMX2 also looks very different with OSPF showing a single default route: [email protected]> show route protocol ospf inet. the OSPF database appears very different with all summary LSAs removed: [email protected]> run show ospf database OSPF database. the default-lsa option must also be included to tell the router to generate a default route.0.4 0x80000001 2576 0x22 0xd7bc 36 Extern 10.2.0.0.1 via ge-0/0/0. In this next scenario.1.0 1.4 1.0. * = Both 0.0.2.0.0.0. NSSA.0.5/32 *[OSPF/10] 00:22:51.0.0.0.0.0. the default-metric option needs to be included.0 1. or not so stubby areas.0.10.4 0x80000002 602 0x22 0x350b 36 Extern 192.1.233.1 1.0.0.3 1. 15 routes (13 active. Area 1 will be changed back to a stub area.0.0. Area 0. which in this case is vMX0: [edit] [email protected]# set protocols ospf area 1 stub no-summaries default-metric 100 After committing this change.0.5/32 *[OSPF/10] 11:08:23.0.0.2 0x80000008 7 0x20 0xfa03 60 Network 10.2.0 0x80000001 47 0x20 0x3eeb 32 OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern 10.0.1 via ge-0/0/0. were created to allow redistribution of another routing protocol into OSPF via a stub area. This is done by replacing type 5 LSAs with a type 7 LSA. With NSSAs.0 224.1.23. metric 1 MultiRecv As you witnessed with stub areas.1.0.2 1.0.0 224.0 1.3.168.0.4 0x80000002 1193 0x22 0xdd8 36 Extern 192.168.0.1 Type ID Adv Rtr Seq Age Opt Cksum Len Router 1.0. metric 1 MultiRecv Note that Area 1 can also be changed into a totally stubby area by adding the keyword no-summaries just before the default-metric option at the end of the previous command.0. 0 hidden) + = Active Route.0. - = Last Active.168.168. 55 . Chapter 4: Open Shortest Path First (OSPF) > to 10. metric 1100 > to 10. This change need only be applied to ABRs.0.0 1. 0 holddown.0.0 1. the ABR replaces the LSA type 4 with a default route.2 1.4 0x80000002 1785 0x22 0xbe18 36 Extern 172.0: 13 destinations.0.0.4 0x80000002 1489 0x22 0x211d 36 Extern 192.1.240. As with stub areas.0/0 *[OSPF/10] 00:05:58. Area 2 will be made into an NSSA.0 0x80000007 47 0x20 0x61c5 36 Router *1.

0 hidden) + = Active Route. 0 holddown. metric 1100 > to 10. metric 1100.0 10. 56 Day One: Routing the Internet Protocol Without it.0.5. * = Both 0.5.0.10.10.0/24 *[OSPF/10] 00:00:16.0 224.5. 0 hidden) + = Active Route. 0 holddown.1 via ge-0/0/1.0/24 *[OSPF/10] 00:00:16. the router will not add the default route to the routing table: [edit] [email protected]# set protocols ospf area 2 nssa default-lsa default-metric 100 [edit] [email protected]# set protocols ospf area 2 nssa Once committed. metric 4000 > to 10.0.0.0.0.1. the results are similar to totally stubby areas in that all OSPF routes external to the area are summarized into a single default route: [edit] [email protected]# set protocols ospf area 0.0.0.0.0 10. metric 1 MultiRecv If Area 2 is made into a not so stubby totally stubby area by adding the no-summaries option.1 via ge-0/0/1. metric 1 MultiRecv Just as important.0 10.0 224.1 via ge-0/0/1.0/24 *[OSPF/10] 00:00:16.5.4.2.5.0. metric 2000 > to 10. metric 3000 > to 10.5/32 *[OSPF/10] 01:17:58.5/32 *[OSPF/10] 01:16:06. however.0.5. * = Both 0. - = Last Active.0.0. metric 2000 > to 10. metric 4000 > to 10.5. 24 routes (21 active.0. - = Last Active.1 via ge-0/0/1.0.0.2 nssa no-summaries default-lsa defaultmetric 100 [email protected]> show route protocol ospf inet.0.3.1 via ge-0/0/1. is that Area 1 is still receiving details of routes learned via RIP – meaning the LSAs are being allowed out of Area 2: .0/0 *[OSPF/150] 00:00:16.0/24 *[OSPF/10] 00:00:16.0.2.0.0/24 *[OSPF/10] 00:00:16. tag 0 > to 10.0 10. 29 routes (24 active.0/0 *[OSPF/10] 00:00:07. a default route is injected into area 2 which can be seen by looking at the routing table on router vMX4: [email protected]> show route protocol ospf inet.0: 21 destinations.1 via ge-0/0/1.1 via ge-0/0/1.0 10.0.0: 24 destinations.

juniper.0 10.0 10.0. OSPF security is only used to authenticate OSPF neighbors.0.0 224.0/24 *[OSPF/10] 00:27:32.0.1 via ge-0/0/0.0.0/24 *[OSPF/10] 00:03:06.2.1 via ge-0/0/0.2. which is the method currently being used. * = Both 0.5/32 *[OSPF/10] 01:06:48.0: 19 destinations.4. html.0 172.3.7. metric 3000 > to 10.0 10.0/24 *[OSPF/10] 00:03:06.23.0/24 *[OSPF/10] 00:27:32.23.0 172.net/documentation/en_ US/junos14.0. In the topology used throughout this chapter.2/topics/topic-map/ospf-stub-and-not-so-stubby-areas. where the password sent is encrypted using a hashing algorithm.1 via ge-0/0/0. OSPF authentication is configured on a per interface basis.2.3.0/24 *[OSPF/10] 00:27:32.1 via ge-0/0/0. therefore it is completely possible to have a situation where the same OSPF domain routers in one subnet are authenticated using MD5 and in another subnet there is no authentication. metric 4000 > to 10.3 illustrates this scenario: between vMX0 and vMX2 there is no authentication. The third is MD5. - = Last Active.0.0. Chapter 4: Open Shortest Path First (OSPF) [email protected]> show route protocol ospf inet. metric 1 MultiRecv MORE? There’s lots of great information on stub and NSSAs within Juniper’s technical documentation: http://www.2. OSPF Security The purpose of OSPF security is to prevent unauthorized persons from attaching a rogue device to the network and injecting bad routing information into it.0.0. 0 holddown. 57 . 0 hidden) + = Active Route.0.0.0.0/0 *[OSPF/10] 00:27:32. What it does not do is encrypt the routing information exchanged between neighbors.1 via ge-0/0/0. metric 1100 > to 10. There are three types of authentication methods OSPF can use to authenticate its neighbors: The first is none. metric 3000 > to 10. metric 4000 > to 10. The second is simple-password. 22 routes (19 active.0.1 via ge-0/0/0.2.5.2. Figure 4. metric 2000 > to 10. which means the password is sent between neighbors using a plain-text password.

and finally. This is done with the following configuration: [edit] [email protected]# set protocols ospf area 2 interface ge-0/0/2. The interfaces connecting vMX1 and vMX4.3 OSPF Authentication Types Although using simple-passwords is allowed in the Junos OS.3. it is not recommended to use on a live network environment. Figure 4. do need to be enabled for simple password authentication. these OSPF authentication examples will be configured per Figure 4. 58 Day One: Routing the Internet Protocol between vMX0 and vMX1 OSPF MD5 authentication is being used. the interfaces connecting vMX1 and vMX4 are using a simple password to authenticate.0 authentication simplepassword secretpd . Configuring OSPF Security To keep this section simple. It’s been included here in the configuration examples so you can see how this differs from configuring MD5 authentication. however. As such. this option was only included to comply with the OSPF standard and for backwards compatibility with older devices where performance could be affected by hashing passwords. No changes need to be applied to the link connecting vMX0 and vMX2.

meaning they have passed the authentication checks. 59 .0] ‘authentication’ ospf password is longer than 8 characters error: configuration check-out failed If you use the now familiar show ospf neighbor command. then it would be obvious there is a problem with authentication. Chapter 4: Open Shortest Path First (OSPF) [edit] [email protected]# set protocols ospf area 2 interface ge-0/0/1. thereby risking losing connectivity. If the above configuration was attempted with the password secretpassword.0. you can use the show ospf overview command. The administrator can also specify the date and time when the new key should be used. the administrator can just create a new key number and new password. routers vMX0 and vMX1 will use key 0 with no start time.0. as you can see here with the possible completions: [edit] [email protected]# set protocols ospf area 0 interface ge-0/0/1. The configuration begins as it does for the simple password. you should see that the routers are still neighbors. This key number allows the administrator to assign multiple passwords to the interface (useful if an administrator wishes to change the passwords on the interfaces). the old passwords can be deleted. routers vMX0 and vMX1 need to be configured for MD5 authentication. The password of secretpassword will be used to illustrate that a longer password can be used: set protocols ospf area 0. Instead of deleting the old password and creating a new one. In this scenario. and this command is covered in the next section.0 authentication md5 0 ? Possible completions: key MD5 authentication key value start-time Start time for key transmission (YYYY-MM-DD. aside from changing the option from simple-password to md5. If the neighbors were showing as 2way. which enables a few more options for the administrator. In addition. after which the administrator needs to specify a key between 0 and 255.0.HH:MM) After this new key comes into effect.2 interface ge-0/0/2.0 authentication simplepassword secretpd There is one limitation to using simple password authentication and that is that the password must be eight characters or less.0. Next.0 authentication md5 0 key secretpassword The best method to confirm these routers are authenticating correctly is to use the show ospf neighbor command. the following error would appear during the commit: [edit] [email protected]# commit [edit protocols ospf area 0.0 interface ge/0/1.

168.7. the area type.0. how many neighbors the router has.0 up up inet 192.1. and as such the database needs updating and all routers in that area need to run the SPF algorithm once more. in which case the ID would become 172. AS boundary routers: 2 Neighbors Up (in full state): 2 Topology: default (ID 0) Prefix export count: 0 Full SPF runs: 20 SPF delay: 0.23. Another option would be to specify the ID manually. One is to use a loopback interface because the loopback interface address will have a higher priority than the physical interface addresses. will be used for the router ID. the authentication type if used. this ID is generated from the lowest IP address of all interfaces that are up. interface ge-0/0/0. SPF rapid runs: 3 Backup SPF: Not Needed This command can be very useful when performing diagnostics as it also shows the areas attached to the router. but also so when it appears in the database all other routers on the network know which subnets are associated with that ID. Should this interface go down. If an engineer creates an additional loopback interface when performing testing. No matter where the ID is sourced.7.1. and the LSA .0.0. then the interface with the second lowest IP address.1/24 ge-0/0/1.0 has the lowest IP address with 10.0. which is ge-0/0/2. There are alternatives. 60 Day One: Routing the Internet Protocol OSPF Router IDs Each router in the OSPF domain needs a unique router ID associated with it so it is identifiable to its neighbors. As an example.0.1/24 From the three interfaces.23. the current ID of the router can be found by running the show ospf overview command: [email protected]> show ospf overview Instance: master Router ID: 10.1 Route table index: 0 LSA refresh time: 50 minutes Area: 0.1.0 up up inet 172. the output generated by the show interfaces terse command on a router with three interfaces that are up is: show interfaces terse Interface Admin Link Proto Local Remote ge-0/0/0. The issue with this is that when an interface goes down the ID can change.1.1. SPF holddown: 5 sec.1/24 ge-0/0/2. then the same issue can arise. As mentioned earlier.200000 sec.0 up up inet 10.0 Stub type: Not Stub Authentication Type: None Area border routers: 0.0. which overrides the IDs from both the physical and loopback interfaces.0.

0.0. If this is attempted. Frame relay networks also have a timer called the Poll interval. which is how often the router will refresh the database with new LSAs to ensure the LSA database matches those on other routers in that area.0 It is also recommended to confirm that the neighbors see the change in the ID with the show ospf neighbors command: [edit] [email protected]# run show ospf neighbor Address Interface State ID Pri Dead 10.1’ address invalid for routerid error: configuration check-out failed [edit] [email protected]# run show ospf overview | match Router | match ID Router ID: 1.0.0.0 Full 1.0 Full 10. it cannot use an address that begins with a zero.0.4.0.0. Chapter 4: Open Shortest Path First (OSPF) refresh time.2 ge-0/0/2. meaning the traditional method of finding neighbors by using multicast will not work.2 128 33 10.4.0 Full 10.3.0.1 ge-0/0/1. then the following error will be displayed during a commit: [edit] [email protected]# commit [edit routing-options router-id] ‘router-id 0. otherwise they will appear to be stuck in ExStart in the neighbor table.0.0.0. OSPF utilizes timers similar to the way RIP does. the administrator needs to add the neighbor manually.0.0.0.2 ge-0/0/0.0 Once a valid ID has been entered. running the show command lists the new address: ospf overview [edit] [email protected]# run show ospf overview | match Router | match ID Router ID: 1.0.5. or 30 seconds for frame relay. The Hello timer determines how often routers send a hello packet out of the interface to other routers. because frame relay networks are typically non-broadcast.0 128 37 10. With frame relay networks.2 128 31 OSPF Timers To help make OSPF converge faster. The ID is set with the following command and the commit takes effect after the dead timer has reached 0: set routing-options router-id 1. The poll interval determines how often the router 61 . The default timer on Ethernet networks and serial links is set to 10 seconds.5. The time period needs to match on all routers on the subnet.0 If the ID is set manually.

0. if vMX1 did not receive a hello packet from vMX0 for 40 seconds by default. the neighborship is restored: [edit] [email protected]# set protocols ospf area 0. For example. timers are changed on a per interface basis. Configuring OSPF Timers Similar to authentication.0.0 interface ge-0/0/1. By default.0. The Dead interval is a period of time where the router has not received a hello packet from a neighbor and as such determines that the neighbor is down. This is set by default to one second and ideally should never be changed.0.0.0. the hello interval to 1 second and the LSA retransmission interval to 2 seconds: [edit] [email protected]# set protocols ospf area 0.0 retransmit-interval 2 [edit] [email protected]# set protocols ospf area 0. If the router does not receive a reply within a certain amount of time.0 hello-interval 1 [edit] [email protected]# set protocols ospf area 0.0. 62 Day One: Routing the Internet Protocol should send a message to the neighbor in order to form an adjacency.0 Full 1.4 128 36 After setting the timers of vMX0 to match vMX1.5.0 dead-interval 4 Unfortunately.0 interface ge-0/0/1. The dead timer is typically four times the hello timer and on frame relay networks the dead timer is by default 120 seconds.0. vMX0 was removed from the neighbor table of vMX1 because it did not respond within the dead timer of 4 seconds (the hello timer on vMX0 is still set to 10 seconds): [email protected]> show ospf neighbor Address Interface State ID Pri Dead 10. it expects to receive a reply from its neighbor stating it received the LSA. this is set to 120 seconds. then vMX1 would remove vMX0 from its neighbor table. This is known as the LSA retransmission interval and by default this is set to five seconds.0 interface ge-0/0/1.0 interface ge-0/0/1. the purpose of the Transit delay is to increase the age of a link state update packet as it’s sent out of an interface.0 retransmit-interval 2 . the router will resend the LSA.0.0.2 ge-0/0/2. after committing this configuration. When a router sends LSAs to its neighbors. The following commands set the dead timer on vMX1’s interface connected to vMX0 to 4 seconds. Finally.0.

Discontiguous OSPF Areas Occasionally a situation may arise where you have no choice but to connect a non-backbone OSPF area to an area other than Area 0.0 interface ge-0/0/1.0 Full 1.0. Should router vMX0 suddenly fail for whatever reason. Chapter 4: Open Shortest Path First (OSPF) [edit] [email protected]# set protocols ospf area 0.0.0.4 128 34 Notice how under the dead column the number is now 3 compared to 34 for the connection to vMX4.4 shows an example of what is known as a discontiguous area where Area 80 needs to cross Area 1 to reach Area 0.0. Figure 4.0.3. In this case it becomes necessary to break the OSPF Area 0 rule. Figure 4.2 ge-0/0/2.1 ge-0/0/1.0.0 dead-interval 4 And let’s verify neighbors: [email protected]> show ospf neighbor Address Interface State ID Pri Dead 10.4 OSPF Virtual Links 63 .0.5.0 Full 1. To do this an engineer can use what is known as a virtual link.0 128 3 10.0 interface ge-0/0/1. vMX1 would remove it from the neighbor table very quickly.0. such as in the case of an acquisition or merger.0 hello-interval 1 [edit] [email protected]# set protocols ospf area 0.0.0.

23.0/24 *[OSPF/10] 00:15:43.0.0.2.1 [edit] [email protected]# set protocols ospf area 0 virtual-link neighbor-id 1.0/24 *[OSPF/10] 00:01:11. 64 Day One: Routing the Internet Protocol With a virtual link a tunnel is created across the area that is between Area 0 and the new area that is cut off from Area 0. The final part of the command tells the router which area the tunnel transits: [edit] [email protected]# set protocols ospf area 0 virtual-link neighbor-id 1.5/32 *[OSPF/10] 05:22:11.1 Now.5.0.0.1 via ge-0/0/0. The routers inside Area 80 wouldn’t know they were crossing a tunnel.0.0/24 appears in the routing table.0 10.0. 26 routes (23 active.4. 0 hidden) + = Active Route.0. metric 1 MultiRecv To resolve this issue.0/24 *[OSPF/10] 00:01:11.0.0 10.5/32 *[OSPF/10] 05:34:02.0. metric 4 > to 10.0.1 transit-area 0. - = Last Active.2.0.0/24 *[OSPF/10] 00:01:11.2.0: 13 destinations. 15 routes (13 active.0.0.3. they are directly connected to Area 0.2.0 224.2.3. * = Both 10.1 via ge-0/0/0. - = Last Active.1 via ge-0/0/0.0.7. 0 holddown.1 via ge-0/0/0.0.0.0.4 the tunnel would cross Area 1.0.4. After neighbor-id the administrator is required to add the router ID of the ABR at the other end of the tunnel. for router vMX0. 0 hidden) + = Active Route. for example. and you look at the routing table on router vMX2.0 224. in Figure 4. metric 3 > to 10.3.0/24 *[OSPF/10] 00:03:52.0. the set protocols ospf area 0 virtual-link command is used in the routers vMX0 and vMX1. metric 1 MultiRecv .0 172. but no other routes are discovered: [email protected]> show route protocol ospf inet.1 via ge-0/0/0. If the routers are configured as in Figure 4. you would specify the ID of vMX1 and for vMX1 you would enter the ID for vMX0. and you should see all routes discovered as advertised via OSPF: [email protected]> show route protocol ospf inet. as far as they are aware.0/24 *[OSPF/10] 00:01:11. let’s look at the routing table on vMX2.0 172. but without the virtual link.0: 23 destinations.23.3. The configuration to allow this is placed on the ABRs of the area that is to be crossed.0. 0 holddown.0.0 transit-area 0.2. metric 3 > to 10. you would observe that vMX0’s interface in subnet 10.0.1 via ge-0/0/0. * = Both 10. metric 2 > to 10. metric 2 > to 10. metric 4 > to 10.0.

3/topics/concept/ ospf-overload-functionoverview.0 Full 1. meaning the neighbors will still receive the routes. overload mode is set.html The last OSPF feature before moving onto IS-IS is something called the OSPF overload function. for example. Once the command is added. then the overload is set until the configuration is removed. if the show ospf neighbors command were to be run. except that the metric will be set to 65535 or infinite. The first is when the administrator would like the router to receive routes.1 128 37 10.0. This interface is the virtual link between routers vMX0 and vMX1: [email protected]> show ospf neighbor Address Interface State ID Pri Dead 10.juniper.0.0.0.0. The command to enable overload is as follows. the router still advertises routes it has learned. an additional neighbor will appear in the list with the same ID as the ABR in area 0 but instead showing the outgoing interface as vl-1. but wants the router to remain up so it can be brought into service much sooner.0.3.1.2.0.2 128 36 10.0. The second situation is when the administrator is performing maintenance and doesn’t want the router to be used as a transit router.0. and as a result they will not be entered into their local routing tables. In this case. The default is 0.2 ge-0/0/1. when a router is being used for analysis of network traffic.0. and as such can no longer participate in normal routing on the network. The command that enables overload is added to the whole OSPF routing process. If no timeout option is set. There are two situations in which an administrator may want to use this function.0.3 ge-0/0/2.2 vl-1.0 Full 1. The timeout period can be set from 60 seconds to 1800 seconds. http://www. This feature is something you probably wouldn’t run too often.3. the timeout is set to 180 seconds. which means in 3 minutes the router will return to normal operation: set protocols ospf overload timeout 180 65 .0. but not to participate in routing itself. It makes the router appear that it is overloaded to other routers on the network.1 Full 1.1 0 35 OSPF Overload Function OSPF overload function: If the time elapsed after the OSPF instance is enabled is less than the specified timeout. It is not possible to set this command for a particular area only. Chapter 4: Open Shortest Path First (OSPF) Finally.0. but it can be quite useful. but will mark them as inaccessible. The command also allows the administrator to specify a time out period.net/ documentation/en_US/ junos12.

juniper. Also. follow these examples in your own lab if you can. It greatly aids in the learning process.net/techpubs/en_US/junos14.html. . if you are interested. 66 Day One: Routing the Internet Protocol Summary OSPF is a popular protocol amongst network engineers. further information can be found at the Juniper TechLibrary and readers might start at this OSPF pathway page: https://www. The key to OSPF’s scalability lies with its use of areas. Understanding the use of areas will become useful during the next chapter when you look at a protocol that can scale to a size beyond the capabilities of OSPF. This chapter shared some useful information about the Junos OS and OSPF. however. The scalability of this protocol means a network administrator may never need to migrate to another protocol. The only downside is that it is more complex to implement compared to RIP or static routes.1/ information-products/pathway-pages/config-guide-routing/configguide-ospf.

the one major difference between IS-IS and other routing protocols is that IS-IS does not use IP as the transport protocol. usually to the loopback interface. each interface is given an address in a different subnet. The address in OSI is made up of several components. and instead uses OSI. even more so than OSPF. the OSI address is made up of four parts: . and not knowing which to support service providers had both protocols running on their networks. a company called Digital Equipment Corporation (DEC).Chapter 5 Intermediate System to Intermediate System (IS-IS) Like OSPF. These protocols were in direct competition with each other. known as Protocol Data Units (PDUs) are comprised of Type Length Value (TLVs). called OSI. With IP. So. However. IP obviously became the dominant protocol. although it was discovered that OSI did have a useful feature in that the packets it sends across the network. IS-IS has a very different history than OSPF and that is because it was never designed to advertise IP subnets. So any router that uses IS-IS to advertise routes must have OSI enabled. These TLVs can be used to exchange routing information. IS-IS is also a link state routing protocol. but unlike IP. usually IP. rather like an IP address is divided into the network address and host address.org/ wiki/Internet_Protocol Back in the early 1990s. the IETF developed another protocol called the Internet Protocol. while with OSI the router as a whole is given a single address. It uses the same SPF algorithm and is scalable. Internet Protocol: The principal communications protocol in the Internet protocol suite for relaying datagrams across network boundaries: https://en. At the same time. or IP. and an address configured. and was in fact designed for another routed protocol. but OSI was very easily adapted to advertise IPv6 routing information. developed and standardized the OSI protocol. which is another major difference compared to IP.wikipedia.

68 Day One: Routing the Internet Protocol 1. 3. Routers in the same level will use the same area ID.00001. this will always be set as 49.2 IS-IS Topology .1 OSI Address Configuring IS-IS Figure 5. For routers. Figure 5. Levels will be explained in the following Configuring IS-IS section. Each router must have a unique number. 2. Area ID: This part is similar to IPv4 subnet addresses. AFI: Authority and Format Indicator. Figure 5. Figure 5. N-selector: Always set as 00. This cannot be all 0s but can be hexadecimal. This identifies the type of device this address is assigned to.0001.1 shows an example of an OSI address where the address has been assigned to a router in Area 1 with an address of 0001. System ID: Similar to an IPv4 host address.2 shows the topology of the network that will be used in this configuration example. 4.

00 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/2 unit 0 family iso Now vMX5 is configured as follows: set interfaces lo0 unit 0 family inet address 192.1.168.4/24 set interfaces lo0 unit 0 family iso address 49. all routers have been given an address and OSI is enabled on all interfaces.168.0 and the /32 IP address will be assigned to this interface.0001.0001.1.0001.0001.0001.1/32 set interfaces lo0 unit 0 family iso address 49. therefore these too are set as passive: 69 . Router vMX2’s interface ge-0/0/0. IS-IS neighborships are formed between routers vMX3. vMX2.168.0004.0002.0 on router vMX3 are part of the RIP domain.0001.00 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/2 unit 0 family iso Now. so let’s tell IS-IS which interfaces to advertise and which not to send hello PDUs out of. the passive option tells IS-IS not to send hello PDUs out of that interface.1.0001.0 passive set protocols isis interface ge-0/0/1. router vMX3 is given a different /32 address and a different OSI address: set interfaces lo0 unit 0 family inet address 192. however the subnet between routers vMX3 and vMX6 is part of the RIP domain that will later be redistributed into IS-IS.0 set protocols isis interface lo0.3/24 set interfaces lo0 unit 0 family iso address 49.0 set protocols isis interface ge-0/0/2.0 and ge-0/0/2. In addition.168.0001. vMX5.0001. Chapter 5: Intermediate System to Intermediate System (IS-IS) As shown in Figure 5.2. The first step is to assign an OSI address to each router.00 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/2 unit 0 family iso Next.00 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/1 unit 0 family iso And vMX6 is given the OSI System ID of 0001.0001. and vMX6. Similar to RIP and OSPF.0001.0003.1.0001. Each router is in area 0001 and the address assigned to the interface is loopback 0.0001.0 is part of the OSPF domain. The first router to be configured is vMX2: set interfaces lo0 unit 0 family inet address 192. OSI needs to be enabled on each interface that sends PDUs.2/32 set interfaces lo0 unit 0 family iso address 49. therefore set this as passive: set protocols isis interface ge-0/0/0.0004: set interfaces lo0 unit 0 family inet address 192.0 Interfaces ge-0/0/0. therefore these interfaces will not send hello PDUs.0001.

2 via ge-0/0/1.0/24 *[IS-IS/15] 00:06:00.1. has two interfaces in the RIP domain.0 Router vMX5 only has two interfaces and it is totally in the IS-IS domain.168.0 passive set protocols isis interface ge-0/0/1. metric 20 > to 10.0 passive set protocols isis interface lo0.168.2/32 *[IS-IS/15] 00:02:57.1.0 VMX5 2 Up 8 0:5:86:71:ed:1 By using the show route protocol IS-IS command.0.2.10. you need to check whether the routers are negotiating successfully.1. 70 Day One: Routing the Internet Protocol set protocols isis interface ge-0/0/0. metric 10 > to 10. 1 routes (1 active.168.0 set protocols isis interface ge-0/0/2.1.2 via ge-0/0/2. 0 hidden) + = Active Route. Therefore it has no passive interfaces: set protocols isis interface ge-0/0/0. metric 20 > to 10. Whereas OSPF calls routers neighbors that have negotiated successfully.0 VMX5 1 Up 7 0:5:86:71:ed:1 ge-0/0/2. therefore these are set as passive: set protocols isis interface ge-0/0/0.0 Finally.0/24 *[IS-IS/15] 00:00:05. metric 10 > to 10.3.0/24 *[IS-IS/15] 00:00:05. Here is the output from when this command was run on router vMX2 prior to it forming an adjacency with vMX3: [email protected]> show isis adjacency Interface System L State Hold (secs) SNPA ge-0/0/2. 0 hidden) .10.0 172. metric 30 > to 10.1.4/32 *[IS-IS/15] 00:06:00.10.0 passive set protocols isis interface ge-0/0/1.10. router vMX6.2.168. like vMX3.3/32 *[IS-IS/15] 00:06:00.10.1. 0 holddown.0 192.0 and ge-0/0/1.0/24 *[IS-IS/15] 00:06:00.2 via ge-0/0/2.10.23.1.2 via ge-0/0/1.0/24 *[IS-IS/15] 00:02:57.0 172.10. 0 holddown.0 set protocols isis interface ge-0/0/1.0 iso. metric 10 > to 10.0 192.1.0 192.2 via ge-0/0/1.23.7. metric 20 > to 10. you can see that the routing table has been populated with routes learned through IS-IS: [email protected]> show route protocol isis inet.0: 1 destinations.0 set protocols isis interface lo0.0 set protocols isis interface lo0. ge-0/0/0. - = Last Active.3. * = Both 10.1.0 172.2 via ge-0/0/1.2 via ge-0/0/2.10.0 passive set protocols isis interface ge-0/0/2.0 192.2.2.2 via ge-0/0/2.0: 23 destinations.23.0 Once the configuration has been committed.10. in IS-IS they are known as adjacencies and use show IS-IS adjacency command to show what routers have formed adjacencies. metric 20 > to 10. 27 routes (23 active.

IS-IS can scale to a considerable size.7. and as shown below. Level 2 is the backbone area.2: icmp_seq=1 ttl=63 time=4. Any routers that are designated as level 1 are non-backbone area routers. purely to illustrate that these are areas separate unto themselves.533/8.23. Figure 5. Levels are assigned on a per-interface basis and any router that has one interface set as Level 2.23.23. all is fine: [email protected]> ping 172.2 PING 172. With IS-IS.7.043/14. and another set as Level 1. similar to OSPF.2 ping statistics --3 packets transmitted.671 ms IS-IS Areas Like OSPF. Chapter 5: Intermediate System to Intermediate System (IS-IS) Then best practice is to send a simple ping from router vMX3 to one of vMX6’s interfaces. Areas X. and Z. similar to OSPF area 0.3 illustrates an example IS-IS domain with multiple routers in Level 2 and three ABRs with Level 1 routers attached.0.644/4.533 ms ^C --- 172.644 ms 64 bytes from 172. is an ABR.2): 56 data bytes 64 bytes from 172.2: icmp_seq=2 ttl=63 time=4.23. a size beyond that of OSPF and some say a size that can rival BGP. Figure 5.23.951 ms 64 bytes from 172.0. 0% packet loss round-trip min/avg/max/stddev = 4. Y. IS-IS areas are slightly different from OSPF in that IS-IS uses levels to designate which areas are the backbone and which are not backbone.0. 3 packets received.7.23.7.7.2: icmp_seq=0 ttl=63 time=14. Level 2 areas should be contiguous.2 (172. It achieves this scalability in the same way via the use of areas.3 An Example of IS-IS Levels 71 .7. there are two levels. A reply will prove connectivity is working as expected.23.7.

both Levels 1 and 2 are enabled on all interfaces that form an adjacency. you need to disable Level 2. to set an interface as part of Level 2. and routers vMX2 and vMX5 will be ABRs. one of its interfaces is set with Level 2 disabled and the other is set with level 1 disabled: set protocols isis interface ge-0/0/0. Router vMX2 is an ABR and interface ge-0/0/1.0 level 1 disable Router vMX3 only has one interface forming an adjacency and it is a Level 1 interface: set protocols isis interface ge-0/0/1. you need to disable Level 1.0 will be a Level 2 interface. Figure 5. to set an interface to be part of Level 1.0 level 2 disable set protocols isis interface ge-0/0/2. instead of enabling Level 2. The commands to configure the router this way are: set protocols isis interface ge-0/0/1.4 The Configuration Topology for IS-IS By default.0 level 2 disable . Router vMX3 is a Level 1 router in Area 2.0 level 1 disable Router vMX6 is similar to vMX3 in that it too only has one interface forming an adjacency so Level 2 is disabled: set protocols isis interface ge-0/0/2.0 will be a Level 1 interface and interface ge-0/0/2. Router vMX6 is a Level 1 router in Area 3. Therefore. And likewise.0 level 2 disable As router vMX5 is an ABR. 72 Day One: Routing the Internet Protocol Configuring IS-IS Areas Figure 5.4 shows how the routers will be configured.0 level 2 disable set protocols isis interface ge-0/0/1.

0001.0001.0003. if router vMX6 pings router vMX3’s ge-0/0/0.0001.00 Router vMX is wholly within Area 2: set interfaces lo0 unit 0 family iso address 49. which confuses IS-IS.00 Once the configuration has been committed. 0 holddown.3. Areas help make IS-IS scalable by summarizing all routes going into an area as a single default route.0 This issue was caused because the areas in the addresses were not changed.0.1.0002. router vMX6 is completely in Area 3: set interfaces lo0 unit 0 family iso address 49.10.0001. * = Both 0.0001.0: 2 destinations.0002.0001.168. the addresses need to be changed. - = Last Active. metric 10 > to 10.168. Chapter 5: Intermediate System to Intermediate System (IS-IS) Now that the configuration has been committed on all routers.1 via ge-0/0/2. the simplest but most reliable test is to send a ping and then look at the routing table.0002. 0 holddown.0003.0: 14 destinations. This is adjoining area 3: set interfaces lo0 unit 0 family iso address 49.0 iso. router vMX6 should receive a successful reply: 73 .0004. Router vMX2 is adjoining Area 2: set interfaces lo0 unit 0 family iso address 49.0 interface. 0 holddown. 0 hidden) + = Active Route. The ABRs need their areas to be set to the Level 1 area they are adjoining. IS-IS sees that there are two Level 1 areas but they all have the same area in the address. 15 routes (13 active.3. metric 10 > to 10. To resolve this issue.10.1 via ge-0/0/2.0001.0. 0 hidden) Now. * = Both 192. - = Last Active.0: 13 destinations.0001.00 The second ABR is router vMX5. 0 hidden) + = Active Route.3/32 *[IS-IS/15] 00:06:53. And as you can see.0001. 16 routes (14 active.1.00 Finally. there is an issue.3/32 *[IS-IS/15] 00:55:15.10. metric 10 > to 10.1 via ge-0/0/2. The routers inside the area only need to know that to reach a subnet that’s not listed in the routing table they just need to forward their packet to the ABR who has a complete routing table: [email protected]> show route protocol isis inet.0003. the routing table should now have one more route and that is a default route. 2 routes (2 active.0/0 *[IS-IS/15] 00:02:28.0 192.3. Router vMX6 can only see one route coming from router vMX5: [email protected]> show route protocol isis inet.

3. but also adds the option to use SHA hashing.905 ms 64 bytes from 172. Area 2. to show what effect this has on the adjacency: set protocols isis interface ge-0/0/1.1: icmp_seq=1 ttl=62 time=74.1): 56 data bytes 64 bytes from 172.994 ms IS-IS Security Hello PDUs: Delivered as a unit among peer entities of a network and that may contain control information.3. 0% packet loss round-trip min/avg/max/stddev = 7. Configuring IS-IS Security To enable plain text and MD5 authentication.1: icmp_seq=2 ttl=62 time=136.23.1: icmp_seq=3 ttl=62 time=7.23.296/154.23.1 (172.1: icmp_seq=0 ttl=62 time=154.905/57. or user data. the password used for authentication can be 255 characters in length and as long as you put the password in quotation marks. then the router simply won’t form an adjacency with it.wikipedia. If the adjacent router doesn’t send a correctly authenticated hello. With IS-IS. the hello-authentication-type option is used after specifying the relevant level on which you wish to enable authentication. such as address information.23. with the password set to THIS-ISAPASSWORD.23.0 VMX5 2 Up 21 0:5:86:71:73:1 .0 level 1 hello-authentication-key THISISAPASSWORD set protocols isis interface ge-0/0/1.3.3. 74 Day One: Routing the Internet Protocol [email protected]> ping 172. the password can even contain spaces.0 level 1 hello-authentication-type md5 Now run the show IS-IS adjacency command.23. The first router to be configured is vMX2 and vMX3 will be left without authentication.org/ wiki/Protocol_data_unit Similar to RIP and OSPF. Like RIP and OSPF. temporarily.3. and you should see from the output that the state of router vMX3 is Down but there is no reason why: [email protected]# run show isis adjacency Interface System L State Hold (secs) SNPA ge-0/0/1.3. IS-IS only enables security on the hello PDUs as opposed to every advertisement. too. IS-IS can use a plain text password and MD5 hashing to authenticate.3. 4 packets received.078 ms ^C --- 172.593 ms 64 bytes from 172. In this case.607 ms 64 bytes from 172.3. MD5 authentication is used in the Level 1.078/93.23.23. https://en. an IS-IS administrator can prevent unauthorized persons from forming an adjacency with an IS-IS router by enabling security.0 VMX3 1 Down 0 0:5:86:71:17:1 ge-0/0/2.1 PING 172.1 ping statistics --4 packets transmitted.

2. the latter being a more secure method. however it is not possible to use plain text. the adjacency is restored: set protocols isis interface ge-0/0/1. however. IPv6. Key 1 is set to start at 16:00 on June 10th 2015 and key 2 begins on September 2nd 2015 at midnight: set security authentication-key-chains key-chain ISIS-KEY-CHAIN key 1 secret THISISSECRET set security authentication-key-chains key-chain ISIS-KEY-CHAIN key 1 start-time 2015-0610. Last transition: 00:00:35 ago Circuit type: 1. two key chains will be configured: key 1 uses MD5 with the password set as “THIS-ISSECRET. in that the administrator can configure options such as setting different authentication keys and then setting the date when that key is valid. thereby allowing the administrator to migrate to new keys on a regular basis without causing any downtime. Speaks: IP. IS-IS has an option for both MD5 and SHA authentication. SHA authentication cannot be enabled by using the hello-authentication-type command and instead needs to be enabled with a key-chain. State: Down.10.2 Transition log: When State Event Down reason Thu Jun 11 11:43:40 Up Seenself Thu Jun 11 11:44:27 Down Error Bad Hello So once the same commands are added to vMX3.00:00 set security authentication-key-chains key-chain ISIS-KEY-CHAIN key 2 algorithm hmac-sha-1 set security authentication-key-chains key-chain ISIS-KEY-CHAIN key 2 options isisenhanced 75 . Chapter 5: Intermediate System to Intermediate System (IS-IS) If the extensive option is added to the end of the command.02.16:00 set security authentication-key-chains key-chain ISIS-KEY-CHAIN key 1 algorithm md5 set security authentication-key-chains key-chain ISIS-KEYCHAIN key 2 secret THISISSECRETTOO set security authentication-key-chains key-chain ISIS-KEY-CHAIN key 2 start-time 2015-92. Level: 1. Expires in 0 secs Priority: 64.” and key 2 uses SHA and the password is “THISISSECRETTOO”. Up/Down transitions: 2. Key chains have an advantage over just setting the adjacency’s type.0 level 1 hello-authentication-key THISISAPASSWORD set protocols isis interface ge-0/0/1.0. In this next scenario.0 level 1 hello-authentication-type md5 As mentioned earlier. then you can clearly see that the reason for the down adjacency is because of a bad Hello. The hello is bad because it has no authentication and that is not what vMX2 expects: [email protected]# run show isis adjacency VMX3 extensive VMX3 Interface: ge-0/0/1. IP addresses: 10. It is still possible to use MD5 authentication from a key chain. MAC address: 0:5:86:71:17:1 Topologies: Unicast Restart capable: Yes. Adjacency advertisement: Advertise LAN id: VMX2.

0 level 2 hello-authentication-key-chain ISIS-KEYCHAIN After committing the configuration. metric 20 > to 10.23.0 192.2.3.10. 0 holddown. IS-IS can use a reference bandwidth as the metric divided by the speed of the interface.10.2. the isis-enhanced option must be enabled. IS-IS does not use a reference bandwidth and instead gives each interface a metric of 10.10.2 via ge-0/0/2.0/24 *[IS-IS/15] 00:00:05.0: set protocols isis interface ge-0/0/1.1.0/24 *[IS-IS/15] 00:00:05.10. metric 10 > to 10. 27 routes (22 active.168.1. metric 20 > to 10. 76 Day One: Routing the Internet Protocol NOTE If SHA authentication is to be used.2.10.2 via ge-0/0/1.3.0 VMX6 1 Up 6 0:5:86:71:98:2 ge-0/0/1. By running the show route protocol IS-IS command.0 VMX2 2 Up 6 0:5:86:71:9a:2 IS-IS Reference Bandwidth Like OSPF.2 via ge-0/0/1.0: set protocols isis interface ge-0/0/2.0 172.2 via ge-0/0/1. too.0 .1.0: 22 destinations. the Junos OS will not allow you to commit the configuration and will warn you. metric 30 > to 10.23.0 192.2 via ge-0/0/1. authentication is enabled on the Level 2 backbone between routers vMX2 and vMX5. This means that all routes in the routing table will show a metric of 10.0/24 *[IS-IS/18] 00:06:00. metric 10 > to 10.1.2 via ge-0/0/2. 20.0 172.2/32 *[IS-IS/15] 00:02:57. Router vMX2’s Level 2 interface is ge-0/0/2. If it isn’t enabled.23. 0 hidden) + = Active Route. by default. metric 20 > to 10. - = Last Active.0/24 *[IS-IS/18] 00:06:00. Unlike OSPF.0/24 *[IS-IS/15] 00:02:57. you can see the metrics: [email protected]> show route protocol isis inet. All that remains to be done is to apply these keys to the relevant interfaces.1. * = Both 10.10. the adjacency should be checked to prove the routers are authenticating each other correctly: [email protected]# run show isis adjacency brief Interface System L State Hold (secs) SNPA ge-0/0/0. 30 and so on depending on how many hops away the subnet is.0 level 2 hello-authentication-key-chain ISIS-KEYCHAIN And router vMX5’s Level 2 interface is ge-0/0/1.0 172. leaving the Level 1 authentication in place between vMX2 and vMX3 (just to prove that both authentication types can be used on the same router at the same time).168.7. In this scenario.2.10.

0 192.0/24 *[IS-IS/15] 00:00:35.2 via ge-0/0/2. metric 126 > to 10.0 172. using hops to determine the best route.168.2 via ge-0/0/1.0 In reality.1. 77 . the metric increased to 126: [email protected]> show route protocol isis inet.3.23.7.10.1.168.2 via ge-0/0/2.10. like this: set reference-bandwidth 100g Once this setting has been added and committed to all routers.3. an administrator can configure a hello-interval.2 via ge-0/0/2.0 192.10.0 192.1.10.10.0: 22 destinations. metric 126 > to 10.1. for example.168.2.000 seconds. metric 63 > to 10.10. * = Both 10. metric 126 > to 10.4/32 *[IS-IS/18] 00:00:34.2 via ge-0/0/1.0/24 *[IS-IS/18] 00:00:35.0 192.1.0/24 *[IS-IS/15] 00:00:29.3.0 172.3/32 *[IS-IS/18] 00:00:35.1.0/24 *[IS-IS/15] 00:00:29. The default setting is 3 seconds.10.10. before the reference bandwidth was added the route to subnet 10. it is better to set a reference bandwidth.2 via ge-0/0/2.1. the reference bandwidth is set to 100Gb/s. To determine how often a hello PDU is sent out of the configured interfaces.10.1. this default setting makes IS-IS’s behavior similar to that of RIP.168. metric 10 > to 10. metric 63 > to 10.23. There are two timers of note that can assist with this. metric 63 > to 10.1. metric 126 > to 10.4/32 *[IS-IS/18] 00:06:00.0/24 had a metric of 20.2 via ge-0/0/2. the metrics in the routing table should look bigger. The reference-bandwidth option needs to be set on all routers in the IS-IS domain and should ideally be set to a higher interface speed than is currently running on the network to allow for future proofing.0 172.2 via ge-0/0/1.23.1.2 via ge-0/0/2. 27 routes (22 active.0 IS-IS Timers Like OSPF and RIP.2/32 *[IS-IS/15] 00:00:35.1.168.0 192.10. - = Last Active. Instead of using the default behavior.2. 0 holddown.2 via ge-0/0/1.1. In this instance. 0 hidden) + = Active Route. Once the reference bandwidth was added. metric 126 > to 10.10. This setting can be set from 1 to 20.2.3/32 *[IS-IS/18] 00:06:00.10.1. metric 20 > to 10.0/24 *[IS-IS/18] 00:00:34.2.168. IS-IS also allows an administrator to adjust the timers that help IS-IS decide when a router has lost an adjacency. Chapter 5: Intermediate System to Intermediate System (IS-IS) 192.

Day One: Routing the Internet Protocol

 The second timer is the hold-time option, which determines how
long the router should wait after not receiving a hello before it
declares the adjacent router down. This can be set from 3 to
65,535 seconds and has a default setting of 9.
Interestingly, if both the hold time and hello interval timers are set to 1,
then the hello PDUs are sent every 333 milliseconds allowing for much
faster route removal and an alternative route being found.

Configuring IS-IS Timers
Before changing the timers on your production networks, it’s a good
idea to remember that this change is made at a time of day when any
potential outage won’t affect anyone.
To check what the timers are currently set to, use the show IS-IS
interface command along with the extensive option. In the following example, the command was run on router vMX2 and the output
shows that the hello interval is set to 3.000 s and the hold time is 9 s.
This command also shows that level 1 on this interface is disabled:
[email protected]# run show isis interface ge-0/0/2.0 extensive
IS-IS interface database:
ge-0/0/2.0
Index: 332, State: 0x6, Circuit id: 0x3, Circuit type: 2
LSP interval: 100 ms, CSNP interval: 10 s, Loose Hello padding
Adjacency advertisement: Advertise
Level 1
Adjacencies: 0, Priority: 64, Metric: 63
Disabled
Level 2
Adjacencies: 1, Priority: 64, Metric: 63

Hello Interval: 3.000 s, Hold Time: 9 s
Designated Router: VMX2.03 (us)

In this next scenario, the level 2 interfaces are set with a sub-second
hello interval. The first router is vMX2:
set protocols isis interface ge-0/0/2.0 level 2 hello-interval 1
set protocols isis interface ge-0/0/2.0 level 2 hold-time 1

Then the same commands are set on router vMX5:
set protocols isis interface ge-0/0/1.0 level 2 hello-interval 1
set protocols isis interface ge-0/0/1.0 level 2 hold-time 1

By running the show IS-IS interface command again, you can see
that the hello interval is now 0.333 s:
[email protected]# run show isis interface ge-0/0/2.0 extensive
IS-IS interface database:
ge-0/0/2.0
Index: 332, State: 0x6, Circuit id: 0x3, Circuit type: 2
LSP interval: 100 ms, CSNP interval: 10 s, Loose Hello padding

Chapter 5: Intermediate System to Intermediate System (IS-IS)

Adjacency advertisement: Advertise
Level 1
Adjacencies: 0, Priority: 64, Metric: 63
Disabled
Level 2
Adjacencies: 1, Priority: 64, Metric: 63

Hello Interval: 0.333 s, Hold Time: 1 s
Designated Router: VMX2.03 (us)

Summary
Typically, IS-IS is used by service providers and not in corporate LANs.
Its sheer scalability and faster convergence meet the demands of this
type of network. There is of course no reason why IS-IS can’t be used
by a company and for companies with many hundreds of subnets, IS-IS
is a better choice. Some say IS-IS can scale to a size that rivals BGP
whereas OSPF can never scale to that level.
After reading this chapter you should have a much better understanding of the alternative protocol to OSPF whilst reaffirming your understanding of areas. This may also help you later in your career if you
find yourself working for a service provider.
This brings us to the end of the last interior gateway protocol (IGP)
covered in this book. The next protocol, BGP, which is discussed in
Chapter 7, is considered an exterior gateway protocol (EGP).
But before moving to BGP you need to look at how protocols can share
routes with each other by a method called redistribution and this is the
subject of the next chapter, Chapter 6. Here, both IS-IS and OSPF are
configured so they are both operating in a single network.

Day One: Routing the Internet Protocol

Chapter 6 Redistributing Route Information In an ideal world.1 illustrates this redistribution scenario. at least until the organizations can agree on a standard protocol. who is using OSPF. IT management decides to join the networks of the two companies by using a temporary serial link until a more permanent MPLS solution can be arranged. decides to acquire EMCA. or if a large company acquires a smaller company and the two entities use different protocols? There needs to be a way of sharing routing information between these organizations. In mergers it is often just a matter of time until this occurs. Once the acquisition is complete. The choice of protocol is usually based on such requirements as scalability or the experience of the administrators when the network was first built. Figure 6. But what happens if two companies merge. a corporate network would be running a single routing protocol. Let us imagine for a moment that ACME. a corporation running IS-IS. once management and personnel get settled. . The method used to merge networks is called redistribution.

and to 2.2. 82 Day One: Routing the Internet Protocol Figure 6. G. Router 2 sees two possible routes . Figure 6. and Router 3 would do the same. it is also possible to inadvertently cause a routing loop while performing route redistribution. and H. through 4. Routing Loops Chapter 1 demonstrated how a routing loop can be caused by adding default static routes on two devices opposing each other. Similarly. E. If Router 5 wished to send a packer to Router 1’s loopback interface. the routing loop would be caused by the administrative distances of each protocol: RIP and OSPF. it would look in its routing table and see that Router 3 is the next hop. which would then get back to Routers 2 and 3. Once the packet gets to Router 2. As the administrative distance of OSPF is lower than that of RIP. These advertisements would be sent to Routers 4 and 5. but router A certainly can’t ping router G. In Figure 6. Router 3 receives the packet and sees two possible routes. Routers C and D can also ping each other across the serial link. Assuming this was successful.1 Redistribution Example In this case. if redistribution were enabled. and C can communicate without issue. routers A. however.2 shows an example of a network where. F. the first being to Router 2 and the second is back via Router 5. In this case. it could cause a routing loop. Router 2 would advertise the loopback interface from Router 1 into OSPF. as can routers D. B. The best solution in this case would be to enable IS-IS on router C’s serial interface and then tell it to redistribute IS-IS into OSPF and OSPF into IS-IS. Router 3 decides that the route via Router 5 is the best. so forwards the packet accordingly. all routers would have complete visibility of both LANs.

The first is to tag the advertisement before redistributing it and tell the other ASBR to ignore any advertisements that carry that tag.3 Traceroute Routing Loop There are two ways to correct this issue. 150. Chapter 6: Redistributing Route Information Figure 6. therefore by making the AD for routes OSPF had learned from RIP. The other method is to tell OSPF to use a higher administrative distance for routes learned from another routing protocol. The screen capture of a traceroute in Figure 6. it sends the packet back to Router 4.3 shows the issue redistribution has caused – the packet goes round and round the network until the TTL expires: Figure 6. the AD for RIP is 100. 83 .2 Redistributing RIP Into OSPF also. and because the administrative distance of OSPF is less than that of RIP. For example. and the AD for OSPF is 10. this would prevent the routing loop.

7.2 via ge-0/0/1.0.0/24 *[OSPF/10] 00:07:38. Redistribution Between OSPF and RIP In order to redistribute between routing protocols in the Junos OS. or external routes.0.0.2 via ge-0/0/1.0/24 and 172. like this. use the following configurations.0/24 should be seen as these are advertised from vMX4 through OSPF: [email protected]> show route protocol ospf inet. 0 holddown.0. a policy statement must be created to tell the OS which routes should be exported from one protocol to another. By setting the ADs for external routes by default.1. metric 3000 > to 10.3.3 via ge-0/0/2.3.2. whereas RIP cannot. metric 1 MultiRecv CAUTION It is important to remember the limitations of RIP.0/24 *[OSPF/10] 00:07:44. IS-IS will set an AD of 160 to Level 1 external routes.0/24 *[OSPF/10] 00:00:08.3.0/24 *[OSPF/10] 00:00:08.10.0. devices running the Junos OS should in theory never suffer from routing loops caused by route redistribution. and an AD of 165 to Level 2 external routes.10.1. In order to create the policy statement to tell OSPF to advertise routes received from RIP.0 172.0 10. OSPF can scale to a large number of subnets. If the number of subnets advertised by OSPF is excessive then you should look either at summarizing the routes or migrate RIP to OSPF without performing any redistribution. OSPF is redistributed into RIP and RIP is redistributed into OSPF.0.0.3 via ge-0/0/2. - = Last Active. * = Both 10.0 10.5/32 *[OSPF/10] 00:56:28.0. RIP cannot distinguish between internal or external routes. metric 2000 > to 10.2 via ge-0/0/1. metric 2000 > to 10. metric 2000 > to 10.0/24 *[OSPF/10] 00:07:44.7. metric 2000 > to 10.0. 0 hidden) + = Active Route.0 224.0. the policy statement will be given the name RIP-TO-OSPF: .23. therefore it has the single AD of 100.23. Subnets 172.0/24 *[OSPF/10] 00:07:38. The aim of this exercise is to allow router vMX0 to be able to ping a router vMX3’s interface in subnet 172.23.4. Let’s run the show route protocol ospf command on router vMX0.0 172.3.0: 17 destinations.3.0 10. 19 routes (17 active. 84 Day One: Routing the Internet Protocol The default behavior in the Junos OS is to set an administrative distance (AD) of 150 to routes OSPF has redistributed.3.2. In this instance. metric 3000 > to 10.23.2 via ge-0/0/1.0. In the following example.23.2.5.

10. the ping should fail: [email protected]> ping 10. 0% packet loss round-trip min/avg/max/stddev = 3. 4 packets received.23.1.23.23.1.1 PING 10.1 (172. the policy statement needs to be added under the OSPF configuration: set protocols ospf export RIP-TO-OSPF Once the configuration has been committed. 0 packets received. 0 holddown.0: 24 destinations.524 ms 64 bytes from 172.0 on router vMX3: [email protected]> ping 172.0/24 *[OSPF/150] 00:00:12.1: icmp_seq=0 ttl=62 time=23.1.1: icmp_seq=1 ttl=62 time=4.1. a policy statement was created in order to tell RIP which subnets would be exported.1. tag 0 > to 10. - = Last Active.1. 27 routes (24 active.23.23.1. In this case the ASBR is router vMX2.0 on router vMX5.23.23.23.1 ping statistics --4 packets transmitted.3.1.3.1.3.157 ms 64 bytes from 172.1): 56 data bytes 64 bytes from 172.0.23.1.10. * = Both 172. 0 hidden) + = Active Route.10.0/24 in its routing table.1.0 And vMX0 should now also be able to ping interface ge-0/0/2.167 ms Redistribution Between OSPF and IS-IS Redistribution between OSPF and IS-IS is similar to redistribution between OSPF and RIP.157/8.3.387 ms 64 bytes from 172. router vMX0 should be able to see the subnet 172. where a policy statement must be created and assigned to the protocol.1 (10.1 PING 172. it’s possible just to tell RIP to include OSPF routes.016/23. If router vMX0 attempts to ping interface ge-0/0/0.996 ms ^C --- 172. too: set policy-options policy-statement RIP term 1 from protocol ospf Finally.1: icmp_seq=3 ttl=62 time=3. As this statement already exists. Let’s check: [email protected]> show route protocol ospf 172.1): 56 data bytes ^C --- 10. Chapter 6: Redistributing Route Information set policy-options policy-statement RIP-TO-OSPF term 1 from protocol rip set policy-options policy-statement RIP-TO-OSPF then accept When RIP was first configured. 100% packet loss As this would be a two-way redistribution and because no policy statement currently exists.1 ping statistics --- 6 packets transmitted. metric 2.3.996/9. two policy statements need to be created. The first statement will be applied to the OSPF configuration: 85 .10.0 inet.2 via ge-0/0/1.1: icmp_seq=2 ttl=62 time=4.23.23.

3. it is perfectly acceptable to reuse the same policy statement RIP already uses.1: icmp_seq=3 ttl=63 time=4. rather than put IS-IS under the same term as RIP and direct.817 ms 64 bytes from 10. In this instance.3.818 ms Redistribution Between RIP and IS-IS As with the redistribution between OSPF and RIP. a new policy statement that will be applied to the IS-IS configuration should be created: set policy-options policy-statement RIP-TO-ISIS term 1 from protocol rip set policy-options policy-statement RIP-TO-ISIS then accept Finally IS-IS is then told to use this policy statement: set protocols isis export RIP-TO-ISIS .10.485/0.3.10. 5 packets received. 86 Day One: Routing the Internet Protocol set policy-options policy-statement ISIS-TO-OSPF term 1 from protocol isis set policy-options policy-statement ISIS-TO-OSPF then accept And this second policy statement will be applied to the IS-IS configuration: set policy-options policy-statement OSPF-TO-ISIS term 1 from protocol ospf set policy-options policy-statement OSPF-TO-ISIS then accept These policy statements are then applied to the protocol configuration as follows: set protocols ospf export ISIS-TO-OSPF set protocols isis export OSPF-TO-ISIS Once things has been committed.3.3.10.10.10.1: icmp_seq=4 ttl=63 time=6.1: icmp_seq=1 ttl=63 time=4.3.1 (10. router vMX0 should now be able to ping interface ge-0/0/0.142/5.1: icmp_seq=0 ttl=63 time=4.841 ms 64 bytes from 10.206/6. 0% packet loss round-trip min/avg/max/stddev = 4. a second term has been created and IS-IS has been placed under this instead.10. too.1: icmp_seq=2 ttl=63 time=5.485 ms ^C --- 10.142 ms 64 bytes from 10.1): 56 data bytes 64 bytes from 10.10.0 on router vMX5: [email protected]> ping 10. however.10.747 ms 64 bytes from 10.10. then this will work.1 PING 10. and to allow the administrator to see at a glance that a protocol is being redistributed.3. As long as there is the then accept statement at the very end of the policy statement.3. The first command adds the second term to the policy statement RIP is currently using: set policy-options policy-statement RIP term 2 from protocol isis Once the RIP policy statement has been modified. One reason to create this as a second term is to help keep it tidy.3. This configuration will be applied to both vMX3 and vMX6 as these are both ASBRs between the RIP and IS-IS domains.1 ping statistics --- 5 packets transmitted.

2.10. if traceroute were to be run from vMX0 to router vMX5s interface in subnet 10.908 ms 3. the packet should go via router vMX2 as this is the best path: [email protected]> traceroute 10.644 ms 5. in addition to a prefix-list.1 (10.773 ms 1.1. First.0: 25 destinations.0. and vMX2: [email protected]> traceroute 10. * = Both 87 .828 ms 5.5.2 traceroute to 10.897 ms 3.2) 1. the subnet 172. 0 hidden) + = Active Route.10.0.10. By utilizing the same policy statement.431 ms Filtering Routes During Redistribution The configuration covered in the previous section would.0. vMX4.0. interface ge0/0/0. router vMX0 should be checked to see if it does have reachability to that subnet: [email protected]> show route protocol ospf inet.0 disable After a brief pause to allow the route to be withdrawn.10.211 ms 2 10.2) 5.1. redistribute every route between protocols. too.1) 7.2 traceroute to 10.2 (10. Imagine for a moment that this was not a desirable result and that there were some subnets you didn’t want to redistribute.10.396 ms 4.2 (10.2).3) 2.673 ms 1.151 ms 5 10. traceroute is run once more to the same address.23.1. 30 hops max. if an interface goes down? By redistributing between these processes.0/24 will be filtered by the ASBRs so that routers vMX0 and vMX1 and the two VSRX firewalls will not be able to reach that subnet.3. 30 hops max. even before the commands to redistribute between RIP and IS-IS were committed.1.3 (10.2.10.10.23. it is possible to filter out individual subnets so that they aren’t redistributed. of course.2 (10.2 (10.2 (10.2.335 ms 4 10.10.0 on router vMX2 will be disabled.0.1.238 ms 2 10. the network should have full redundancy.10.2.10.557 ms 1.1.3. Chapter 6: Redistributing Route Information In theory.958 ms 1.2) 3. What happens.10.090 ms 2. This time the packet traverses routers vMX1.1. 29 routes (25 active.2.1. all routers should have been able to see all subnets as routers vMX2 and vMX4 were redistributing between IS-IS and OSPF and between OSPF and RIP.2) 1.1) 8. Before this is done. however. meaning every subnet was accessible from every part of the network.3. In this section. however.2).1. vMX3. 40 byte packets 1 10.5.23.10.345 ms 3 172.1. 40 byte packets 1 10. 0 holddown.10.813 ms 1.659 ms 2.518 ms The interface between vMX0 and vMX2 is then disabled by using the following command: set interfaces ge-0/0/0.1 (172.2 (10.536 ms 3.0.1. - = Last Active.119 ms 4. To prove this.3.1.

3. metric 2.3.0 172. Policy statements operate from the top down.3.2 via ge-0/0/1.1. tag 0 > to 10.3. The name of this prefix list will be ONESEVENTWOTWENTYTHREEONE and it will match the subnet 172. a policy statement was created and assigned to the OSPF configuration. it can be added to the policy statement.2.0.3. metric 3000 > to 10.0. } This policy statement can be easily modified by adding extra “terms. metric 2.0.0 172.0. The configuration of the existing policy statement is as follows: policy-statement ISIS-TO-OSPF { term 1 { from { protocol isis.1.3.168.2 via ge-0/0/1. tag 0 > to 10.3. tag 0 > to 10.0/24 *[OSPF/150] 00:13:14. tag 0 > to 10.0.2 via ge-0/0/1.0.2 via ge-0/0/1.2 via ge-0/0/1.0.0.5/32 *[OSPF/10] 00:15:29.23. metric 1 MultiRecv In the previous sections.168.1.1. it stops processing.2/32 *[OSPF/150] 00:13:14. metric 2.2 via ge-0/0/1.2 via ge-0/0/1.1. metric 2.3.23.0.168.0 10. tag 0 > to 10.” Before this is done.0.2 via ge-0/0/1. tag 0 > to 10.0 224. and if it doesn’t .0.240.0.2 via ge-0/0/1.0 10.10.2 via ge-0/0/1. metric 2000 > to 10. tag 0 > to 10. tag 0 > to 10. 88 Day One: Routing the Internet Protocol 10. metric 3000 > to 10.3.0 10. metric 2.0 192. metric 2000 > to 10. } then accept.1/32 *[OSPF/150] 00:13:09.0.0/24 *[OSPF/10] 00:13:14.233.3.3.0 172.0/24 *[OSPF/10] 00:14:00.1. a prefix list needs to be created that will identity which subnets are to be filtered.3.0/24 *[OSPF/10] 00:13:14.7.0 192.5.3/32 *[OSPF/150] 00:12:48.0. tag 0 > to 10.2 via ge-0/0/1.1.3.1.4/32 *[OSPF/150] 00:12:08. metric 2.0.0/24 *[OSPF/10] 00:14:00. metric 2.0/24 *[OSPF/150] 00:12:48.0/24 *[OSPF/150] 00:13:09. however.168.10.0.1.0 192.0.0/24 *[OSPF/150] 00:13:14.0.2 via ge-0/0/1.3.23. metric 2.0/20 [OSPF/150] 00:13:14. tag 0 > to 10.168.2 via ge-0/0/1. metric 2.10.23.0 192.0 10.0/24 *[OSPF/150] 00:13:14.3.0/24 Now that the prefix list has been created. As soon as the policy statement finds a match.3.23.0/24: set policy-options prefix-list ONESEVENTWOTWENTYTHREEONE 172. metric 0.0 192.2 via ge-0/0/1.0 10. The first router these changes will be made to is vMX2.4.

then within Term 1 a reject will be set. In this case it will be given the same name as on router vMX2: set policy-options prefix-list ONESEVENTWOTWENTYTHREEONE 172. through. NOTE There are in fact two ways of specifying which routes should be filtered.23. In this case. this should be added to Term 1 and a reject should be applied: set policy-options policy-statement RIP-TO-OSPF term 1 from prefixlist ONESEVENTWOTWENTYTHREEONE set policy-options policy-statement RIP-TO-OSPF term 1 then reject Finally. and the second is using a route-filter.1. the first is using the prefix-list as described here. So these filters need to be applied to vMX4. because there are two ASBRs. where routes will be filtered and summarized instead: set policy-options policy-statement ISIS-TO-OSPF term 1 from prefixlist ONESEVENTWOTWENTYTHREEONE set policy-options policy-statement ISIS-TO-OSPF term 1 then reject If this were to be committed now. too. and therefore the prefix list needs to be applied to Term 1.0/24 And. Chapter 6: Redistributing Route Information find a match then it automatically rejects. which will be covered in Chapter 9. as before. are now accepted: set policy-options policy-statement ISIS-TO-OSPF term 2 from protocol isis Once this is committed. if the filter was applied to the next “term” then the policy statement will still allow this route. therefore a second term needs to be created that matches just the protocol. The accept term already at the end of the policy statement will ensure that routes other than the one filtered in Term 1. In this case. this policy would reject all routes because of the implicit reject. the filter needs to be applied on the policy statement that redistributes RIP into OSPF. a second term needs to be created so that the other routes are accepted: set policy-options policy-statement RIP-TO-OSPF term 2 from protocol rip 89 . } then accept. The existing policy statement is configured as follows: policy-statement RIP-TO-OSPF { term 1 { from { protocol rip. } The first thing that should be done is to create the prefix list. router vMX0 will be able to reach this subnet.

1: icmp_seq=0 ttl=62 time=10.1 PING 172. This protocol is BGP.0/24 *[OSPF/10] 00:20:21. it should be apparent that this route has disappeared. three.1. Aside from being used during an acquisition or merger.23. with the exception of those in the private address ranges. meaning the filter was successful: [email protected]> show route protocol ospf | match 172.1. metric 3000 Summary While running a single protocol on a LAN is ideal.23.1): 56 data bytes 64 bytes from 172. just by looking at the routing table. redistribution is typically used when a corporate LAN grows beyond its existing routing protocol.1.757 ms ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host As a final check.23. Junos is ideal in this case as the administrator has an easy means to rollback the configuration should something go wrong during a migration.7. .1: icmp_seq=11 ttl=62 time=9.23.23. this is not always possible and as such this chapter has demonstrated that it is possible to run two. the Junos OS warns us that there was no route to the host: [email protected]> ping 172.1.307 ms 64 bytes from 172. 90 Day One: Routing the Internet Protocol If vMX0 starts to ping vMX3’s ge-0/0/2.0/24 *[OSPF/10] 00:20:21.478 ms 64 bytes from 172. or even four routing protocols on a LAN at the same time should the need arise.23. The next chapter covers the most scalable protocol available on any network today. The scalability is such that it is capable of advertising almost every single subnet that exists in the world. In this case.23 172.0 interface while the configuration is committed to router vMX4.23.1 (172.1: icmp_seq=10 ttl=62 time=5. In addition the Junos OS runs each protocol in its own process thereby protecting the network device should something happen to one of the processes.1. this means the network largely remains accessible. metric 3000 172.1. An administrator can enable the new routing protocol on a router by router basis and redistribute between the new and the old protocol until the migration is complete. you should see that the route is very quickly withdrawn by OSPF.23.3.

Let’s now move on to exterior gateway protocols (EGPs). . BGP4 is a routing protocol that operates between networks that are under different administrative control.org/ wiki/Border_Gateway_ Protocol. This is what makes BGP4 an exterior gateway protocol as it operates between Autonomous Systems (ASs). BGP is an exterior gateway protocol that allows the exchange of routing information between routers in different autonomous systems (ASs). EGP in this book refers to BGP4 (Border Gateway Protocol). Border Gateway Protocol (BGP) is a standardized exterior gateway protocol designed to exchange routing and reachability information between autonomous systems (ASs) on the Internet. https://en. BGP uses this information to maintain a Routing Information Base (RIB). Routing information includes the complete route to each destination. It literally runs the world’s networks! NOTE Do not confuse EGP with the 1980s EGP3 that was defined in RFC 827.Chapter 7 Border Gateway Protcol (BGP) The previous chapters in this Day One book have explored interior gateway protocols (IGPs). So much has been written already about BGP that it is hard to add a unique introduction to one of world’s most popular protocols. which allows it to remove routing loops and to enforce policy decisions at an AS level.wikipedia.

This is resolved by the use of keepalive packets. It originated in the initial network implementation in which it complemented the Internet Protocol (IP). Origin. also known as reachability information. You can use routing policies to choose among multiple paths to a destination and to control the redistribution of routing information. BGP still needs to confirm that other ASs are still reachable and functional. An AS is defined as a group of IP networks operated by one or more network operators that has a single. Now. Below are the categories into which all BGP route attributes fall. Next-hop. There are also examples of BGP path attributes on each category. The Transmission Control Protocol (TCP) is a core protocol of the Internet Protocol Suite. Local Preference. These attributes are discussed later in this chapter.wikipedia. BGP Route Attributes BGP uses additional attributes and route reachability to describe the path to prefixes. AS Path. before drilling down into the Junos OS examples. If not recognized it is still expected to be propagated to other neighbors. Atomic Aggregate. https://en. let’s first discuss routing attributes. BGP uses additional attributes to describe the path to prefixes. Aggregator. Optional transitive: May not be recognized by all BGP speakers. Well-known discretionary: May be present in update messages and must be supported by all BGP speakers. you can see that BGP (both iBGP and eBGP) is a path vector routing protocol that uses the uniqueness of AS numbers to help detect any loops.org/wiki/ Transmission_Control_ Protocol. as well as a short explanation: Well-known mandatory: Must be present in all update messages and must be supported by all BGP speakers. . This means that there is no need for periodic route updates – quite handy since the current BGP Global IPv4 routing table is ~542. One of the main differences of BGP as a routing protocol compared to other IGPs in this book is that BGP uses the Transmission Control Protocol (TCP) for its transporting reliability. This is referred to as Next Layer Reachability Information (NLRI). clearly defined routing policy.2.000 prefixes! With the lack of periodic updates. Table 2. 92 Day One: Routing the Internet Protocol BGP allows for policy-based routing. If you look back at Chapter 2. Community.

BGP Path Attributes Let’s examine some of these path attributes a bit further.1. Chapter 7: Border Gateway Protcol (BGP) Optional nontransitive: May not be recognized by all BGP speakers. It is used for loop detection and path metrics where the length of the path is used for the path selection. Multi Exit Descriminator (MED). 93 . AS Path Attribute The mandatory attribute AS Path lists the ASs that are traversed when forwarding to the associated NLRI as shown in Figure 7.1 An AS Path Attribute The AS Path Attribute shows the sequence of ASs a route has traversed. Attribute not propagated to other neighbors. Figure 7.

0/16 is not accepted by AS30 due it having AS40 in its path.2 Loop Detection Attribute You can see here in Figure 7.1.2 that 92.3 Next Hop Attribute . 94 Day One: Routing the Internet Protocol Loop Detection Figure 7.0. Next Hop Figure 7.

localpref 100 AS path: 30 I.1. validation-state: unverified > to 10.2 via ge-0/0/0. The higher the local preference the more desirable the path.1.0/ via two paths.0/16 *[BGP/170] 00:40:49. localpref 100 AS path: 20 40 I. validation-state: unverified > to 10. you can see the following: [email protected]> show route protocol bgp inet. validation-state: unverified > to 10. validation-state: unverified > to 10. and the other path via 10. The next-hop attribute is well known and mandatory in BGP.0 [BGP/170] 00:40:49.2.0.0.0.6 via ge-0/0/1. localpref 100 AS path: 30 40 I. which is AS20.0 91.0.0. localpref 100 AS path: 20 40 I.0.0. Chapter 7: Border Gateway Protcol (BGP) The next hop AS attribute shows the IP address to reach the next AS. which is AS30.0/16 *[BGP/170] 00:50:10.0 92.0: 9 destinations.1.1. * = Both 90. - = Last Active. validation-state: unverified > to 10.6 via ge-0/0/1. Origin is a well known mandatory attribute. localpref 100 AS path: 20 I.0/16 *[BGP/170] 00:40:49.0.0.0.0.0. 10 routes (9 active. It is a well-known discretionary attribute and is kept within the AS.2 via ge-0/0/0. From the viewpoint of AS15.6.0.0. It can be one of the following: I – IGP E – EGP ? – Unknown/Incomplete 90.0 So AS15 can see 90.0.0. 95 . Local Preference The local preference attribute is used to advertise to iBGP neighbors on how to leave their AS.2 via ge-0/0/0.1. 0 holddown.0. Origin The origin code is used to identify the original source of a route being learned.0 A BGP speaker prefers origins in the following order: IGP / EGP / Unknown/Incomplete.0/16 *[BGP/170] 00:49:35.0. One path via 10.0. 0 hidden) + = Active Route.

Prefers the path with the highest local preference 3. The common format is LOCAL-AS:xx. MED is also kept within the AS it was advertised to and will not transit any further. BGP Path Selection Tutorial The Junos OS BGP path selection algorithm is slightly different from other vendors (who all have their own slant of path selection). 0 holddown. validation-state: unverified > to 10. the Junos OS route selection process is started and it operates on the following logic: 1. When a BGP router is presented with a prefix that has more than one route to it. Here’s an example: [email protected]> show route protocol bgp inet.0. should all other decisions with BGP path selection process be equal (more on BGP path selection next). This book only describes the Juniper path selection process so as not to muddy the waters. * = Both 90.0/16 *[BGP/170] 00:01:07. MED 10.1. localpref 100 AS path: 40 I. Community is an optional transitive attribute. 10 routes (9 active.0: 9 destinations. These tags can be used to allow upstream devices to apply specific routing policies within their AS. where xx is represented as two 16 bit integers as per RFC1998. Community BGP communities allow for the tagging of multiple routes that may share one or more characteristics. you should consult the documentation of your device’s vendor.0. NOTE For interop issues. Can the next hop be resolved? 2.10 via ge-0/0/0.0. Prefers the path with the shortest AS path length 4. - = Last Active.0 The lower the MED the more preferred the path. 0 hidden) + = Active Route. Prefers the path with the lowest origin value . 96 Day One: Routing the Internet Protocol Multi Exit Discriminator The multi exit discriminator (MED) is an optional non-transitive attribute and some BGP speakers may not understand or even use the attribute.

Having digested all that.net/techpubs/en_US/junos12. Prefers the path with lower MED value 6.0. Chapter 7: Border Gateway Protcol (BGP) 5. let’s take a look at BGP path selection using the topology shown in Figure 7.0. 65500.0/24.4. To calculate the amount of iBGP sessions you need a full mesh that uses the following calculation: N(N-1)/2 and applied to the above 4(4-1)/2 = 6.4 has four routers within AS15 and two external ASs. announcing 192. So let’s have a look at R3 and R4 to see the routes that the external ASs are announcing: 97 . Prefers paths with shortest cluster length 9. see the Juniper TechLibrary: http:// www.juniper.0/24. Figure 7.2. and 203. Prefers routes from peer with lowest peer ID The last two points can be removed if you activate multipath. Enabling the multipath option allows routes for the same prefix that have passed the first eight steps to be installed onto the route table. Prefers paths learned by eBGP over iBGP 7.113. OSPF is running between them and the loopbacks are also announced. MORE? For more on the multipath option. and 65501.1/topics/reference/configuration-statement/multipath-edit-protocols-bgp. There is a full mesh of iBGP sessions between all four routers within AS15. Prefers paths with lowest IGP metric 8.html. Prefers routes from peer with lowest router ID 10. respectively.4 BGP Path Selection Example Figure 7.

51. If you look back at Figure 7.0/24 198. 90. Now. 2 hidden) Prefix Nexthop MED Lclpref AS path 192. 0 holddown.0/24 198.100.2. and the same is true of 192.0.0/24 via 65501 when you can see it directly from 65500.0.0/24 and 203.0: 20 destinations. 25 routes (20 active. 0 holddown.51.51. as there would be no point getting to 203.1.1.0.0/24.0.100.2. It makes good sense.0.113. Why add an extra AS to traverse! Let’s have a look at R4: .0.113.51.10 65501 I 203. This is due to the best path selection preferring eBGP over iBGP in Step 6 of the selection process.2.0.1. let’s have a look at why only one route from each session is active: [email protected]> show route receive-protocol bgp 198.1 15 187 186 0 0 1:23:11 0/2/2/0 0/0/0/0 198.0. If you also look at the AS Path you can see that each external AS is announcing their locally originated route plus the other AS’s locally originated route.1 15 176 177 0 0 1:19:04 0/0/0/0 0/0/0/0 92.6 65500 I [email protected]> show route receive-protocol bgp 198.0. 2 hidden) Prefix Nexthop MED Lclpref AS path * 192.1.6 65500 56 53 0 0 23:01 1/2/2/0 0/0/0/0 198.2.0.51.1.51. 25 routes (20 active.0 6 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/ Dwn State|#Active/Received/Accepted/Damped.51.100.100.113.100. and you can see R3 has direct connections to each external AS.1 15 227 227 0 0 1:40:57 0/0/0/0 0/0/0/0 91.100.6 inet. but only one route is selected as active (denoted by the *).113. This means that in the BGP best path selection process this made it Step 3 (prefers the path with the shortest AS Path length).0.10 inet.0/24 being seen via 65500 when you can see it directly via 65501.100..10 65501 65500 I If you look closely you can see that both ASs are sending 192.0/24 198..100.0.6 65500 65501 I * 203.0/24 198.10 65501 96 96 0 0 41:42 1/2/2/0 0/0/0/0 From R3 you can see that AS 65500 and 65001 are both sending two routes that have been accepted but only one route from each AS has been made active.51.3 you can see where the connection to each AS is. but neither are the active routes.0: 20 destinations. 98 Day One: Routing the Internet Protocol [email protected]> show bgp summary Groups: 2 Peers: 5 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet. You can also see the two routes via the iBGP session with 92.

Let’s have a look at the routes learned from AS65500: [email protected]> show route receive-protocol bgp 198. which have been received and accepted.51.2.1 65500 103 102 0 0 45:07 2/2/2/0 0/0/0/0 Now in this output you can see that R4 is receiving two routes (boldface): from iBGP (AS15) and eBGP (AS65500).0.1.1.0.51.1. 90. 15 routes (11 active.1 inet.51.0/24 198.1 15 15 286 283 286 283 0 0 0 0 2:08:35 0/2/2/0 2:07:36 0/2/2/0 0/0/0/0 0/0/0/0 Here. 2 hidden) Prefix Nexthop MED Lclpref AS path * 192. they should all be able to see the two external prefixes. Chapter 7: Border Gateway Protcol (BGP) [email protected]> show bgp summary Groups: 2 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.1.0 4 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/ Accepted/Damped. but they haven’t become active.1 inet.1 65500 I You can see here that R4 has received and accepted the two routes and has made them active in the FIB.0: 13 destinations.. starting at R2: [email protected]> show route receive-protocol bgp 92. 17 routes (15 active.0.0 4 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/ Accepted/Damped.0/24 198. Let’s do some debugging to see why..1. you are seeing both routes via AS65500 with 192.0.0.100.1 65500 65501 I * 203. 0 holddown.0. 90.0.100.51. so it makes sense that the active routes (routes installed to the Forwarding Information BASW – FIB) are installed from the routes accepted from AS6500.0: 15 destinations.1 15 253 256 0 0 1:54:01 0/0/0/0 0/0/0/0 91.113. As R4 only has one external eBGP connection.1.0/24 transiting through to AS65501.1 93. and since there is a full mesh iBGP setup between all the routers in AS15. both the eBGP facing routers (R3 and R4) receive the same routes. which is great.. So now. 4 hidden) 99 .0.1 15 253 254 0 0 1:53:53 0/2/2/0 0/0/0/0 198. You already know that eBGP is preferred over iBGP.100.100. 0 holddown.0.1.0. Or can they? Let’s have a look at R2 to confirm: [email protected]> show bgp summary Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.1 15 246 247 0 0 1:50:45 0/0/0/0 0/0/0/0 93.2.. both R3 and R4 have sent two routes.1 15 325 326 0 0 2:26:22 0/0/0/0 0/0/0/0 92.

100. 15 routes (11 active.93.0.113. Could these be the two routes from R3 and from R4? Let’s investigate: [email protected]> show route receive-protocol bgp 92. 0 announced) BGP Preference: 170/-101 Next hop type: Unusable Address: 0x92854a4 Next-hop reference count: 4 State: <Hidden Int Ext> Local AS: 15 Peer AS: 15 Age: 1:12:13 Validation State: unverified Task: BGP_15.100.100.1 Accepted Localpref: 100 Router ID: 93.51.2.0.51. and the next hop and the Origin attributes all look okay.0. it’s not showing us any routes. 0 holddown. 0 holddown.2.92.1 Indirect next hop: 0x0 - INH Session ID: 0x0 BGP Preference: 170/-101 Next hop type: Unusable Address: 0x92854a4 Next-hop reference count: 4 State: <Hidden Int Ext> Local AS: 15 Peer AS: 15 Age: 1:39:30 Validation State: unverified Task: BGP_15.51.1.1.0: 13 destinations. 4 hidden) Prefix Nexthop MED Lclpref AS path 192.1 Accepted Localpref: 100 Router ID: 92. but from the output (boldface) you can see that four routes are hidden.0.0/24 198.0/24 198.2.51.6 100 65500 I The missing routes are found.1.1 100 65500 65501 I 203.0.0.1.10 Indirect next hop: 0x0 - INH Session ID: 0x0 .0.0/24 (2 entries.100. 15 routes (11 active.0/24 198.2.0. 100 Day One: Routing the Internet Protocol Hmm.1+179 AS path: 65501 I Aggregator: 65501 192.0.0.100.1+179 AS path: 65500 65501 I Aggregator: 65501 192.0/24 hidden extensive inet.0/24 198.2. 4 hidden) Prefix Nexthop MED Lclpref AS path 192.1 hidden inet.0.1 Indirect next hops: 1 Protocol next hop: 198.0.100.10 100 65501 I 203. 15 routes (11 active. 4 hidden) 192.2.0.1 hidden inet.1 Indirect next hops: 1 Protocol next hop: 198.51.0.113.51.1.1 100 65500 I [email protected]> show route receive-protocol bgp 93.1.0: 13 destinations. but why are they hidden? The AS paths look correct.0: 13 destinations. 0 holddown. Let’s look at one of the hidden routes in a bit more detail using the extensive option: [email protected]> show route 192.

51.1 15 394 395 0 0 2:57:53 0/0/0/0 0/0/0/0 92.0/24 198.0 [edit] [email protected]# commit commit complete Now to check out R2: [[email protected]> show bgp summary Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet. * = Both 198.0: 14 destinations.0: 15 destinations. and passively add the interface into OSPF and see what happens on R2: [edit] [email protected]# set protocols ospf area 0. - = Last Active.1 100 65500 65501 I * 203. like OSPF.100. 16 routes (14 active.1. So how does R2.. 2 hidden) + = Active Route. 0 holddown.1.100. 0 holddown.1.1. 90.1 100 65500 I 101 .0 4 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/ Received/Accepted/Damped.100.0.0.0.1 inet.0. How do you fix this? Let’s jump back to R4 and see what can be done: [email protected]> show route 198.10 [email protected]> The next hops that both R3 and R4 are advertising are not in the routing table. R4 does have a route to 198.1 15 354 355 0 0 2:40:06 2/2/2/0 0/0/0/0 93.0.0 interface ge-0/0/2.51.1 inet. but both are saying the next hop is unusable!? Let’s double-check this: [email protected]> show route 198. Let’s look at a routing protocol. as both routes are active on this router.100.51.1 15 351 352 0 0 2:39:07 0/2/2/ 0/0/0/0 [email protected]> show route receive-protocol bgp 92..51.0.0/24 198. and presumably all the other routers in AS15.51.0 Here.51.0.100.100.0/30 *[Direct/0] 01:32:08 > via ge-0/0/2.51.1 [email protected]> show route 198. allowing them to be announced back to R2. 2 hidden) Prefix Nexthop MED Lclpref AS path * 192. know about this directly connected interface and also the two directly connected interfaces on R3? Static routes can be added (remember Chapter 1?) across all the routers in AS15 but this seems a bit cumbersome and not very scalable.100. Chapter 7: Border Gateway Protcol (BGP) So you can see the routes from both R3 and R4.0. 17 routes (15 active.2.113. That makes sense.1.

2 65500 89 88 0 0 38:35 1/2/2/0 0/0/0/0 You can see that there is one learned route from AS65500 and one from our iBGP neighbor. 90.0 203.2.0.0.0. - = Last Active.0 [BGP/170] 01:08:49.0/24 *[BGP/170] 01:08:53. R3.0 . which makes sense because looking at the BGP best path selection steps you can see that they have been selected because: 192.1.0. * = Both 192. validation-state: unverified > to 198.1.1 15 1886 1889 0 0 14:14:25 1/2/2/0 0/0/0/0 198..1 15 1886 1888 0 1 13:07:38 0/0/0/0 0/0/0/0 93.1.1 15 366 366 0 0 2:45:01 0/1/1/0 0/0/0/0 93. localpref 100 AS path: 65500 I.1.0/24 *[BGP/170] 01:25:59.0.0.51.. 21 routes (19 active. 0 hidden) + = Active Route. validation-state: unverified > to 10..0.113.100.0.0 3 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/ Received/Accepted/Damped.0.0/24 is selected as active from R3 because it is a lower IGP metric from R2 to R3 than R2 to R4.1 15 362 363 0 0 2:44:02 2/2/2/0 0/0/0/0 Fantastic! The active routes from R3 can be seen now.1 AS path: 65501 I. 102 Day One: Routing the Internet Protocol Great! Both routes are now active but two routes are still hidden and it still needs the external interfaces on R3 added into OSPF.51. from 93.2 via ge-0/0/3.100. localpref 100. 203. Why would that be? Let’s have a look back on R4: [email protected]> show bgp summary Groups: 2 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 4 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/ Accepted/Damped. Let’s have a look at the routes and why there is one active from each peer: [email protected]> show route protocol bgp inet.113.0.2.1 15 405 406 0 0 3:02:48 0/0/0/0 0/0/0/0 92.5 via ge-0/0/2.2 via ge-0/0/3.1.1 15 1886 1887 0 1 10:41:22 0/0/0/0 0/0/0/0 91. 90.0: 19 destinations. 0 holddown..100.1.51.1. Let’s do this and then see how this affects R2: [email protected]> show bgp summary Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet. localpref 100 AS path: 65500 65501 I.0.0/24 is selected as active from R3 because it is a shorter AS Path length than R4. validation-state: unverified > to 198.0.0. The more careful reader may have spotted that there is only receiving one route from R4 instead of an earlier two.

Now does this explain why R4 is only sending one route to R2 or doesn’t it? Let’s investigate iBGP to find out. One of the fundamental differences between iBGP and eBGP is that to avoid routing loops iBGP does not advertise routes learned from other iBGP neighbors. For this reason. The router then takes these routes and advertises them internally within the AS with other BGP-speaking peers with iBGP. Scaling iBGP The topology that has been used in the AS is a full mesh BGP that is manageable. BGP requires that all internal peers be fully meshed so that any route advertised by one router is advertised to all peers within the AS. External peers (according to peers within an AS) establish links via eBGP. and that is why 192.1 AS path: 65500 I. BGP cannot propagate routes throughout an AS by passing them from one router to another.0.0/24 is preferred via 65501 with the next hop being R3.02.wikipedia. That’s a lot of time and effort to put into the network to build it full mesh! What if there was a way to scale the amount of routers within your network but not be held up by setting up a full mesh network? MORE? Thankfully there are two ways to scale your iBGP: route reflectors and confederations.0.org/wiki/ Mesh_networking. from 93. localpref 100. you can see that fifty routers would require 50(501)/2=1225 BGP peering sessions. Chapter 7: Border Gateway Protcol (BGP) [BGP/170] 01:26:45. Fully Meshed: A mesh network whose nodes are all connected to each other is a fully connected network. but what if there were fifty routers within the AS? Using the calculation. And this explains why R2 is only seeing one prefix from R4 because it has learned one route from eBGP (which is advertised to R2) and one route from iBGP (which is not advertised to avoid routing loops). iBGP does not prepend its own AS when making the calculation.0. The implementation of these two methodologies is outside the scope of this Day One book. but further information can 103 . validation-state: unverified > to 10.5 via ge-0/0/2.0 Here you can see that each route has two paths. https://en.1. However. BGP best path has selected both active routes due to their shortest AS Path length. This means that our topology is working as expected. iBGP At the beginning of this chapter eBGP was noted as external and iBGP as being internal. Instead.

0.10 Indirect next hop: 0x0 - INH Session ID: 0x0 So the next hop to 198.1.100.0/24 hidden extensive inet.0.net/ documentation/en_US/junos13. and at.100.0.51.2.0: 13 destinations.1+179 AS path: 65500 65501 I Aggregator: 65501 192.51.0/24 (2 entries. Is this really scalable by adding all these link subnets to our IGP? Probably not.html Let’s look at scaling BGP and how to resolve the next-hop issue by adding external links. http://www.1/topics/concept/routing-protocol-bgp-securityroute-reflector-understanding.1 Indirect next hops: 1 Protocol next hop: 198. The reason the external links were added to our IGP was to activate routes within our AS that couldn’t resolve the next hop.100.html.0.51.juniper. 104 Day One: Routing the Internet Protocol be found at the Juniper TechLibrary: http://www.0.2. 0 holddown.10 is unusable because it’s not in the IGP.1+179 AS path: 65501 I Aggregator: 65501 192.1 Accepted Localpref: 100 Router ID: 93.1. so what can you do to resolve this? Let’s have a look at R2 and show OSPF: . A quick reminder is here: [email protected]> show route 192.1 Accepted Localpref: 100 Router ID: 92.1. 0 announced) BGP Preference: 170/-101 Next hop type: Unusable Address: 0x92854a4 Next-hop reference count: 4 State: <Hidden Int Ext> Local AS: 15 Peer AS: 15 Age: 1:12:13 Validation State: unverified Task: BGP_15.0.93.100. so let’s see what we can do about that.1 Indirect next hops: 1 Protocol next hop: 198.1 Indirect next hop: 0x0 - INH Session ID: 0x0 BGP Preference: 170/-101 Next hop type: Unusable Address: 0x92854a4 Next-hop reference count: 4 State: <Hidden Int Ext> Local AS: 15 Peer AS: 15 Age: 1:39:30 Validation State: unverified Task: BGP_15. 4 hidden) 192. 15 routes (11 active.juniper.1 and 198.1/topics/topic-map/bgp-confederations.2.net/documentation/en_US/junos15.51.1.0.2.0.92.

51. metric 1 > to 10.2 via ge-0/0/2. metric 3 > to 10.0.1.1. So let’s create a policy and apply it as an export to our iBGP neighbors: 105 .0. metric 1 > to 10.1.1/32 *[OSPF/10] 02:26:11. 0 hidden) + = Active Route.0.2 via ge-0/0/2.1 15 3190 3192 92.0. metric 2 > to 10.0.0.0. metric 2 > to 10.8/30 *[OSPF/10] 09:35:13. metric 2 > to 10. 0 holddown. metric 1 MultiRecv From R2’s output you can see the link subnets between OSPF neighbors and you can also see the loopback interfaces of the other routers within the AS. before adding the interfaces to OSPF.9 via ge-0/0/1.0 198. metric 2 > to 10.0.0.0 198.0.0 10. Chapter 7: Border Gateway Protcol (BGP) [email protected]> show route protocol ospf inet.0. roll back the changes on R3 and R4 and see things are back to accepting routes but not activating them from R2: [email protected]> show bgp summary Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed inet.12/30 *[OSPF/10] 02:26:11.0.1 15 3043 3046 93.0 90.0.9 via ge-0/0/1. metric 2 > to 10.0.51.0/30 *[OSPF/10] 02:26:11.0.2 via ge-0/0/2. it is exporting routes to the other iBGP neighbors. Let’s have a go! First.0 to 10.1.0 92. - = Last Active.0.0. 90.0.0 4 0 0 Peer AS InPkt OutPkt Received/Accepted/Damped.100. What if the next-hop addresses could be changed to that of the router which learned the route? That would allow the AS to scale without adding additional routes into the IGP.4/30 *[OSPF/10] 09:35:13.9 via ge-0/0/1.0: 18 destinations.1.5/32 *[OSPF/10] 23:44:42.1/32 *[OSPF/10] 02:26:11. It may sound daunting but it’s really simple because from the standpoint of R4.4/30 *[OSPF/10] 20:09:34.0..2 via ge-0/0/2.0 224.1.1/32 *[OSPF/10] 20:09:34.0.0.0.0 to 10. 19 routes (18 active.0.51.0.0.2 via ge-0/0/2.1 15 3183 3194 History Damp State 0 OutQ 0 0 0 Pending 0 0 Flaps Last Up/Dwn State|#Active/ 0 1d 0:04:53 0/0/0/0 1 22:58:10 0/2/2/0 0 1d 0:05:02 0/2/2/0 0/0/0/0 0/0/0/0 0/0/0/0 That takes us back to an earlier point in this chapter.100.100.0.0.0.9 via ge-0/0/1. * = Both 10.0.0 198.0 93..0.0. which is handy because they are the IPs that we are establishing our iBGP sessions to and from. so let’s jump on to R4 and see how to set the eBGP learned routes to be advertised to our iBGP neighbors with the next hop of R4’s loopback interface.0.2 via ge-0/0/2.

106

Day One: Routing the Internet Protocol

[email protected]# set policy-options policy-statement NEXT-HOP-SELF then accept next-hop self
[edit]
[email protected]# set protocols bgp group internal export NEXT-HOP-SELF
[edit]
[email protected]# commit
commit complete
[edit]
[email protected]# show protocols bgp group internal
type internal;
local-address 92.1.0.1;
export NEXT-HOP-SELF;
peer-as 15;
local-as 15;
neighbor 90.1.0.1 {
description R1;
}
neighbor 91.1.0.1 {
description R2;
}
neighbor 93.1.0.1 {
description R3;
}

And let’s see if the desired result is on R2:
[email protected]> show bgp summary
Groups: 1 Peers: 3 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
4 2 0 0 0 0
Peer
AS
InPkt
OutPkt
OutQ Flaps Last Up/Dwn State|#Active/Received/
Accepted/Damped...
90.1.0.1 15 3222 3228 0 0 1d 0:18:57 0/0/0/0 0/0/0/0
92.1.0.1 15 3076 3081 0 1 23:12:14 2/2/2/0 0/0/0/0
93.1.0.1 15 3214 3230 0 0 1d 0:19:06 0/2/2/0 0/0/0/0

Looking good so far. Let’s have a look at the routes received:
[email protected]> show route receive-protocol bgp 92.1.0.1 detail
inet.0: 15 destinations, 17 routes (15 active, 0 holddown, 2 hidden)
* 192.0.2.0/24 (2 entries, 1 announced)
Accepted
Nexthop: 92.1.0.1
Localpref: 100
AS path: 65500 65501 I
Aggregator: 65501 192.0.2.1
* 203.0.113.0/24 (2 entries, 1 announced)
Accepted
Nexthop: 92.1.0.1
Localpref: 100
AS path: 65500 I
Aggregator: 65500 203.0.113.1

Fantastic! You can see that the next-hop address for both routes is
now the loopback of R4. All that’s left to do is add the next-hop policy
to R3 and you should be back to having an active route from R4 and
R3 on router R2:

Chapter 7: Border Gateway Protcol (BGP)

[email protected]> show bgp summary
Groups: 1 Peers: 3 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
3 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/
Received/Accepted/Damped...
90.1.0.1 15 3248 3255 0 0 1d 0:31:05 0/0/0/0 0/0/0/0
92.1.0.1 15 3104 3108 0 1 23:24:22 0/1/1/0 0/0/0/0
93.1.0.1 15 3247 3257 0 0 1d 0:31:14 2/2/2/0 0/0/0/0

Awesome! You are now seeing one route received from R4 and two
routes received and activated from R2, which is the same as when there
were the two external links in OSPF, but this time there are two less /30
link subnets in the IGP!
From this last example you can see that a routing policy was used to
achieve our objective. Routing policies can be very powerful and can
help us achieve many objectives, so let’s look at them further.

BGP Routing Policy
Junos routing policy is both fast and granular so it could have a Day
One book to itself. In the meantime, this chapter covers some basics to
give you a taste of what it can do. Further exploration is advised to the
reader.
Let’s continue from the previous example where a next-hop self policy
was used to affect routing decisions within the AS. But now let’s
expand on that further and have a look at manipulating both ingress
and egress traffic. To do this, look at the import policy to affect routing
decisions on how traffic exits our AS and also the export policies that
affect routing decisions on traffic destined to our AS. Figure 7.5 repeats
Figure 7.4 for your convenience.

Figure 7.5

This Section’s Network Topology

107

108

Day One: Routing the Internet Protocol

The network AS15 has been assigned 10.0.0.0/24 by the Acme Inernet
Registry, hurrah! Let’s announce it to our transit providers!
On R3 and R4 create an export policy as follows:
[email protected]# show | compare
[edit policy-options]
+ policy-statement ANNOUNCE-OUR-RANGE {
+ term announce-aggregate-route {
+ from {
+ protocol aggregate;
+ route-filter 10.0.0.0/24 exact;
+ }
+ then accept;
+ }
+ }

Let’s have a look at our BGP group to see what it looks like now:
[email protected]# show protocols bgp group external
type external;
log-updown;
export ANNOUNCE-OUR-RANGE;
local-as 15;
neighbor 198.51.100.10 {
peer-as 65501;
}
neighbor 198.51.100.6 {
peer-as 65500;
}

Great. Let’s see if it is announcing to the transits:
[email protected]> show route advertising-protocol bgp 198.51.100.6
inet.0: 20 destinations, 23 routes (20 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 192.0.2.0/24 Self 65501 I
[email protected]> show route advertising-protocol bgp 198.51.100.10
inet.0: 20 destinations, 23 routes (20 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 203.0.113.0/24 Self 65500 I

Hmmm, that’s not right. The 10.0.0.0/24 range is not being announced
and what’s more, it seems to be transiting our transits! BGP policy has
an implicit accept, so watch out! You don’t want to be one of those
people that mistakenly announces the Internet from their AS!
Let’s append a reject to the policy and see how that looks. Hopefully,
after that, you can figure out why the 10.0.0.0/24 range isn’t being
announced:
[email protected]# edit policy-options policy-statement ANNOUNCE-OUR-RANGE
[edit policy-options policy-statement ANNOUNCE-OUR-RANGE]
[email protected]# set term REJECT then reject
[edit policy-options policy-statement ANNOUNCE-OUR-RANGE]

0. So let’s get this fixed and check again: [email protected]# set routing-options aggregate route 10/24 [edit] [email protected]# commit commit complete [edit] [email protected]# exit Exiting configuration mode [email protected]> show route advertising-protocol bgp 198. 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.1 via ge-0/0/1.0/30 *[Direct/0] 00:56:39 > via ge-0/0/1.0. - = Last Active.0. Chapter 7: Border Gateway Protcol (BGP) [email protected]# show | compare [edit policy-options policy-statement ANNOUNCE-OUR-RANGE] term announce-aggregate-route { .0.0.0 10. That’s why it hasn’t been announced. Can it see the route for the range in the routing table? Let’s check: [email protected]> show route 10.0 10.0 Ah ha.8/30 *[OSPF/10] 00:04:16.2/32 *[Local/0] 00:56:40 Local via ge-0/0/1.0/24 inet. 24 routes (21 active. 0 holddown.0. } + term REJECT { + then reject.6 via ge-0/0/2.0 10.0.0.0.10 [email protected]> show route advertising-protocol bgp 198.0.0. Also.0. it has inhibited more specifics from within 10.100. 0 holddown. metric 2 > to 10.0: 21 destinations.0.0.51..0: 20 destinations.0. * = Both 10.5/32 *[Local/0] 00:56:40 Local via ge-0/0/2.12/30 *[OSPF/10] 00:55:46.0.0. metric 2 > to 10. 0 hidden) + = Active Route.0.6 inet. 23 routes (20 active.4/30 *[Direct/0] 00:56:39 > via ge-0/0/2.0.0 10.0. The aggregate route was not added in the routing options.51.0.0.0. + } [edit policy-options policy-statement ANNOUNCE-OUR-RANGE] [email protected]# commit and-quit commit complete Exiting configuration mode [email protected]> show route advertising-protocol bgp 198..0/24 Self I 109 . Because the ANNOUNCE-OUR-RANGE policy was very specific.100.0/24 exactly. it’s no longer transiting the transits announcements but it still isn’t announcing the range.100.51.6 Great.0/24.0.0 10. it needs to be from the aggregate protocol and match the filter 10.

0/24. You can also see that R3 (198.5) has been selected as the best path for 10.0.0/24 Self I The network is now announcing the range! Add the same configuration to R4 (not shown here) and you can see that the range is also being advertised correctly.1 15 155 163 0 1 40:26 0/1/1/0 0/0/0/0 198. 0 hidden) Prefix Nexthop MED Lclpref AS path * 10. At the moment R3 (198.0.51.100.0.100.51.51. So.0.5 15 155 163 0 1 41:04 1/1/1/0 0/0/0/0 198.0 4 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/ Dwn State|#Active/ Received//Accepted/Damped. What if you wanted to change this? Let’s have a look at some of the ways you could do it. 0 holddown. 198.0.0: 21 destinations.0.100.0/24 range.100.100.51.51. with only one route being active due to the BGP best path selection. let’s have a look at MED first. What happens if you use MED to make R4 become the active path: [email protected]# show | compare [edit policy-options policy-statement ANNOUNCE-OUR-RANGE term announce-aggregate-route then] + metric 10.100. You can also see AS65501 announcing the /24 and it’s locally originated /24.0/24.10 inet. 24 routes (21 active.5) is the active path for 10.. 110 Day One: Routing the Internet Protocol [email protected]> show route advertising-protocol bgp 198. and the lower the MED the more preferred the route.51. as shown here with the output of AS65500: [email protected]> show bgp summary Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet. Let’s see if that has managed to change which router is now advertising the best path: .14 65501 156 156 0 0 1:09:24 1/2/2/0 0/0/0/0 Both the AS15 routers are announcing the 10.. First if you look at the BGP best path selection process you can see that there are some things within our control (AS-PATH length and MED ) and some things you cannot control (ISP’s local preference of our route).0. [edit] [email protected]# commit commit complete You may be wondering why we went on to R3 rather than R4 to make our MED change? This is because if a MED is not explicitly set.0. the value is the equivalent to zero.

14 via ge-0/0/2.1 via ge-0/0/1. 0 hidden) + = Active Route.5 via ge-0/0/3.0 [BGP/170] 00:01:10. So let’s think about how you can affect the way that AS65500 sees and selects the route from R4. has a MED of 10 set. Let’s have a look at the route itself to see if the MED value has been sent by R3: [email protected]> show route 10.100.51.51. localpref 100 AS path: 65501 15 I. validation-state: unverified > to 198. since AS Path shows the number of ASs the path traverses. validation-state: unverified > to 198.0. localpref 100 AS path: 15 I. Chapter 7: Border Gateway Protcol (BGP) [email protected]> show bgp summary Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet. Hopefully.51. with AS65501 choosing to go via AS65500: [email protected]# show | compare [edit policy-options policy-statement ANNOUNCE-OUR-RANGE term announce-aggregate-route then] + as-path-prepend “15 15 15”.0/24 *[BGP/170] 00:26:56.0/24 inet.0.100..0 [BGP/170] 00:27:07. localpref 100 AS path: 15 I. - = Last Active. and you can see that AS65501 is sending the advertised route to AS65500 but this isn’t selected due to AS Path length (AS65501 then AS15).51. [edit] [email protected]# commit commit complete 111 .100.51.14 65501 1395 1383 0 5 1:58:31 1/2/2/0 0/0/0/0 Excellent..0 Here you can see that R4 is the active route (denoted by the *).5 15 2183 2204 0 2 1:59:26 0/1/1/0 0/0/0/0 198.0 4 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/ Dwn State|#Active/ Received/Accepted/Damped.51.1 15 727 726 0 10 27:10 1/1/1/0 0/0/0/0 198.0. R4 is now the active path for 10. You can now also see that the second path.0.100.0. MED 10. * = Both 10.0/24.0. but then also propagates this to our other external ASs. 0 holddown. validation-state: unverified > to 198.0: 12 destinations. 198. Let’s see if it can be artificially inflated and have both AS6500 and AS65501 have the best path as R4.100. you have figured out that if you can manipulate the AS Path length then you can affect the routing decision of not only your directly connected neighbor but also peers connected upstream. which has been taken into account in the path selection. in boldface.100. 14 routes (12 active.

0. Hang on. 198. 198. we only set three times AS15 in our export policy.51. localpref 100 AS path: 65500 15 I. which are 10..0. 0 holddown.100.0.100.0/24 from R4 and AS65500’s locally originated route. validation-state: unverified > to 198.100.51.100..9 via ge-0/0/1.13 65500 310 321 0 5 2:18:00 2/2/2/0 0/0/0/0 And here AS14 is sending one route but it is not active and AS65500 is sending two routes.1 15 762 761 0 11 10:30 1/1/1/0 0/0/0/0 198.0: 10 destinations. that’s how you can affect traffic coming into your AS (ingress).0/24 *[BGP/170] 00:17:33.0 3 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/ Dwn State|#Active/ Received/Accepted/Damped.13 via ge-0/0/2.1465501 1431 1417 0 5 2:13:22 1/1/1/0 0/0/0/0 So R4 is still the preferred route but also note that AS65501 is no longer sending two routes but only one. 0 hidden) + = Active Route. 112 Day One: Routing the Internet Protocol Let’s see how this change has affected the path selection: [email protected]> show bgp summary Groups: 1 Peers: 3 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet. So. This is due to AS65501 seeing that the best path to 10..0. validation-state: unverified > to 198.51. . but let’s have a more in-depth look: [email protected]> show route 10/24 inet.0 3 2 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/ Dwn State|#Active/ Received/Accepted/Damped.0/24 is active via AS65500 and you can see that the route from R3 has four times AS15s in its advertised path. 11 routes (10 active.0.0.51.5 15 2216 2236 0 2 2:14:17 0/1/1/0 0/0/0/0 198.0 So you can see that 10.100.100.0.9 15 2206 2296 0 9 15:59 0/1/1/0 0/0/0/0 198.0 [BGP/170] 00:07:38. so why are there four? This is due to using the as-path-prepend which takes what you have set in the policy and prepends it to the announcement which already includes what AS it is coming from. localpref 100 AS path: 15 15 15 15 I.. * = Both 10.51.0. MED 10. so no point in advertising the route back to it! Let’s have a look at AS65501 to see how the path manipulation has worked: [email protected]> show bgp summary Groups: 1 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet. Let’s now see how you can manipulate your traffic heading out of your AS (egress). - = Last Active.51.51.0/24 is via AS65500.100.

1.51.0.100. 23 routes (20 active. AS65501. validation-state: unverified > to 198. and as you already know from the BGP best path selection process. [edit policy-options] + policy-statement SET-LOCALPREF-200 { + then { + local-preference 200.1 AS path: 65500 I.100. + accept.1 AS path: 65501 I. localpref 100 AS path: 65501 I.0. 0 hidden) + = Active Route.6 via ge-0/0/2. so one can reach the rest of the Internet. validation-state: unverified > to 198.0.0: 20 destinations.0/0 from the perspective of R3 and R4: [email protected]> show route 0/0 inet.0/0 *[BGP/170] 00:05:05.0.1. from 93. Why isn’t traffic sent destined to the Internet via AS65501? Let’s have a look at 0.0/0 *[BGP/170] 00:05:28.0.2 via ge-0/0/3. validation-state: unverified > to 198. 0 holddown. This is due to the default local preference for BGP learned routes being set at 100.100.51. With local preference. * = Both 0.0 [BGP/170] 00:08:01. - = Last Active. 0 hidden) + = Active Route. even though they have set a local preference.51.0. * = Both 0. so let’s get back onto R3 and write an import policy to set the local preference to 200: [edit protocols bgp group external neighbor 198. validation-state: unverified > to 10.100. localpref 100.0 Here. localpref 100 AS path: 65500 I.0. and also via R4 (AS65500) using iBGP.51. Chapter 7: Border Gateway Protcol (BGP) AS65500 and AS65501 are now sending a default route. You might also notice that the paths have a local preference of 100 associated with them.0. as well as their locally originated route. 26 routes (21 active.10 via ge-0/0/3.5 via ge-0/0/2. from 92.0 [BGP/170] 00:02:31. localpref 100 AS path: 65500 I. R3 is seeing a default route from AS65500. 0 holddown.10] + import SET-LOCALPREF-200. Let’s have a look at R4 now: [email protected]> show route 0/0 inet.0. validation-state: unverified > to 10.0: 21 destinations.6 via ge-0/0/4. the higher the value the more preferred the route is. eBGP is preferred over iBGP in any tie-breaker.0. localpref 100.0.0 And R4 is seeing the default route from AS65500 and R3 (AS65501) via iBGP. - = Last Active. + } + } [edit] [email protected]# commit 113 .0.0 [BGP/170] 00:02:31.

24 routes (21 active.51.100.0 [BGP/170] 02:53:48.0.0.51.0 6 3 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/ Dwn State|#Active/ Received/Accepted/Damped.2. let’s see how that has affected the routing table: [email protected]> show bgp summary Groups: 2 Peers: 5 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.10 (AS65501) to have a local preference of 200. localpref 100 AS path: 65500 I.51. validation-state: unverified > to 198.6 65500 385 384 0 2 2:51:51 0/3/3/0 0/0/0/0 198. validation-state: unverified > to 198.0 [BGP/170] 02:54:44.100. localpref 200 AS path: 65501 I.51. It looks like this: . - = Last Active. 90. which includes AS65500’s locally originated route.0.1.10 via ge-0/0/3. 0 holddown.100.113.100.0 192.0/0 *[BGP/170] 00:20:07.100.0 [BGP/170] 00:17:33.6 via ge-0/0/4. validation-state: unverified > to 198.51.100. localpref 100 AS path: 65500 I. 0 hidden) + = Active Route. validation-state: unverified > to 198.100.1 15 182 178 0 4 1:16:33 0/0/0/0 0/0/0/0 198. which was not desired: [email protected]> show route protocol bgp inet. the policy is now very specific.6 via ge-0/0/4.0/0 exact.0: 21 destinations.51. localpref 200 AS path: 65501 65500 I.0.0. localpref 100 AS path: 65500 65501 I. * = Both 0.0. It looks like the local preference for all routes learned from AS65501 was set.1 15 749 749 0 1 11:46:41 Active 92.6 via ge-0/0/4.0 203.51.100. localpref 200 AS path: 65501 I. validation-state: unverified > to 198.0/24 *[BGP/170] 00:51:47..0.1.. + } [edit] [email protected]# commit With the addition of the patch.1 15 306 321 0 8 1:54:17 0/0/0/0 0/0/0/0 91.10 via ge-0/0/3.10 via ge-0/0/3.0/24 *[BGP/170] 00:51:47.0 Let’s use the power of the Junos OS routing policy to fix this and only set the local preference for 0/0 learned from AS65501: [email protected]# show | compare [edit policy-options policy-statement SET-LOCALPREF-200] + from { + route-filter 0. 114 Day One: Routing the Internet Protocol So after setting the local preference for routes learned via neighbor 198.0.10 65501 115 111 0 9 48:54 3/3/3/0 0/0/0/0 Oops. validation-state: unverified > to 198.51.100.0.1.51.

Chapter 7: Border Gateway Protcol (BGP)

[email protected]# show policy-options policy-statement SET-LOCALPREF-200
from {
route-filter 0.0.0.0/0 exact;
}
then {
local-preference 200;
accept;
}

This policy now says that if the route is exactly 0.0.0.0/0 then it will set
the local preference to 200. As BGP policy has an implicit accept, any
routes that do not match 0.0.0.0/0 will still be accepted but with the
default local pref of 100. Let’s see how this looks now:
[email protected]> show route protocol bgp
inet.0: 21 destinations, 25 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/170] 00:30:04, localpref 200
AS path: 65501 I, validation-state: unverified
> to 198.51.100.10 via ge-0/0/3.0
[BGP/170] 00:27:30, localpref 100
AS path: 65500 I, validation-state: unverified
> to 198.51.100.6 via ge-0/0/4.0
192.0.2.0/24 *[BGP/170] 01:01:44, localpref 100
AS path: 65501 I, validation-state: unverified
> to 198.51.100.10 via ge-0/0/3.0
[BGP/170] 03:03:45, localpref 100
AS path: 65500 65501 I, validation-state: unverified
> to 198.51.100.6 via ge-0/0/4.0
203.0.113.0/24 *[BGP/170] 03:04:41, localpref 100
AS path: 65500 I, validation-state: unverified
> to 198.51.100.6 via ge-0/0/4.0
[BGP/170] 00:08:14, localpref 100, from 92.1.0.1
AS path: 65500 I, validation-state: unverified
> to 10.0.0.6 via ge-0/0/2.0
[BGP/170] 01:01:44, localpref 100
AS path: 65501 65500 I, validation-state: unverified
> to 198.51.100.10 via ge-0/0/3.0

Fantastic. The network is preferring 0.0.0.0/0 from AS65501 and all
other routes are at their default.
R4 also shows that it is preferring the path for 0.0.0.0/0 from
AS65501, going via R3 who has advertised it via iBGP:
[email protected]> show route protocol bgp
inet.0: 20 destinations, 23 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/170] 00:18:12, localpref 200, from 93.1.0.1
AS path: 65501 I, validation-state: unverified
> to 10.0.0.5 via ge-0/0/2.0
[BGP/170] 00:30:51, localpref 100
AS path: 65500 I, validation-state: unverified
> to 198.51.100.2 via ge-0/0/3.0

115

116

Day One: Routing the Internet Protocol

So, traffic has been affected. Note how it exits AS15 using the local
preference and is manipulated into how it enters the AS. Looking at
the small amount of configuration taken to achieve this, you can see
how powerful the Junos OS route policy can be, especially when tied
into BGP.

Summary
You have made it to the end of the BGP chapter and the rather in-depth
tutorial!
No matter how much BGP is explained, explanations only seem to
scratch the surface of this powerful protocol. In this tutorial you have
learned the differences between iBGP and eBGP, best path computation, and how you can manipulate how the outside world views your
prefixes. Through the use of some simple routing policy you have also
been able to control how traffic exits the AS.
The Junos OS with its very granular routing policy allows the user to
leverage the true power and scale of BGP with what can be considered
some very simple CLI commands. It’s no surprise that due to BGP’s
maturity as a protocol and it’s scalability that it has also been used for
the likes of VPLS, L2VPN, and EVPN, which allows it to carry MAC
address information within its BGP updates.
Some great information on BGP can be found at the following links on
Wikipedia and at the Juniper’s TechLibrary:
https://en.wikipedia.org/wiki/Border_Gateway_Protocol
http://www.juniper.net/techpubs/en_US/junos15.1/information-products/pathway-pages/config-guide-routing/config-guide-routing-bgp.
html
Also recommended are the following books:
http://www.juniper.net/us/en/training/jnbooks/oreilly-juniper-library/
junos-enterprise-routing/
http://www.ciscopress.com/store/routing-tcp-ip-volume-ii-ccie-professional-development-9781578700899

Chapter 8
Route Summarization

If, for a moment, we were to compare routers to PCs in terms of
memory usage, PCs have an advantage in that more memory can
usually be quite easily purchased and installed.
Routers, on the other hand, do not have virtual memory. Memory can
be expanded, but it’s usually at a premium and even then, on a live
network, the administrator needs to find downtime to install it.
Memory management on a router is very critical and potential issues
should be identified and corrected before they become serious.
The purpose of routers is to route data between subnets. The router
needs to know which subnets to have reachability to because if the
router receives a packet with a destination the router is not aware of,
the router will drop the packet.
And every route the router is aware of needs to be stored in the routing
table, so the more routes that are in the routing table the more memory
is consumed. To put this into perspective for a moment, if the entire
BGP table from the Internet was loaded into a router, the BGP database would consume over 1.7GB of memory. If a router on a corporate
LAN has 1GB RAM, the router simply would not have enough
memory.

118 Day One: Routing the Internet Protocol In the case of Internet routes being redistributed into a corporate network. If summarization were to be used. and often have hundreds or thousands of subnets where each router needs to know how to reach each individual subnet. which in Figure 9. This means the memory on each router is now being filled with those routes.x. multiple networks can be joined so they appear in the routing table as a single subnet instead of as multiple entries.x.7. on the other hand. then instead of creating a default route.1 Summarizing Four Subnets into a Single Route In this situation.23.10. Summarization is a means of compressing the routing table and by using summarization.1 shows an example of multiple subnets being summarized. whether router E has the route in its routing table or not. then it should send the packet to the default route. the default route of 0.0. In this case there are six routers.0. the administrator would use simple bit matching to determine which common bits are in use with each subnet. are different.1 is 21 bits.x networks could be made into the single network 10. Routers A through E are each attached to a network that begins 10. The link between routers E and F uses subnet 172.0/0 is advertised into the LAN so that routers do not need to know every subnet that is available on the Internet. With summarization.10.x.0. however that would mean that all traffic is sent to router E. Figure 8.10.0/21. under normal circumstances. The bit matching should be as long as possible. the 10. When router F receives a packet destined for one of the subnets that . a router just needs to know that if a particular subnet is not in its routing table. Corporate networks. Figure 8. router F could have a default route to router E.0/24.

the offices in the U. for example 10. will be configured to take three subnets that are advertised by IS-IS and summarize them into a single subnet.2.0.2.S.x. could use subnets beginning with 10.0/22. it is important to realize that if a subnet is directly connected to a router – for example subnets 10. This way the routers in Europe and the Middle East will receive a single route instead of potentially hundreds of routes.150.x. Chapter 8: Route Summarization 10.20.0/24.10. At the same time. and the Middle East might.2 gives a graphical representation of what this scenario achieves.0/x. 10. so these should automatically start appearing in the routing table of all routers in the LAN: [email protected]> show interfaces terse lo0.1/24 10.0/24 are directly connected to router vMX2 – then these subnets will not be summarized and will still be advertised as separate subnets by OSPF.3.1/24 10.x.0004 Figure 8. which are routers vMX2 and vMX4.S.20.20.100. 119 . it will immediately forward it to router E. In this situation.x.0001.1/24 192.4 --> 0/0 iso 49.0.0. to the WAN could then summarize the routes to 10.x. These have therefore created three new subnets and as IS-IS has already been configured to advertise subnets connected to interface lo0. whereas Europe could use 10. and the Middle East could use networks beginning 10.1. Before this can be done.10.168. The amount of subnets could increase substantially if each subnet was a /25 or less. the U.S. Configuring Route Summarization In the following scenario. a multi-national corporation with offices in the U. the ASBRs. The routers that connect.1 is a small LAN and therefore would not benefit from summarization.200.10. The three subnets from router vMX6 are summarized to a single route.10.100.20.100. three new IP addresses have been added to the loopback interface of router vMX6.1.1.0 Interface Admin Link Proto Local Remote lo0. say.0. Although Figure 8.x. then router F will discard the packet. the three subnets from router vMX6 are then filtered to prevent these separate subnets from being advertised to routers vMX0 and vMX1 in the OSPF domain.0/24 and 10.0 up up inet 10. Europe. Should the subnet not be covered by that route.0003.0001.0/21 covers.. In order to work around this limitation.

0/16 inet.1.0.0 10.0.0/16 command were to be run on this router.5.1.0. 120 Day One: Routing the Internet Protocol Figure 8.0 10.2 via ge-0/0/2. - = Last Active. as these subnets were added to the loopback interface and as such OSPF treats these as host routes. once as a /24 and once as a /32.1/32 *[OSPF/150] 00:00:31.0/24 *[OSPF/150] 00:00:31. metric 2. router vMX1 will be used to test whether the summarization has worked successfully and to test reachability.1/32 *[OSPF/150] 00:00:31.20. metric 2.20.20.2 via ge-0/0/2. tag 0 > to 10. tag 0 .0 10. 0 holddown.20.0.0/24 *[OSPF/150] 00:00:31.5. metric 2. metric 2. 32 routes (29 active.0.2 via ge-0/0/2.3.20. metric 2.2. tag 0 > to 10.0: 29 destinations.2 Summarizing Routes from Router vMX6 For the purposes of this scenario.2.0 10.0/24 *[OSPF/150] 00:00:31. tag 0 > to 10. the subnets should be listed twice.20.5.5. and if the show route 10. 0 hidden) + = Active Route. tag 0 > to 10.20.2 via ge-0/0/2.0. * = Both 10. Let’s check: [email protected]> show route 10.

This is done by using the same policy statement that was created when performing redistribution.1 PING 10. metric 2. whereas with a /16 prefix.20. the router would need to process the packet and forward it to the ASBR.20.1.20. The policy statement in use on vMX4 currently is: [edit] [email protected]# show policy-options policy-statement RIP-TO-OSPF term 1 { from { protocol rip.1.0. 0% packet loss round-trip min/avg/max/stddev = 3.0/22 While it is possible to summarize these routes to 10.0 Router vMX1 should also be able to ping one of the IP addresses too.1.1. In this scenario.5. the policy statement works from the top down and stops once there is a match.20.20. if someone attempted to send a packet to 10.1.20.0/22: set routing-options aggregate route 10.105 ms 64 bytes from 10.1. tag 0 > to 10.20.1: icmp_seq=2 ttl=63 time=5.1.3.0.1: icmp_seq=3 ttl=63 time=4.2 via ge-0/0/2.500/5. 4 packets received.20. in this case 10. therefore the term to tell OSPF to redistribute the aggregate route should ideally be added first.0.1): 56 data bytes 64 bytes from 10. the routing protocol needs to be told to export this route to neighbors. For example. } 121 . This would affect each router in the path of the packet all for the ASBR to discard the packet anyway.20.20. two things need to be added to the configuration. } then reject.1/32 *[OSPF/150] 00:00:31.20.1 (10.20.881/4.346 ms ^C --- 10. the IP addresses added on router vMX6 can be summarized to a single route – 10.1. Once the aggregate router has been created. it’s considered best practice to use the longest match possible so that the router isn’t processing unnecessary traffic. the packet would be dropped by the router.2 via ge-0/0/2. the changes will first be made on router vMX4.0.1. Chapter 8: Route Summarization > to 10.881 ms 64 bytes from 10. In this case. prefix-list ONESEVENTWOTWENTYTHREEONE.0 10.1.20.666 ms 64 bytes from 10. by using a /22 prefix.1: [email protected]> ping 10. As with redistribution.0.5. This tells the Junos OS what the routes will be summarized to.666/0. The first is what is known as an aggregate route.5.1: icmp_seq=1 ttl=63 time=3.1: icmp_seq=0 ttl=63 time=4.0/16.1 ping statistics --4 packets transmitted.20.693 ms In order to perform summarization.

The new term will then be added as Term 1. } then reject. just to keep things tidy: rename policy-options policy-statement RIP-TO-OSPF term 2 to term 3 rename policy-options policy-statement RIP-TO-OSPF term 1 to term 2 After a quick check to see if the terms have been renumbered correctly. an accept has been added at the end of this term. } term 3 { from protocol rip. prefix-list ONESEVENTWOTWENTYTHREEONE.0. therefore the term needs to specify to match routes from protocol aggregate and to match the subnet specified when added the routing option. although in theory. The new term is really just redistributing from the protocol aggregate to OSPF.20. As the policy statement is using numbered terms. When a policy statement is numbered. so in reality this term could have been called summarize. } then reject. if the policy statement is viewed. Term 1 can then be recreated with a new rule: [edit] [email protected]# show policy-options policy-statement RIP-TO-OSPF term 2 { from { protocol rip. the numbering convention was retained: [email protected]# show policy-options policy-statement RIP-TO-OSPF term 2 { from { protocol rip. the accept at the end of the policy statement should already accept this term: set policy-options policy-statement RIP-TO-OSPF term 1 from protocol aggregate set policy-options policy-statement RIP-TO-OSPF term 1 from routefilter 10. and the term currently numbered 1 to Term 2. } then accept.0/22 exact set policy-options policy-statement RIP-TO-OSPF term 1 then accept Once this is added. it would be ideal to change Term 2 to Term 3. } . prefix-list ONESEVENTWOTWENTYTHREEONE. } then accept.20. the Junos OS only sees this as a label as opposed to a numerical value.0. 122 Day One: Routing the Internet Protocol term 2 { from protocol rip. it’s interesting to see that the new term has been added after Term 3.0/22. which in this case is 10. Finally. but in the case of this scenario.

the insert command is used. The first step is to rename the terms to match those changes made on vMX4. } term 1 { from { protocol aggregate. In order to move Term 1 to before Term 2. but as there are two ASBRs.20.0. the summarization won’t be effective in decreasing the size of the routing table.0/22 exact.0/22 exact. Router vMX4 has now been configured. } term 3 { from protocol rip. route-filter 10. route-filter 10. } then accept. } then accept. Chapter 8: Route Summarization term 3 { from protocol rip. The command to add the aggregate route should be the same on both ASBRs: set routing-options aggregate route 10. Although in theory the terms could be given different names. therefore the same configuration should be applied to vMX2. as it helps when it comes to supporting it later on: 123 . } then accept. In order to move Term 1 up the list.20.0.0.20. it is better to keep naming conventions common across your network. } then reject.0/22 The policy statement on router vMX2 is called IS-IS-TO-OSPF as opposed to RIP-TO-OSPF on vMX4. the following command is applied: insert policy-options policy-statement RIP-TO-OSPF term 1 before term 2 The policy statement should now appear in the correct order: [edit] [email protected]# show policy-options policy-statement RIP-TO-OSPF term 1 { from { protocol aggregate. prefix-list ONESEVENTWOTWENTYTHREEONE. } term 2 { from { protocol rip. } then accept.

2. 0 holddown. metric 0.1/32 *[OSPF/150] 00:08:51. in Chapter 6 the term to filter the router included a prefix-list.2 via ge-0/0/2.3. and longer keywords can be used to determine whether to match just that subnet. orlonger. By using a route filter.1/32 *[OSPF/150] 00:08:51.0: 31 destinations.0. or subnets that begin the same. metric 2. in addition the exact.1.0 10.5.0/22 exact set policy-options policy-statement ISIS-TO-OSPF term 1 then accept Finally. the new term is created: set policy-options policy-statement ISIS-TO-OSPF term 1 from protocol aggregate set policy-options policy-statement ISIS-TO-OSPF term 1 from routefilter 10. are still appearing in the routing table. 124 Day One: Routing the Internet Protocol rename policy-options policy-statement ISIS-TO-OSPF term 2 to term 3 rename policy-options policy-statement ISIS-TO-OSPF term 1 to term 2 Once the terms have been renamed.20.5 from protocol isis As you may recall. In this case. tag 0 > to 10.0.2.5. or ones that don’t begin the same but match the rest of the subnet. the filter is first applied to router vMX2.0/24 *[OSPF/150] 00:08:51. metric 2. What is also unexpected is that the routes. it has instead increased it: [email protected]> show route 10.20.0.0 10.0. tag 0 > to 10. Instead of decreasing the size of the routing table. metric 2. the term will simply be called 0.3. the new term is inserted before what is now term 2: insert policy-options policy-statement ISIS-TO-OSPF insert term 1 before term 2 Once the configuration has been committed. 0 hidden) + = Active Route.20. 34 routes (31 active.20.0/24 *[OSPF/150] 00:08:51.3.2 via ge-0/0/2. there is no need to create a prefix list before creating the policy statement. * = Both 10.2 via ge-0/0/2.0 10.0 10.2 via ge-0/0/2.0 10.2 via ge-0/0/2. metric 2. tag 0 > to 10. tag 0 > to 10. instead of renaming them.20.0 To prevent these subnets from being advertised.5: set policy-options policy-statement ISIS-TO-OSPF term 0. The issue is that there are now three terms that need renaming. tag 0 > to 10.20. - = Last Active.0.0/24 *[OSPF/150] 00:08:51.0.5. tag 0 > to 10.20.0. metric 2. The configuration in this scenario uses a different method of specifying which routes to suppress – a route-filter.1/32 *[OSPF/150] 00:08:51.1.5.20. therefore. even though they have been summarized. the routing table on vMX1 can be checked to confirm the new aggregate route has been added (bold in the output).0 10. a filter should be applied to the ASBRs. tag 0 > to 10.0/16 inet.20.0. metric 2. .1 via ge-0/0/1.5.0.0/22 *[OSPF/150] 00:04:38.5.0.2 via ge-0/0/2.

tag 0 > to 10.1 via ge-0/0/1. 0 holddown.20.3.0/22 *[OSPF/150] 00:05:57. * = Both 10. 0% packet loss round-trip min/avg/max/stddev = 4.20.0/22 longer set policy-options policy-statement ISIS-TO-OSPF term 0.20.1 ping statistics --4 packets transmitted. - = Last Active.1): 56 data bytes 64 bytes from 10.5 from routefilter 10.1.0/22 longer set policy-options policy-statement RIP-TO-OSPF term 0. You can read more about route filters at the following URL: http://www.1.1: icmp_seq=1 ttl=63 time=6.1/topics/ usage-guidelines/policy-configuring-route-lists-for-use-in-routingpolicy-match-conditions. Chapter 8: Route Summarization NOTE The best resource to learn more about route filters is from Juniper’s Tech Library.5 then reject insert policy-options policy-statement RIP-TO-OSPF term 0.1: icmp_seq=2 ttl=63 time=4.20. 4 packets received.0/22 but you do want to suppress routes that are longer than this: 10.1 (10.0/24.5 from protocol rip set policy-options policy-statement RIP-TO-OSPF term 0.1.0.0/16 inet.0. metric 0.5 from routefilter 10.1 PING 10. Term 0. 28 routes (25 active.781/6. therefore the route-filter command is followed with the keyword longer: set policy-options policy-statement ISIS-TO-OSPF term 0.5 before term 1 Once done.20.20.0.20.html.net/techpubs/en_US/junos15. and 10.341 ms 64 bytes from 10.5 before term 1 After committing these changes.1. the same rules can be applied to router vMX4 and the term inserted before term 1: set policy-options policy-statement RIP-TO-OSPF term 0.3.5 then reject Here.979 ms 125 .20.1.1: icmp_seq=3 ttl=63 time=6.0.1.20.421 ms 64 bytes from 10.0.0/24. 10. 0 hidden) + = Active Route.20.1. a ping to one of the subnets should prove that routes from vMX1 to vMX6 have not been suppressed inadvertently: [email protected]> ping 10.0/22 is present. In this scenario. you don’t want to suppress 10.5 is inserted before Term 1: insert policy-options policy-statement ISIS-TO-OSPF insert term 0.20.juniper.751 ms ^C --- 10.751/0.0.341/5.0.1. but the individual /24 routes are not: [email protected]> show route 10.1: icmp_seq=0 ttl=63 time=5.0: 25 destinations.1.610 ms 64 bytes from 10.20.20.20.0/24.20.0 Finally. router vMX1’s routing table should be checked once more to ensure that the route 10.2.20.20.

It can decrease the number of routes in a routing table. Where to Go Next While the authors have attempted to make this book as informative as possible. there are 11 subnets. it is nonetheless a “fundamentals” book. That said.x.x. visit the Day One library and browse the Junos OS Fundamentals Series suite of books: http://www. 126 Day One: Routing the Internet Protocol Summary Summarization is useful for several reasons.x. The administrator could use 172.net/dayone. it’s unlikely because in this case the MX routers that are in this LAN wouldn’t really benefit from this approach. MORE? If you want to learn more about the protocols covered in this book. therefore summarization really needs to be used when subnets are in their hundreds for the benefit to be felt. Summarization could in theory decrease this number to just three.net/documentation. solutions.juniper.x addresses on the other site and summarize the addresses on both sites to a single address. . and network configuration examples for the entire Junos OS at Juniper’s TechLibrary: http://www.juniper. meaning there’s enough information to get you started.x.x addresses on one site and 10. and this in turn increases available memory and reduces the amount of processing the router needs to perform. but that doesn’t mean you can stop here. There are also complete documentation guides. Summarization could be used when there are two large sites that are connected via a WAN connection. If you use the topology given at the beginning of this book.

Do Routing The Ip

Share

Rating

Date

Size

Views

Categories

Transcript

Junos® OS Fundamentals Series

Select your language