Re: [j-nsp] MX204 port 1G
On Fri, Oct 9, 2020 at 11:49 AM Dave Bell wrote: > > On Fri, 9 Oct 2020 at 16:28, David Miller wrote: >> >> If you are using RFC 1918 private addresses, then you will want to >> remove them from the Junos martian dropping. >> >> Like: >> set routing-options martians 192.168.0.0/16 exact allow >> >> Info: >> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/recognize-martian-addr-routing.html > > > This is not required. RFC1918 are not martians. You are correct. Got my wires crossed there for a second. Apologies for the noise. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX204 port 1G
If you are using RFC 1918 private addresses, then you will want to
remove them from the Junos martian dropping.
Like:
set routing-options martians 192.168.0.0/16 exact allow
Info:
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/recognize-martian-addr-routing.html
--
__
David Miller
dmil...@tiggee.com
On Fri, Oct 9, 2020 at 11:08 AM Eric Krichbaum wrote:
>
> One of many working 204s with 1G.
>
> Model: mx204
> Junos: 18.2R3-S1.7
>
> Chassis:
> PIC 1 BUILTIN BUILTIN 8XSFPP PIC
> Xcvr 0 @(+ NON-JNPR F179CO14506 SFP-LX10
> Xcvr 1NON-JNPR F179CO14505 SFP-LX10
> Xcvr 2 Et NON-JNPR G1908908498 SFP-LX10
>
> Chassis ports are set 10G:
> set chassis fpc 0 pic 0 tunnel-services bandwidth 200g
> set chassis fpc 0 pic 0 port 0 speed 100g
> set chassis fpc 0 pic 0 port 1 speed 40g
> set chassis fpc 0 pic 0 port 2 speed 40g
> set chassis fpc 0 pic 1 port 0 speed 10g
> set chassis fpc 0 pic 1 port 1 speed 10g
> set chassis fpc 0 pic 1 port 2 speed 10g
> set chassis fpc 0 pic 1 port 3 speed 10g
> set chassis fpc 0 pic 1 port 4 speed 10g
> set chassis fpc 0 pic 1 port 5 speed 10g
> set chassis fpc 0 pic 1 port 6 speed 10g
> set chassis fpc 0 pic 1 port 7 speed 10g
>
> Interface:
> set interfaces xe-0/1/0 gigether-options no-auto-negotiation
> set interfaces xe-0/1/0 gigether-options speed 1g
> set interfaces xe-0/1/0 unit 0 family inet rpf-check mode loose
> set interfaces xe-0/1/0 unit 0 family inet address x.x.x.x/30
> set interfaces xe-0/1/0 unit 0 family inet6 address x:x:x:x::x/127
> set interfaces xe-0/1/1 gigether-options no-auto-negotiation
> set interfaces xe-0/1/1 gigether-options speed 1g
> set interfaces xe-0/1/1 unit 0 family inet rpf-check mode loose
> set interfaces xe-0/1/1 unit 0 family inet address x.x.x.x/29
> set interfaces xe-0/1/1 unit 0 family inet6 address x:x:x:x::x:x/112
>
>
> Eric
>
>
>
> -Original Message-
> From: juniper-nsp On Behalf Of Lukasz
> Trabinski
> Sent: Friday, October 09, 2020 9:49 AM
> To: Juniper List
> Subject: Re: [j-nsp] MX204 port 1G
>
>
> When I removed "speed 10g" from chassis section
>
>
> admin@mx1> show configuration |compare rollback 1 [edit chassis fpc 0 pic 1]
> - port 4 {
> - speed 10g;
> - }
>
> and bounced FPC 0, interface not found.
>
> admin@mx1> show interfaces xe-0/1/4
> error: device xe-0/1/4 not found
>
> In documentation we can read that 10g is default. It’s seems not.
> When I removed "speed 1G” from gigether-options section, interface is found,
> but is DOWN.
>
> Any Idea? :)
>
>
>
>
>
> > Wiadomość napisana przez Richard McGovern w dniu
> > 09.10.2020, o godz. 16:05:
> >
> > Correct. Unlike EX/QFX where for 1/10 capable interfaces the name will
> > match the insert Optic. 1G Optic shows as ge, 10G Optic shows as xe. Both
> > ge/xe names allowed.
> >
> > For MX/SRX (and I assume PTX and maybe ACX - don't much deal with those
> > products ) xe is ONLY name allowed, and is used to indicate the interface
> > is 10G capable. For show interface info, the interface will show the
> > correct speed.
> >
> > NOTE: Please don't ask me the why. Tried to fight that battle, this will
> > NOT be changed.
> >
> > As for William original question why are you hard coding 1G in the config,
> > and setting 10G in the HW (chassis stanza)? From initial look, that is
> > first place to look. BTW, on MX204, neither should needed. FPC does not
> > need speed setting (default supports 1/10) and auto should work fine at
> > interface config. If you needed fixed speed for working with remote device,
> > then set speed at interface level only. If you are going to do both, make
> > them equal, although I am guess chassis fpc only has 10G as option.
> >
> > Did you have issue with auto for interface, which is default setting?
> >
> > HTH, 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
> >
> >
> > On 10/9/20, 8:02 AM, "Łukasz Trąbiński" wrote:
> >
> >Hi.
> >
> >It does not work. according to the documentation it must be xe-
> >
> >> Wiadomość napisana przez Jackson, William w
> >> dniu 09.10.2020, o godz. 13:42:
> >>
> >> Rename the interface ge-0/1/4
> >>
> >> admin@mx1>
Re: [j-nsp] MX routers and DAC cables?
Juniper's official Hardware Compatibility Guide lists 100G DACs as officially supported on MX10003, so "no DACs" being officially supported is not true. https://apps.juniper.net/hct/product/#prd=MX10003 We have used DAC cables (10G, 40G, & 40G -> 4x10G) with MX204s up to 18.4R3. I have also labbed up 40G DACs with EX4300s (for VC and uplink to MX) with no issues. -- ______ David Miller dmil...@tiggee.com On Fri, Jun 12, 2020 at 2:41 PM Chris Adams wrote: > > Is anybody using DAC cables on MX routers? We have a customer with an > MX10003 connected to EX4600 switches with 40G DAC cables (Juniper parts, > not third-party). Upon upgrading the router JUNOS to 18.2R3-S3, none of > the interfaces with a DAC cable would come up on the router end. > > JTAC's response was that no DAC cables are supported on any MX routers. > > That seems a little odd to me... I thought DAC cables are a part of the > various specs, so saying they're not supported is saying those aren't > actually Ethernet ports to me. > > -- > Chris Adams > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper Optics 10G SM XFP
On 7/7/2015 12:01 AM, Dale Shaw wrote: Hi David, On Tue, Jul 7, 2015 at 9:17 AM, David Miller dmil...@tiggee.com mailto:dmil...@tiggee.com wrote: Can anyone tell me the differences between these two optics? XFP-10G-L-OC192-SR1740-014279 XFP-10G-L-OC192-SR1-C 740-031833 740-014279 = EX-XFP-10GE-LR (EX-series) SRX-XFP-10GE-LR (SRX-series) 740-031833 = XFP-10G-L-OC192-SR1 (M/T/MX-series) They are similar transceivers but not exactly the same. Perhaps, in the past, the part-to-SKU mappings were different. The latter part seems to support some additional standards (ITU-T G.693 VSR2000-2R1, 8 Gb/s FC 800-SM-LC-L, 10 Gb/s CPRI, and ITU G.709 FEC OTU1e/OTU2/OTU2e) but it may not work in platforms it hasn't been qualified for. Cheers, Dale Many thanks for all the replies. All that I have on hand at the moment are 740-031833 optics, so I can't do side by side testing. I have some 740-014279 optics on the way to me and I'll check them out and report back what I find. To add to the fun, I have some optics labeled as the 740-031833 part number with and without the trailing -C https://imgur.com/2MN8KMa My first suspicion was that the two optics were designed for different operating temperature ranges (CO vs DC), but the above part descriptions lead me to believe that these are essentially the same optics differentiated mostly by whether they are sold for EX/SRX or M/T/MX. -DMM ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Juniper Optics 10G SM XFP
Can anyone tell me the differences between these two optics? XFP-10G-L-OC192-SR1 740-014279 XFP-10G-L-OC192-SR1-C 740-031833 -DMM ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] TACACS in Junos
On 3/20/2014 5:16 PM, Skeeve Stevens wrote: Hey all, We've been implementing Tacacs on our networks and have this issue where we can't seem to get Tacacs working unless we declare the username and Tacacs is used just for the authentication. Does anyone know how to get Tacacs working like Cisco where you just set it up and once you add users to the Tacacs back-end, they can login? Template users - not exactly what you want, but works: http://kb.juniper.net/InfoCenter/index?page=contentid=KB17269 -DMM ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Junos 12.3R3.4 Processor Utilization
On 9/21/2013 7:38 AM, Serge Vautour wrote: We hit an SNMP memory leak bug on 12.3R3 which drove up the CPU Mem. Might be something similar. 12.3R4 is out. Maybe give it a try? Thanks for the thought, but 12.3R4.6 displays the same behavior for me - spiking the procs and log spam on a simple show command. -DMM *From:* David Miller dmil...@tiggee.com *To:* juniper-nsp@puck.nether.net *Sent:* Friday, September 20, 2013 5:59:35 PM *Subject:* [j-nsp] EX4200 Junos 12.3R3.4 Processor Utilization Anyone running the JTAC recommended version of Junos (12.3R3.4) on any EX4200s and collecting configs with RANCID? If so, then I would be curious to see what your proc utilization looks like. What I see on my 12.3R3.4 switch is a large CPU spike whenever RANCID collects data. The command that seems to be the issue is: show version detail | no-more On my switch the following 3 log messages appear in /var/log/messages every time 'show version detail' is run: Jun 14 03:19:39 mgd[2139]: UI_OPEN_TIMEOUT: Timeout connecting to peer 'remote-operations' Jun 14 03:19:39 mgd[2139]: UI_OPEN_TIMEOUT: Timeout connecting to peer 'dhcp' Jun 14 03:19:40 mgd[2139]: UI_OPEN_TIMEOUT: Timeout connecting to peer 'autoinstallation' Top shows: CPU states: 39.2% user, 0.0% nice, 55.3% system, 0.1% interrupt, 5.5% idle during a run of this show command. My SNMP monitoring over time shows spikes of: jnxOperatingCPU.FPC0 max: 81.80 jnxOperatingCPU.RE0 max: 35.92 Anyone else seeing this as well? I can reproduce this behavior exactly on a brand new switch, upgraded to 12.3R3.4, with vanilla default Juniper config on it (so I don't think that it is my config). Am I missing some simple config option? set chassis routing-engine dont-blow-out-cpus-on-simple-show-cmds - DMM ___ juniper-nsp mailing list juniper-nsp@puck.nether.net mailto:juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- -__ David Miller dmil...@tiggee.com signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4200 Junos 12.3R3.4 Processor Utilization
Anyone running the JTAC recommended version of Junos (12.3R3.4) on any EX4200s and collecting configs with RANCID? If so, then I would be curious to see what your proc utilization looks like. What I see on my 12.3R3.4 switch is a large CPU spike whenever RANCID collects data. The command that seems to be the issue is: show version detail | no-more On my switch the following 3 log messages appear in /var/log/messages every time 'show version detail' is run: Jun 14 03:19:39 mgd[2139]: UI_OPEN_TIMEOUT: Timeout connecting to peer 'remote-operations' Jun 14 03:19:39 mgd[2139]: UI_OPEN_TIMEOUT: Timeout connecting to peer 'dhcp' Jun 14 03:19:40 mgd[2139]: UI_OPEN_TIMEOUT: Timeout connecting to peer 'autoinstallation' Top shows: CPU states: 39.2% user, 0.0% nice, 55.3% system, 0.1% interrupt, 5.5% idle during a run of this show command. My SNMP monitoring over time shows spikes of: jnxOperatingCPU.FPC0 max: 81.80 jnxOperatingCPU.RE0 max: 35.92 Anyone else seeing this as well? I can reproduce this behavior exactly on a brand new switch, upgraded to 12.3R3.4, with vanilla default Juniper config on it (so I don't think that it is my config). Am I missing some simple config option? set chassis routing-engine dont-blow-out-cpus-on-simple-show-cmds - DMM signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Help: Learning routes from same ASN, cisco vs juniper
On 9/10/2013 1:28 PM, OBrien, Will wrote:
I've found an interesting issue and I wanted to get some thoughts before
talking to JTAC about it.
I have a few of MX480s. In the past, I've advertised a dedicated /24 from my
lab to my providers upstream.
That /24 was never learned by my primary MX.
The issue comes down to either the MX or the Cisco filtering routes that are
from the same ASN. It's been a couple of years since I ran across this and I
can't remember who was at fault.
This behavior is biting my with regard to my DR site.
At my DR, I have a SRX with say ASN 1234. It's advertising a /24.
At my primary site, I also use ASN1234. I do not receive the /24 via BGP.
So, either the Cisco (7600 I think) isn't advertising the route to me because
it's from my ASN - OR - The MX is filtering it because it's from my ASN and
coming in on a eBGP link.
If it's the MX, I'm certain I can write an import filter, but I'm having an
issue hunting down syntax on that.
If it's the Cisco, then I can yell at the provider to have them open a TAC
case.
Like I said, I ran across this a few years ago, but can't remember who was at
fault. I could build a multi-hop neighbor relationship to get around this,
but surely there's a simpler solution...
In Juniper:
https://www.juniper.net/techpubs/en_US/junos/topics/reference/configuration-statement/loops-edit-protocols-bgp-family.html
protocols {
bgp {
neighbor 10.2.3.4 {
family inet {
unicast {
loops 1;
}
}
}
}
}
-set-
set protocols bgp neighbor 10.2.3.4 family inet unicast loops 1
^^ Will allow AS in path 1 time (can be set higher).
-DMM
signature.asc
Description: OpenPGP digital signature
___
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 2/19/2013 6:22 AM, Robert Hass wrote: On Tue, Feb 19, 2013 at 10:54 AM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: This is really frustrating and limits the scope where we can put the MX80 platform. Would it have been so much more expensive to put a faster CPU/RE into that thing? Or is this just a case of diversifying the product line? It's not about slow CPU. MX80 has very fast PPC (fastest from it's like) processor but RPD code sucks. Same family was used eg. in RSP720 in Cisco 7600 which is much faster - but it's probably becouse IOS preforms better than JunOS in terms of performance/scheduling on PPC platform. Last I checked, MX80 was only using a single core of the dual core PPC CPU - because JUNOS (32 bit) cannot gracefully handle SMP. -DMM ___ 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 1/16/2013 10:11 PM, Brandon Ross wrote: 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. You may also be able to set BGP communities on your announcements to Peer1 to control their handling of your prefixes. http://bgp.he.net/AS13768#_irr -DMM ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5 to MX80 virtual chassis feature
On 10/22/2012 9:05 AM, Skeeve Stevens wrote: From what I heard at the SE Summit, never. It was just too difficult to do with a single RE, so they have dumped it. But, there is another product coming which is similar, but will be able to do it from the start. This is all conjecture and hearsay ;-) * [snip] On Mon, Oct 22, 2012 at 10:49 PM, Riccardo S dim0...@hotmail.com wrote: Does anybody knows if there is a chance to have soon available the virtual chassis feature on MX5 - MX80 ? As far as I understood Juniper announced it for Q3 2011, but nothing has been released... We were told 2+ years ago that Juniper would be releasing a module for the port in the back of the MX5 - MX80 that could be used to VC another MX -or- be used as high speed link to an EX (4200 / 8500). This has changed a few times in our discussions with Juniper over the subsequent years from coming soon to no idea what you are talking about to coming soon again. Latest responses from Juniper have been reasonably solid never going to happen. My guess (merely a guess) is that marketing/product positioning folks within Juniper decided that this functionality would compete against their more expensive products and killed the development/release. -DMM ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 poor monitoring, packet loss to RE, SNMP not responding
On 7/19/2012 5:56 PM, Morgan McLean wrote: So I actually don't use the FXP interface. I basically have four OSPF connections coming into my edge firewall srx cluster, and I use the loopback address advertised over OSPF to manage all of my devices. The MX80's are the only ones that seem to have a problem...am I S.O.L if I'm not using the FXP interface? Morgan Not at all. Management and monitoring over the loopback (in-band) is a perfectly valid and workable configuration. Knowing nothing at all about the config on your gear, I would think that the first places to look for the source of intermittent failures would be route stability and RE firewalls/policers. You said that you get intermittent ping failures to the box. Can you ssh into the box reliably? Can you ping from the box reliably to the destination that has issues pinging to the box? ...and so on... -DMM On Wed, Jul 18, 2012 at 9:14 AM, Xu Hu jstuxuhu0...@gmail.com wrote: Does the Juniper RE not the same as Cisco RSP. I think the control plane information all need to go to the RE, if RE had any issue, why the traffic don't have any issue? Thanks and regards, Xu Hu On 18 Jul, 2012, at 22:32, OBrien, Will obri...@missouri.edu wrote: Check your fxp0 configuration. You may be shipping return traffic out random interfaces... We are leaning toward putting all production traffic inside a virtual routing instance/chassis and using the main routing instance just for management. From: juniper-nsp-boun...@puck.nether.net [ juniper-nsp-boun...@puck.nether.net] on behalf of Morgan McLean [ wrx...@gmail.com] Sent: Wednesday, July 18, 2012 1:34 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] MX80 poor monitoring, packet loss to RE, SNMP not responding I have a pair of MX80's that both are very unreliable in terms of trying to monitor them. Any traffic destined to the RE, be it ICMP or SNMP seems to be very hit or miss. Sometimes SNMP won't respond, pinging it gives me maybe 50% loss on average, but it passes traffic fine. This causes issues with monitoring, false alerts, etc. I realize the traffic destined for the RE is not as important, but the box is hardly loaded and among maybe 50 other juniper devices I have, EX, SRX, only these are giving me issues. Can anybody give me any insight? Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Hidden IPv4 iBGP routes
On 3/13/2012 4:15 PM, Stefan Fouant wrote:
Yes this is correct and is indeed the default Junos behavior. If you wanted
to receive a looped BGP update, you can define the amount of loops allowed
(.i.e. number of times your own AS appears in the AS Path attribute) by
configuring the 'set routing-options autonomous system as-num loops num'
command.
HTHs.
Stefan Fouant
JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI
Technical Trainer, Juniper Networks
Follow us on Twitter @JuniperEducate
Sent from my iPad
You can also allow loops on a per BGP neighbor basis with:
neighbor 10.0.0.1 {
family inet {
unicast {
loops 1;
}
}
}
-DMM
On Mar 13, 2012, at 4:10 PM, Mohammad masal...@gmail.com wrote:
Hi john;
As far as I know when an eBGP router receives a route contains its own AS
in the AS path it consider it as a loop, so for your case the juniper router
is seeing its own AS () in the route's ASPATH received from its eBGP
neighbor (X Y I), so the solution I would suggest is to remove AS
on the other router before sending it to the juniper router, if is
a private AS you can use remove private on the other router; or you can use
AS override.
Hope it is helpful;
Mohammad Salbad
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mounting MX80 at an angle
On 2/16/2012 1:41 PM, Jerry Jones wrote: I would be careful the hot air exiting the rear is not sucked back in the front, if the front is higher. Checkout link for airflow description. http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/requirements/mx5-mx10-mx40-mx80-cabinet-requirements.html MX80 air flow is not front-back it is instead side-side (from the front intake is on right side and exhaust on left). In the link for the airflow above, keep in mind that that is a front view and not a side view. -DMM On Feb 16, 2012, at 12:29 PM, Serge Vautour wrote: I don't mean angled side-side, I mean angles front-back. So the back end would be lower than the front end. After mounting, if you stood in front of the MX, the front plate would be pointing towards the ceiling a bit instead of horizontally. Serge From: Justin M. Streinerstrei...@cluebyfour.org To: juniper-nsp@puck.nether.netjuniper-nsp@puck.nether.net Sent: Thursday, February 16, 2012 1:22:34 PM Subject: Re: [j-nsp] Mounting MX80 at an angle On Thu, 16 Feb 2012, Serge Vautour wrote: Has anyone ever rack mounted an MX80 or a similar sized router at an angle before? Any reason why this isn't a good idea? Could it have an impact on the electrical components? I'm not entirely sure what you mean by mounting at an angle. Do you have any pictures/examples? jms ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Graphs for IPv6 traffic
On 8/22/2011 8:06 AM, Ido Szargel wrote: Hi All, I am looking for a way to poll snmp data on IPv6 traffic (bps, pps) on MX80 to a cacti graph, does anyone have any luck with doing that? Thanks, Ido. If you are looking for global IPv6 stats for the router you can start at *JUNIPER-IPv6-MIB*: http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/ipv6-mib-overview.html http://www.oidview.com/mibs/2636/JUNIPER-IPv6-MIB.html You may also need to set forwarding-options family inet6 route-accounting http://www.juniper.net/techpubs/en_US/junos10.1/information-products/topic-collections/config-guide-policy/topic-28331.html -DMM ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 throughput
On 5/16/2011 4:19 AM, Saku Ytti wrote: On (2011-05-16 11:41 +0800), Chen Jiang wrote: MX80-48T doesn't support scheduling hierarchy compared with MX80, except that, all the same. I don't think you need scheduling hierarchy in your It is also missing clocking stuff (uarts, bits, synce). IIRC the MX80-48T bundle is also restricted in certain licenses that are available. We were told at the time we were going through the process to determine the best upgraded Juniper gear for us (~6 months ago) that they wouldn't sell us the ADV-R license on a 48T bundle. http://forums.juniper.net/t5/Routing/MX80-Advanced-License/td-p/52014 These bundles and licensing restrictions and such seem to change daily with Juniper, so my recommendation would be to give your sales rep your complete set of requirements and let them muddle through the morass of different bundles. For us this was a (longer than expected) iterative process of several rinse, lather, repeats. -DM ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
