Migrating from Cisco to Juniper – Admin Distances

When migrating from Cisco to Juniper, care has to be taken because the two vendors have completely different values for default admin distances. If you haven’t come across this before then you’ll be scratching your head for a few minutes wondering why, for example, your traceroute is bouncing around your IGP and never heading out to eBGP.

A couple of examples:

Route Source Cisco Value Juniper Value
Connected interface 0 0
Static route 1 5
External Border Gateway Protocol (BGP) 20 170
OSPF 110 150
Intermediate System-to-Intermediate System (IS-IS) 115 160/165
Routing Information Protocol (RIP) 120 100
Internal BGP 200 170

BGP cost can be “fixed” globally to be Cisco equivalent if desired by the following example on Juniper:

set protocols bgp preference 20

Backing up and Restoring JunOS devices

One great thing about JunOS – it’s extremely quick to get a replacement unit into service when something’s gone wrong. The following procedure can be used to achieve this. It’s crazy how many people still use cut and paste when you can just do something like this.

1) Backups are taken to a management server

testbox# scp me@myjuniper:/config/juniper.conf.gz /backups/myjuniper.conf.gz
myjuniper.conf.gz            100% 5051     4.9KB/s   00:00

2) Log on to replacement unit (assumes that root-authentication is already configured here) and copy the config over

me@amnesiac> start shell
% cd /config
% scp me@testbox:/backups/myjuniper.conf.gz .
myjuniper.conf.gz            100% 5051     4.9KB/s   00:00
% exit

3) Load the config file, completely discarding the current config.

me@amnesiac> edit
Entering configuration mode

me@amnesiac> load override /config/myjuniper.conf.gz
me@amnesiac> commit and-quit

Alternatively, load merge could be used, but you’d have to remember to remove anything unnecessary such as any default route you added to make the box manageable to start with.

Also, you can keep config backups you can read and paste in more easily by running:

me@myjuniper> show configuration | display set
set version 8.5R4.3
set system host-name myjuniper
set system domain-name subnetzero.org
set system mirror-flash-on-disk
set system authentication-order tacplus 
set system authentication-order password

Splunk Field Extractions for Juniper SRX

The first two were found elsewhere on the web but I noticed there was no deny event extraction so made my own.

To make your SRX send syslogs, the following example can be modified. You might find it easier to use local facilities to split out your logs by type using syslog-ng. Be sure to monitor performance as you enable logging – lots of logging on a extremely busy firewall may generate a fair bit of extra CPU overhead.

SRX Config

    syslog {
         host {
            any any;
            match RT_FLOW_SESSION;
            facility-override local5;

Set your desired policies to log… eg:

edit security policies from-zone trust to-zone untrust
set policy web-traffic-outbound then log session-init session-close
set policy default-drop-trust-untrust then log session-init session-close

Splunk Extractions

Create events


Close events


Deny Events


Policy Action Field (common)


Next personal project: Write a decent Splunk app for SRX!

Resolve MAC addresses to Port, IP and DNS Name

Resolving MAC address to port, IP and DNS or name service name (or more simply for some, resolve mac to name) is a challenge that every network engineer has come across at some point in their career. It’s easily solved with a bit of thought and logic. Unfortunately the past few products I’ve dealt in the past with for this purpose have either been abandoned or aren’t as multi-vendor as I’d like, so it seems that the only solution is to write your own… bash and expect is sufficient.

If you’re thinking about doing this (and it’s a great learning exercise), you need to get around the following:

– Determining which interfaces are trunks on the switches so you can strip those MAC entries out (CDP works quite well)
– Converting ARP and MAC info into a “clean” format (eg: CatOS and IOS output is a different format)
– Detecting the fields across various pieces of hardware as display output isn’t always consistent for the same commands
– Inconsistent logins/passwords
– Correlating the IP/MAC/Interface information together. This can be done with the UNIX join command and some awk/sed
– What you do with MACs that don’t resolve to an IP address (I include a flag to print these if required)
– Whether the machine you run DNS queries on will be able to resolve the IPs to PTR records
– If using expect, stripping out stray characters (eg \r) that will mess up your greps and other string searches
– Add plenty of debugging so you can quickly tell why something isn’t working properly

I used expect to go and grab the ARP, CDP and MAC information seeing as you can’t get all the required information from SNMP on many devices these days. In my case, this results in the following type of output:

Switch       Interface       VLAN  MAC             IP               DNSName
nycsw12      Fa3/10          100   0060.b0aa.0000    NO_DNS
nycsw12      Fa2/16          99    1060.4b61.0001     nyc-pc573.company.corp.
nycsw12      Fa2/37          101   1060.4b64.0002    nyc-pc555.company.corp.
nycsw12      Fa2/42          101   1060.4b68.0003   nyc-pc572.company.corp.
nycsw12      Fa2/45          98    1060.4b6a.0004     nyc-pc588.company.corp.
nycsw12      Fa2/32          98    1060.4b6a.0005    nyc-pc601.company.corp.
nycsw12      Fa3/3           100   2c41.389e.d19f    nyc-pc480.company.corp.
nycsw13      Fa2/4           100   5c26.0a01.0ac4    nyc-pc246.company.corp.
nycsw13      Fa2/6           100   6c3b.e531.2ddf    nyc-pc745.company.corp.

Of course, you can always just use Excel to do a VLOOKUP of your mac-address table output against a sorted table containing all your arp entries, but that’s a bit less automatic.