I’ve worked through enough of the Juniper documentation/books to have a fairly good handle on how to configure these, but I wanted to check with the list to see if there are any Juniper-Specific gotchas I might run into that isn’t documented well.
I’ve done a bit of googling and am either finding stuff that is largely Cisco-specific or which is generic - all of which I’m rather familiar with based on my past history. Is there anything I should worry about which is Juniper-specific?
JUNOS default ARP timeout: 20 min.
If you connect to IXP's. Recommended ARP timeout: 4 hours.
If you are an OSPF shop, Cisco AD is 110 for internal and external
routes. Juniper is 10 for internal and 150 for external. This can be
changed via an export (maybe import) policy on the OSPF protocol.
There is no 'network' statement in the Junos world. There are a few
different ways to solve this same problem. Up to you how you do it.
Routing engine protection is much easier. A firewall filter on the
loopback interface. Here is a sample. This is really where your BCP
starts.
https://github.com/jcoeder/juniper-configurations/blob/master/protect-re.txt
Dynamic prefix-lists are pretty cool. They allow you to create prefix-
list based on other sections of the configuration.
# In this first statement we use wildcards surrounding a . as this is
the format of an IPv4 address.
set policy-options prefix-list BGP_PEERS_DYNAMIC apply-path "protocols
bgp group <*> neighbor <*.*>"
# In this second statement we use wildcards surrounding a : as this is
the format of an IPv6 address.
set policy-options prefix-list BGP_PEERS_DYNAMIC_V6 apply-path
"protocols bgp group <*> neighbor <*:*>"
Justin
If using loopbacks on the router you have to have a firewall filter on it to permit traffic to the device even if you have a firewall filter on individual interfaces that would allow/deny traffic
Hi
https://www.juniper.net/assets/kr/kr/local/pdf/books/tw-hardening-junos-devices-checklist.pdf
http://62.210.157.99/juniperdayone/TW_Hardening_Junos_Devices.pdf
Cheers
Pierre
Forrest,
Between Jason and Justin, (and now others probably) they’ve captured what I was already typing. Basically, that as soon as you create a loopback interface (with a L3 IP) you need to start planning your firewall filter for it. Most of it is as simple as creating filters for SSH and other administrative access to the loopback address, but some of it is not at all intuitive if you’re coming from a Cisco/Brocade world.
The loopback filter protects the RE, and, can, in many cases affect traffic flowing across transit interfaces, in a way that in a Cisco shop you would never have never considered. On a Juniper, if it will be processed in just about any way by the routing engine (even just a few packets in the flow) you need to account for that. It’s not as daunting as it sounds, but it needs to be accounted for. I’ll let their comments fill in the rest, because others have already provided good resources.
Above all, JUNOS makes sense when configuring, you literally the software gives you the feel of talking to the device. If your brain is programmed to be logically then all pieces and modes easily come to life and adaptation becomes a zero hustle.
~30 years of being a Cisco IOS shop or Cisco IOS-XR shop? A bit different.
Welcome to the SP-world of really nice JunOS
Conf
Blah blah blah
Commit check <----- will check your pending config for correctness
Commit | compare <----- will tell you what is about to change (similar to IOS-XR “show commit change diff”
…if you don’t like it….
Rollback
…if you are nervous about breaking something and what to smoke test it…
Commit confirmed 2 <----- allows you a couple minutes to see if the sky falls…if it does, it’ll all be good in 2 minutes when it reverses the change. XR has this too
…if you like it…
Commit
…if you still don’t like it…
Conf
Rollback 1
Commit
Gosh, there’s so much more
Built in monitor/sniffer for interfaces
JunOS is so linux based, that you will find a lot of things like that in it. Shell under the hood and see various other things
The mx204 has some strange 1 gig option for 10 gig interfaces… which are still referred to as xe-?/?/? even when operating in 1 gig…
-Aaron
I just remembered another one I use the heck out of….
Show whateverwhatever | refresh 1
Love it
Or refresh 30 (whatever time you want)
It’s so nice to be able to take hands off keyboard and know exactly when something changes in that show command…. Piping to “refresh” and a timer will redo that command over and over again
Another one is the ability to stop and restart processes, which wasn’t as possibly in Classic IOS (perhaps more in XE and was possible in XR), but I was pleased with the ability to do this in JunOS
There have been a few occasions when the JTAC has had me restart a jdhcpd process or fxp0 process or whatever during bug-hits as a quick way of freeing up the pegged CPU or leaked out memory, until a JunOS upgrade perm fix could be accomplished.
Oh, show log interactive – really cool, it’s like having your own local aaa (tacacs) accounting log… right there on the box a built in log file showing every command that was typed be everyone!
Forgive me if I continue sending emails as I recall nice things I’ve learned over the last few years during my conversion from cisco to juniper
IOS is nice
IOS-XE is nicer (I guess, lol)
IOX-XR is great
JunOS is greater I think – seems that there is just more you can do in JunOS than XR… and JunOS capabilities are across many of Junipers products… XR is a bit limited to certain platforms (although growing with more NCS products, first 5x00, not 540)
-Aaron
Typos, sorry…
Meant …fxpc process…
Meant …now 540
Um, my MX-204 says FreeBSD amd64.
I will say that so far I’m finding JunOS and the Juniper documentation to be a welcome change. In my other life I write networking/IoT code and have done my fair share of unix (linux, freebsd, sunos, etc.) administration over the years. As a result, JunOS is feeling more natural than some devices I’ve configured over the years. Right now, It’s just a matter of learning where all the stones one has to turn over to make it work well are…
Thanks to everyone for the answers so far. It will take a bit for me to dig through and process them… I can also see that there are definitely some gems I didn’t know about.
Matt Harris
Infrastructure Lead Engineer
816‑256‑5446
Direct
Looking for something?
We build and deliver end‑to‑end IT solutions.
Google around for Junos Evolution. Junos is going native Linux.
There is linux happening in some devices.
https://www.juniper.net/documentation/en_US/junos/topics/concept/evo-overview.html
Ryan
Once upon a time, Matt Harris <matt@netfire.net> said:
There's no Linux going on in Junos itself as far as I know, however Juniper
does utilize Wind River Linux as an intermediary virtualization step for
some of their virtualized products like the vSRX.
Most (if not all) of the current routing engines run the FreeBSD-based
Junos in a VM on a Linux hypervisor. There's also Junos Evolved, which
is Junos ported over to a Linux-based system instead of FreeBSD (among
other architectual changes).
Right, it's been freebsd forever as I understand it, but I thought there had
been some more recent involvement with linux, which is why I said that. I'm
not an authority on it though.
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/vm-host-o
verview.html
-Aaron
Yeah, it changes.
They started with FreeBSD 4.x + their patches, then moved it inside a hardened Linux for virtualization functions (watch closely the boot sequence).
uname returns
MX960 - FreeBSD amd64
QFX 5100 - JUNOS i386 (build tag show indication its FreeBSD still)
Very-specifically for the MX204, not all the possible port combinations work. Check https://apps.juniper.net/home/port-checker/index.html, if you haven't already.
Juniper more generally, the big one that bit me coming from Cisco-land is that lots of the config telling you what the interface is doing isn't under the interface config, nor is it findable at all without some magic pipelines. If you're used to seeing:
#show run int gi0/0/0
interface gi0/0/0
ip vrf forwarding blah
To tell you what VRF the interface is in, you may be annoyed by:
#show configuration routing-instances | display set | m gi0/0/0
routing-instance blah interface gi0/0/0
Similarly for QoS / service policies. They're not attached to the interface at the interface level.
There are some BGP differences that may or may not hurt your brain depending on what you're offering in your network and how you build it. Loop-detection is the opposite way around across the two platforms. Juniper won't send to a neighbour whose AS is already in the path unless you specifically tell it to; Cisco sends everything regardless, but does the path check and drops on receipt unless you configure 'allow-as-in'.
From memory, default behaviour for EBGP is also different, absent any filtering policy. Juniper works like IOS XR and fails closed - no policy = send nothing. Vanilla IOS (and XE) fail open - no policy = send all the routes.
Mostly, though, quality-of-life improvements around tab-completion of named objects, atomic commit, rollback, etc are good. "Commit confirm" is less of a blunt tool than "reload in..." before you start configuring. Less of a revelation if you're coming from XR.
Regards,
Tim.
I guess he never saw a Juniper M40, it’s literally an i686/x86 32-bit motherboard for the routine engine, glued to a chassis with linecards containing custom ASICs and optics. As I recall it was a moderate speed Pentium 2 with some average amount of RAM and a 2.5" 44pin ATA66 laptop hard drive.
Or a M20 or so on… The entire origin of JunOS is with FreeBSD.