Re: [j-nsp] MX304 Port Layout
Hi, > On 26 Jun 2023, at 20:56, Jackson, William via juniper-nsp > wrote: > >> The MX204 is an MPC7E, so whatever H-QoS is on the MPC7E is what the >> MX204 will also do. > >> We have used them as an edge router on a temporary basis at new sites, >> with an Arista switch hanging off of them via an 802.1Q trunk, until we >> can get our standard MX480 to site. They are capable for such a >> use-case. But usually, we use them for peering and value-added traffic. > > Similar use case here but we use a QFX as a fusion satellite if port > expansion is required. > Works well as an small site start up option. I have done the same. One thing to remember is that even though you can run dual-RE on the MX304, the QFX won’t be able to do an upgrade without rebooting. Don’t plan to do ISSU in such a setup. Cheers, Sander ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VMX integrated FPC
Hi, I remember when I originally got my mittens on VMX there was a boot > flag to tell it to use an integrated FPC or integrated RIOT without a > separate VM running forwarding. I can't find my notes on that. > > Does anyone know if that's still possible? I just want a pretend/low > performance/fake FPC ideally. I think you're referring to the Nested VM Model: https://www.juniper.net/documentation/en_US/vmx/topics/topic-map/vmx-nested-installing-on-kvm.html Cheers! Sander signature.asc Description: This is a digitally signed message part ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Managing MX480 fxp0
Hi, > I would personally not wire or use fxp0 unless I'm out of options. > Some other vendors today have real out-of-band ethernet for MGMT, > meaning own CPU, own memory, own OS not fate-sharing the > control-plane, which is the correct solution for OOB, but not > something we as a community are actively asking vendors to deliver. We built an OOB network exactly like that. Cheap L3 switches talking OSPF to each other over their own 1G DWDM channels, completely independent of the production network. A separate OOB network used to be crazy expensive, but with cheap DWDM gear suddenly all you need is a free DWDM channel and some cheap second hand L3 switches. And that's what we connect our fxp0 ports to. Cheers, Sander signature.asc Description: Message signed with OpenPGP ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX10003 rack size
Hi, Has anyone ever managed to fit a Juniper MX10003 in a 90cm deep rack? Without applying power tools to either the rack or the router ;) Cheers, Sander signature.asc Description: Message signed with OpenPGP ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPv6 firewall policy for MX
Hi, > Is there a good online resource for IPv6 firewall policy/hardening for MX > series routers? I would start with the IPv6 filter example starting on page 336 of Juniper MX Series, 2nd Edition (ISBN: 978-1-4919-3272-8). There are eBook versions available, and o'Reilly Safari gives you online access. See https://www.juniper.net/us/en/training/jnbooks/oreilly-juniper-library/mx-series/. If you have the 1st edition it should be around page 260. Cheers, Sander signature.asc Description: Message signed with OpenPGP ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BFD for IPv6 in Hardware
Hi Mark, > Some good news from my friendly SE... the ER to add support per subject > has been filed. > > Timelines on when we shall see code are forthcoming. Good news! Sander signature.asc Description: Message signed with OpenPGP ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] fusion QFX5120 and MX204
Hi, > Am 12.04.2019 um 22:10 schrieb Aaron Gould: >> Trying to do fusion from MX204 (AD) to QFX5120-48Y-8C (SD). but getting this >> message.. "Satellite image not available" >> Is a QFX5120-48Y-8C capable of being a satellite device in fusion ? > > Not yet. > https://www.juniper.net/documentation/en_US/junos/topics/concept/fusion-components.html > > Fusion PE supports EX4300, QFX5100/5110 and QFX5200 > > Interesting side Note on QFX5200 being supported as Satellite and my favorite > Fun Fact on Fusion PE. MX80 is supported as AD and QFX5200 is supported as > SAT. > This allows us to build the most useless router in the world with 248x100GE > Interfaces (31x100GE on 8 QFX5200) + 24x10GE Interfaces (1x100GE broken into > 3x10GE + 1x10GE for AD Connectivity) with a oversubscription factor of at > least 2483:1 per SAT and MX80 control plane. The worst of all worlds! Haha! That would indeed be a useless combination :) I think I'll stick with my MX10003 instead :) Cheers, Sander signature.asc Description: Message signed with OpenPGP ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Old JunOS upgrade path
Hi, > On Fri, Mar 08, 2019 at 01:17:44PM -0700, Eldon Koyle wrote: >> Many (most?) network operating systems are an image file that the >> switch either writes over a partition (ie. block-level copy) or boots >> directly (ie. initrd/initramfs) with a separate partition for a config >> file. Junos is a full BSD operating system that installs packages to >> partitions on the device, runs upgrade scripts, etc. > > So? I didn't do an upgrade but I replaced an SRX last week. Went from an SRX210 with 12.1X to an SRX345 with 18.4R. Almost the whole configuration was copy The interface names were different, but that was about it. I see no reason why an upgrade wouldn't have worked: it's basically the same as copy an old config to a new OS release. Cheers, Sander signature.asc Description: Message signed with OpenPGP ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] DNS Flag Day
Hi Melchior, > Thanks for pointing this out. Please have a look at > https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1379433 and > let me know your ideas. Yep, that sounds exactly like what's happening! "Resolved In 15.1X49-D160 17.4R3 18.1R3 18.2R2 18.3R1 18.4R1" sounds hopeful :) Thanks! Sander ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] DNS Flag Day
Hi, When doing some investigation for the upcoming DNS Flag Day (https://dnsflagday.net: February 1st 2019) I got some bad news from one of the service providers: they use Juniper SRX firewalls, and claim that they can't properly support EDNS because of a bug in their SRX firewalls. This seems outrageous to me. Is this just because they haven't upgraded their JunOS for years, they're running ancient DNS server software, or is there really a problem? I didn't get any more information from them, just "it's because of Juniper". An example test can be seen here: https://ednscomp.isc.org/ednscomp/704c5b6649: > Checking: 'computel.nl' as at 2019-01-25T11:05:00Z > > computel.nl. @83.137.17.10 (ns2.computel.nl.): dns=ok edns=ok edns1=timeout > edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok > edns512tcp=ok optlist=timeout > computel.nl. @2001:4038:0:17::10 (ns2.computel.nl.): dns=ok edns=ok > edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=ok > docookie=ok edns512tcp=ok optlist=timeout > > computel.nl. @83.137.20.153 (ns3.computel-standby.eu.): dns=ok edns=ok > edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok > edns512tcp=ok optlist=ok,nsid (ns3.computel-standby.eu) > computel.nl. @2001:4038:0:21::153 (ns3.computel-standby.eu.): dns=ok edns=ok > edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok > edns512tcp=ok optlist=ok,nsid (ns3.computel-standby.eu) > > computel.nl. @83.137.20.10 (ns1.computel.nl.): dns=ok edns=ok edns1=timeout > edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=ok docookie=ok > edns512tcp=ok optlist=timeout > computel.nl. @2001:4038:0:20::10 (ns1.computel.nl.): dns=ok edns=ok > edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=ok > docookie=ok edns512tcp=ok optlist=timeout I am wondering what's going on here, and whether there is really a bug in JunOS on SRX or whether it's just "easiest to blame the firewall"... Cheers! Sander ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] RFC5837
Hi, > I somewhat recently discovered https://tools.ietf.org/html/rfc5837 > > Exec summary: your traceroute will show the ingress ifindex where > packet came in, allowing you to discriminate LAG/bundle/ae interfaces > and determine actual path in network with ease. > > It seems like massively useful feature for modern networks where LAG > is rule, not exception, much more useful than widely supported MPLS > labels. > > If you do agree, and have some leverage, please ping your account team > and make enhancement request. I like it! Sander signature.asc Description: Message signed with OpenPGP ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] router reflector clients and non-clients
Hi Adam, > Op 30 mei 2018, om 10:56 heeft adamv0...@netconsultings.com het volgende > geschreven: > >> Of Sander Steffann >> Sent: Wednesday, May 30, 2018 9:36 AM >> >> Hi, >> >>> But in this scenario, a client will send an update both to RR1 and >>> RR2, and RR1 will reflect this update to RR2, and RR2 will reflect it >>> to RR1, and voila! We have a routing loop. >> >> The moment it loops back to an RR that it has already been through it will > see >> its own cluster-id in the list and ignore it. So RR1 and RR2 learn from > each >> other, but the update won't loop. >> > The example suggested RR1 and RR2 with different Cluster-IDs -so it would > loop* It won't, because at that time both CLUSTER_IDs are in CLUSTER_LIST, which will stop it from looping between RR1 and RR2. > *it will loop only in absence of PE1 route sent directly to RR2 -in which > case RR2 will be comparing PE1's route received via RR1 and route received > directly from PE1, the direct route will be selected based on the shorter > cluster-list and as such will not be looped/advertised back to PE1 based on > the split horizon rule. Sorry, I don't follow that example. If PE1 talks to RR1 and RR2 then both will keep the directly received route because its CLUSTER_LIST length will be 0, compared to 1 when received from the other RR. If PE1 only talks to RR1 then RR2 will only receive the routes from RR1, which will be the best path. RR2 receives it with the CLUSTER_LIST containing RR1's ID, and will advertise it with both RR1's and its own ID. If that route comes back to RR1 it will ignore it because its CLUSTER_ID is already in CLUSTER_LIST. What am I missing? Cheers, Sander ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Ansible juniper_junos -add license module?
Hi, > The "xml-name" statement gives the name of the RPC used to access > this command, which means the RPC adds a > license from either a URL or a string, and the > exports license data to a URL. I tried that, and git an error message back saying eta the license-add command is only supported on cli and not over RPC :'( Cheers, Sander ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
