nanog mailing list archives

RE: Juniper configuration recommendations/BCP


From: "tim () pelican org" <tim () pelican org>
Date: Fri, 9 Oct 2020 17:30:39 +0100 (BST)

On Thursday, 8 October, 2020 10:37, "Forrest Christian (List Account)" <lists () packetflux com> said:

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?

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.



Current thread: