Mailing List Archive

On 08/10/2020 11:37, Forrest Christian (List Account) wrote:
> 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

On Thu, 2020-10-08 at 03:37 -0600, Forrest Christian (List Account)
wrote:
> <ISP hat on>
> After nearly 30 years of being a cisco shop, I'm working on
> configuring our first pair of Juniper MX204's to replace our current
> provider-edge cisco.
>
> 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?
>
> --
> - Forrest

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.

Sincerely,
Casey Russell
Network Engineer
[image: KanREN] <http://www.kanren.net>
[image: phone]785-856-9809
2029 Becker Drive, Suite 282
Lawrence, Kansas 66047
XSEDE Campus Champion
Certified Software Carpentry Instructor
[image: linkedin]
<https://www.linkedin.com/company/92399?trk=tyah&trkInfo=clickedVertical%3Acompany%2CclickedEntityId%3A92399%2Cidx%3A1-1-1%2CtarId%3A1440002635645%2Ctas%3AKanREN>
[image:
twitter] <https://twitter.com/TheKanREN> [image: twitter]
<http://www.kanren.net/feed/> need support? <support@kanren.net>



On Thu, Oct 8, 2020 at 4:39 AM Forrest Christian (List Account) <
lists@packetflux.com> wrote:

> <ISP hat on>
> After nearly 30 years of being a cisco shop, I'm working on configuring
> our first pair of Juniper MX204's to replace our current provider-edge
> cisco.
>
> 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?
>
> --
> - Forrest
>

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.



*Paschal Masha*
Lead Network Engineer
6x7 Networks | 1 (831)325-0544
Time Zone: PST


On Thu, Oct 8, 2020 at 6:44 PM Justin Oeder <jcoeder@gmail.com> wrote:

> 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
>
> On Thu, 2020-10-08 at 03:37 -0600, Forrest Christian (List Account)
> wrote:
> > <ISP hat on>
> > After nearly 30 years of being a cisco shop, I'm working on
> > configuring our first pair of Juniper MX204's to replace our current
> > provider-edge cisco.
> >
> > 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?
> >
> > --
> > - Forrest
>
>

~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







From: NANOG <nanog-bounces+aaron1=gvtc.com@nanog.org> On Behalf Of Forrest Christian (List Account)
Sent: Thursday, October 8, 2020 4:38 AM
To: nanog list <nanog@nanog.org>
Subject: Juniper configuration recommendations/BCP



<ISP hat on>

After nearly 30 years of being a cisco shop, I'm working on configuring our first pair of Juniper MX204's to replace our current provider-edge cisco.



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?



--

- Forrest

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

> On Oct 8, 2020, at 10:55 AM, <aaron1@gvtc.com> <aaron1@gvtc.com> wrote:
>
> JunOS is so linux based

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.

On Thu, Oct 8, 2020 at 9:53 AM Paschal Masha <paschal.masha@6by7.net> wrote:

> 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.
>
>
>
> *Paschal Masha*
> Lead Network Engineer
> 6x7 Networks | 1 (831)325-0544
> Time Zone: PST
>
>
> On Thu, Oct 8, 2020 at 6:44 PM Justin Oeder <jcoeder@gmail.com> wrote:
>
>> 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
>>
>> On Thu, 2020-10-08 at 03:37 -0600, Forrest Christian (List Account)
>> wrote:
>> > <ISP hat on>
>> > After nearly 30 years of being a cisco shop, I'm working on
>> > configuring our first pair of Juniper MX204's to replace our current
>> > provider-edge cisco.
>> >
>> > 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?
>> >
>> > --
>> > - Forrest
>>
>>

--
- Forrest

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.
On Thu, Oct 8, 2020 at 5:51 PM Chris Boyd <cboyd@gizmopartners.com> wrote:

>
>
> > On Oct 8, 2020, at 10:55 AM, <aaron1@gvtc.com> <aaron1@gvtc.com> wrote:
> >
> > JunOS is so linux based
>
> Um, my MX-204 says FreeBSD amd64.
>

Junos has always had a large basis coming from FreeBSD way back when.

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.

Google around for Junos Evolution. Junos is going native Linux.



From: NANOG <nanog-bounces+webnetwiz=gmail.com@nanog.org> on behalf of Matt Harris <matt@netfire.net>
Date: Thursday, October 8, 2020 at 4:15 PM
To: Chris Boyd <cboyd@gizmopartners.com>
Cc: nanog list <nanog@nanog.org>
Subject: Re: Juniper configuration recommendations/BCP



Matt Harris?
|

Infrastructure Lead Engineer

816?256?5446
|

Direct

Looking for something?
Helpdesk Portal
|

Email Support

|

Billing Portal

We build and deliver end?to?end IT solutions.
On Thu, Oct 8, 2020 at 5:51 PM Chris Boyd <cboyd@gizmopartners.com> wrote:



> On Oct 8, 2020, at 10:55 AM, <aaron1@gvtc.com> <aaron1@gvtc.com> wrote:
>
> JunOS is so linux based

Um, my MX-204 says FreeBSD amd64.



Junos has always had a large basis coming from FreeBSD way back when.



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.

There is linux happening in some devices.

https://www.juniper.net/documentation/en_US/junos/topics/concept/evo-overview.html

Ryan

On Thu, Oct 8, 2020, 4:16 PM Matt Harris <matt@netfire.net> wrote:

> Matt Harris?
> | Infrastructure Lead Engineer
> 816?256?5446
> | Direct
> Looking for something?
> *Helpdesk Portal* <https://help.netfire.net/>
> | *Email Support* <help@netfire.net>
> | *Billing Portal* <https://my.netfire.net/>
> We build and deliver end?to?end IT solutions.
> On Thu, Oct 8, 2020 at 5:51 PM Chris Boyd <cboyd@gizmopartners.com> wrote:
>
>>
>>
>> > On Oct 8, 2020, at 10:55 AM, <aaron1@gvtc.com> <aaron1@gvtc.com> wrote:
>> >
>> > JunOS is so linux based
>>
>> Um, my MX-204 says FreeBSD amd64.
>>
>
> Junos has always had a large basis coming from FreeBSD way back when.
>
> 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.
>
>

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).

--
Chris Adams <cma@cmadams.net>

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)

-----
Alain Hebert ahebert@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443

On 2020-10-08 18:50, Chris Boyd wrote:
>
>> On Oct 8, 2020, at 10:55 AM, <aaron1@gvtc.com> <aaron1@gvtc.com> wrote:
>>
>> JunOS is so linux based
> Um, my MX-204 says FreeBSD amd64.

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.

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.


On Thu, Oct 8, 2020 at 3:51 PM Chris Boyd <cboyd@gizmopartners.com> wrote:

>
>
> > On Oct 8, 2020, at 10:55 AM, <aaron1@gvtc.com> <aaron1@gvtc.com> wrote:
> >
> > JunOS is so linux based
>
> Um, my MX-204 says FreeBSD amd64.
>

Thanks for setting me straight.



I had heard that there was some new stuff with Linux hypervisors or something like that…. So I misspoke.



Appreciate y’all



-Aaron

Here's a fun one.
By default Junos accepts extended communities on any BGP session (not just
on MP-BGP sessions like it's the default case on cisco -unless explicitly
enabled).
Since most operators are not aware of this default Junos behaviour, one can
be importing routes to interesting places if one were so inclined.

-so yeah bleach unwanted communities on ingress (bleach those that would
interfere with the ones used by the AS internally -so called
"untaggable"/"untouchable" ).

adam

> -----Original Message-----
> From: NANOG <nanog-
> bounces+adamv0025=netconsultings.com@nanog.org> On Behalf Of
> Chriztoffer Hansen
> Sent: Thursday, October 8, 2020 11:05 AM
> To: nanog@nanog.org
> Subject: Juniper configuration recommendations/BCP
> Importance: Low
>
>
> On 08/10/2020 11:37, Forrest Christian (List Account) wrote:
> > 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.

IOS-XR accepts extended communities and large communities by default.
You have to enable to send them, but not receive.

Regards,
Jakob.

-----Original Message-----
Date: Mon, 12 Oct 2020 15:06:05 +0100
From: <adamv0025@netconsultings.com>

Here's a fun one.
By default Junos accepts extended communities on any BGP session (not just
on MP-BGP sessions like it's the default case on cisco -unless explicitly
enabled).
Since most operators are not aware of this default Junos behaviour, one can
be importing routes to interesting places if one were so inclined.

-so yeah bleach unwanted communities on ingress (bleach those that would
interfere with the ones used by the AS internally -so called
"untaggable"/"untouchable" ).

adam

> -----Original Message-----
> From: NANOG <nanog-
> bounces+adamv0025=netconsultings.com@nanog.org> On Behalf Of
> Chriztoffer Hansen
> Sent: Thursday, October 8, 2020 11:05 AM
> To: nanog@nanog.org
> Subject: Juniper configuration recommendations/BCP
> Importance: Low
>
>
> On 08/10/2020 11:37, Forrest Christian (List Account) wrote:
> > 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.

* Forrest Christian (List Account) <lists@packetflux.com> [2020-10-08 11:39]:
> 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?

Some things that come to mind:

* Juniper has a default ARP policer that is _shared_ between all
interfaces. This will bite you if you attach the box to a large L2
segment (*cough* DE-CIX *cough*). So you should either:
- configure a non-shared policer:
set firewall policer my-arp-policer if-exceeding ....
set interface xe-0/0/0.0 family inet policer arp my-arp-policer

- disable default ARP policer for the interface (this is not recommended
and a hidden command)
set interface xe-0/0/0.0 family inet policer disable-arp-policer


* If you do Aggregated Ethernet (Port-Channel interfaces) you need to
reserve resources for the ae interface by declaring:
set chassis aggregated-devices ethernet device-count X
"device-count 3" would give you ae0 to ae2 as possible interfaces


* For all modern MX boxes you should normally set network-services
mode to enhanced-ip (this requires a reboot of the box):
set chassis network-services enhanced-ip

* Groups (set groups some-group ... / set <some config hierarchy> apply-group some-group)
are your friend

Want to see stuff that gets applied to the config trough groups?
show <some config hierarchy> | display inheritance
(add "no-comments" for just the config without additional information)

* It is kind of hard sometimes to figure out the right encapsulation /
vlan-tagging config for an interface. For most flexible use of a
port (this might differ depending on your configuration) on MX you
can use:
set interface xe-0/0/0 encapsulation flexible-ethernet-services
set interface xe-0/0/0 flexible-vlan-tagging

* Physical interface MTU for Juniper includes Ethernet overhead
(standard MTU is 1514, 1518 with VLAN tag). So basically coming from
Cisco its Cisco-MTU+14. You can configure a separate MTU per
protocol family (set interface ... family inet mtu 1500). Handy for
OSPF and co.

* You need to enable every protocol family on an interface that you
wish to accept. So for example if you want to do IPv4(OSPF) + IPv6(ISIS) + MPLS
(with LDP) you need on the interface:

set interface .. family inet ...
set interface .. family inet6 ...
set interface .. family iso
set interface .. family mpls

After that you need to enable the interface separately under the
relevant protocols (set protocol mpls interface ..., set protocols
ldp interface ...)

Yes this is a bit much but I always try to remember that the first
part enables the receiving of the protocol packets on the interface
and the second part enables the processing of the received packets.

* I love that Juniper shows you all routes for a destination, so if a
destination is reachable via BGP, OSPF and direct route a 'show
route <prefix>' will show that information for all protocols. The
active route is marked with a star. Routes that are hidden (for
example BGP routes that are rejected by import filters) can be shown
by 'show route hidden'.

* You can set standard BGP parameters for the whole box under
'routing-options':

set routing-options router-id 1.2.3.4
set routing-options route-distinguisher-id 1.2.3.4
set routing-options autonomous-system 65500

* You need to enable ECMP by binding a filter to the forwarding-table:
set policy-options policy-statement ecmp term 10-ecmp then load-balance per-packet
set routing-options forwarding-table export ecmp

(Yes, per-packet means per-flow ECMP, don't ask)

* Sometimes if you change config and don't see a change in behaviour a
'commit full' will fix the problem (this shouldn't be necessary
normally).

* Some global BGP settings I would use:
set protocols bgp precision-timers (Helps with very low BGP timers to avoid timeouts)
set protocols bgp log-updown
set protocols bgp always-compare-med (Depends on your routing policy)

* Want to look under the hood? Go to the linecard:
> start shell pfe network fpcX (fpc0 only for MX204)
Danger Zone: There are many commands on the linecard that can mess
stuff up. I even managed to crash stuff with some 'show ..' commands
there.

* Change things and want to apply it later? Save and load the patch
later:
<change stuff in config>
# show | diff | tee patch.txt
# rollback
# exit
<time goes by>
# configure
# load patch patch.txt
# commit


Sebastian


--
GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant