Re: [j-nsp] MX304 - Edge Router
Base licensing is useful if you self-spare, such that the capital invested in cold spares sitting in a warehouse is significantly less than the full cost of the device with licensing. On Wed, Oct 25, 2023 at 9:53 AM Michael Hare via juniper-nsp < juniper-nsp@puck.nether.net> wrote: > Richard- > > Sorry if this is off topic, but what's the use case for Base license on an > MX? Is it just to align the name of the licensing with EX and the ilk? > Are there significant customers using hardware as whitebox? We've been > Juniper customer since the m40 days and always routed with them. Thoughts > and feelings aside about price and licensing management aside, I always > found it curious that someone would purchase an MX and not need even static > routing. Our ASNs ended up in the "Advanced" bucket, which was essentially > equivalent for us to the old "base". > > -Michael > > > -Original Message- > > From: juniper-nsp On Behalf Of > > Richard McGovern via juniper-nsp > > Sent: Wednesday, October 25, 2023 7:51 AM > > To: Saku Ytti ; Aaron Gould > > Cc: Karl Gerhard ; juniper-nsp@puck.nether.net > > Subject: Re: [j-nsp] MX304 - Edge Router > > > > Aaron, what version of Junos are you using on your MX304? This should NOT > > happen and if it did/is, then I suggest you open a Case with JTAC. > Minimally > > your account team should be able to get you a temp license to work-around > > this until resolved. > > > > The introduction of newer (well now like 2 years old) Flex licensing all > newly > > purchased MX (which would include ALL MX304s) support only L2 in the base > > (free) license. For any L3 (even static) you require some additional > level of > > license. For MX those levels are Base/Advanced/Premium - > > https://www.juniper.net/documentation/us/en/software/license/flex/flex- > > license-for-mx-series-routers-and-mpc-service-cards.pdf. Your local > Partner or > > Juniper Sales team should be able to help with any questions in this > area. > > > > Flex License can be purchased on a Subscription (yearly) basis or > Perpetual > > (matches older style) – this is similar/same for almost all vendors in > current > > times. > > > > Most (but not ALL!) Juniper license are currently “honor” based. This > means > > features that require a license will NOT be turned off if the license is > not > > present. Instead warning/error messages will be shown, which will > [obviously] > > fill up your logs quickly MACSec maybe one of those licenses which are > > NOT “honor” based; there are others as well. Of course, Perpetual > licenses > > never expire Subscription licenses have a built-in ‘safety zone’ of > > approximately 30 days after the subscription date expires. This is to > provide > > time for renewal of the subscription for those that “forget” > > > > If you have an older subscription license which is no longer valid under > newer > > Flex license structure, at renewal the license will automatically be > converted by > > Juniper internal renewals team to the new Flex license SKU, at same > price as > > the older SKU, if there is a price [increase] difference. > > > > One big advantage of the new Flex license structure is that these > licenses are > > transferable. That is, these licenses are not permanently tied to a > single device > > SN. This also includes Perpetual Flex Licenses. In the Juniper Agile > License Portal > > (https://license.juniper.net/licensemanage/) where one turns a License > SKU > > [Entitlement] into a Activation [code] which then is used to create the > actual > > loadable license. Here one MUST associate the License with a SN, but that > > License can then be re-called (changed from Activation back to > Entitlement) > > and then that Entitlement can be associated with a new SN. The license > on the > > old SN is no longer valid. > > > > As for current checks, Juniper is covered by EULA – End User License > > Agreement. In the future Juniper can (and is likely to) add additional > > enforcement checks into their SW – Just an FYI. > > > > FYI only, Rich > > > > > > Richard McGovern > > Sr Sales Engineer, Juniper Networks > > 978-618-3342 > > > > I’d rather be lucky than good, as I know I am not good > > I don’t make the news, I just report it > > > > > > > > > > Juniper Business Use Only > > > > On 10/25/23, 2:01 AM, "Saku Ytti" wrote: > > On Tue, 24 Oct 2023 at 22:21, Aaron Gould via juniper-nsp > > mailto:juniper-nsp@puck.nether.net>> > > wrote: > > > > > My MX304 trial license expired last night, after rebooting the MX304, > > > various protocols no longer work. This seems more than just > > > honor-based... ospf, ldp, etc, no longer function. This is new to me; > > > that Juniper is making protocols and technologies tied to license. I > > > need to understand more about this, as I'm considering buying MX304's. > > > > Juniper had assured me multiple times that they strategically have > > decided to NEVER do this. That it's an actual decision they've > > considered
Re: [j-nsp] Juniper EX4500 VLAN Translation?
Thanks to those of you that responded privately. We were also able to find it in Feature Explorer. It is supported, for the record. On Fri, 31 Mar 2017, Brandon Ross wrote: We have a customer wanting to do VLAN translation on an EX4500. I believe it's supported, but I am unable to find any documentation anywhere that says for sure one way or the other (there is documentation that the EX3200 and EX4200 support it, see URL below). Does anyone have any experience doing this on an EX4500 or have a pointer to documentation that says it's supported? https://kb.juniper.net/InfoCenter/index?page=content=KB16755=true -- Brandon Ross Yahoo & AIM: BrandonNRoss Voice: +1-404-635-6667ICQ: 2269442 Signal Secure SMS: +1-404-644-9628 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Juniper EX4500 VLAN Translation?
We have a customer wanting to do VLAN translation on an EX4500. I believe it's supported, but I am unable to find any documentation anywhere that says for sure one way or the other (there is documentation that the EX3200 and EX4200 support it, see URL below). Does anyone have any experience doing this on an EX4500 or have a pointer to documentation that says it's supported? https://kb.juniper.net/InfoCenter/index?page=content=KB16755=true -- Brandon Ross Yahoo & AIM: BrandonNRoss Voice: +1-404-635-6667ICQ: 2269442 Signal Secure SMS: +1-404-644-9628 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MPC-3D-16XGE-SFPP/SCBE2 incompatibility?
On Tue, 10 Jan 2017, Daniel Verlouw wrote: all MPC cards should work, but make sure you're running in enhanced services mode. set chassis network-services enhanced-ip or -ethernet (reboot after commit) That sure did the trick, thanks! -- Brandon Ross Yahoo & AIM: BrandonNRoss Voice: +1-404-635-6667ICQ: 2269442 Signal Secure SMS: +1-404-644-9628 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Juniper MPC-3D-16XGE-SFPP/SCBE2 incompatibility?
I have a colleague trying to use a MPC-3D-16XGE-SFPP with SCBE2s and getting an "FPC misconfiguration" message in 'show chassis fpc' on an MX. It works fine with SCBE, just not SCBE2, they tell me. Does anyone have any experience with this? I searched all over the place but can find no documentation that says which SCBs are compatible with this MPC, does anyone know of any docs to that effect? -- Brandon Ross Yahoo & AIM: BrandonNRoss Voice: +1-404-635-6667ICQ: 2269442 Signal Secure SMS: +1-404-644-9628 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] exception traffic types for Juniper routers
On Tue, 29 Sep 2015, Martin T wrote: as I understand, there are several different exception traffic types: 1) unicast traffic addressed to router itselt. For example telnet, SSH or SNMP traffic. I guess it is technically correct to say that "incoming frames which have one of the router interfaces MAC addresses as a destination MAC address are exception traffic"? I certainly hope not, that would mean that every packet routed by the router would be punted to the processor. It would have to have an IP address that matches one of the addresses assigned the the router, not the MAC. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] proposed changes to clear bgp neighbor
On Wed, 26 Feb 2014, ryanL wrote: yeah, i'm not slagging. just seems like poor training for newbie noc engineers or something. this is a pretty rookie error, in my view, but i've been around almost as long as you have ;-) I've been doing BGP work for nearly 20 years, and Juniper for more than 15, including for many major and minor service providers, Interop and NANOG itself, and somehow I still make mistakes, hit the wrong key, log into the wrong window, etc. I fully support this change. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] proposed changes to clear bgp neighbor
On Thu, 27 Feb 2014, heasley wrote: Thu, Feb 27, 2014 at 10:30:29AM +0900, Paul S.: +1 to the 'all' requirement -- and then further include another question as suggested like 'Reset all BGP sessions? [Y/N]' Please - if you're dumb enough to enter a command that you do not understand on a production device, you deserve what you get. Stupid should be painful. Clearly someone should take away my router configuration license since I accidentally hit the wrong key on occasion. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Link local address errors when committing VRRP for inet6
On Fri, 21 Jun 2013, Morgan McLean wrote: Is anybody able to explain the purpose of the link local address? I know several dozen people who can explain the purpose of link-local. http://lmgtfy.com/?q=ipv6+link+local -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX2200 OSPF question
On Wed, 22 May 2013, Paul Stewart wrote: You have to buy the extended feature license on the EX2200 to run OSPF. We have a bunch of EX2200-C deployed that have OSPF routes on them and they work fine - to qualify that though, there is very little traffic through them at layer3 - cant' see them handling much layer3 traffic. That deployment is mainly layer2 oriented. Can you explain your concerns about layer 3 performance? I was under the impression that the EX2200 was a hardware forwarding platform. Am I incorrect? -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
On Thu, 25 Apr 2013, Saku Ytti wrote: On (2013-04-24 20:54 -0400), Jeff Wheeler wrote: My view is that fxp0 is an out-of-band interface for manual intervention; not one that I ever use for SNMP. My view is that fxp0 is completely useless interface. It's not OOB, it's completely fate-sharing the freebsd/junos. OOB in this context refers to having a different path through the network than the path used for production IP traffic. I see the value in having an Ethernet/IP interface that is not fate-sharing with the core OS as well, but that doesn't make fxp0 completely useless as previously stated. In RS232 you can at least do 'panic-on-break', not having to rely freebsd/junos to work to kick the box. But RS232 sucks otherwise: I'm not sure why we are suddenly debating the benefits and drawbacks of RS232. The two interface types are there for very different reasons. Of course correct solution would be, to connect fxp0 to separate HW, running its own miniOS, from which you could copy imagees, reload RE etc. That essentially what we are talking about. Connect fxp0 to a SEPARATE switch that is used for only out of band traffic. You then use this network to copy images, etc. What am I missing here? And no, you would not use this FXP0 for SNMP or Netflow or whatnot. Sure you can, I've done it, others here have said they've done it. Assuming the OOB network is well protected from outside traffic to avoid attacks and the like, why not? -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
On Thu, 25 Apr 2013, Pavel Lunin wrote: No, I propose to not even bother with copper, if you prefer. Just use a VLAN or any other type of virtual circuit inside those TerabitEthernet / SONET / FrameRelay / whatever. So you propose to do away with the out of band network entirely, and instead do all of your management inband. While that is a certainly a fine choice for some networks, others do not want to fate share their management capabilities with their production traffic. Is that unreasonable? And do you propose to use dedicated fibers just for management? I don't just propose it, I do it. Depends on the network of course, but if you'd like an example, the network we put together for Interop every year has what we call Access Ether. It is a true out of band management network. It's flat layer 2 (to keep it simple since it doesn't have to scale greater than a 100 devices or so), runs on completely independent switches from production traffic and runs on separate backhaul fiber (or copper in some cases). There are operators that run their networks in a similar way. Or, otherwise, how would you pass traffic to/from the copper switch, into which you plug the fxp0 of a remote router? I bet in 99% of cases, connectivity from NOC to the OOB switch shares fate with the connectivity to the router, whose fxp0 is plugged into this switch. At some level there's fate sharing, sure. If Darth Vader uses the Death Star against Earth, then I'll lose both my inband and out of band management capabilities. If, however, I have a failure of the data plane somewhere in my production network, at least I can still reach the processor and send it new code or whatever I need to do. Not even mentioning that this OOB switch is an additional point of failure with little chances to be backed up. That's only the case if you completely disable inband management capabilities. Some networks choose to do this, some do not. For those that do not (again see the Interop network) it is not an additional failure point at all, but actually redundancy. So there is nothing in the fxp0's OOBness, what is worth its clumsiness. Please don't get me wrong. I think the way fxp0 is implemented sucks big time. The fact that I have to use the default logical-system to make it useful and move all of my production traffic to others is super annoying. The lack of other features on that port makes it downright dangerous if you don't pay attention, but it is NOT useless. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
On Thu, 25 Apr 2013, Saku Ytti wrote: On (2013-04-25 10:55 -0400), Brandon Ross wrote: I'm not sure why we are suddenly debating the benefits and drawbacks of RS232. The two interface types are there for very different reasons. Done right, you'd need one MGMT interface, and ethernet is obvious solution. I guess we'll just have to agree to disagree then. One management interface causes a truck roll when that one management interface fails. They all fail in one way or another. Clearly this is acceptable risk to you and the networks that you build. As a well known network expert likes to say, I encourage my competition to build their networks this way. That essentially what we are talking about. Connect fxp0 to a SEPARATE switch that is used for only out of band traffic. You then use this network to copy images, etc. What am I missing here? What are you winning by not doing this on-band in HW interface? Once again, when I have a device without an interface card that can economically connect to an out of band switch (i.e. a core router with all 10GbE interfaces, a router with SONET line cards, etc.) Sure you can, I've done it, others here have said they've done it. Assuming the OOB network is well protected from outside traffic to avoid attacks and the like, why not? Additional ports, wiring. Your words were, And no, you would not use this FXP0 for SNMP or Netflow or whatnot. I am disagreeing with that statement, I WOULD, in the appropriate cases, use fxp0 for SNMP, and have. I did not say it did not come at extra cost or complexity. Like everything in networking, or business in general, doing something comes at the cost of something else. A good engineer is able to balance the costs and the benefits. For many networks, once again, I agree the that cost and complexity of the fxp0 port is beyond it's value. I've built several of those networks myself and have even been on your side of the argument. But to make sweeping generalizations that the port shouldn't ever be used or is useless, is not accurate. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
On Thu, 25 Apr 2013, Saku Ytti wrote: On (2013-04-25 08:29 -0700), joel jaeggli wrote: It's not OOB, it's completely fate-sharing the freebsd/junos. it's not part of the forwarding plane so it certainly is not in-band, what you connect it to of course is your business. we connect them to our oob network. Yes it's not fate-sharing forwarding-plane, but it's fate-sharing the whole control-plane. You need ports, wiring to build fxp0 management network, which isn't even redundant, single port down and it's not reachable. Which is MUCH better that not reachable, ever, at all. Lot of cost+complexity for only benefit of being able to configure router when forwarding is broken but router not. Which never happens, right? I guess I'm just the lucky one that gets routers that freak out due to a bug (not necessarily just Juniper, but in general) or attack or whatever and become unreachable except for out of band access. I'm also probably the only one that has worked on networks that had cascading routing protocol failure and needed some emergency reconfiguration (which could only be done from out of band). I'm sure Joel is the only one that's had this happen too. Right Joel? inline flow export is generated in linecard asics so it's not really suitable for the oob port. I think this is really my point, you need * fxp0 for ssh, snmp * inband for netflow, snmp (if HW) (redundant) * rs232 to attempt recovering box from control-plane software failure Why build fxp0, if you need inband for something anyhow? It costs money, adds complexity, and delivers no value if RS232 is also implemented with in-band. I think we've covered this multiple times now and you even covered it above a bit. ssh, snmp, software loads, etc. require the fxp0 port if/when you have no in-band access for wahtever reason, of which there could be many. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
On Thu, 25 Apr 2013, Pavel Lunin wrote: Well, I agree, if you are brave enough to run a real OOB management network, you have reasons to use fxp0 on the devices, that don't have 1G ports, though I believe it's at least not cheaper than buying 1GE ports just for management :) I suppose that's a local calculation of all of the costs and complexity involved. But in my experience real OOB mgt is a too rare case in real life of the ISP world. We have very different experiences then. I'm not claiming it's a majority, but I will claim that many of the largest networks in the world do, indeed, have true OOB management networks. Enough that the business case for what is probably a fairly minimal cost for Juniper to keep the hardware in the box for fxp0 makes sense. BTW, yes, there is much more sense in real OOB management in the access, but you first gave an example of an all 10/100GE core, which is a slightly different thing. And even in the access nothing really pushes you to use fxp0 for OOB mgt. I see no difference in the purpose or usage of the port weather the box is access or core. If there's no economical ports in the box already, fxp0 makes sense. In many networks, consistency is more important than the cost of each deployment, so in those cases it may be cheaper overall for ALL Juniper devices to be managed via fxp0. If you know what and why you are doing, there is no problem. But most people, who I talk with about using fxp0, want to use it just because, with no good reason except it is specially developed by vendors, so I think, it's better to manage devices through it and they just don't really understand implications of bypassing data plane. Yup, there are many idiots out there that will do anything vendors say. There's even more that think they know what they are doing because they were able to pass the vendors trivia quiz. You can't fix stupid and taking away the tools that not-stupid need to do their job only results in boxes that not-stupid don't want to buy. So far, I'd say, Juniper caters to not-stupid. Stupid is just going to buy Cisco anyway because their fancy VP showed up and took the VPs out golfing. BTW, I don't say it's useless. When you need to remotely upload software to a non-operationg box, this is an only option. But I'm sure it's better to not use it for every day routine management like SNMP, if only you have an option. You did not. I've been partially responding to Saku who said, My view is that fxp0 is completely useless interface. My apologies if my comments implied that you made such a statement. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
On Thu, 25 Apr 2013, Pavel Lunin wrote: 2013/4/25 Brandon Ross br...@pobox.com But in my experience real OOB mgt is a too rare case in real life of the ISP world. We have very different experiences then. I'm not claiming it's a majority, but I will claim that many of the largest networks in the world do, indeed, have true OOB management networks. Just let me clarify that with real OOB mgt network I mean dedicated media, switches and all or, more formally, independence of control traffic from forwarding plane of what it controls. We are using the same definition informally I think. Formally, I don't know of any networks where the actual network control traffic (routing protocols) are on a completely independent, out of band network, nor would I recommend such a design for any use cases I can think of. If you change control traffic to management traffic in your statement, then I think we'd be in complete agreement. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
On Thu, 25 Apr 2013, Saku Ytti wrote: On (2013-04-25 13:03 -0400), Brandon Ross wrote: We have very different experiences then. I'm not claiming it's a majority, but I will claim that many of the largest networks in the world do, indeed, have true OOB management networks. Enough that I'm not saying don't build OOB, I'm saying, I don't want to build three networks to access the router. On-band is given. So will the second network be rs232 or fxp? Both. Both of them are bad options, but RS232 is less bad, as you can reboot the box even if JunOS is wonky. Everything is a bad option. You work with what you can get economically. Your statement was, My view is that fxp0 is completely useless interface. I disagree with you. It is a useful interface for the reasons that I, and others, have stated. Is it perfect? Hell no. But that doesn't change that fact that it's useful. Either defend that statement or admit that it was overly broad. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
On Wed, 24 Apr 2013, Pavel Lunin wrote: This is what I never understood. Why people want to use fxp0 (or any other dedicated management) iface for real production management? Many operators have backbone routers with 10's of 10GbE ports and maybe even a few 40 or 100GbE ports at this point, perhaps a variety of SONET still, etc. Are you suggesting that they should purchase a 10/100/1000 copper card just for management? Or are you suggesting that they should buy 10GbE switches for their out of band management network? -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
On Fri, 19 Apr 2013, Chip Marshall wrote: So, I have an MX5 with it's fxp0 management interface connect to one network, which I've placed in a logical-system so it can have it's own default route for out-of-band management. [snip] The problem is the replies to SNMP queries are being routed out using the main system's routing table, not the routing table of the logical-system. I have confirmed this with packet captures. Use the default logical-system for management and put your production stuff in a new logical-system. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
On Mon, 11 Feb 2013, Jeff Wheeler wrote: I am sorry I missed Richard Steenbergen's lightning talk at NANOG, which was something like if you want your routers to install routes, call Juniper and reference PR#whatever because they do not want to fix this bug. It looks like I've beaten him to reply. It's PR836197. http://www.nanog.org/meetings/nanog57/presentations/Tuesday/tue.lightning2.steenbergen.juniper-slowfib.pdf -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RR cluster
On Thu, 7 Feb 2013, Huan Pham wrote: Lets go back to Ali question, and what he wants: I want them to send updates to each other and to the RR-Clients. He will need to have unique RR IDs. Pls tell me if this is not the case. Thanks. If you take that statement very literally, then you are correct. However, if what he really wants is for all of his routers to have a coherent view of the routing table, then it will work either way. I interpret that this is really the question on the table, and if it's not, it's the question he should be asking. I would strongly advise against the previous suggestion of not running iBGP between the routers. While the topology in particular may function without it, the next person to come along and work on the network may not expect it to be configured inconsistent with standards and best practices and may, thorough a seemingly unrelated change in topology, break things horribly. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Q-in-Q
On Mon, 21 Jan 2013, lppmas...@yandex.ru wrote: Does MX ambiguous vlan? Do you ambiguous questions ask? -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX480 - 10.4R4.5 BGP
On Wed, 16 Jan 2013, Keith wrote: Peer #1 - all 4 networks are prepended with our AS 5 times: Okay so far... This way I have two networks coming in on one gig link and the other two networks are coming in over the other gig link. No, you don't. You have all 4 networks coming in on all 4 links. There should be no traffic incoming in on Peer #1 from the internet. But there is. Not quite. You have advertised a route to another AS. Each AS will use it's own criteria to decide how to route traffic. For example, most service providers will prefer to send traffic to their customers' direct connections instead of sending that traffic to an intermediate AS. That preference is usually implemented using localpref which is a decision made by routers before AS path length, just like you are doing to choose how to send traffic out of your network. The only way to ensure that NO traffic comes in on that link is to advertise NO routes at all. You can, however, influence traffic in a stronger way by advertising more specific routes (since more specific routes are always preferred) on links that you want to carry traffic. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] GRE on MX - weird performance issue
On Tue, 18 Dec 2012, Luca Salvatore wrote: I have a MX5 and a MX10 router connected over the Internet via a GRE tunnel. When I do a file transfer between the two sites that these routers connect it looks like there is some form of rate-limiting going on. My transfer speed flat lines at about 300KB. However I know it is not a bandwidth issue because I can have multiple file transfers going on at once and they all sit at about 300KB. So this shows me that I have enough bandwidth to push lots of traffic at once, but each single stream of traffic never gets much faster than 300KB. This sounds like the classic example of a Bandwidth-Delay product problem. I suggest careful study of this page: http://www.psc.edu/index.php/networking/641-tcp-tune I've tried different MTU settings on the GRE interface without much change, was thinking of adjusting the MSS but can't seem to figure that out on the MX. MSS is a function of the end stations, not of a normal router, but you are on the right track. Adjusting the MSS of the end stations on each side will help improve performance, most likely. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF on a VRRP Interface
On Thu, 6 Dec 2012, Ali Sumsam wrote: Off the top of my head, we cant have OSPF neighbor via VRRP interface, the reason would be the router-id. What router-id should it pick. It is best practice to have a loopback interface and use it for OSPF router ID, so you could easily have a unique address to use. Also, OSPF router ID does not need to be a an address in use on the router at all, so you could even configure any old random address, as long as it's unique in the network, although that wouldn't be advisable. And besides all of that, interfaces configured with VRRP always also have unique addresses in that subnet, so the router still has a unique address, even if you don't follow best practices and haven't manually configured a router ID. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 100Base-LX10 and MX80
On Thu, 1 Mar 2012, �~Aukasz Dudzi�~Dski wrote: W dniu 29.02.2012 14:39, Brandon Ross pisze: On Wed, 29 Feb 2012, �~Aukasz Dudzi�~Dski wrote: Since it is impossible to use a Juniper optic that doesn't exist, if your requirement is for LX10, your only choice is to purchase 3rd party. That is exactly, what I did. My supplier provided me a SFP with nice blue sticker Juniper Compatible. Unfortunately, I couldn't force the interface to be up, even with external fiber loop on the same module (TX2RX). The manufacturer of that module was GBC Photonics (SF-SM31020D-01G-GP). Have you worked with the company that sold it to you to resolve the issue? What did they say? Most sellers will give you a lifetime warranty. I have used 3rd party LX10 optics (along with just about any other kind of optic you can imagine) on MX series with no problem. Heck I even RECOMMEND to my clients to save money by using 3rd party optics (but I might have a bias since my wife sells them). Can you tell what exactly type of MX-series line card and what was exactly manufacturer and P/N of SFP you used with 100Base-LX10 ? In my case it was: MIC 3D 20x 1GE(LAN) and SFP as mentioned above. It's been some time but I'm pretty sure it was and MPC2 with the same MIC you are referring to above. The optic I was using was probably manufactured by Finisar, but I no longer have access to that system so I can't tell you for certain. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 100Base-LX10 and MX80
On Wed, 29 Feb 2012, ?ukasz Dudzi?ski wrote: Do you have some experience with that type of SFP on MX80 platform ? If it is supported on MX80 (by 'supported' I mean - it's working, not that I can get support from JTAC in that type of SFP issues), what kind of SFP you have ? Original, Juniper signed (designed for other router/switch series) or third party ? Check the list archives, we JUST discussed the use of 3rd party optics a week or so ago. The bottom line is that some people (me for example) see no problem at all with using 3rd party optics, and have used them in multiple installations without any more problems than Juniper own optics cause. Other folks believe that you shouldn't use 3rd party optics because Juniper won't support them, and because availability, quality and sourcing are questionable. I suggest you read the archives and come to your own conclusion. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 100Base-LX10 and MX80
On Wed, 29 Feb 2012, �~Aukasz Dudzi�~Dski wrote: I did it already. The topic you have mentioned does not cover the essence of my question. I've asked for that specific SFP (100Base-LX10), not for using third party optics at all. The problem is that I don't know if it is possible to use 100Base-LX10 optics in MX80, because Juniper documentation does not mention about 100Base-LX10 SFP. There is a note regarding 100Base-FX (FE on MMF), but no 100Base-LX10 (FE on SMF). Apologies, I will be more specific. Juniper does not support or sell an LX10 optic. Since it is impossible to use a Juniper optic that doesn't exist, if your requirement is for LX10, your only choice is to purchase 3rd party. I have used 3rd party LX10 optics (along with just about any other kind of optic you can imagine) on MX series with no problem. Heck I even RECOMMEND to my clients to save money by using 3rd party optics (but I might have a bias since my wife sells them). Other people will tell you not to use 3rd party optics for the before mentioned reasons. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Sources for SFP+ optics
On Thu, 23 Feb 2012, Saku Ytti wrote: Buying 3rd party can be done in many ways. One way is to use broken who uses many sources to find what you need. They can offer very good price and can rapidly deliver say any DWDM colour for any form-factor. But they have no idea what they are delivering, it's almost drop-shipping, will the DDM work? How well the I2C channel works all together? Newer routers poll I2C aggressively and some SFPs answer too slowly. Another way is to use shop which does nothing but optics and as such are subject matter experts. Uses single source for single part-number. Who has access to various vendors routers and switches and knows before shipping that it'll work on your gear. These are marginally more expensive than the brokers when buying one unit at a time, and they might have 7-8 week lead time (factory lead time) for stuff no on shelf (like certain DWDM colour) I strongly disagree with your characterization. I work with a couple of different companies (yes, one of which is owned by my wife) to sell 3rd party optics among other things. I've been active in the service provider community for many years, I still design networks and configure routers on a regular basis. While there certainly are many others that know a lot more than me, I think I am pretty competent to understand and deal with optics related issues. Both companies I work with can deliver optics very quickly, often next day and NEVER as long as 7-8 weeks and have VERY competitive prices (and I don't mean competitive with the router manufacturer's prices, I mean with other 3rd party optics). Perhaps you've dealt with the wrong people. Just like any other industry, there are some that are good and some that are bad. Similarly, no one expects Juniper to support the Cisco switch connected to their router, why anyone would expect Juniper to support a Finisar optic plugged into their router, I don't understand. A good optic supplier will give you a lifetime, advanced replacement warranty and will be able to fully support the optics they sell. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Sources for SFP+ optics
On Thu, 23 Feb 2012, Saku Ytti wrote: Both companies I work with can deliver optics very quickly, often next day and NEVER as long as 7-8 weeks and have VERY competitive prices (and I don't mean competitive with the router manufacturer's prices, I mean with other 3rd party optics). This is not economical position to be in for DWDM. There are 80 channels and at least 6 form factors and you need 40km and 80km reaches, so just to have units for single leg + spare you need 2880 parts, at 1kUSD each. I have no idea how they do it, but I can tell you for certain that I've been able to source DWDM optics for my clients within a week every single time. And yes, I'm referring to specific colors. You can get any waves for any form factor from brokers rapidly, but they use multiple sources to hunt for them. So when possible, I plan ahead and order from single source, but use brokers as last resort. There's no doubt that if you are running a DWDM network you ABSOLUTELY should be sparing your own stuff. Often this means a few tunables so you don't have to stock every frequency you are using, but that's a completely different subject. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX3500 optics lock?
On Sat, 7 Jan 2012, Phil Mayers wrote: The device must support generic / unbranded transceivers. Any device which prevents use of, or restricts features based on transceiver vendor will be immediately disqualified. I'm very glad to see people doing this in their procurement. I'm also happy to see that a majority of the RFPs that I see, mostly BTOP ones, also include some sort of requirement for support of 3rd party optics. Preventing 3rd party optics from working in the QFX immediately disqualifies it from a majority of the new network builds I see and I would never recommend a product to my customers that won't work with 3rd party optics. -- Brandon Ross AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] VPLS and IP on a PE-4FE-TX (M10i)
I have an colleague with a config like this on his GbE interfaces:
ge-0/0/3 {
flexible-vlan-tagging;
mtu 1650;
encapsulation flexible-ethernet-services;
unit 0 {
vlan-id 1;
family inet {
address 10.50.14.1/24;
}
}
unit 16 {
encapsulation vlan-vpls;
vlan-id 16;
}
Basically some VLANS are VPLS and one is IP (mostly for management).
Is there any way to do something similar on a PE-4FE-TX? My understanding
is that the answer is no since the PE-4FE-TX does not support
flexible-vlan-tagging, is that correct?
--
Brandon Ross AIM: BrandonNRoss
ICQ: 2269442
Skype: brandonross Yahoo: BrandonNRoss
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 1GE CWDM/DWDM Optics???
On Thu, 8 Sep 2011, Juno Guy wrote: Anyone know of any 1GE (not 10GE) CWDM/DWDM optics that work with MX series? Your implication that there aren't any Juniper branded ones is correct. You can get them from many 3rd party sources, I'd recommend Subspace Communications, but that's probably because my wife runs it. ;-) You can get options and pricing from her at gi...@subspacecom.com. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Pass DSCP unchanged under ScreenOS 6.2 / Netscreen 5400
On Tue, 23 Nov 2010, Phil Mayers wrote: I would however like the devices to pass DSCP unchanged, so that traffic which flows through out firewall can be QoS'ed later on in the network, and avoiding me having to re-apply the classification already done at the edge. Do you have a reason to believe that this is not the default behavior? -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Policy based routing on SRX 210
{
static {
route 0.0.0.0/0 {
next-hop 10.10.10.2;
qualified-next-hop 192.168.254.1;
metric 100;
}
}
}
}
pbr_fe-0/0/6_adsl {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/24 {
qualified-next-hop 192.168.1.1;
qualified-next-hop 10.10.10.1 {
metric 100;
Regards,
Bikash Bhattarai
Technical Manager
Dristi Tech Pvt. Ltd.
skype: bkbhattarai
mob:+977-9851039710
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Brandon Ross AIM: BrandonNRoss
ICQ: 2269442
Skype: brandonross Yahoo: BrandonNRoss
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
