Category Archives: juniper

Adding the “last commit” line back into your Junos RANCID commits

As of RANCID 3.7, an annoying change was made by the authors of RANCID. The “last commit” line was removed from Junos-based device diiffs.

http://www.shrubbery.net/pipermail/rancid-announce/2017-September/000031.html

junos.pm: filter cycling & useless last commit config line

This wasn’t a switch that we could easily turn on or off, depending on your preference either. We had to dig through the code to re-enable this “useless” feature.

Find your junos.pm file and comment out the following line:

next if (/^## last commit: /i);

The “last commit” line will be present again upon your next RANCID run.

For another valuable RANCID tip, check out another article we wrote.

Using the replace command in Junos

My ISP has the audacity to change my dynamic IP after only two years and I had to change my IP across many different systems. I found a command and worked out the regex to replace my IP across the entire Junos configuration in a single line. Here’s how:

replace pattern "172\.16\.1\.1" with "10.0.0.1"

I was able to change address books, firewall rules, security policies, prefix lists, etc, with a single command.

Junos packet capture on branch series SRXs

Performing a packet capture is easy to do on any Juniper branch series SRX.

Three sections of configuration are required: forwarding-options, interfaces and firewall. Examples are below:

set forwarding-options packet-capture file filename PCAP files 5 size 10m

set interfaces ge-0/0/0 unit 0 family inet filter input PCAP
set interfaces ge-0/0/0 unit 0 family inet filter output PCAP

set firewall filter PCAP term PCAP1 from source-address 172.16.0.0/12
set firewall filter PCAP term PCAP1 from destination-address 192.168.0.0/16
set firewall filter PCAP term PCAP1 then sample
set firewall filter PCAP term PCAP1 then accept
set firewall filter PCAP term PCAP2 from source-address 192.168.0.0/16
set firewall filter PCAP term PCAP2 from destination-address 172.16.0.0/12
set firewall filter PCAP term PCAP2 then sample
set firewall filter PCAP term PCAP2 then accept
set firewall filter PCAP term ALLOW-EVERYTHING-ELSE then accept

The result looks as such:

interfaces {
    fe-0/0/0 {
        unit 0 {
            family inet {
                filter {
                    input PCAP;
                    output PCAP;
                }
            }
        }
    }
}

forwarding-options {
    packet-capture {
        file filename PCAP files 5 size 10m;
    }
}

firewall {
    filter PCAP {
        term PCAP1 {
            from {
                source-address {
                    172.16.0.0/12;
                }
                destination-address {
                    192.168.0.0/16;
                }
            }
            then {
                sample;
                accept;
            }
        }
        term PCAP2 {
            from {
                source-address {
                    192.168.0.0/16;
                }
                destination-address {
                    172.16.0.0/12;
                }
            }
            then {
                sample;
                accept;
            }
        }
        term ALLOW-EVERYTHING-ELSE {
            then accept;
        }
    }
}

Alternatively, you can apply this filter on the loopback interface if you wish to capture all packets matching the filter criteria on all interfaces.

To read the PCAP file, simply enter into the shell and use tcpdump:

start shell
tcpdump -r /var/tmp/PCAP.fe-0.0.0

Juniper BGP path selection

  1. Verify that the next hop can be resolved.
  2. Choose the path with the lowest preference value (routing protocol process preference).
  3. Prefer the path with higher local preference. For non-BGP paths, choose the path with the lowest preference2 value.
  4. If the accumulated interior gateway protocol (AIGP) attribute is enabled, prefer the path with the lower AIGP attribute.
  5. Prefer the path with the shortest autonomous system (AS) path value.
  6. Prefer the route with the lower origin code.  Routes learned from an IGP have a lower origin code than those learned from an exterior gateway protocol (EGP), and both have lower origin codes than incomplete routes (routes whose origin is unknown).
  7. Prefer the path with the lowest multiple exit discriminator (MED) metric.
  8. Prefer strictly internal paths, which include IGP routes and locally generated routes (static, direct, local, and so forth).
  9. Prefer strictly external BGP (EBGP) paths over external paths learned through internal BGP (IBGP) sessions.
  10. Prefer the path whose next hop is resolved through the IGP route with the lowest metric.
  11. If both paths are external, prefer the currently active path to minimize route-flapping.
  12. Prefer a primary route over a secondary route. A primary route is one that belongs to the routing table. A secondary route is one that is added to the routing table through an export policy.
  13. Prefer the path from the peer with the lowest router ID. For any path with an originator ID attribute, substitute the originator ID for the router ID during router ID comparison.
  14. Prefer the path with the shortest cluster list length. The length is 0 for no list.
  15. Prefer the path from the peer with the lowest peer IP address.

Comparing Cisco and Juniper administrative distance

Protocol Cisco Juniper
Connected / Direct 0 0
Static 1 5
EIGRP Summary 5
OSPF Internal 10
IS-IS Level 1 Internal 15
IS-IS Level 2 Internal 18
BGP External 20
EIGRP Internal 90
OSPF All 110
IS-IS All 115
RIP 120 100
OSPF External 150
IS-IS Level 1 External 160
IS-IS Level 2 External 165
EIGRP External 170
BGP All 170
BGP Internal 200

Fixing your Juniper SRX branch series boot partition

A recent storm caused us to lose power and the next time I logged in into my SRX100H2 home router, I was greeted with this warning:

***********************************************************************
**                                                                   **
**  WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE      **
**                                                                   **
**  It is possible that the primary copy of JUNOS failed to boot up  **
**  properly, and so this device has booted from the backup copy.    **
**                                                                   **
**  Please re-install JUNOS to recover the primary copy in case      **
**  it has been corrupted.                                           **
**                                                                   **
***********************************************************************

Luckily, the fix was easy and kudos to Juniper for implementing the two-partition system. Here’s the fix:

request system snapshot slice alternate

To verify the procedure, issue the following command:

show system snapshot media internal

The results should look something like this:

Information for snapshot on       internal (/dev/da0s1a) (backup)
Creation date: Aug 14 18:06:53 2015
JUNOS version on snapshot:
  junos  : 12.1X44-D35.5-domestic
Information for snapshot on       internal (/dev/da0s2a) (primary)
Creation date: Jul 31 11:15:08 2016
JUNOS version on snapshot:
  junos  : 12.1X44-D35.5-domestic

Juniper SRX data center firewall default security policy

Being a routing and switching guy (mostly service provider stuff), I don’t deal with firewalls very often, because I am far from a security expert and I would be doing a disservice to my clients. However, this week, I was tasked with getting two brand new Juniper SRX1400s setup and updated I learned three things during this process: 1) unlike the branch-series SRXs, the data-center series comes with very little configuration and no security configuration whatsoever; 2) the default policy if no policy is to deny, and; 3) there’s a difference between inbound host packets and transit packets, and at the very least, the inbound host configuration must be set before you can do anything to the firewall. Example below:

Show

zones {
    security-zone untrust {
        interfaces {
            xe-0/0/7.0 {
                host-inbound-traffic {
                    system-services {
                        all;
                    }
                }
            }
        }
    }
}

Display set

set security zones security-zone untrust interfaces xe-0/0/7.0 host-inbound-traffic system-services all

A couple caveats:

First, if this is the only policy you add, you’ll probably find people trying to brute force any services you have running on the firewall within minutes, such as SSHD.

Second, the statement must be applied to a logical interface and not a physical interface (xe-0/0/7.0 vs. xe-0/0/7) in order for it to work.