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
Security policies are one of the biggest tasks when working with firewalls. They define how the device handles traffic, whether it lets it through, make it subject to deeper analysis (IDP, AppFW, UTM, etc.) or denies it. It is essential to know the available troubleshooting options and how to use them.
Lets start with short security policies theory recap.
Three categories of security policies exist:
- regular – defined in a zone context (from-zone to-zone). They are unidirectional and evaluated as first.
- global – defined without a zone context and applied to any traffic not handled by regular policies.
- default – the action applied when traffic did not match any regular or global policies. The default “deny” can be changed to “permit” through explicit configuration.
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.
This post presents how to configure BGP as routing protocol over an IPSEC hub and spoke VPN.
The following diagram depicts the network architecture:
This security related blog post discusses aggressive aging, initial timeout, SYN and sequence checking in TCP connections – few of the session global parameters on SRXs.
The SRX device stores information and details about the ongoing sessions in its session table. The bigger the device the bigger the table. Product datasheets list the exact values (http://www.juniper.net/us/en/products-services/security/srx-series/?c_title=Datasheets#literature). However in none of the boxes is the session table unlimited and when it gets full, no new sessions are allowed. The aggressive sesson aging is used to minimize this impact. The device enters aggressive mode when the defined threshold of the session table utilization is reached. While in this mode the device enforces shorter idle timers as the ones defined in the applications. The sessions are removed sooner from the session table, which in turn frees resources for new ones.
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 blog post we will discuss the SRX VLAN retagging feature and show you how to configure it.
SRX devices are also capable to operate in transparent mode. In transparent mode forwarding decisions are based on layer 2 information, instead on layer 3 information. In transparent mode SRX devices act like a layer 2 switch and support tagged and untagged interfaces.
For certain layer 2 designs it is required to change the VLAN ID between interfaces. For example a tagged ingress frame with VLAN ID 10 must be changed to VLAN ID 20 on the egress interface (and vice versa).
Obviously VLAN retagging cannot be configured on access ports. Only trunk ports support this feature. However, keep in mind that it is possible to map untagged traffic received on a trunk interface to a VLAN.
Please see below an example configuration
As you can see the interface is configured as a normal layer 2 trunk interface. What is new in this configuration is the “vlan-rewrite translate” command.
Two values must be specified when configuring the “vlan-rewrite translate” feature
The 1st value represents the “incoming” VLAN ID, i.e. the VLAN ID used in the received frame
. The 2nd value represents the “target “ VLAN ID, i.e. the VLAN ID the frame header will be rewritten to.
Simply put, the 1st value is the input VLAN ID and 2nd value is the output VLAN id.
Keep in mind that that there is a restriction that both of these VLAN ids must be different than the “native-vlan-id” value. In Junos the “native-vlan-id” statement defines the VLAN for received untagged frames.
For correct configuration the “target” VLAN IDs needs to be defined in the vlan-id-list (either explicitly or as a member of the range) on the interface.
VLAN retagging / translation happens of course in two directions. Frames with the target VLAN ID are send out the interface with the “incoming” VLAN id.
In the example shown above VLAN ID 999 is rewritten to VLAN ID 1000. This means a frame with the VLAN ID value 999 received on the ge-0/0/5 interface is rewritten to VLAN ID 1000. The SRX device then processes the frame as a member of the VLAN 1000. In the opposite direction – a frame with VLAN ID 1000 leaves interface ge-0/0/5 tagged with VLAN ID 999.
A small reminder: Do not forget that each VLAN requires a bridge domain configuration under the [edit bridge-domains] stanza. Otherwise the device will not forward frames in that VLAN. However a bridge domain is not needed for the “incoming” VLAN
The command below is useful for troubleshooting because it shows the rewriting statistics. Either the interface or the “incoming” VLAN ID can be specified as the command parameters.
In this post we described the SRX VLAN rewrite functionality when the devices is operation in transparent mode. This feature is very helpful and often used in migration scenario’s.
Address translation (NAT) is one of the big topics on the JNCIE-SEC exam. Generally the NAT area is overall very broad covering source NAT and destination NAT with or without port translation, static NAT, address persistency, etc. This text presents only a specific part of this area – namely an option how to use the OSPF protocol for advertising networks used for translation. This example does not cover the overall device configuration – such as interfaces, zones, security policies, etc.
The topology depicted below was used for this example.