News, and site update!

So I have moved the blog from Tumblr over to WordPress, and the new DNS propagation should be completed by the end of the day.

On a sad note, I did not pass the JNCIE-ENT Beta exam. Back to the drawing board on that.

In a future post I will talk about migrating a MX Virtual Chassis to MX MC-LAG configuration. This should be exciting.
– Clay

JNCIS-SP – Intro to IS-IS

While waiting to hear back on the results of my JNCIE-ENT exam I have decided to start learning about the service provider realm. In particular there are many techniques in the service provider realm that could be used to enhance the toolset of any engineer, and potentially can be used to re-think the architecture of any enterprise. In this post I will discuss IS-IS, and how to perform a basic configuration of it.

What is IS-IS?

IS-IS is an interior gateway protocol used in many networking environments to dynamically update routes. It utilizes link-state information to make routing decisions, and uses Dijkstra’s algorithm to calculate the shortest path on the network – similar to OSPF.

An IS-IS network is called an Autonomous System (AS) and is divided up into segments called Areas. A single AS can contain multiple areas, and each area contains End Systems (ESs) and Intermediate Systems (ISs). ESs send and receive packets while ISs send, receive, and relay packets to other ISs. For simplicity’s sake we will consider an IS a router from this point forward.

In each area a router can be configured to relay routes into its own area (Level 1), relay routes to another area or AS (Level 2), or act as both a Level 1 and Level 2 router. This is very similar to OSPF as Level 2 router could be considered a backbone area, and a Level 1&2 router behaves like an area border router.

How Do I Configure IS-IS?

IS-IS is relatively straightforward to configure:

  1. Enable family iso on each logical interface that will participate in IS-IS
  2. Configure a loopback interface with an ISO Network Address
  3. Enable the interface under protocols isis

Configuring the interface:

ge-0/0/0 {
    unit 0 {
        family inet {
            address 10.0.0.2/24;
        }
        family iso;
    }
}

Configuring the loopback:

lo0 {
    unit 0 {
        family inet {
            address 192.168.254.3/32;
        }
        family iso {
            address 49.0001.1921.6800.2543.00;
        }
    }
}

Enabling the interfaces:

protocols {
    isis {
        interface ge-0/0/0.0;
        interface lo0.0
    }
}

Now let us move on to a little more advanced design. The diagram below shows two Juniper SRX’s in packet mode that will be participating in IS-IS. In particular we will be configuring two virtual routers, and two IS-IS areas that will share routing information:

image

Let’s first start with the interface configuration.

SRX1:

interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 10.0.0.1/24;
            }
            family iso;
        }
    }
    lt-0/0/0 {
        unit 1 {
            encapsulation ethernet;
            peer-unit 2;
            family inet {
                address 172.16.1.0/31;
            }
            family iso;
        }
        unit 2 {
            encapsulation ethernet;
            peer-unit 1;
            family inet {
                address 172.16.1.1/31;
            }
            family iso;
        }
    }
    ge-0/0/1 {
        unit 0 {
            family inet {
                address 10.1.0.1/24;
            }
            family iso;
        }                               
    }
    lo0 {
        unit 1 {
            family inet {
                address 192.168.254.1/32;
            }
            family iso {
                address 49.0001.1921.6800.2541.00;
            }
        }
        unit 2 {
            family inet {
                address 192.168.254.2/32;
            }
            family iso {
                address 49.0002.1921.6800.2542.00;
            }
        }
    }
}

SRX2:

interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 10.0.0.2/24;
            }
            family iso;
        }
    }
    lt-0/0/0 {
        unit 1 {
            encapsulation ethernet;
            peer-unit 2;
            family inet {
                address 172.16.1.2/31;
            }
            family iso;
        }
        unit 2 {
            encapsulation ethernet;
            peer-unit 1;
            family inet {
                address 172.16.1.3/31;
            }
            family iso;
        }
    }
    ge-0/0/1 {
        unit 0 {
            family inet {
                address 10.1.0.2/24;
            }
            family iso;
        }                               
    }
    lo0 {
        unit 1 {
            family inet {
                address 192.168.254.3/32;
            }
            family iso {
                address 49.0001.1921.6800.2543.00;
            }
        }
        unit 2 {
            family inet {
                address 192.168.254.4/32;
            }
            family iso {
                address 49.0001.1921.6800.2544.00;
            }
        }
    }
}

In this example the SRX’s have multiple loopback addresses configured. These will be used to identify the connections inside each AS belonging to each router. The address can be variable in length ranging from eight octets to twenty octets, and consists of 5 major parts:

  • Authority and Format Identifier (AFI)
  • Domain ID
  • Area ID
  • System ID
  • Selector

In the case of the configured ISO addresses they are omitting the Domain ID. In the example of SRX1 lo0.1 and its address 49.0001.1921.6800.2541.00:

  • AFI: 49
  • Area ID: 0001
  • System ID: 1921.6800.2541
  • Selector: 00

The AFI and Area ID on each loopback address should match up to the area listed in each diagram.

Now onto the virtual router configuration, and enabling IS-IS in each virtual router.

SRX1:

routing-instances {
    r1 {
        instance-type virtual-router;
        interface ge-0/0/0.0;
        interface lt-0/0/0.1;
        interface lo0.1;
        protocols {
            isis {
                interface ge-0/0/0.0 {
                    level 2 disable;
                }
                interface lt-0/0/0.1;
                interface lo0.1 {
                    level 2 disable;
                }
            }
        }
    }
    r2 {
        instance-type virtual-router;
        interface lt-0/0/0.2;
        interface ge-0/0/1.0;
        interface lo0.2;
        protocols {                     
            isis {
                interface lt-0/0/0.2;
                interface ge-0/0/1.0 {
                    level 2 disable;
                }
                interface lo0.2 {
                    level 2 disable;
                }
            }
        }
    }
}

SRX2:

routing-instances {
    r1 {
        instance-type virtual-router;
        interface ge-0/0/0.0;
        interface lt-0/0/0.1;
        interface lo0.1;
        protocols {
            isis {
                interface ge-0/0/0.0 {
                    level 2 disable;
                }
                interface lt-0/0/0.1;
                interface lo0.1 {
                    level 2 disable;
                }
            }
        }
    }
    r2 {
        instance-type virtual-router;
        interface lt-0/0/0.2;
        interface ge-0/0/1.0;
        interface lo0.2;
        protocols {                     
            isis {
                interface lt-0/0/0.2;
                interface ge-0/0/1.0 {
                    level 2 disable;
                }
                interface lo0.2 {
                    level 2 disable;
                }
            }
        }
    }
}

With the exception of the lt interfaces, all interfaces have level 2 explicitly disabled. This is to ensure that those interfaces cannot establish adjacencies to routers outside of their respective areas. Let’s take a look at the interfaces and adjacencies below:

SRX1:

root@SRX-1> show isis interface instance r1    
IS-IS interface database:
Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric
ge-0/0/0.0            1   0x2 SRX-1.02          Disabled               10/10
lo0.1                 0   0x1 Passive           Disabled                0/0
lt-0/0/0.1            3   0x1 SRX-1.00          1921.6800.2542.03      10/10

root@SRX-1> show isis interface instance r2    
IS-IS interface database:
Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric
ge-0/0/1.0            1   0x2 1921.6800.2542.00 Disabled               10/10
lo0.2                 0   0x1 Passive           Disabled                0/0
lt-0/0/0.2            3   0x3 1921.6800.2542.00 1921.6800.2542.03      10/10

SRX2:

root@SRX-2> show isis interface instance r1    
IS-IS interface database:
Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric
ge-0/0/0.0            1   0x1 SRX-1.02          Disabled               10/10
lo0.1                 0   0x1 Passive           Disabled                0/0
lt-0/0/0.1            3   0x1 SRX-2.02          SRX-2.02               10/10

root@SRX-2> show isis interface instance r2    
IS-IS interface database:
Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric
ge-0/0/1.0            1   0x1 SRX-2.00          Disabled               10/10
lo0.2                 0   0x1 Passive           Disabled                0/0
lt-0/0/0.2            3   0x2 SRX-2.02          SRX-2.02               10/10

It appears that all the interfaces are configured correctly. Let’s check the adjacencies:

SRX1:

root@SRX-1> show isis adjacency instance r1 
Interface             System         L State        Hold (secs) SNPA
ge-0/0/0.0            SRX-2          1  Up                   24  0:c:29:48:6d:a4
lt-0/0/0.1            SRX-1          2  Up                    8  2:96:14:10:1:34

root@SRX-1> show isis adjacency instance r2    
Interface             System         L State        Hold (secs) SNPA
lt-0/0/0.2            1921.6800.2541 2  Up                   22  2:96:14:10:1:33

SRX2:

root@SRX-2> show isis adjacency instance r1 
Interface             System         L State        Hold (secs) SNPA
ge-0/0/0.0            SRX-1          1  Up                    7  0:c:29:a5:26:b3
lt-0/0/0.1            SRX-2          1  Up                    8  2:96:14:10:1:34
lt-0/0/0.1            SRX-2          2  Up                    8  2:96:14:10:1:34

root@SRX-2> show isis adjacency instance r2    
Interface             System         L State        Hold (secs) SNPA
lt-0/0/0.2            1921.6800.2543 1  Up                   24  2:96:14:10:1:33
lt-0/0/0.2            1921.6800.2543 2  Up                   24  2:96:14:10:1:33

That is odd; it appears that IS-IS established adjacencies across ge-0/0/0 and the lt interfaces, but not ge-0/0/1. Let’s monitor traffic on ge-0/0/1 and see what is going on:

SRX1:

root@SRX-1> monitor traffic interface ge-0/0/1 detail no-resolve 
Address resolution is OFF.
Listening on ge-0/0/1, capture size 1514 bytes

--snip--

01:06:46.358359  In IS-IS, length 48
        L1 Lan IIH, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0)
          source-id: 1921.6800.2544,  holding time: 27s, Flags: [Level 1 only]
          lan-id:    1921.6800.2544.00, Priority: 64, PDU length: 48
            Protocols supported TLV #129, length: 2
              NLPID(s): IPv4 (0xcc), IPv6 (0x8e)
            IPv4 Interface address(es) TLV #132, length: 4
              IPv4 interface address: 10.1.0.2
            Area address(es) TLV #1, length: 4
              Area address (length: 3): 49.0001
            Restart Signaling TLV #211, length: 3
              Flags [none], Remaining holding time 0s

--snip--

I think we found our problem; as per the diagram the address should be 49.0002 when coming from SRX2’s lo0.2 interface. Let’s correct that:

SRX2:

root@SRX-2> edit 
Entering configuration mode

[edit]
root@SRX-2# delete interfaces lo0.2 family iso address 49.0001.1921.6800.2544.00 

[edit]
root@SRX-2# set interfaces lo0.2 family iso address 49.0002.1921.6800.2544.00  

[edit]
root@SRX-2# commit and-quit

Now let’s check the adjacencies one more time:

SRX1:

root@SRX-1> show isis adjacency instance r1                         
Interface             System         L State        Hold (secs) SNPA
ge-0/0/0.0            SRX-2          1  Up                   20  0:c:29:48:6d:a4
lt-0/0/0.1            1921.6800.2542 2  Up                    8  2:96:14:10:1:34

root@SRX-1> show isis adjacency instance r2    
Interface             System         L State        Hold (secs) SNPA
ge-0/0/1.0            1921.6800.2544 1  Up                   25  0:c:29:48:6d:ae
lt-0/0/0.2            SRX-1          2  Up                   20  2:96:14:10:1:33

SRX2:

root@SRX-2> show isis adjacency instance r1    
Interface             System         L State        Hold (secs) SNPA
ge-0/0/0.0            1921.6800.2541 1  Up                    7  0:c:29:a5:26:b3
lt-0/0/0.1            1921.6800.2544 2  Up                    7  2:96:14:10:1:34

root@SRX-2> show isis adjacency instance r2    
Interface             System         L State        Hold (secs) SNPA
ge-0/0/1.0            SRX-1          1  Up                    6  0:c:29:a5:26:bd
lt-0/0/0.2            SRX-2          2  Up                   25  2:96:14:10:1:33

Perfect! And now look at the routing:

SRX1:

r1.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.0.0/24        *[IS-IS/18] 00:04:13, metric 20
                    > to 172.16.1.1 via lt-0/0/0.1
172.16.1.2/31      *[IS-IS/15] 01:55:23, metric 20
                    > to 10.0.0.2 via ge-0/0/0.0
192.168.254.2/32   *[IS-IS/18] 01:54:31, metric 10
                    > to 172.16.1.1 via lt-0/0/0.1
192.168.254.3/32   *[IS-IS/15] 01:55:23, metric 10
                    > to 10.0.0.2 via ge-0/0/0.0
192.168.254.4/32   *[IS-IS/18] 00:04:07, metric 20
                    > to 172.16.1.1 via lt-0/0/0.1

r2.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.0/24        *[IS-IS/18] 01:54:31, metric 20
                    > to 172.16.1.0 via lt-0/0/0.2
172.16.1.2/31      *[IS-IS/15] 00:04:08, metric 20
                    > to 10.1.0.2 via ge-0/0/1.0
192.168.254.1/32   *[IS-IS/18] 01:54:31, metric 10
                    > to 172.16.1.0 via lt-0/0/0.2
192.168.254.3/32   *[IS-IS/18] 01:54:31, metric 20
                    > to 172.16.1.0 via lt-0/0/0.2
192.168.254.4/32   *[IS-IS/15] 00:04:08, metric 10
                    > to 10.1.0.2 via ge-0/0/1.0

We have now successfully configured IS-IS inside Junos!

More to come soon.

JNCIE-ENT Beta Exam

I recently took the JNCIE-ENT Beta exam in Sunnyvale, CA, and have been meaning to post my thoughts on the experience.

Back in September I took the JNCIE-ENT Exam in Herndon, VA. After being involved in several switching projects, and putting in over 200 hours of labs on my own I thought I would be ready to pass this exam. The study materials I had available are listed below:

I began to study and understand the wide world of L2/L3. It was a major change from the Security track that I was so familiar with, but all in all it turned out to be a very exciting and enlightening experience. It also was my first real exposure of IPv6 outside of a HE Tunnel on my SSG at home.

Unfortunately the exam itself was an eye opening experience for me in what I did know, and more importantly what I did not know. I fell short of the requirements needed to pass the exam, and got the unpleasant email that I failed the exam. It was a humbling experience, and after a few months I began to hit the books again for attempt #2.

In the meantime Juniper had put out an announcement for candidates for the JNCIE-ENT Beta exam in February, and they accepted my request to participate in the beta. This was an excellent opportunity to attempt the exam again as well as provide feedback on the exam team. A huge THANK YOU goes out to Liz Burns and her team on providing such an opportunity!

After finding out some of my friends and Internet colleagues were also accepted into the beta we began to collaborate to truly understand some of the techniques needed to understand the objectives of the JNCIE-ENT exams. We were able to provide scenarios/tools used to test many of the requirements needed to pass the JNCIE-ENT. Individuals such as Tim Hoffman were valuable as well as instrumental in leading the collaboration efforts.

February finally rolls around to sit the Beta Exam. It is important to note that these exams are under a very strict NDA so I cannot detail the exam itself. That being said I can say that the topics extremely thorough, and the tasks to configure/troubleshoot each topic would likely be seen in a real-world scenario. That being said even after taking the exam once already I almost got tripped up on a few requirements to get the network up and running. Fortunately Juniper does provide the entire configuration/examples guide, which was instrumental in helping figure the steps necessary to accomplish such tasks. The trick is combining PDF searches with CLI commands such as help apropos or help reference – quick tools to help find that correct command.

All in all I had plenty of time to review my work, and continually test portions of the configuration to ensure that new changes did not break existing functionality. I completed the exam with about an hour to spare, and had plenty of opportunities to review each task to ensure that I understood what was being asked as part of the requirements. It was another great learning experience, and I am hopeful that this time I will earn a passing grade. Since this exam was a beta, I will have to wait for 2 months before I learn the results of the exam.

Those two months give me plenty of time to start working towards JNCIE-SP…

Packet Mode and Selective Packet Services

Packet mode enables a SRX firewall to act strictly as a router, forwarding packets from a source to a destination without tracking sessions. This is useful for an engineer in certain situations such as high throughput applications that do not need full firewall functionality, or asymmetric traffic flows. We can also enable this mode on interesting traffic which is called Selective Packet Services. More details on Selective Packet Services is available on the following PDF as well as the rest of this post.

Enabling packet mode does change some of the behaviors of the SRX. For starters, it will bypass practically everything under the security stanza of the SRX. This means that the following features are disabled:

  • NAT
  • VPN Termination
  • Firewall Policies under the security stanza
  • IPS
  • UTM
  • Screens

Furthermore, when enabling packet mode for all traffic you will need to use stateless firewall filters to manage traffic which is located under the firewall stanza in the config.

On to business, shall we?

How to turn on Packet Mode for all traffic:

set security forwarding-options family mpls mode packet-based
commit and-quit
request system reboot

How to turn on Packet Mode for selective traffic:

  1. Set up a firewall filter to accept interesting traffic with an action of packet-mode
  2. Apply filter to interface that traffic is ingresses the firewall
  3. Set up 2nd firewall filter to accept return traffic with an action of packet-mode
  4. Apply 2nd filter to interface that return traffic ingresses the firewall

Below is a slightly fancier version of Selective Packet Services as it includes forwarding the traffic out of a forwarding instance:

interfaces {
    gr-0/0/0 {
        unit 0 {
            tunnel {
                source 1.1.1.1;  
                destination 2.2.2.2;
            }
            family inet {
                filter {
                    input redirect-return;
                }
                address 172.25.0.1/30;
            }
        }
    ge-0/0/1 {
        description "Trust Zone";
        unit 0 {
            family inet {
                filter {
                    input redirect-packet;
                }
                address 192.168.0.1/24;
            }
        }
    }
}

routing-options {
    interface-routes {
        rib-group inet global-rib;
    }
    rib-groups {
        global-rib {
            import-rib [ r1.inet.0 inet.0 ];
        }
    }
}

firewall {
    filter redirect-packet {
        term packet {
            from {
                destination-port [ http https ];
            }
            then {
                packet-mode;
                routing-instance r1;
            }
        }
        term allow-everything-else {
            then accept;
        }
    }
    filter redirect-return {
        term packet {
            from {
                source-port [ http https ];
            }
            then {
                packet-mode;
            }
        }
        term allow-everything-else {
            then accept;
        }
    }
}

routing-instances {
    r1 {
        instance-type forwarding;
        routing-options {
            static {
                route 0.0.0.0/0 next-hop gr-0/0/0.0;
            }
        }
    }
}

Route-based VPN with Multiple Source/Destination Networks to a 3rd Party Device

I have seen this question several times on the Juniper Forums, so I decided to post a quick write up on how to build a route-based VPN to a 3rd party device, such as a Cisco ASA, with multiple subnets on each side. The answer is more straightforward than you think.

Take the example below, where the SRX has a network of 192.168.1.0/24, and needs to access 192.168.10.0/24 and 192.168.11.0/24 which is behind a Cisco ASA.

image

The Cisco Administrator specifies interesting traffic via an Access Control List to intercept traffic to be sent down the vpn tunnel. This ACL essentially creates what the SRX identifies as a proxy-id. By default the SRX will send the following proxy-id to any remote peer:

        proxy-identity {
            local 0.0.0.0/0;
            remote 0.0.0.0/0;
            service any;
        }

So, we will need to create multiple VPN’s with differing proxy-id’s that reference the same ike-gateway:

vpn abc1 {
    bind-interface st0.0;
    ike {
        gateway ike-vpn;
        proxy-identity {
            local 192.168.1.0/24;
            remote 192.168.10.0/24;
            service any;
        }
        ipsec-policy ipsec-policy;
    }
}

vpn abc2 {
    bind-interface st0.0;
    ike {
        gateway ike-vpn;
        proxy-identity {
            local 192.168.1.0/24;
            remote 192.168.11.0/24;
            service any;
        }
        ipsec-policy ipsec-policy;
    }
}

The tricky part is handling next-hop-tunnel bindings:

st0 {
  unit 0 {
   multipoint;
   family inet {
     next-hop-tunnel 172.31.255.2 ipsec-vpn abc1;
     next-hop-tunnel 172.31.255.3 ipsec-vpn abc2;
     address 172.31.255.1/24;
   }
  }
}

The st0.0 address must use a subnet for its local address, and the NHTB address are ephermal (they don’t exist on the cisco side); they just need to be unique for each vpn.

Routing is pretty straightforward – just specify the ephermal NHTB address as the next-hop:

routing-options {
    static {
        route 192.168.10.0/24 next-hop 172.31.255.2;
        route 192.168.11.0/24 next-hop 172.31.255.3;
    }
}

There is still one slight caveat here:

If you have multiple source subnets headed to the same destination then you will need to perform policy-based VPNs. This is because there is no way to specify the same destination subnet across two separate interfaces. In the case above we are using a single source subnet so this above configuration should work.

Studying for JNCIE-SEC Exam

Many people have now asked me for advice on how to pass the JNCIE-SEC Exam, which is a great thing as it seems many people are working towards achieving the next level in their certification journey. This post will cover:

  • Exam Objectives
  • Studying Materials
  • Additional Advice

In later posts I will discuss specific methods/techniques from those objectives.

A shout-out and thanks goes to CentraComm supplying many of the study materials/gear, as well as the terrific support and encouragement many coworkers provided throughout this journey!

Exam Objectives

So let’s first talk about what to study in order to prepare for the exam. Since this is a practical exam there is no single resource that covers every single aspect of the test. That being said, there are several books I would strongly recommend reading first in order to address 95% of the exam objectives:

One more important thing to know – be aware of what features are available for the version of Junos you are using! Right now the exam is set for 11.1, so things such as GRE tunnels in chassis clusters are not available. You can find those feature listings in either the Feature Explorer or the Feature Support PDF.

Studying Materials

You will absolutely need to get at least 2 SRX’s of the same model in order to set up chassis clustering and understand all the options for the clusters. In addition one of the units needs to be a High Memory unit in order to test UTM functionality. Obviously, the more the merrier is recommended in this case. The additional benefit of using the branch series is that they are extremely portable. I could fit my equipment into my carryon bag, and with the right cables/powerstrips it was extremely easy to set up a new mock lab anywhere I traveled. My lab was as follows (picture below):

  • 2x SRX-210’s
  • 3x SRX-100’s
  • 1x EX2200-C

MY JNCIE-SEC Lab

Other Advice

The nearest testing site for me was in Herndon, Virginia so that required booking a flight. I actually left two days early to get situated in Herndon, and to get one last day of good studying in before the exam. It turned out to be a blessing in disguise as the plane landed several hours late due to storms! A 4-hour flight turned into an 8-hour ordeal due to the weather. Trying to get through an ordeal like that the day before the exam would have been extremely unpleasant, and add unnecessary stress to an already stressful exam.

In terms of how long to study, I did nothing but read for about a solid month prior to using the lab gear. The books mentioned above provided a good solid background to all the functionality inside the SRX’s. From there I would go through the exam objectives and create scenarios to reinforce understanding of a particular piece of technology. One of the important things to remember here is that building out complicated networks still require fundamental knowledge in the basics. For an example if you do not understand how to create/troubleshoot a simple VPN tunnel or how the SRX’s negotiate both phases of the tunnel, then you will struggle at this exam. If you don’t know how to perform a certain task, then take a look at the vast wealth available on the Internet. Here are a couple of sites that I would refer back to constantly:

Take your time when going through the exam, and make sure you review your configurations after you have completed the exam. Even after reviewing my configs there were still minor errors that would have cost dearly on the final scoring.

Lastly, ask the proctor questions if you’re unsure of what is required on an objective. The proctor will not be able to tell you the answer if you are stuck at a certain point, but they can provide valuable guidance on what needs to be done in your configurations.

Hopefully this will help you in your journey to achieving the JNCIE-SEC certification. Feel free to ask questions here, and stay tuned for more posts on how to configure many of the objectives for this exam.