On Thursday, 8 October, 2020 10:37, "Forrest Christian (List Account)" <li...@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.
