In networks that use BGP as part of their routing protocols it is very important to understand how the BGP route selection works. BGP is an important part of the JNCIE exams so this information is also very useful for candidates preparing for any of the practical exams.
BGP route selection can be broken down into discrete steps so it then becomes easy to understand how you can influence the route selection with the appropriate attributes. So lets have a look at the algorithm used in Junos OS in a somewhat simplified form. For all detailed steps I refer to http://www.juniper.net/techpubs/en_US/junos13.1/topics/reference/general/routing-ptotocols-address-representation.html
Before we can start the actual BGP route selection the router needs to make sure that the route is valid, so it checks for Martian routes, AS loops and next-hop reach-ability. The actual route selection steps are:
Anyone that ever studied OSPF was probably confused about all the different link-state advertisement types (LSA 1,2,3,4,5,7 etc) at some point in time. Equally confusing are all the possible area types. OSPF allows for 5 different area types, which provides flexibility in deployments but also introduces quite a bit of complexity.
In this blog post we will discuss the different area types, their general use and especially focus on the configuration intricacies of the “stubbie” area types.
RFC2328 defines area as: “OSPF allows collections of contiguous networks and hosts to be grouped together. Such a group, together with the routers having interfaces to any one of the included networks, is called an area”. Now isn’t this crystal clear 🙂
Lets say you have a network with 100 routers in it. You now have to make a design choice how to organize this network. The basic options when using OSPF are:
– Single area: all 100 routers share the same information
– Multiple area’s: split the 100 routers into multiple area’s, for example 4 area’s with each 25 nodes.View article
In my recent training sessions I noticed that intermediate and even advanced users of JUNOS struggled with some of the basics of routing on Juniper devices. Of course they know how to create a static route with the basic settings, and maybe even how to create a aggregate route for summarization with BGP or ISIS/OSPF. But they are not familiar with some of the more esoteric settings that are possible in the [edit routing-options] hierarchy.
In this post I’ll discuss the following topics as they are useful for both network engineers and JNCIE candidates.
1. Static routes
2. Aggregate routes
3. Generate routes
In this article we will explain the several protocols and Junos configurations that can be used to design a simple VPLS domain. We will also provide some troubleshooting commands and some recommendations.
The topology for the different scenarios covered is depicted below:
As you can see, we want to interconnect 3 CEs (in grey) in a VPLS architecture. Each CE is connected via a VLAN to a dedicated PE. The core network is made of P routers that only have ISIS and LDP enabled. A Route Reflector is in charge of distributing BGP NLRI between the PEs.
We will cover different scenarios, but each time the result should be the same: the 3 CE can communicate between each other. The 3 CE are in the same subnet (192.168.1.0/24)
For any OSPF network engineer, and JNCIE candidates, it is crucial to understand the tools to improve the scalability and stability of the OSPF domain. As with any routing protocol the main instrument for this is some form of summarization and/or filtering. By limited sharing of details between different parts of the OSPF domain any instabilities can be hidden, resulting in less CPU and memory usage on the router RE’s.
OSPF has a few restrictions on where you can summarize and/or filter routes in the network.Within an area summarization is not allowed as all routers need to share the same database in an area. A somewhat general rule is that OSPF only can summarize when route / LSA conversion is taking place. For internal routes this is done on the ABR when converting intra-area route information (type 1 and 2) into inter-area route information (type 3). For external routes this is done at redistribution ASBR’s when non-OSPF route information is converted into External OSPF route information (type 5 or 7), as well as on nssa area ABR’s when converting NSSA External route information (type 7) into External route information (type 5).
For OSPF with Junos the following options exist:
1. Inter-area internal LSA summarization and filtering on the ABR using area-range command
2. Inter-area internal LSA filtering on the ABR using the network-summary-import/export policies
3. External route summarization and filtering on the ASBR using aggregate routes and export policies
4. Inter-area NSSA external route summarization and filtering on the NSSA ABR using nssa area-range command.
5. Route-table filtering of external routes using import policies
For Stub and NSSA area’s normally some form of default routes are also configured for reach-ability which is also a form of summarization. A 0/0 route is the ultimate form of summarization. The Stub and NSSA area intricacies will be part of different blog post in the future so this will not be covered here.
As a JNCIE you are expected to known how to troubleshoot misconfigurations in your given network and fix them. Troubleshooting IGP neighbor issues is easiest if you can compare the configurations of the routers involved. However this is not always possible as in some situations you can not view the configuration of all routers. An example of real-life is a MPLS L3 VPN with unmanaged CE devices where OSPF is used between PE and CE. This blog covers OSPF adjancency issues that might arise from misconfiguration of parameters between OSPF neighbors.
For troubleshooting routing adjacencies there are basically three tools within JUNOS. These are syslog, traceoptions, and monitor traffic interface. Of course the show commands can also be of use, but in many cases they are not useful. The syslog output might be useful to detect problems with your OSPF neighbor but typically it doesn’t specify what caused your neighbor going down as shown in the output below.
In this article we will configure an ISIS multi-area network and also explain some part of the ISIS theory.
For network guys ISIS is not a goddess in Ancient Egyptian religious beliefs but rather, the Intra Domain routing protocol specified by the IEC and then extended by the IETF.
IS-IS was first developed for the DECNET project Phase V by ISO:IEC. It was the first Intra AS (Autonomous System) network protocol, but only for network equipment that supported the OSI model and thus a CLNP stack (CLNS systems) : Connectionless Network Protocol. IS-IS was not designed by default for IP. The first version was published in 1987: ISO10589, then a second version in 2002 : ISO10589:version 2. At the beginning of the 90th : the IETF ISIS Working Group specified IP support for ISIS in RFC 1195. Other RFCs after that have been published to enrich the RFC 1195. IP support for IS-IS is also referred to as Integrated IS-IS. ISIS stack’s :
- IS-IS is conveyed directly at Layer 2
- Even though IS-IS was not initially designed for IP, it provides a simple way to add new extensions by using TLV (Type Length Value) fields.
- Indeed, ISIS data is conveyed by using the TLV method : That was the case for IPv4 and then IPv6 extension and recently for SPB. The concept is: Just adding new TLVs for a new protocol family and If you don’t support a given TLV just silently ignore it. Note: TLV has been also extended with sub-TLV.
The Basis :
In the whole article we’ll speak about:
- IS: Intermediate System (This is the router)
- Circuit: it’s a link between 2 IS
- Neighbor: a directly connected IS on a Circuit
- LSP: Link State PDU (packets that transport the IS-IS database of a router)
- Adjacency: IS-IS “session” established between 2 IS directly connected allowing LSP exchanges.
- Point to Point (P2P) link: implicit P2P link like for example Sonet or Frame Relay (not multipoint) but also a multipoint link (Ethernet) configured explicitly in Point to Point (useful when only 2 routers are connected on an Ethernet segment).
- Pseudo-Node: One specific router on a LAN.
- Area : Like OSPF, this is a group of routers that are in the same ISIS flooding domain.
- Level : Hierarchical level. Only 2 Levels in IS-IS
- Leaking : ISIS routes leaked from an IS-IS level to another.
- Redistribution : Injected routes into IS-IS (coming from other protocols: static, RIP, BGP…)
In this post we explain the feature defined in the RFC 4610 “Anycast RP using Protocol Independent Multicast” and its configuration on Junos devices.
PIM sparse mode is the protocol that allows to build the multicast distribution tree in IPv4 or IPv6 Global Routing environment (not MPLS) from a Source of a stream and a set of multicast Subscribers.
A multicast stream is uniquely identified by a couple of addresses named (S;G) :
– The IP address of the Source : a unicast IPv4 or IPv6 address
– The Multicast IP address of a multicast group : an IP IPv4 (range 224/8) or IPv6 (range FF00::/8)
Usually final subscribers don’t know the source(s) of a given multicast stream but only the Group address of this one. They used a protocol like IGMPv2 or MLDv1 that simply provides interfaces to “Join” or “Leave” a given multicast group G.
N.B. : Enhanced protocols like IGMPv3 or MLDv2 provide the ability to also convey the associated source S of a given group G (not the scope of this post)
Therefore, IGMPv2 or MLDv1 protocols convey ASM information (Any Source Multicast). Its notation is (*,G) and refers to any source that forwards traffic under the multicast G address. In contrary, SSM information (Source Specific Information) refers to a specific stream (S;G).
PIM router receives ASM or SSM information from subscribers and translates them in ASM or SSM PIM messages :
– IGMP Report / MLD Listener report are translated in PIM Join message
– IGMP Leave / MLD Listener done are translated in PIM Prune message