Then, in November I took the “real deal”. Definitely failed that one on my own. Having hardware issues and no documentation until lunch certainly didn’t help, but there’s no question I wasn’t prepared enough.

Chatting with Stefan Fouant on Twitter, I jokingly said I’d fly to Herndon VA (a five hour flight) rather than Sunnyvale (a 45 minute flight) if he promised to grade it quickly. He accepted that challenge, and though I know it’s often out of the proctors hands when an exam gets graded I decided I’d go out there and finally meet him.

I scheduled attempt “2.5″ for March 2012, but after feeling pretty confident in late December, I decided to push it up to early February. I had a pretty good idea of what was going to be on the lab because of the alpha and the first attempt, so I made sure to focus on the areas I felt I was weak in. I used my home lab extensively to lab out scenarios I could remember from the exam.

Fast forward to February. I got to the airport at 6am for my 8am flight. Turns out they don’t have a ticket for me. I wasn’t flying standby, I had a ticket confirmation number and everything, they just simply didn’t have one. All they had was my March ticket. WTF?

So I call the company travel agency to scream at somebody, and they tell me that APPARENTLY while I changed my date in the booking website (we use Concur), the backend process of somebody actually ticketing the flight never happened. They were able to put me on the 1pm flight at a cost of about $900 on top of the $450 they applied for the old ticket. Good job, guys.

So I got back to the airport later that day, and (I’m proud to say) opted out of the body xray and instead received my TSA Freedom Fondle. No big deal, took 2 minutes and was done very professionally. The flight itself was long and boring, not much more to say there.

I got to the hotel about 9pm local time, ordered some pizza, and went to bed. The next day was spent mostly at the hotel just hanging out, taking an occasional look at my notes, but in general it was relaxing. I booked an entire extra day like this because I know doing my exam early the morning after a long flight (especially one that ends up being delayed or worse, as in my situation) would be awful. I’m glad I did it.

Then, test day. I didn’t sleep at all the night before. Woke up at 2am and couldn’t get back to sleep. At about 6am I decided it made no sense to try to sleep and just got up and had a shower. I hit Starbucks at around 7am, and hung out there on my laptop for a bit before heading over to the test site.

Once I got there, I was greeted by Stefan, and he brought me into a classroom with some IBM laptops. Boy, am I ever glad I brought my own apple clone keyboard! He also provided me with a mouse, which was very helpful. I had also brought a set of coloured pens, which I actually used quite a bit. I highly recommend it.

I suppose I can’t say too much about the exam itself, but I got through most of it with no issue. At one point I hit the multicast section, configured things are I was pretty sure they needed to be configured.. and they didn’t work. I tried troubleshooting, but my multicast troubleshooting skills are my achilles heel. However, I was pretty darn sure I had done it right, but I didn’t want to linger too long so I kept moving on to other things. Every time I came back to multicast, though, I still couldn’t figure out what was wrong.

Eventually I’d had enough and just mentioned to Stefan that I was doing well except that my multicast wasn’t working. He provided some very proctor-esque suggestions (the kind that are vague but still helpful – anyone who has taken a CCIE knows what I’m talking about). Eventually I think he could tell I was frustrated and came over to take a look. I showed him what I had done, and he seemed confused by the result. He sat down and started to troubleshoot to ensure it wasn’t a hardware issue. But it was.

He got on the phone and called up the cert team to ask about it, and after a while we got verification that the multicast VMs being used for the lab were not running correctly, and eventually they suggested we move my configs to a new rack. This provisioning takes a while, so we hit dinner. This was probably about 7-8pm at this point.

We went to a thai place that was actually pretty decent! Though, it’s hard to screw up pad thai ;) Oh, and lunch was a pretty darn good kebob place. Now that I think of it, I actually forgot my leftovers in Juniper’s fridge.

Once we got back, my lab had been reprovisioned and Stefan gave me an hour extra to check things had come up okay, and to troubleshoot my multicast now that the senders and receivers were actually working. Good thing, too, because I had completely messed up one of the tasks.

It was only about 20 minutes in, and I said I was done. Everything else looked good, and my multicast appeared to be working correctly. It was finally time to go home! (or, back to the hotel..) So that was it, my fate was in his hands now. He said he’d try to grade it as soon as possible.

Slept like a baby that night, I can tell you that!

The next day I woke up to an email from Liz Burns apologizing for the issues. After I replied with a pretty detailed recount of what had occured, she actually offered a free attempt if I were to fail this one. She also said she’d have my grading rushed. When it comes to customer service, Juniper far exceeds expectations!

After that, I decided to check out and go see if I could get on an earlier flight because mine wasn’t due to leave until about 7 hours from then. I was able to get a seat, so off home I went.

However, as we were boarding (literally, I was in line to board the plane), Liz asked me to call her via a Twitter DM. I did so, and she informed me that I had PASSED the JNCIE-ENT! I couldn’t believe what I was hearing! I also couldn’t believe how quickly it was graded! It was actually graded by somebody on the cert team, rather than by Stefan. I think this is probably for the better, to avoid anyone making nonsense accusations of having a friend pass me when I hadn’t earned it, or whatever else somebody might come up with. After the garbage thrown at me after I passed the CCIE, it wouldn’t have surprised me one bit.

So I was pretty giddy the whole way home, all 5 hours of it. I was so excited!

So that’s my JNCIE-ENT story. I would highly recommend going for a JNCIE to anyone out there with any interest in networking!

Chris Jones,
JNCIE-ENT #272

• Part 1: Initial Lab Setup
• Part 2: Static RP
• Part 3: BSR
• Part 4: Anycast-RP
• Part 5: IPv6

So without further adieu, we’ll begin by setting up our topology.

Topology

We’ll be using the following diagram (click to enlarge):

Note the use of both IPv4 and IPv6 addressing. I won’t be covering IPv6 multicast in the first four sections, mainly because I’m unable to do verification without real senders and receivers at this time. IPv6 will be touched on in part 5.

Also note that we are using virtual-routers with logical-tunnels to build this entire topology on one router. I’m using an SRX210H, but any Juniper router should suffice. I’ve attempted to keep the addressing scheme sane by using the format 10.42.<routerx><routery>.<router#>/24. For example, the link between routers 3 and 4 would be 10.42.34.0/24 with R3 being .3 and R4 being .4. Those who have used INE workbooks for the CCIE exams should be familiar with this concept. IPv6 is similar, and again the R3 to R4 link would be 2001:db8:34::/64

We’re using 192.168.255.0/24 for the sender, and 192.168.1.0/24 for the receiver.

Setting up a lab using virtual-routers is covered in an earlier blog post, so I won’t repeat those details here. Simply click here to view the configuration you’ll need. Please note that PIM-SM is already enabled on all VR interfaces, minus the loopbacks. We’re also running single-area OSPF.

Verification

Let’s make sure our simulated hosts can reach each other:

cjones@R7> traceroute 192.168.1.100 routing-instance SNDR1
traceroute to 192.168.1.100 (192.168.1.100), 30 hops max, 40 byte packets
 1  192.168.255.1 (192.168.255.1)  12.040 ms  11.852 ms  10.490 ms
 2  10.42.13.3 (10.42.13.3)  12.498 ms  11.387 ms  11.175 ms
 3  10.42.34.4 (10.42.34.4)  12.232 ms  10.052 ms  11.816 ms
 4  10.42.45.5 (10.42.45.5)  16.665 ms  17.614 ms  10.518 ms
 5  192.168.1.100 (192.168.1.100)  6.527 ms  5.594 ms  12.724 ms

Great! Let’s also take a look at our PIM neighborships:

cjones@R7> show pim neighbors instance R1 inet | except =
Instance: PIM.R1

Interface           IP V Mode        Option      Uptime Neighbor addr
lt-0/0/0.12          4 2             HPLGT      02:10:34 10.42.12.2
lt-0/0/0.13          4 2             HPLGT      02:10:06 10.42.13.3     

cjones@R7> show pim neighbors instance R2 inet | except =
Instance: PIM.R2

Interface           IP V Mode        Option      Uptime Neighbor addr
lt-0/0/0.21          4 2             HPLGT      02:10:37 10.42.12.1
lt-0/0/0.23          4 2             HPLGT      02:10:09 10.42.23.3
lt-0/0/0.24          4 2             HPLGT      02:10:10 10.42.24.4     

cjones@R7> show pim neighbors instance R3 inet | except =
Instance: PIM.R3

Interface           IP V Mode        Option      Uptime Neighbor addr
lt-0/0/0.31          4 2             HPLGT      02:10:13 10.42.13.1
lt-0/0/0.32          4 2             HPLGT      02:10:13 10.42.23.2
lt-0/0/0.34          4 2             HPLGT      02:10:40 10.42.34.4     

cjones@R7> show pim neighbors instance R4 inet | except =
Instance: PIM.R4

Interface           IP V Mode        Option      Uptime Neighbor addr
lt-0/0/0.42          4 2             HPLGT      02:10:17 10.42.24.2
lt-0/0/0.43          4 2             HPLGT      02:10:43 10.42.34.3
lt-0/0/0.45          4 2             HPLGT      02:10:43 10.42.45.5     

cjones@R7> show pim neighbors instance R5 inet | except =
Instance: PIM.R5

Interface           IP V Mode        Option      Uptime Neighbor addr
lt-0/0/0.54          4 2             HPLGT      02:10:46 10.42.45.4

Looks like everything is up!

Let’s take a quick look at the PIM join status on R5 before we go any further:

cjones@R7> show pim join instance R5
Instance: PIM.R5 Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Instance: PIM.R5 Family: INET6
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Exactly as expected… nothing.

In order for us to test our multicast, we need to set up a static IGMP (for IPv4) and MLD (for IPv6) join on the receivers first-hop gateway. Again those with an IOS background should be familiar with this concept, however in Junos there is an additional step required, as a join does not equal a listening process. (Those familiar with the mgen utility know that it requires both a join and a listen on a receiver as well). We’ll utilize the SAP protocol to listen on our chosen IPv4 multicast address of 225.1.1.1, and IPv6 multicast address of FF1E::1.

set protocols igmp interface lt-0/0/0.2 static group 225.1.1.1
set protocols mld interface lt-0/0/0.2 static group FF1E::1
set protocols sap listen 225.1.1.1 port 5000
commit and-quit

Here is where our inability to test IPv6 multicast comes to light – SAP doesn’t allow an IPv6 address. (If anyone knows of a workaround or an alternate protocol, please leave a comment!)

Everything looks good with our topology at this point, so on to part 2!

Aside from built-in OSX apps like iTunes and Textedit, here is my list:

• Google Chrome
• MS Office 2011
• VMWare Fusion (for MS Visio 2010)
• iTerm2
• ipcalc
• Adium
• TweetDeck (old version)
• SecureCRT
• uTorrent
• Skype
• Adobe Creative Suite 5
• Dropbox
• HandBrake
• Screenflow
• Spotify
• UnRarX
• Vidalia
• VLC
• WhatSize

I have to admit, I’m slightly burnt out on this stuff after the last attempt and the study time I put into it. I don’t know if I could handle picking up a Junos book right about now…

What do you think?

The proctor actually got the other two guys set up before me, one was doing the JNCIE-SP and the other the JNCIE-SEC. I started my exam at approximately 9:30 am. Unlike last time, when we were in an open classroom with laptops, this time we were in a small room with cubicles and desktops with ancient monitors and not much newer keyboards. Also on the desk was a cup of pens, many of which barely worked. Hopefully Juniper is able to improve on this in the future!

About an hour into the lab, the proctor brought in a USB stick containing PDFs of the relevant documentation. Problem is, using Secure Desktop, we weren’t able to view the contents of the USB stick. Over lunch, he loaded the PDFs onto our desktops while we were eating. Yes, this means we had to work with zero documentation for 2.5 hours of the lab! I know Junos has the documentation available via the ‘help’ command, but finding what you’re looking for isn’t always intuitive. There were a few tasks that I knew I was going to have to look up the commands for, I was unable to do until after lunch.

I also ran into an issue with my virtual-chassis. Somehow after pre-provisioning my VC and rebooting, my switches decided to split-brain. I worked with the proctor for a good 30 minutes or more trying to troubleshoot, with a solution finally coming in via email from the cert team after they had somebody log into my pod.

Up until they were able to determine what the problem was, I had assumed it was a configuration error. All of the interfaces were up, everything seemed normal, but one of my tasks was simply not working. I spent probably 20 minutes trying to fix it before I even went to the proctor. (Yes, I normally would have just skipped it, but it was a task that despite being only 2 points was absolutely critical for the rest of the exam).

I made up some time on the IGP section, as the OSPF tasks were fairly simple. The first half of the BGP section also went by rather quickly, as I was able to lab most of the tasks recently during my study period.

I burned though the CoS section since it was very short, very easy, and worth a lot of points.

The protocol independent routing section took me FAR too long. This seemed to be a recurring theme. Tasks taking longer than they should, configurations not working as I’d expected, etc. Near the end of my exam, the proctor asked me if I was just verifying my work now, and I laughed. I wasn’t even 3/4 of the way through at that point!

All in all, I’m 99% sure I failed. I finished a couple of the bigger multicast tasks, but didn’t have time to properly verify. If I did those right, then… maybe.

I was pleased with the exam itself, for the most part. Especially after being very critical of it after the alpha. There still seemed to be a bit of wonkyness with some of the tasks – things not being worded well, or well explained. I think the biggest complaint I’d have overall is the lack of documentation for far too much of the exam.

However, I was told that I was the first person to take the real JNCIE-ENT (non-alpha/beta, that is), so there were bound to be kinks. I was asked to take a lot of notes for them as I went. I will say this… if I don’t pass, I’m not re-taking this for at least a good 6 months. Hopefully by then the kinks will have worked themselves out. The proctor said himself that with it being this new, the solutions to issues come very slowly because they aren’t yet familiar with the exam and the topology.

In summary, I’m happy with the exam. It’s challenging, but very fair. I still don’t care for the diagrams (even after they updated them), and some of the “housekeeping” needs work, and the facility itself could really use a bit of a refresh. But it was a good experience, I’m happy I did it, and (eventually) I look forward to another try.

Since grading is done manually…twice… (once by the proctor, and again by the cert team.. grading script not written yet), it could be a few weeks before I get word of pass/fail, but unfortunately I already think I know the result…

Older Cisco IOS

interface e0
 ip address 192.0.2.1 255.255.255.0
!
router ospf 1
 network 192.0.2.1 0.0.0.0 area 0
!

Analysis: Cisco’s original way of configuring an IGP was to use the “network” statement. This is an overly convoluted way of doing something that should be very simple. The idea of using a network statement with a mask to determine which interfaces OSPF will run on is certainly a stone age idea. It also has a great tendency to confuse the noobs, who may think the network command dictates what networks are “advertised” into OSPF.

New Cisco IOS

interface g0/0/0
 ip address 192.0.2.1 255.255.255.0
 ip ospf 1 area 0
!

Analysis: Originally introduced with OSPFv3, the new IOS method was “backported” to OSPFv2, which allows the “ip ospf” command to be run on the interface itself. This is a huge improvement over the original IOS method, but strays from the simple concept that IGP configuration belongs under the IGP, not under the interface. Moving on…

Cisco NX-OS

interface e1/2
 ip address 192.0.2.1/24
 ip router ospf 201 area 0.0.0.0
!

Analysis: Cisco’s NX-OS works in a very similar fashion to newer IOS, in that the interface is assigned to run OSPF using an interface-specific command. The only real differences here are the inclusion of the OSPF “instance-tag”, and the word “router” in the command. Why they felt the need to add that, I don’t know. If anyone does, please leave a comment!

Cisco IOS-XR

interface T0/1/0/0
 ipv4 address 192.0.2.1 255.255.255.0
!
router ospf 1
 area 0
  interface T0/1/0/0
!

Analysis: Cisco’s IOS-XR takes after the Junos way of configuring OSPF (see the next section), and finally provides proper separation of interface and protocol commands. This is a good start, and hopefully Cisco will go this route in the future releases of IOS and NX-OS. I also hope they start allowing the use of a prefix length in IP address commands (if they do already, and I’m just not aware of it, again please comment!)

Juniper’s Junos

set interfaces ge-0/0/0 unit 0 family inet address 192.0.2.1/24
set protocols ospf area 0 interface ge-0/0/0

Resulting in:

interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 192.0.2.1/24;
            }
        }
    }
}
protocols {
    ospf {
        area 0.0.0.0 {
            interface ge-0/0/0.0;
        }
    }
}

Analysis: As you can see, Junos has been doing it this way all along. Clear separation of the interface and protocol commands! Two simple commands, clean resulting configuration. What more can be said? Cisco obviously liked this method, as they’ve included it in IOS-XR. As I’ve said, hopefully they start doing it this way in IOS and NX-OS. Or better yet, ditch the whole “variant” thing and create a modern OS from the ground up… but that’s unlikely.

Summary

So which method is best? Well, old IOS clearly fails at being logical and simple. New IOS and NX-OS are slightly better, but still lack that logical separation of interface and protocol configuration. IOS-XR and Junos both have it right, in my opinion. As with most OS configuration, Junos holds the clear advantage here in logical configuration. However, I must admit I was pleasantly surprised to see Cisco take a page out of Juniper’s book and include the interface configuration under the OSPF process.

We’re going to build this topology, with OSPF routing, on a single SRX210 running packet-mode Junos:

Let’s start with R1. First, configure the interfaces for R1. Note the use of the peer-unit line that specifies which lt-0/0/0 unit this interface will connect to. Here we’re using units 0 and 5, as per the diagram. We also configure the lo0.1 interface.

set interfaces lt-0/0/0 unit 0 family inet address 10.0.0.1/30
set interfaces lt-0/0/0 unit 0 peer-unit 1
set interfaces lt-0/0/0 unit 0 encapsulation ethernet
set interfaces lt-0/0/0 unit 5 family inet address 10.0.0.10/30
set interfaces lt-0/0/0 unit 5 peer-unit 4
set interfaces lt-0/0/0 unit 5 encapsulation ethernet
set interfaces lo0 unit 1 family inet address 1.1.1.1/32

Next we configure the virtual-router, along with the logical-tunnel interface’s units 0 and 5. We’ll also include lo0.1:

set routing-instances R1 instance-type virtual-router
set routing-instances R1 interface lt-0/0/0.0
set routing-instances R1 interface lt-0/0/0.5
set routing-instances R1 interface lo0.1

Repeat the steps for R2 and R3, following the diagram:

set interfaces lt-0/0/0 unit 1 family inet address 10.0.0.2/30
set interfaces lt-0/0/0 unit 1 peer-unit 0
set interfaces lt-0/0/0 unit 1 encapsulation ethernet
set interfaces lt-0/0/0 unit 2 family inet address 10.0.0.5/30
set interfaces lt-0/0/0 unit 2 peer-unit 3
set interfaces lt-0/0/0 unit 2 encapsulation ethernet
set interfaces lo0 unit 2 family inet address 2.2.2.2/32
set routing-instances R2 instance-type virtual-router
set routing-instances R2 interface lt-0/0/0.1
set routing-instances R2 interface lt-0/0/0.2
set routing-instances R2 interface lo0.2

set interfaces lt-0/0/0 unit 3 family inet address 10.0.0.6/30
set interfaces lt-0/0/0 unit 3 peer-unit 2
set interfaces lt-0/0/0 unit 3 encapsulation ethernet
set interfaces lt-0/0/0 unit 4 family inet address 10.0.0.9/30
set interfaces lt-0/0/0 unit 4 peer-unit 5
set interfaces lt-0/0/0 unit 4 encapsulation ethernet
set interfaces lo0 unit 3 family inet address 3.3.3.3/32
set routing-instances R3 instance-type virtual-router
set routing-instances R3 interface lt-0/0/0.3
set routing-instances R3 interface lt-0/0/0.4
set routing-instances R3 interface lo0.3

After we do this, we issue the commit command.

Let’s check our interfaces:

cjones@R1> show interfaces terse | match lt-
lt-0/0/0                up    up
lt-0/0/0.0              up    up   inet     10.0.0.1/30
lt-0/0/0.1              up    up   inet     10.0.0.2/30
lt-0/0/0.2              up    up   inet     10.0.0.5/30
lt-0/0/0.3              up    up   inet     10.0.0.6/30
lt-0/0/0.4              up    up   inet     10.0.0.9/30
lt-0/0/0.5              up    up   inet     10.0.0.10/30    

cjones@R1> show interfaces terse | match lo0
lo0                     up    up
lo0.1                   up    up   inet     1.1.1.1             --> 0/0
lo0.2                   up    up   inet     2.2.2.2             --> 0/0
lo0.3                   up    up   inet     3.3.3.3             --> 0/0

Looks good! Next we test connectivity for all three links:

cjones@R1> ping 10.0.0.2 routing-instance R1 rapid count 3
PING 10.0.0.2 (10.0.0.2): 56 data bytes
!!!
--- 10.0.0.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.116/3.052/4.435/0.998 ms

cjones@R1> ping 10.0.0.9 routing-instance R1 rapid count 3
PING 10.0.0.9 (10.0.0.9): 56 data bytes
!!!
--- 10.0.0.9 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.285/13.683/36.429/16.084 ms

cjones@R1> ping 10.0.0.1 routing-instance R2 rapid count 3
PING 10.0.0.1 (10.0.0.1): 56 data bytes
!!!
--- 10.0.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.117/2.699/3.391/0.526 ms

cjones@R1> ping 10.0.0.6 routing-instance R2 rapid count 3
PING 10.0.0.6 (10.0.0.6): 56 data bytes
!!!
--- 10.0.0.6 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.123/4.776/7.982/2.424 ms

cjones@R1> ping 10.0.0.5 routing-instance R3 rapid count 3
PING 10.0.0.5 (10.0.0.5): 56 data bytes
!!!
--- 10.0.0.5 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.407/3.452/5.359/1.351 ms

cjones@R1> ping 10.0.0.10 routing-instance R3 rapid count 3
PING 10.0.0.10 (10.0.0.10): 56 data bytes
!!!
--- 10.0.0.10 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.094/5.480/8.832/2.440 ms

Awesome. Let’s also take a quick look at our routing table:

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

1.1.1.1/32         *[Direct/0] 00:06:09
                    > via lo0.1
10.0.0.0/30        *[Direct/0] 00:06:09
                    > via lt-0/0/0.0
10.0.0.1/32        *[Local/0] 00:06:09
                      Local via lt-0/0/0.0
10.0.0.8/30        *[Direct/0] 00:06:08
                    > via lt-0/0/0.5
10.0.0.10/32       *[Local/0] 00:06:08
                      Local via lt-0/0/0.5

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

2.2.2.2/32         *[Direct/0] 00:06:09
                    > via lo0.2
10.0.0.0/30        *[Direct/0] 00:06:09
                    > via lt-0/0/0.1
10.0.0.2/32        *[Local/0] 00:06:09
                      Local via lt-0/0/0.1
10.0.0.4/30        *[Direct/0] 00:06:09
                    > via lt-0/0/0.2
10.0.0.5/32        *[Local/0] 00:06:09
                      Local via lt-0/0/0.2

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

3.3.3.3/32         *[Direct/0] 00:06:09
                    > via lo0.3
10.0.0.4/30        *[Direct/0] 00:06:08
                    > via lt-0/0/0.3
10.0.0.6/32        *[Local/0] 00:06:08
                      Local via lt-0/0/0.3
10.0.0.8/30        *[Direct/0] 00:06:08
                    > via lt-0/0/0.4
10.0.0.9/32        *[Local/0] 00:06:08
                      Local via lt-0/0/0.4

Perfect! Now let’s add OSPF to all three virtual-routers:

set routing-instances R1 protocols ospf area 0.0.0.0 interface lt-0/0/0.0
set routing-instances R1 protocols ospf area 0.0.0.0 interface lt-0/0/0.5
set routing-instances R1 protocols ospf area 0.0.0.0 interface lo0.1 passive

set routing-instances R2 protocols ospf area 0.0.0.0 interface lt-0/0/0.1
set routing-instances R2 protocols ospf area 0.0.0.0 interface lt-0/0/0.2
set routing-instances R2 protocols ospf area 0.0.0.0 interface lo0.2 passive

set routing-instances R3 protocols ospf area 0.0.0.0 interface lt-0/0/0.3
set routing-instances R3 protocols ospf area 0.0.0.0 interface lt-0/0/0.4
set routing-instances R3 protocols ospf area 0.0.0.0 interface lo0.3 passive

Next we try to commit, but we may get an error:

cjones@R1# commit
error: Cannot parse routing-option max-interface-supported
error: configuration check-out failed

This is kind of an obscure error that occurs due to a bug in Junos 11.1 and 11.2, and detailed in Juniper KB 20977. It is fine in Junos 10.4 and fixed in Junos 11.3. To fix it, either configure *something* under routing-options, or use the following hidden command:

[edit]
cjones@R1# set routing-options max-interface-supported 0 

[edit]
cjones@R1# commit check
configuration check succeeds

Now we commit, and check our routing tables for OSPF routes:

cjones@R1> show route protocol ospf 

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

2.2.2.2/32         *[OSPF/10] 00:00:55, metric 1
                    > to 10.0.0.2 via lt-0/0/0.0
3.3.3.3/32         *[OSPF/10] 00:00:50, metric 1
                    > to 10.0.0.9 via lt-0/0/0.5
10.0.0.4/30        *[OSPF/10] 00:00:50, metric 2
                    > to 10.0.0.2 via lt-0/0/0.0
                      to 10.0.0.9 via lt-0/0/0.5
224.0.0.5/32       *[OSPF/10] 00:01:49, metric 1
                      MultiRecv

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

1.1.1.1/32         *[OSPF/10] 00:00:53, metric 1
                    > to 10.0.0.1 via lt-0/0/0.1
3.3.3.3/32         *[OSPF/10] 00:00:58, metric 1
                    > to 10.0.0.6 via lt-0/0/0.2
10.0.0.8/30        *[OSPF/10] 00:00:53, metric 2
                      to 10.0.0.1 via lt-0/0/0.1
                    > to 10.0.0.6 via lt-0/0/0.2
224.0.0.5/32       *[OSPF/10] 00:01:49, metric 1
                      MultiRecv

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

1.1.1.1/32         *[OSPF/10] 00:00:48, metric 1
                    > to 10.0.0.10 via lt-0/0/0.4
2.2.2.2/32         *[OSPF/10] 00:00:58, metric 1
                    > to 10.0.0.5 via lt-0/0/0.3
10.0.0.0/30        *[OSPF/10] 00:00:48, metric 2
                      to 10.0.0.5 via lt-0/0/0.3
                    > to 10.0.0.10 via lt-0/0/0.4
224.0.0.5/32       *[OSPF/10] 00:01:49, metric 1
                      MultiRecv

Perfect. One last thing to check is full connectivity, so…

cjones@R1> ping 2.2.2.2 routing-instance R1 rapid count 3
PING 2.2.2.2 (2.2.2.2): 56 data bytes
!!!
--- 2.2.2.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.227/7.059/10.238/3.473 ms

cjones@R1> ping 3.3.3.3 routing-instance R1 rapid count 3
PING 3.3.3.3 (3.3.3.3): 56 data bytes
!!!
--- 3.3.3.3 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.092/2.892/3.749/0.678 ms

cjones@R1> ping 1.1.1.1 routing-instance R2 rapid count 3
PING 1.1.1.1 (1.1.1.1): 56 data bytes
!!!
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.514/4.918/8.915/2.846 ms

cjones@R1> ping 3.3.3.3 routing-instance R2 rapid count 3
PING 3.3.3.3 (3.3.3.3): 56 data bytes
!!!
--- 3.3.3.3 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.104/2.693/3.742/0.744 ms

cjones@R1> ping 1.1.1.1 routing-instance R3 rapid count 3
PING 1.1.1.1 (1.1.1.1): 56 data bytes
!!!
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.364/5.589/8.287/2.037 ms

cjones@R1> ping 2.2.2.2 routing-instance R3 rapid count 3
PING 2.2.2.2 (2.2.2.2): 56 data bytes
!!!
--- 2.2.2.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.162/3.175/4.645/1.064 ms

And there you have it! A full three router topology using a single SRX210H. This should save you some cash when it comes time to building a lab for your JNCIE studies!

Check it out: www.overpromisesunderdelivers.net

Now, granted the pizza video is pretty amusing, the entire thing just screams of desperation. Is Cisco really doing this poorly? This past year, they’ve had their “Good Enough Network” campaign, directed squarely at HP (though they certainly didn’t name them – that would give HP credibility it doesn’t deserve).

Cisco also came up with their new marketing term: “Junipered”. According to the links that Cisco’s various Twitter accounts have been spamming, Junipered means “to be promised a service or a product that was not delivered”. Again, this might have been a decent PR angle for Cisco if they had followed suit with their “Good Enough Network” campaign, and simply stated to not trust a company that over-promises and under-delivers. While it’s not accurate, it would at least be a credible PR angle.

So lets talk for a moment about the “over promised and under delivered” thing. Cisco’s PR stunt website mentions two key things, Project Stratus and QFabric, and 100GigE modules for the MX series routers. First of all, I think Cisco (and apparently many others in the Twitterverse) are confused about the difference between a project and a product.

You see, a project announcement (for example, Project Stratus) is a definition of a plan, or goal. A project. Something being worked on. Project Stratus was announced years ago, in 2009. Since then, it has changed and evolved. Once it became ready, it became a product. QFabric was announced in February of 2011. If you read the press release for QFabric, you’ll notice a key piece: “The QF/Interconnect and QF/Director will be available for order in Q3“. More on this in a bit.

I think the reason Cisco is confused by this, is the fact that they rarely, if ever, announce projects. They only announce products. And even then, usually only when they are very close to shipping. This means Cisco doesn’t PROMISE anything, which means it’s near-impossible for them to under-deliver on a promise that doesn’t exist. So let’s make this clear: Cisco is bashing Juniper for being forward-thinking, and letting their customers know what’s in the pipeline. Bravo.

The other product mentioned is the 100GigE modules for the MX series routers. Cisco’s white paper, entitled “Why Cisco, Not Juniper”, from their “OPUD” site (as I will now refer to it) states that “Juniper promised 100 Gigabit Ethernet on MX-series edge routing products two-and-a-half years ago. It’s still not available.” Yes, it is true that Juniper announced 100GigE in 2009. They also announced 100GigE specifically for the MX series in Nov 2010. So in fact, it hasn’t even been a year, yet.

It should also be mentioned that there are already Juniper 100GigE interfaces in live use for customers who require it, for example Verizon, and the UK’s JANET. So while technically not available still, they are most certainly in use.

But wait… what else does Cisco say in their white paper? “Cisco promises and delivers: Cisco announced 100 Gigabit Ethernet on the ASR 9000 edge routing platform in June 2011 and will be shipping in Q4 of CY2011.” Wait a second. They “delivered” by saying it will ship NEXT QUARTER? Are they serious? Perhaps they invented a time machine? Now THAT would get their stocks out of the gutter!

Clearly you see the pattern here.

But the point of this blog post isn’t to argue with the FUD and lies that Cisco is spreading, it’s to comment on the childish PR stunt. So let’s get back to that, shall we?

Now after all of this nonsense began, Twitter was abuzz with comments about it, mostly negative. Even the Cisco supporters who drink the koolaid daily were talking about how it was a pathetic move. None of the posts were more telling than the one by Aaron Paxson:

Wow. Not much else you can say. Cisco, what have you done?

We also made up the #ciscoed twitter hashtag. The funny part is that Cisco actually started using it too. Unfortunately they managed to get a definition put on tagdef with their FUD, and because of the legion of pass4sure’d CCNAs, it’s an uphill battle to dethrone their definition. Some of the best ones are as follows:

@ccie15672: You know you’ve been #ciscoed when you find a bug and Cisco tells you to buy more routers or to not try to use that feature

@IPv6Freely You know you’ve been #ciscoed when your TAC call ends with them asking you what you did.

@jjjans You know you’ve been #ciscoedwhen the answer to a best practice implementation is that there are multiple ways and here are the whitepapers

Then I noticed Cisco’s newest blog post: “Trust, Relationships and Reputation: How Cisco Differs from the Competition”. I posted my thoughts on the PR stunt, and I got a very generic bunch of marketing babble from Rob Lloyd, going on about basically they must be doing things right because they had 16,000 customers at Cisco Live. He also rambled on with some supposed statistics about their customers. Worthless. But then I got an email that there had been a new reply to my post, and wow… pure comedy. Somebody had replied talking about how Juniper only gained market share because they made acquisitions. No, seriously, that was really his argument. I just mentioned words like “airespace”, “Catalyst” and “PIX”.

Cisco’s director of PR, David McCulloch replied with a whole load of nonsense about QFabric being late, and some more marketing babble. I’m not going to re-post it all here, go see for yourself. I also posted a reply, but it didn’t make it through moderation (I can tell, because it no longer says “your comment is awaiting moderation” anymore, and my comment is gone). But hey, I happened to screenshot my comment, figuring that might happen.

All while this was happening, I was having a pretty funny chat with a guy on Twitter. It wasn’t until about halfway through that I realized this was actually David McCulloch as well. I took a screenshot of this conversation too, as it’s pretty funny.

So what was Juniper’s response to all this? Not much, from the PR department (which is a good thing). They simply had this to say:

And after this, Juniper did the absolute best thing they could have done: they released the remaining pieces of QFabric. This was no surprise, considering the QF/I and QF/D have both been on the September price list for weeks (which I summarized in a recent blog post). But what makes this such a big deal? Scroll up, and check when Juniper promised QFabric to be shipping…. That’s right, they said Q3 2011. Over-promised and under-delivered? Hmm.. nope. Announced in February, and delivered exactly on time. The best part of the announcement was Juniper’s use of the #junipered hashtag that Cisco had made up:

Hilarious. Cisco, insert foot in mouth.

I just have to wonder what will happen from here. Will Cisco’s PR person who thought this was a good idea be let go? I mean, it’s not every day you see a multi-billion dollar company make an absolute fool of themselves.

“But what about the comics?”, I keep hearing. For those who don’t know, Juniper once had a (really bad and kinda creepy) series of cartoons they used in their marketing materials. Here’s my favourite:

Yes, they are bad. But still kinda funny. In fact, the most amusing part about them is the fact that they’re still pretty darn accurate. So, how is the latest Cisco PR stunt worse? Well, Juniper grew up. These cartoons were done at a time when Juniper was a small company, with very little market share, outside of the service provider world. You almost expect this kind of marketing from an upstart company. Certainly not from the 800lb gorilla of the industry. As an article posted by Stefan Fouant (@sfouant) mentioned: “The rule of thumb is never compare down because it degrades your position.”

All this PR stunt has managed to do is make Cisco look really desperate. They know their market share is slipping, their stocks are in the gutter, and Wall St has been calling for the head of their CEO for years. Brandon Bennett (@brandonrbennett) linked to a blog post by Luc Ceuppens which made a lot of sense. Actually, this sums up the entire thing nicely:

Well said, sir. All this PR stunt really does is acknowledge that Juniper has grown into a significant threat to their market share. Gone are the days of Cisco reigning through familiarity. The old adage of “Nobody ever got fired by buying Cisco” is dead. There are now options, and better options in many cases, and Cisco knows it and is getting desperate knowing that their lack of any real innovation for so long, and spending too much time working on things like Flip cameras, is starting to catch up to them.

I should probably also add a disclaimer here. I want to make it very clear that I’m not necessarily saying Juniper is better than Cisco, or anything like that. I’m just making commentary on the nonsense FUD that happened this week. As I stated to Juniper employees in private conversations, if they had done something as colossally stupid as what Cisco did this week, I’d be all over them too. They responded with “We’d expect nothing less.”

The following is a breakdown of the QFabric components, including pricing.

	QF/Node The QFabric Node (QFX3500) was the first component released, and is what your servers and storage will connect into. 1 RU device 48 SFP+ ports: 36 10GbE and 12 dual-mode 10GbE or 2/4/8 Gbps FC 4 QSFP+ ports: 4x 10Gbe or 40Gbps Redundant AC power supplies Runs Junos Operating System Model SKU Description List Price QFX3500-48S4Q-ACR QFX3500, 48 SFP+/SFP and 4 QSFP ports, redundant dual AC power supply, front to back air flow $34,000
	QF/Interconnect The QFabric Interconnect (QFX3008) is the chassis that the QFX3500s connect to. 21 RU high 8 slot chassis 128 QSFP 40G ports – wire speed 8 Fabric cards (10.24Tbps/chassis) Dual redundant control board Redundant AC power supply Front to back air flow Model SKU Description List Price QFX3008-CHASA-BASE QFX3008, 8 slots A/C base system with redundant dual control card, six redundant power supply $165,000 QFX3008-SF16Q Front card with 16 port QSFP for QFX3008 $95,000
	QF/Director The QFabric Director (QFX3100) is the “brains” of the whole thing. While the QFX3008 has “control cards” for the local chassis, QFabric as a whole needs a central device for management. Multiple QF/Ds are therefore recommended for redundancy. 2 RU device Has GE ports to connect to QF/Node and QF/Interconnect devices Based on x86 architecture Redundant AC power supply Dual disk and network interface cards Model SKU Description List Price QFX3100-GBE-ACR QFX3100 base system with redundant AC power supply, dual disk and network interface cards $25,000

Optics

Licensing

For more information on QFabric, head over to the QFabric page on Juniper.net.

For “real life” action photos of the QFabric pieces, head over to Greg Ferro’s blog.

Starting on R1, create your IKE proposal. In our case we will use:

• DH Group 2
• SHA1
• AES-128-CBC
• 3600 second lifetime

set security ike proposal IKE_PROPOSAL authentication-method pre-shared-keys
set security ike proposal IKE_PROPOSAL dh-group group2
set security ike proposal IKE_PROPOSAL authentication-algorithm sha1
set security ike proposal IKE_PROPOSAL encryption-algorithm aes-128-cbc
set security ike proposal IKE_PROPOSAL lifetime-seconds 3600

Next we create our IKE policy, and specify the IKE_PROPOSAL proposal. We also specify our pre-shared key here:

set security ike policy IKE_POLICY proposals IKE_PROPOSAL
set security ike policy IKE_POLICY pre-shared-key foobarpsk

Finally, we have to specify our IKE gateway information. In this example:

• We’re going to use our IKE_POLICY policy
• Our peer address is 2.2.2.2
• The interface our IPSec tunnel is running on is ge-0/0/0.0

set security ike gateway IKE_GW ike-policy IKE_POLICY
set security ike gateway IKE_GW address 2.2.2.2
set security ike gateway IKE_GW external-interface ge-0/0/0

Great! Next up is our IPSec proposal. We’ll be using:

• ESP
• SHA1
• AES-128-CBC
• 3600 second lifetime

set security ipsec proposal IPSEC_PROPOSAL protocol esp
set security ipsec proposal IPSEC_PROPOSAL authentication-algorithm hmac-sha1-96
set security ipsec proposal IPSEC_PROPOSAL encryption-algorithm aes-128-cbc
set security ipsec proposal IPSEC_PROPOSAL lifetime-seconds 3600

Following this is our IPSec policy, which specifies to use the IPSEC_PROPOSAL proposal:

set security ipsec policy IPSEC_POLICY proposals IPSEC_PROPOSAL

Last but not least, we have to tie it all together. We’re going to use the following:

• Secure Tunnel interface st0.0
• IKE gateway IKE_GW
• IPSec Policy IPSEC_POLICY

We will also use the “establish-tunnels immediately” configuration option that specifies that the tunnel should come up immediately.

set security ipsec vpn VPN bind-interface st0.0
set security ipsec vpn VPN ike gateway IKE_GW
set security ipsec vpn VPN ike ipsec-policy IPSEC_POLICY
set security ipsec vpn VPN establish-tunnels immediately

Now we can add an IP address to our st0.0 interface, and we can even run OSPF across the tunnel:

set interfaces st0 unit 0 family inet address 10.0.0.1/30
set protocols ospf area 0 interfaces st0.0

Beyond this, we need to add st0.0 to a zone, and be sure there is a policy permitting that traffic. Also keep in mind your Untrust zone is going to require host-inbond-traffic to allow the IPSec VPN to establish. Be sure to commit!

Duplicate the configuration on the other side, changing IP addresses as necessary, and you’re done!