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.
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
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.