Vagrant and Juniper's Firefly Perimeter

Looks like Juniper is working hard to get their Firefly perimeter usable on Vagrant. See also, the firefly-packer github for info and caveats.

fluong@fluong-ltm:vagrant$ mkdir firefly010
fluong@fluong-ltm:vagrant$ cd firefly010/
fluong@fluong-ltm:firefly010$ ls
fluong@fluong-ltm:firefly010$ vagrant init juniper/ffp-12.1X46-D20.5
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
fluong@fluong-ltm:firefly010$ ls
Vagrantfile
fluong@fluong-ltm:firefly010$ vim Vagrantfile
fluong@fluong-ltm:firefly010$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'juniper/ffp-12.1X46-D20.5' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Loading metadata for box 'juniper/ffp-12.1X46-D20.5'
    default: URL: https://vagrantcloud.com/juniper/ffp-12.1X46-D20.5
==> default: Adding box 'juniper/ffp-12.1X46-D20.5' (v0.1.2) for provider: virtualbox
    default: Downloading: https://vagrantcloud.com/juniper/boxes/ffp-12.1X46-D20.5/versions/3/providers/virtualbox.box
    default: Progress: ##########################################################==> default: Successfully added box 'juniper/ffp-12.1X46-D20.5' (v0.1.2) for 'virtualbox'!
==> default: Importing base box 'juniper/ffp-12.1X46-D20.5'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'juniper/ffp-12.1X46-D20.5' is up to date...
==> default: Setting the name of the VM: firefly010_default_1411482071141_14275
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
    default: Warning: Connection timeout. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
    default: No guest additions were detected on the base box for this VM! Guest
    default: additions are required for forwarded ports, shared folders, host only
    default: networking, and more. If SSH fails on this machine, please install
    default: the guest additions and repackage the box to continue.
    default:
    default: This is not an error message; everything may continue to work properly,
    default: in which case you may ignore this message.
fluong@fluong-ltm:firefly010$ vagrant ssh
--- JUNOS 12.1X46-D20.5 built 2014-05-14 20:38:10 UTC
vagrant>

vagrant> show interfaces terse
Interface               Admin Link Proto    Local                 Remote
ge-0/0/0                up    up
ge-0/0/0.0              up    up   inet     10.0.2.15/24
gr-0/0/0                up    up
ip-0/0/0                up    up
lsq-0/0/0               up    up
lt-0/0/0                up    up
mt-0/0/0                up    up
sp-0/0/0                up    up
sp-0/0/0.0              up    up   inet
                                   inet6
sp-0/0/0.16383          up    up   inet     10.0.0.1            --> 10.0.0.16
                                            10.0.0.6            --> 0/0
                                            128.0.0.1           --> 128.0.1.16
                                            128.0.0.6           --> 0/0
dsc                     up    up
gre                     up    up
ipip                    up    up
lo0                     up    up
lo0.16384               up    up   inet     127.0.0.1           --> 0/0
lo0.16385               up    up   inet     10.0.0.1            --> 0/0
                                            10.0.0.16           --> 0/0
                                            128.0.0.1           --> 0/0
                                            128.0.0.4           --> 0/0
                                            128.0.1.16          --> 0/0
lo0.32768               up    up
lsi                     up    up
mtun                    up    up
pimd                    up    up
pime                    up    up
pp0                     up    up
ppd0                    up    up
ppe0                    up    up
st0                     up    up
tap                     up    up
vlan                    up    down

#JUNOS - Recovering from Alternate Media (YMMV)

Had a situation at work where I had to remind myself of something so that means it’s time for a new blog post.

--- JUNOS 12.3R3.4 built 2013-06-14 00:09:12 UTC
---
--- NOTICE: System is running on alternate media device      (/dev/ad1s1a).
---

fluong@tickle-me-elmo-re0> show system storage | no-more 
Filesystem              Size       Used      Avail  Capacity   Mounted on
/dev/ad1s1a             3.5G       283M       3.1G        8%  / <<<<<
devfs                   1.0K       1.0K         0B      100%  /dev
/dev/md0                 41M        41M         0B      100%  /packages/mnt/jbase
/dev/md1                 32M        32M         0B      100%  /packages/mnt/jkernel64-12.1R1.9
/dev/md2                 73M        73M         0B      100%  /packages/mnt/jpfe-X960-12.1R1.9
/dev/md3                5.0M       5.0M         0B      100%  /packages/mnt/jdocs-12.1R1.9
/dev/md4                 78M        78M         0B      100%  /packages/mnt/jroute-12.1R1.9
/dev/md5                 28M        28M         0B      100%  /packages/mnt/jcrypto64-12.1R1.9
/dev/md6                 46M        46M         0B      100%  /packages/mnt/jpfe-common-12.1R1.9
/dev/md7                388M       388M         0B      100%  /packages/mnt/jruntime-12.1R1.9
/dev/md8                7.9G        22K       7.2G        0%  /tmp
/dev/md9                7.9G        15M       7.2G        0%  /mfs
/dev/ad1s1e             394M        42K       390M        0%  /config
procfs                  4.0K       4.0K         0B      100%  /proc
/dev/ad1s1f              18G       2.3G        14G       14%  /var

Here’s the initial scenario. Routing-Engine re0 is booting from alternate media. IN MOST CASES this means a compact-flash on the routing has gone bad and has to be replaced by RMA, but in this case I happen to know that it’s a new RE and we had a USB install that went south. Keep this in mind and know that your mileage may vary with this one.

Other interesting considerations for this scenario is that for this router, a remote hands technician is not on site so we don’t have cheap easy options to do another USB install. Luckily JUNOS provides a means to rewrite the image on the compact-flash if you’re able to boot off the HDD/SSD: “request system snapshot partition

{backup}
root@tickle-me-elmo-re0> request system snapshot partition
Clearing current label...
Partitioning compact-flash media (ad0) ...
Partitions on snapshot:

  Partition  Mountpoint  Size    Snapshot argument
      a      /           671MB   root-size
      e      /config     400MB   config-size
      f      /var        2GB     var-size
Running newfs (671MB) on compact-flash media  / partition (ad0s1a)...
Running newfs (400MB) on compact-flash media  /config partition (ad0s1e)...
Running newfs (2GB) on compact-flash media  /var partition (ad0s1f)...
Copying '/dev/ad1s1a' to '/dev/ad0s1a' .. (this may take a few minutes)
Copying '/dev/ad1s1e' to '/dev/ad0s1e' .. (this may take a few minutes)
The following filesystems were archived: / /config

{backup}
root@tickle-me-elmo-re0> exit   

We verify that the compact-flash is in the boot list before rebooting.

root@tickle-me-elmo-re0% sysctl machdep.bootdevs
machdep.bootdevs: usb,compact-flash,disk1,disk2,lan

root@tickle-me-elmo-re0% cli req sys reboot

*** FINAL System shutdown message from root@tickle-me-elmo-re0 ***            

System going down IMMEDIATELY         

When your router boots next time, you should be able to verify that the root “/” partition is /dev/ad0xxx (for RE-S-1800). (marked below with “<<<<<<”)

fluong@tickle-me-elmo-re0> show system storage | no-more 
Filesystem              Size       Used      Avail  Capacity   Mounted on
/dev/ad0s1a             3.5G       272M       2.9G        8%  / <<<<<<
devfs                   1.0K       1.0K         0B      100%  /dev
/dev/md0                 40M        40M         0B      100%  /packages/mnt/jbase
/dev/md1                 19M        19M         0B      100%  /packages/mnt/jkernel64-11.4R3.7
/dev/md2                 60M        60M         0B      100%  /packages/mnt/jpfe-X960-11.4R3.7
/dev/md3                5.0M       5.0M         0B      100%  /packages/mnt/jdocs-11.4R3.7
/dev/md4                 78M        78M         0B      100%  /packages/mnt/jroute-11.4R3.7
/dev/md5                 28M        28M         0B      100%  /packages/mnt/jcrypto64-11.4R3.7
/dev/md6                 45M        45M         0B      100%  /packages/mnt/jpfe-common-11.4R3.7
/dev/md7                382M       382M         0B      100%  /packages/mnt/jruntime-11.4R3.7
/dev/md8                7.9G        18K       7.2G        0%  /tmp
/dev/md9                7.9G       744K       7.2G        0%  /mfs
/dev/ad0s1e             393M        44K       362M        0%  /config
procfs                  4.0K       4.0K         0B      100%  /proc
/dev/ad1s1f              18G       1.7G        15G       10%  /var

JNCIE-SP: For Class-of-Service Know Your Defaults and Be Ready to Do Some Conversion

My exam prep continues. I spent a bit of time sitting with class-of-service this weekend and I think I have a good strategy for CoS that I want to share.

Preparation

I’m going to assume that you’re studying how to configure all of the basics of class-of-service for the exam. This post won’t cover much about configuration. You should know how to create custom classifiers, rewrite rules, forwarding-classes, schedulers, and scheduler-maps. You should know how to apply these to your interfaces.

You need to study that. I’m not here to talk about it. Instead, I wanted to discuss a couple of points that are a bit more subtle and strategic in nature that I think I worked out this weekend.

Know your Defaults

If you’re not asked to implement any special forwarding classes, using the default forwarding classes, rewrite-rules, classifiers, and schedulers can be a huge time saver during the exam. The assumption here is that you’re doing some work at the edge to get the traffic marked into the specified forwarding classes. After you have it classified on the first box, you may have some additional work to do to make sure the rest of the network knows how to handle your classifications.

So here’s my big tip: Learn your defaults and be prepared to modify or over-configure them.

So what do I mean by “Learn Your Defaults”? Basically, you need to be able to answer these questions:

  • What forwarding-classes exist by default?
  • What classifiers and rewrite rules are configured by default?
  • What is the difference between classifiers: ipprec-default and ipprec-compatibility?
  • What schedulers are configured by default?
  • What show commands can I use to look at these if I forget?

Because it’s too lengthy to include here, I’ll just link to an Evernote Shard with a whole bunch of outputs and links to the documentation.

You can augment your bit of memorization work by using “show class-of-service…” commands available. This is good for me because I am lazy but there is another good reason to use the show command output. Because the details of what configuration is default may change as you go from one version of JUNOS to another, (and you may not be practicing on the exact version used on in the exam environment) knowing how to verify the defaults from show command outputs can save you in case of any differences between.

With any luck, the requirements will permit you to apply some default classifiers and rewrite rules to get you carried through your backbone.

Be Ready to Do Some Binary Conversion

You’re gonna need to be able to check your work.

Ping lets you set the ToS bit, which is handy to create DSCP or IP-Precedence marked traffic, but the value has to be specified as a decimal number. This may require math or a calculator or a bit of memorization. If you’re not verifying against IP header code points, you will have to do some temporary config changes with MF classifiers to test your configs. I don’t discuss that in detail here, just the IP ToS verification.

Knowing your basics for how ToS/IPPrec/DSCP are mapped is crucial knowledge here:

  • IP Precedence is a 3-bit value occupying the high order bits of the ToS field in the IP header. You can convert IP precedence to a decimal TOS value by multiplying by 32 (or 2^5) (e.g. 101 == 5 // 5*32 = 160).
  • DSCP is a 6-bit value occupying the high order bits of the ToS field in the IP header. Incidentally, this makes it mutually exclusive vs. IP Precendence. You can convert these to a decimal ToS value by converting to decimal and then multiplying by 4 (2^2). My brain is tired just thinking about this, so…

If you don’t want to do math at all, use the “Programmer” mode of the calculator app that comes with Windows to do the conversion. You still need to know that the value occupies the high order bits of an 8-bit field to do this. Pad IPPrec with 5 zeros to the right or DSCP with 2 zeroes to the right and you are good to go. Example follows for IP Precendence value 101:

binary

decimal

If you are going to verify with pings, be able to do this conversion quickly.

Exam Strategies

  1. Read the requirements in detail and correlate with any requirements from other sections that may impose restrictions on what methods you may use to achieve these goals.

  2. Classify at the ingress edge. To classify by behavior aggregate code-points, use a classifier. Only use multifield classification if it is required for classification based on other packet characteristics.

  3. If you need to police certain classes based on code-points, you’re already classified and you can simply use “from forwarding class”.

  4. If you have to add a firewall filter, including counters in the filter can be handy for verification.

  5. If possible, use the available “default” forwarding-classes, classifiers, and rewrite rules to your advantage and either over-configure them (meaning, explictly configure defaults) or know how to verify them quickly. Apply these to backbone interfaces. This will be handy if you need forwarding classes to be handled on every router in the backbone.

  6. Verify with pings through to your designated destinations, if you can. Use the calculator to work out ToS values if you need to. Use any firewall counters you have applied and “show interfaces queue” outputs. Test as many traffic classes as you can to verify you have the requirements met.

The Wording Will Get You

Something to watch out for: If the requirements tell you to preserve the “markings” through the network, I suppose you may not be able to achieve that using defaults. I’d ask the proctor on that note.