This article will focus on the LDP protocol. Although this protocol is quite simple, I often had some doubts about some LDP Junos commands and behaviours. This is the aim of this new article: clarify basic LDP stuffs.
To speak about LDP configuration on Junos, we will use this very simple and atypical topology. The IGP is OSPF (a single area) and LDP is activated only on physical interfaces.
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
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 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