Re: [j-nsp] EX4550 version
I have several running 12.2R1.8, some of them as pure L2 aggregation switches, some of them doing basic L3 including OSPF, VRRP. No VC. No issues found so far. nick On Wed, Jul 24, 2013 at 5:27 AM, Luca Salvatore wrote: > Hi All, > > Just got a couple of new EX4550 switches... current recommended version is > 12.2r2.5 > But I just saw tha the 12.2 train is up release 5.3. > > Just wondering what the rest of you guys are running and if you have any > horror stories. > I'm not doing VC with these guys, they are going to be a pretty simple > layer 2 aggregation type switch. > > Thanks. > > ___ > 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] EX-RPS configuration
Yes. I was confused by the part of documentation saying "No configuration is required on an RPS if you: Plan to back up as many as six non-PoE switches". (page 72 - Using default RPS configuration"). So I said to myself: "I am ok if I don't have the ability to adjust the priorities or upgrade the firmware at this point. I just need the redundant power". Tried to make a shortcut. Wrong idea. Nick On Thu, Jul 4, 2013 at 9:40 PM, Morgan McLean wrote: > This is true, because I run 3300's and ran into this very problem. > > Morgan > > > On Thu, Jul 4, 2013 at 10:36 AM, Nick Kritsky wrote: > >> Thanks for all who replied on- and off-list. >> Looks like the obvious step I was missing is - "EX3300 switches have to >> run >> 12.1 or above to work with EX-RPS". I will try to confirm this tomorrow. >> >> nick >> >> >> On Thu, Jul 4, 2013 at 6:04 PM, Nick Kritsky >> wrote: >> >> > Hello all, >> > >> > Is anyone here who has experience with EX-RPS - redundant power supply >> for >> > EX switches? >> > I'd like to ask some questions/directions . >> > >> > From what I see - basically they are just DC converters with some >> minimal >> > set of knobs. >> > Documentation is virtually non-existent. Main idea I got from the site - >> > it should just work when you plug it in. But guess what - it doesn't. >> It >> > looks like I have missed some very simple step. The one that was >> considered >> > obvious to the guy who was creating the manual :) >> > >> > thanks >> > nick >> > >> > >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > > > -- > Thanks, > Morgan > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX-RPS configuration
Thanks for all who replied on- and off-list. Looks like the obvious step I was missing is - "EX3300 switches have to run 12.1 or above to work with EX-RPS". I will try to confirm this tomorrow. nick On Thu, Jul 4, 2013 at 6:04 PM, Nick Kritsky wrote: > Hello all, > > Is anyone here who has experience with EX-RPS - redundant power supply for > EX switches? > I'd like to ask some questions/directions . > > From what I see - basically they are just DC converters with some minimal > set of knobs. > Documentation is virtually non-existent. Main idea I got from the site - > it should just work when you plug it in. But guess what - it doesn't. It > looks like I have missed some very simple step. The one that was considered > obvious to the guy who was creating the manual :) > > thanks > nick > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX-RPS configuration
Thanks, I will try that. And I will file the case with JTAC as well. Could it be that RPS would only work with switches running 12.x ? For example documentation says about "show redundant-power-system version" - "Command introducedin Junos OS Release 12.1 for EX Series switches". The command is recognized in 11.3R4.2 . If I recall correctly - EX-RPS was there before 12.x . nick On Thu, Jul 4, 2013 at 8:58 PM, Jerry Jones wrote: > Couple ideas to try. > > You say switches have internal DC power so I guess there is no POE. If so > then when you get a switch up I would suggest setting mode to multi on the > RPS with > > request-redundant-power-system multi-backup > But first how about disconnecting all but one cable from the RPS. What is > the condition of LEDs? > > I assume you have done at least one commit on each switch? > > > On Jul 4, 2013, at 11:38 AM, Nick Kritsky wrote: > > Jerry, > > Most annoying thing - it does not provide redundant power to the switches. > I could live with other problems, but this one is kind of a deal breaker. > I have all 3 AC PS inserted. I have 4 DC outlets connected to 4 EX3300 > switches. I have console port on RPS connected to console server and I can > get access to some crippled shell inside it. > when I issue command "show chassis redundant-power-system" on the switch > with DC connected to RPS, I got following answer: > "error: No RPS connected (chassis-control)" > > nick > > > On Thu, Jul 4, 2013 at 7:58 PM, Jerry Jones wrote: > >> Only gotcha I have heard of is to use the center slot for the first power >> supply. >> >> What specifically is it not doing? >> >> >> On Jul 4, 2013, at 9:04 AM, Nick Kritsky wrote: >> >> Hello all, >> >> Is anyone here who has experience with EX-RPS - redundant power supply for >> EX switches? >> I'd like to ask some questions/directions . >> >> From what I see - basically they are just DC converters with some minimal >> set of knobs. >> Documentation is virtually non-existent. Main idea I got from the site - >> it >> should just work when you plug it in. But guess what - it doesn't. It >> looks like I have missed some very simple step. The one that was >> considered >> obvious to the guy who was creating the manual :) >> >> thanks >> nick >> ___ >> 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] EX-RPS configuration
Jerry, Most annoying thing - it does not provide redundant power to the switches. I could live with other problems, but this one is kind of a deal breaker. I have all 3 AC PS inserted. I have 4 DC outlets connected to 4 EX3300 switches. I have console port on RPS connected to console server and I can get access to some crippled shell inside it. when I issue command "show chassis redundant-power-system" on the switch with DC connected to RPS, I got following answer: "error: No RPS connected (chassis-control)" nick On Thu, Jul 4, 2013 at 7:58 PM, Jerry Jones wrote: > Only gotcha I have heard of is to use the center slot for the first power > supply. > > What specifically is it not doing? > > > On Jul 4, 2013, at 9:04 AM, Nick Kritsky wrote: > > Hello all, > > Is anyone here who has experience with EX-RPS - redundant power supply for > EX switches? > I'd like to ask some questions/directions . > > From what I see - basically they are just DC converters with some minimal > set of knobs. > Documentation is virtually non-existent. Main idea I got from the site - it > should just work when you plug it in. But guess what - it doesn't. It > looks like I have missed some very simple step. The one that was considered > obvious to the guy who was creating the manual :) > > thanks > nick > ___ > 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
[j-nsp] EX-RPS configuration
Hello all, Is anyone here who has experience with EX-RPS - redundant power supply for EX switches? I'd like to ask some questions/directions . >From what I see - basically they are just DC converters with some minimal set of knobs. Documentation is virtually non-existent. Main idea I got from the site - it should just work when you plug it in. But guess what - it doesn't. It looks like I have missed some very simple step. The one that was considered obvious to the guy who was creating the manual :) thanks nick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] DOM monitoring MIB
Does anyone know if jnxDomMib is supported for SFP+ interfaces on EX series (4550, 4200, 3300)? thanks nick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [OT] unit-level vs interface-level description
Thank you all for your answers. That gave me a lot to think about. One additional question: do you use the same approach (description on both levels) for switch-ports inside DC or in campus network? Assuming that we talk about regular access level ports that only have unit 0 with "family eth" on them. I mean - in this case, descriptions on unit-level and interface-level will be pretty much the same? Does it make sense to let go of interface-level descriptions and use only unit-level? Because from what I remember, majority of internal reporting stuff uses sub-interfaces in their output (from top of my head - "show ethernet-switching table" and "show lldp ne") thanks nick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] [OT] unit-level vs interface-level description
Hi fellow J-users, I hope I will not trigger some long-forgotten flame-war by that question. But I do wonder: what are the best practices for interface/unit descriptions? Do you put them on interface-level or unit-level? Especially when you have pure-L3 interface that only has "unit 0" with "family inet" on it. Do you put description to interface level? Unit level? Or both levels? Or do you put it on both levels but different descriptions? I've seen people using different approaches, and I am just curious what's driving them. To be completely honest, this question is not entirely theoretical. Recently I was writing some reporting scripts for my NetFlow data. And I have noticed that InterfaceIn and InterfaceOut fields are populated with unit-level ifIndex. And in my case that meant - no description. That made me wonder if I am actually "doing it right" (TM) thanks nick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3 Incompletes
If the L3 incomplete errors are increasing on the interface that is facing Cisco, check out this article: http://kb.juniper.net/InfoCenter/index?page=content&id=KB12386&actp=RSS Nick On Tue, May 21, 2013 at 11:30 AM, Mohammad Khalil wrote: > Hi , I have mx480 connected to My ASN Gateway > The LAN side which is conncted to the access network is configured with > 1600 and has no errors > The WAN interface is also configured with MTU 1600 but the L3 incomplete > are increasing , what could be the issue ? > ___ > 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] DOM support for OEM optics
Hi Amos, Positive experience: SFP-1GE-LX from SolidOptics Negative experience (working, but without DOM): SFP-1GE-LX from Recurrent There also is a number of DOM-capable LR/SR 10g SFP+, but I cannot get the name out of them. "show chassis pic" gshows them as "OEM" Nick On Wed, May 15, 2013 at 6:31 PM, Amos Rosenboim wrote: > Hi, > > Can you share some models that support DOM ? > All the compatibles that we have do not support it. > > Thanks > > Amos > > Sent from my iPhone > > On 15 May 2013, at 14:28, "sth...@nethelp.no" wrote: > > I have started collecting information regarding DOM support for 3rd party > > optics. > > I am primarily interested in support for MX and EX series. > > Brief search of list did not reveal much information. > > This is what I got so far: > > 1. 3rd party optics are accepted in MX/EX most of the times > > 2. DOM support works for _some_ of the optics. > > > No experience with EX. MX: In all cases where the optics part itself > supports DOM, we have been able to read the information with "show > interfaces diagnostics optics". > > Steinar Haug, Nethelp consulting, sth...@nethelp.no > ___ > 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
[j-nsp] DOM support for OEM optics
Hello, I have started collecting information regarding DOM support for 3rd party optics. I am primarily interested in support for MX and EX series. Brief search of list did not reveal much information. This is what I got so far: 1. 3rd party optics are accepted in MX/EX most of the times 2. DOM support works for _some_ of the optics. But I have never seen a matrix of supported vendors. If you know about such table existing - please send me the link. If you think that having such table would be a good idea - please feel free to send me optics compatibility information that you have. Something like: "MX240/DPC:Finisair-LX-GE:Working:DOM+" or "MX240/MPC:SuperOpticsVendor-LX-GE:Working:No DOM" and I will work to build the chart. thanks Nick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Srx 240 ipsec site to site
I guess you can achieve this functionality using event-scripts. Nick On Mon, May 13, 2013 at 10:30 AM, Klaus Groeger wrote: > Hi > > > you may not resolve the issue with auto vpn, because the main problem is: > both sites are assigned the IPs dynamically - via dhcp or whatever. If > both sites do not know the peer's IP address, they cannot establish a > tunnel. > > > In ScreenOS, one has the option to use hostname instead of an IP address, > the system makes a name lookup and connects to the resolved address. This > isn't possible with SRX, because the hostname is resolved during > configuration and the IP address will be naild down in the config. > > > Even if you use aggressive mode, one site has to be a fixed IP address! > > > Regards > > > Klaus > > > > — > Sent from Mailbox for iPhone > > > On So., Mai 12, 2013 at 20:58, Misha Gzirishvili < > misha.gzirishv...@gmail.com="mailto:misha.gzirishv...@gmail.com";>> wrote: > Hi Aji, > Take a look at AutoVPN. > Some links about it: > ___ > 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] VC-port over Ethernet
Graham,
short answer is - yes, EX-3300 can form VC when connected via 3rd switch.
No special settings are required on the uplink switch. However without
special configuration (q-in-q? jumbo frames?) VC is unstable (see below in
"test results").
here is the test setup.
1. Topology:
ASW13 ASW11 --- ASW14
ASW11 is EX-4200-24T with two 10G interfaces
ASW13, ASW14 are EX-3300 with default configuration
2. Configuration
ASW11:
xe-0/1/0 {
description sjc-net-asw13:xe-0/1/2;
unit 0 {
family ethernet-switching;
}
}
xe-0/1/2 {
description sjc-net-asw14:xe-0/1/2;
unit 0 {
family ethernet-switching;
}
}
3. results of tests.
3.1 time T: link up on both 10G ports of ASW11
3.2 time T+2 min: link on one of 10G ports of ASW11 goes down and stays
this way.
Somewhere between 3.1 and 3.2 ASW13 and ASW14 form 2-member VC.
After one of the 10G links goes down, VC obviously becomes crippled.
I also have strong suspicion that connecting vc-port to uplink switch may
result in some nasty 2-minute-long loop that is not blocked by STP. I will
check it tomorrow.
nick
On Wed, Apr 17, 2013 at 5:41 AM, Graham Brown
wrote:
> Nick,
>
> Let us know the results of your testing.
>
> However you can disable the default by issuing the below two commands:
> request virtual-chassis vc-port delete pic-slot 1 port 2
> request virtual-chassis vc-port delete pic-slot 1 port 3
>
> HTH,
> Graham
>
>
> On 15 April 2013 23:54, Nick Kritsky wrote:
>
>> Klaus,
>>
>> No, I don't want to form VC between 3300 and 4500.
>>
>> nick
>>
>>
>> On Mon, Apr 15, 2013 at 2:16 PM, Klaus Groeger wrote:
>>
>> > Just one word, to double check if i understand you. You would like to
>> form
>> > a VC between 3300 and 4500?
>> >
>> > That won't work. You can only form VC between 3300 or between 45xxx and
>> > 4200.
>> > Klaus
>> > —
>> > Sent from Mailbox <https://bit.ly/SZvoJe> for iPhone
>>
>> >
>> >
>> > On Mon, Apr 15, 2013 at 9:41 AM, Nick Kritsky > >wrote:
>> >
>> >> Thanks. Just to clarify - I am actually trying to prevent this from
>> >> happening.
>> >> EX-3300 have ports xe-0/1/2 and xe-0/1/3 put in VC-port mode by
>> default.
>> >> So I wonder if two fresh, brand new EX-3300 can form VC when they are
>> >> plugged into upstream 4550 using vc-ports.
>> >> This can explain some strange behavior i was observing recently, but I
>> >> was too busy fixing it, so I didn't run much tests.
>> >> I plan to setup small lab for that. I will let you know of the outcome.
>> >>
>> >> nick
>> >>
>> >>
>> >> On Sun, Apr 14, 2013 at 4:33 PM, Klaus Groeger
>> wrote:
>> >>
>> >>> Hi
>> >>>
>> >>> I would recommend Q-in-Q on the intermediate switch. I have seen 4550
>> VC
>> >>> spanning over metro erhernet, so this should work for 3300 also.
>> >>>
>> >>> Regards
>> >>>
>> >>> Klauzi
>> >>> —
>> >>> Sent from Mailbox <https://bit.ly/SZvoJe> for iPhone
>>
>> >>>
>> >>>
>> >>> On Sat, Apr 13, 2013 at 9:21 PM, Nick Kritsky > >wrote:
>> >>>
>> >>>> Dear J-NSP,
>> >>>>
>> >>>> Can anyone confirm/deny if two EX3300 can form virtual-chassis when
>> >>>> their
>> >>>> vc-ports are connected via third switch?
>> >>>>
>> >>>> thanks
>> >>>> nick
>> >>>> ___
>> >>>> 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
>>
>
>
>
> --
> Graham Brown
> Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer>
> LinkedIn <http://www.linkedin.com/in/grahamcbrown>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VC-port over Ethernet
Klaus, No, I don't want to form VC between 3300 and 4500. nick On Mon, Apr 15, 2013 at 2:16 PM, Klaus Groeger wrote: > Just one word, to double check if i understand you. You would like to form > a VC between 3300 and 4500? > > That won't work. You can only form VC between 3300 or between 45xxx and > 4200. > Klaus > — > Sent from Mailbox <https://bit.ly/SZvoJe> for iPhone > > > On Mon, Apr 15, 2013 at 9:41 AM, Nick Kritsky wrote: > >> Thanks. Just to clarify - I am actually trying to prevent this from >> happening. >> EX-3300 have ports xe-0/1/2 and xe-0/1/3 put in VC-port mode by default. >> So I wonder if two fresh, brand new EX-3300 can form VC when they are >> plugged into upstream 4550 using vc-ports. >> This can explain some strange behavior i was observing recently, but I >> was too busy fixing it, so I didn't run much tests. >> I plan to setup small lab for that. I will let you know of the outcome. >> >> nick >> >> >> On Sun, Apr 14, 2013 at 4:33 PM, Klaus Groeger wrote: >> >>> Hi >>> >>> I would recommend Q-in-Q on the intermediate switch. I have seen 4550 VC >>> spanning over metro erhernet, so this should work for 3300 also. >>> >>> Regards >>> >>> Klauzi >>> — >>> Sent from Mailbox <https://bit.ly/SZvoJe> for iPhone >>> >>> >>> On Sat, Apr 13, 2013 at 9:21 PM, Nick Kritsky wrote: >>> >>>> Dear J-NSP, >>>> >>>> Can anyone confirm/deny if two EX3300 can form virtual-chassis when >>>> their >>>> vc-ports are connected via third switch? >>>> >>>> thanks >>>> nick >>>> ___ >>>> 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] VC-port over Ethernet
Thanks. Just to clarify - I am actually trying to prevent this from happening. EX-3300 have ports xe-0/1/2 and xe-0/1/3 put in VC-port mode by default. So I wonder if two fresh, brand new EX-3300 can form VC when they are plugged into upstream 4550 using vc-ports. This can explain some strange behavior i was observing recently, but I was too busy fixing it, so I didn't run much tests. I plan to setup small lab for that. I will let you know of the outcome. nick On Sun, Apr 14, 2013 at 4:33 PM, Klaus Groeger wrote: > Hi > > I would recommend Q-in-Q on the intermediate switch. I have seen 4550 VC > spanning over metro erhernet, so this should work for 3300 also. > > Regards > > Klauzi > — > Sent from Mailbox <https://bit.ly/SZvoJe> for iPhone > > > On Sat, Apr 13, 2013 at 9:21 PM, Nick Kritsky wrote: > >> Dear J-NSP, >> >> Can anyone confirm/deny if two EX3300 can form virtual-chassis when their >> vc-ports are connected via third switch? >> >> thanks >> nick >> ___ >> 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
[j-nsp] VC-port over Ethernet
Dear J-NSP, Can anyone confirm/deny if two EX3300 can form virtual-chassis when their vc-ports are connected via third switch? thanks nick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 generates power supply and fan alarms when environment is good
Assuming they are using EX as their own offices' switches ;) On Thu, Apr 4, 2013 at 5:44 AM, Chuck Anderson wrote: > I think Juniper's internal IT department should be required to > immediately load any new version of software on their own offices' > switches before it is released to the general public. > > On Thu, Apr 04, 2013 at 02:14:10AM +0200, Jasper Jans wrote: > > I can actually confirm that on 12.3R2.5 on the M10i the Fan/Blower alarms > > are still there. So it seems the PR only resolved the Fan/Blower messages > > on some platforms and not all. > > > > Apr 4 01:22:13 JuniperLog: chassisd[1421]: > > %DAEMON-5-CHASSISD_SNMP_TRAP6: SNMP trap generated: Fan/Blower Removed > > (jnxContentsContainerIndex 4, jnxContentsL1Index 1, jnxContentsL2Index 7, > > jnxContentsL3Index 0, jnxContentsDescr Fan Tray 0 Fan 7, > > jnxOperatingState/Temp 1) > > Apr 4 01:22:13 JuniperLog: chassisd[1421]: > > %DAEMON-5-CHASSISD_SNMP_TRAP6: SNMP trap generated: Fan/Blower Removed > > (jnxContentsContainerIndex 4, jnxContentsL1Index 1, jnxContentsL2Index 8, > > jnxContentsL3Index 0, jnxContentsDescr Fan Tray 0 Fan 8, > > jnxOperatingState/Temp 1) > > > > Jasper > > > > > > On Mon, Apr 1, 2013 at 4:47 PM, Peter Tavenier >wrote: > > > > > After an upgrade to 12.3R2.5 I still see errors for the power > supplies, 3 > > > messages per hour. The Fan/Blower alarms seems to be solved. > > > > > > Mar 28 14:30:52 chassisd[1308]: > %DAEMON-5-CHASSISD_SNMP_TRAP6: > > > SNMP trap generated: Power Supply Removed (jnxContentsContainerIndex 2, > > > jnxContentsL1Index 1, jnxContentsL2Index 3, jnxContentsL3Index 0, > > > jnxContentsDescr Power Supply: Power Supply 2 @ 0/2/*, > > > jnxOperatingState/Temp 1) > > > Mar 28 14:30:52 chassisd[1308]: > %DAEMON-5-CHASSISD_SNMP_TRAP6: > > > SNMP trap generated: Power Supply Removed (jnxContentsContainerIndex 2, > > > jnxContentsL1Index 1, jnxContentsL2Index 4, jnxContentsL3Index 0, > > > jnxContentsDescr Power Supply: Power Supply 3 @ 0/3/*, > > > jnxOperatingState/Temp 1) > > > Mar 28 14:30:52 chassisd[1308]: > %DAEMON-5-CHASSISD_SNMP_TRAP6: > > > SNMP trap generated: Power Supply Removed (jnxContentsCoontainerIndex > 2, > > > jnxContentsL1Index 1, jnxContentsL2Index 5, jnxContentsL3Index 0, > > > jnxContentsDescr Power Supply: Power Supply 4 @ 0/4/*, > > > jnxOperatingState/Temp 1) > > > > > > Kind regards, > > > Peter Tavenier > > > > > > Op 24 mrt. 2013, om 12:48 heeft Peter Tavenier < > peter.taven...@vancis.nl> > > > het volgende geschreven: > > > > > > > I got the two PR numbers (PR842933, PR858565) for this issues which > will > > > be fixed in 12.3R2. > > > > > > > > Which other problems do 12.3 have with the chassisd process? > > > > > > > > Kind regards, > > > > Peter Tavenier > > > > > > > > Op 22 mrt. 2013, om 22:09 heeft Giuliano > het > > > volgende geschreven: > > > > > > > >> Never mind about 12.3 > > > >> > > > >> It has big trouble with chassid daemon > > > >> > > > >> Sent from my iPhone > > > >> > > > >> On 22/03/2013, at 17:12, JP Velders wrote: > > > >> > > > >>> > > > Date: Thu, 21 Mar 2013 09:04:49 + > > > From: Peter Tavenier > > > Subject: [j-nsp] EX4200 generates power supply and fan alarms when > > > environment > > > is good > > > >>> > > > On my EX4200 running version 12.3R1.7 is see the following alarms > in > > > the logging: > > > >>> > > > Mar 21 08:46:46 chassisd[1290]: > > > %DAEMON-5-CHASSISD_SNMP_TRAP6: SNMP trap generated: Power Supply > Removed > > > (jnxContentsContainerIndex 2, jnxContentsL1Index 1, jnxContentsL2Index > 3, > > > jnxContentsL3Index 0, jnxContentsDescr Power Supply: Power Supply 2 @ > > > 0/2/*, jnxOperatingState/Temp 1) > > > ... 41 more times same type of alarms ... > > > Mar 21 08:46:46 chassisd[1290]: > > > %DAEMON-5-CHASSISD_SNMP_TRAP6: SNMP trap generated: Fan/Blower Removed > > > (jnxContentsContainerIndex 4, jnxContentsL1Index 2, jnxContentsL2Index > 1, > > > jnxContentsL3Index 1, jnxContentsDescr FAN: Fan 1 @ 1/0/0, > > > jnxOperatingState/Temp 1) > > > Mar 21 08:46:46 chassisd[1290]: > > > %DAEMON-5-CHASSISD_SNMP_TRAP6: SNMP trap generated: Power Supply > Removed > > > (jnxContentsContainerIndex 2, jnxContentsL1Index 8, jnxContentsL2Index > 1, > > > jnxContentsL3Index 0, jnxContentsDescr Power Supply: Power Supply 0 @ > > > 7/0/*, jnxOperatingState/Temp 1) > > > Mar 21 08:46:46 chassisd[1290]: > > > %DAEMON-5-CHASSISD_SNMP_TRAP6: SNMP trap generated: Fan/Blower Removed > > > (jnxContentsContainerIndex 4, jnxContentsL1Index 2, jnxContentsL2Index > 1, > > > jnxContentsL3Index 2, jnxContentsDescr FAN: Fan 2 @ 1/0/1, > > > jnxOperatingState/Temp 1) > > > Mar 21 08:46:46 chassisd[1290]: > > > %DAEMON-5-CHASSISD_SNMP_TRAP6: SNMP trap generated: Power Supply > Removed > > > (jnxContentsContainerIndex 2, jnxContentsL1Index 8, jnxContentsL2Index > 3, > > > jnxContentsL3Index 0, jnxContentsDescr Power Supply: Power Supply 2 @ > > > 7/2/*, jnxOperatingSta
Re: [j-nsp] ability to turn USB port on/off for MX routing engine?
This rises the question that is more generic. Have anyone built custom binaries that can be run on RE? I would love to see some additions to /usr/bin and /usr/sbin . Nick On Wed, Mar 20, 2013 at 1:04 PM, Wood, Peter (ISS) wrote: > > I thought Junos was built on FreeBSD. Aren't you supposed to be able > to do > > just about anything you want with FreeBSD? > > Built on/manipulated/"mutated"... On one of my various FreeBSD 9 machines > I use usbconfig to actually do this, but a quick check of a SRX 3600 and > MX 960 (both on 11.4) shows that binary is missing. > > If the command were to exist something like this should work: > /usr/sbin/usbconfig -u 0 -a 2 power_off > > P. > -- > Peter Wood > Network Security Specialist > Information Systems Services > Lancaster University > > ___ > 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] Interface tail drops vs. ifOutDiscards
You can use counters in jnx-cos MIB ( 1.3.6.1.4.1.2636.3.15 ). They will give you per-queue drop counters for each interface. I use jnxCosIfqTailDropPkts for monitoring interfaces on EX switches. These are the counters you see in "show interface extensive" - dropped packets for for each queue. nick On Wed, Jan 30, 2013 at 12:37 AM, Clarke Morledge wrote: > Really? > > Is there any know way to measure tail drops via SNMP with Juniper? In > particular, I am wondering about the MX platform. > > That is really odd. > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Interface tail drops vs. ifOutDiscards
That is known issue. and very irritating issue for me. Please make sure that your SE knows that you are not happy with that. Maybe some time in the future, J will fix it. Nick On Fri, Jan 25, 2013 at 3:00 PM, Antti Ristimäki wrote: > Hi, > > It seems that ifq tail drops don't increment IF-MIB::ifOutDiscards > counter, whereas e.g. packets dropped by RED do. Has anyone else > encountered this and is this an expected behaviour or a known issue? > > -Antti > ___ > 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] Problem with 802.1p/802.1q priority values and MX / EX4200
sorry, misread the original email. were you able to identify any pattern in which packets are remarked? also, can you share interface config for EX/MX? thanks nick On Thu, Nov 22, 2012 at 9:28 PM, Sebastian Wiesinger < juniper-...@ml.karotte.org> wrote: > * Nick Kritsky [2012-11-22 18:15]: > > Judging on previous experience, I would blame EX, not MX. :) > > But just to be sure - can you add input counter filters to EX interface > > connected to MX? Just to be 100% sure that packets are coming in without > > weird 802.1p > > Hi, > > I did that (see my first mail) and it DOES show packets with weird > 802.1p coming in from the MX. But the same counter on the MX outgoing > interface does NOT show these packets (they are instead having a > 802.1p field of 000 when outgoing, which is what I expected). > > Regards > > Sebastian > > -- > GPG Key: 0x93A0B9CE (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 > ___ > 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] Problem with 802.1p/802.1q priority values and MX / EX4200
Judging on previous experience, I would blame EX, not MX. :)
But just to be sure - can you add input counter filters to EX interface
connected to MX? Just to be 100% sure that packets are coming in without
weird 802.1p
hth
nick
On Thu, Nov 22, 2012 at 8:58 PM, Sebastian Wiesinger <
juniper-...@ml.karotte.org> wrote:
> * Sebastian Wiesinger [2012-11-22 16:45]:
> > I tried forcing all packets to best-effort/loss-priority low on the MX
> > but that didn't change anything. I'm currently suspecting the EX4200
> > to be the problem.
>
> Okay, now I found a workaround but I'm still not sure about the
> original cause. I configured this class-of-service rewrite rule on
> the interface to the service provider:
>
> swiesinger@sw1# show class-of-service
> interfaces {
> ge-0/0/10 {
> unit 0 {
> rewrite-rules {
> ieee-802.1 service-provider-rewrite;
> }
> }
> }
> }
> rewrite-rules {
> ieee-802.1 service-provider-rewrite {
> forwarding-class best-effort {
> loss-priority low code-point 000;
> loss-priority high code-point 000;
> }
> }
> }
>
> So I'm rewriting the codepoints in the 802.1p field to what they
> should have been from the beginning... and now it works. I'm confused.
>
> Regards
>
> Sebastian
>
> --
> GPG Key: 0x93A0B9CE (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
> ___
> 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] [SRX650] show pfe statistics weirdness
Thank you Graham. Just to clarify. counters in "Packet Forwarding Engine local protocol statistics" - what are they? My understanding was that they represent the number of network-control packets handled by PFE. thanks Nick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] [SRX650] show pfe statistics weirdness
Hello, There is something I don't understand. There is a SRX650 running BFD for OSPF sessions. BFD is working, however I wanted to make sure that it is processed in PFE. All counters of "show pfe statistics traffic protocol bfd" are zero, but BFD-related counters of "show pfe statistics traffic" are on-zero and increasing. What might be the reason of such difference? thanks Nick OS: 10.4R4.5 BFD is running on ge-0/0/1 Here is the output of "show pfe statistics traffic protocol bfd": BFD protocol statistics: Packets with invalid interface : 0 Packets with invalid address family: 0 Packets with bad IP checksum : 0 Packets with bad IP options: 0 Packets with bad IP length : 0 Packets with bad udp checksum : 0 Packets with bad udp length: 0 Packets with bad udp ports : 0 Packets with no logical interface : 0 Packets with prefix length mismatch: 0 Packets received : 0 Packets absorbed : 0 Packets failed to transmit : 0 Packets receive failures : 0 Packets allocation failures: 0 And here is the output of "show pfe statistics traffic": Packet Forwarding Engine traffic statistics: Input packets: 53237611735 5350 pps Output packets: 80428514254 7630 pps Packet Forwarding Engine local traffic statistics: Local packets input : 38162325 Local packets output: 37968315 Software input control plane drops :0 Software input high drops :0 Software input medium drops : 1088 Software input low drops:0 Software output drops :0 Hardware input drops:0 Packet Forwarding Engine local protocol statistics: HDLC keepalives:0 ATM OAM:0 Frame Relay LMI:0 PPP LCP/NCP:0 OSPF hello : 1434683 OSPF3 hello:0 RSVP hello :0 LDP hello :0 BFD: 26625331 IS-IS IIH :0 LACP :0 ARP: 7093341 ETHER OAM :0 Unknown:0 Packet Forwarding Engine hardware discard statistics: Timeout:0 Truncated key :0 Bits to test :0 Data error :0 Stack underflow:0 Stack overflow :0 Normal discard : 20239282 Extended discard :0 Invalid interface :0 Info cell drops:0 Fabric drops :0 Packet Forwarding Engine Input IPv4 Header Checksum Error and Output MTU Error statistics: Input Checksum :0 Output MTU :0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L2L SRX - Linux
By the way, does anybody know if SRX/Netscreen route-based VPNs use any sort of transport encapsulation like GRE or IPIP? Or is it just plain tunnel with 0.0.0.0/0 encryption domain and policy-based routing? thanks Nick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX5 vs Brocade CER
Doug, thanks for the book. Nice to see the kindle edition also. I will definitely order it today. Can you recommend the book of same depth for the EX series? thanks Nick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Assigning Forwarding Class and DSCP Value for Routing Engine–Generated Traffic
don't you need to add rewrite rules to "class-of-service interfaces lo.0"? Based on my experience, this is where the marking occurs for egress packets. Disclaimer - I was working with physical interfaces. On Wed, Oct 10, 2012 at 4:18 PM, Huan Pham wrote: > Hi all, > > > There seems to be a bug with this feature. > > http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-cos/cos-assigning-fc-dscp-to-re-pkts.html > > Once I apply the Firewall Filter with QoS term on loopback interface, it > does not seem to change the default behaviour. > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] FPC CPU
Dear j-nsp, Apologies, if this is a trivial FAQ - but I cannot find the information anywhere. For M, MX, EX series there is an OID for monitoring FPC CPU. Question - what is this CPU for? What are we measuring here? Is it raw throughput stats of an ASIC, or CPU time that is used for some FPC-level tasks by some utility processor (BFD? LACP? STP? J-Flow?). What happens when this value reaches 100% (card freeze, drops, LACP link loss)? Appreciate your help. Thanks Nick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX as a server load balancer for service redundancy?
Maybe d-nat pool is what you are looking for. I am not sure if there is a health-check though - you may need to read documentation on that. nick On Wed, Aug 15, 2012 at 8:07 PM, OBrien, Will wrote: > I'm wondering if I can do a simple server load balancer using a SRX. > > Example: > Server A offers up service on port . > > Server B has the same service. > > If Server A goes offline, send traffic over to server B. > Resume when Server A becomes available again. > > > > One thought is to use something like track-ip to push a static nat mapping > around. > Ideally, I'd love to monitor the port. > > Ideas or examples? This is really just for failover, rather than load > balancing. > > > I suppose I could monitor the service from a control machine and have a > script execute a configuration change if the service becomes unreachable. > I'd prefer it if the entire process were managed from the SRX. > > (In this case it's a pair of clustered SRX 210s.) > > Will > ___ > 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
[j-nsp] flood-groups on EX switches
Hi j-nsp, I am looking for the way to partially disable IGMP snooping on EX series switches (4200, 3200) for particular multicast groups. Something like "flood-groups" command on MX. As for now, it looks like there is no such functionality in 11.x . Can someone confirm that or correct me? thanks Nick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] root-login via ssh and 11.x
To all: sorry for misinformation. It looks like change in root authentication behavior was caused not by JunOS upgrade, but by change from "system authentication-order [ tacplus password ]" to "system authentication-order tacplus" I have to be more careful. Still, I can't understand the logic behind this. "system authentication-order [ tacplus password ]" == root can login "system authentication-order tacplus" == root cannot login "system authentication-order tacplus" + "system services ssh root-login allow" == root can login Nick On Tue, Jun 26, 2012 at 4:51 PM, Wayne Tucker wrote: > On Tue, Jun 26, 2012 at 5:09 AM, Nick Kritsky wrote: > >> FYI: It looks like in version 11 Juniper has changed default settings >> for "system services ssh root-login". >> Now if you want to login as root via ssh, you have to explicitly allow >> it. in 10.X it was allowed by default. >> Tested on EX-4200, SRX-100. > > > I can't reproduce this on any of these: > > EX4200 running 11.4R2 > EX4200 running 11.3R6 > SRX240 running 11.2R6 > SRX240 running 11.2S6 > MX80 running 11.4R3 > > Are you using a RADIUS server? What setting are you using for > system/authentication-order, if any? > > :w > ___ > 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] root-login via ssh and 11.x
On Tue, Jun 26, 2012 at 4:51 PM, Wayne Tucker wrote: > > Are you using a RADIUS server? What setting are you using for > system/authentication-order, if any? > I am using TAC+. settings are: system authentication-order tacplus "root" user is local. There is no user "root" in TAC+ database Are you saying that you can login via SSH as user "root"? And you don't have "system services ssh root-login allow" configuration clause? Nick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] root-login via ssh and 11.x
FYI: It looks like in version 11 Juniper has changed default settings for "system services ssh root-login". Now if you want to login as root via ssh, you have to explicitly allow it. in 10.X it was allowed by default. Tested on EX-4200, SRX-100. Funny thing is that documentation is still claiming that default setting is to allow: http://www.juniper.net/techpubs/en_US/junos11.4/topics/reference/configuration-statement/root-login-edit-system.html I don't have any device with 12.1 to test, but I suspect that the problem exists there as well. If anyone from J is reading - please update documentation or JunOS defaults. It would be nice to keep them in sync. thanks Nick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vmember limits in EX series stack
On Tue, May 1, 2012 at 5:35 PM, Chuck Anderson wrote: > On Mon, Apr 30, 2012 at 08:15:59PM -0700, Naveen Nathan wrote: >> To manually specify the members for each downstream switch trunk port >> requires a significant amount of administrative overhead. I would prefer >> each trunk port just allow all the vlans. > > Doesn't that mean you are effectively always sending all broadcast > traffic on all VLANs down every port? That seems pretty pessimal. > Perhaps you could use GVRP or MVRP to automatically maintain VLAN > memberships. According to relnotes, GVRP is no longer supported after 11.1. MVRP could work but I am not sure about cisco-juniper interoperability here. As per original question, Juniper states pretty clearly: "If you ignore the warning and commit such a configuration, the configuration succeeds but you run the risk of crashing the Ethernet switching process (eswd) due to memory allocation failure." If you plan to enable all downstream ports as trunks with "vlan members all", you are going to exceed this limit not just for 10% but more than twice. I would not recommend this risk :) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4200: Scheduling on egress on analyzer interface
Is it just me, or EX4200/EX3200 switches do not support scheduling on analyzer interface. I could not find any statement regarding this in technical documentation or J-Net forums. Applying scheduler map to analyzer interface generates no error on commit, and output of "show interface extensive" says that 4 queues are in use. But the counters of queues other than best-effort are not increasing, when I can see on the on the analyzer output packets with DSCP bits set. JunOS version: 11.4R2.14 I thought I would ask here before going to J-TAC, maybe someone has already researched that. thanks Nick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX virtual chassis snmp polling - cacti - weathermap
Usual interface polling is the same as for standalone EX. As far as I know currently there is no OID to poll traffic information for stack interfaces. per-FRU data should be available. Now that you have asked that I wonder why didn't I include them into my cacti :) Currently I only monitor health data from active RE. There also are links in google pointing to both Cacti and Juniper forums - did you try them? Nick On Fri, May 11, 2012 at 1:04 PM, pkc_mls wrote: > Hi all, > > I'd like to graph via cacti/weathermap a virtual chassis of EX switches. > > Is it possible to reach each physical device ? > > Is it possible to graph the links between the EX devices ? > > Does anyone have a cacti template for juniper EX running as virtual chassis > ? > > thanks. > ___ > 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] tcp reset on srx
This can happen if you are using policy-based IPSEC and if the outgoing interface of RST packet is not included in encryption domain. NK On Tue, Jan 17, 2012 at 11:01 AM, ashish verma wrote: > Yes it is "reject". > Just found out that it is only over the IPSEC tunnel. Without IPSEC tunnel > it seems to be working. > > On Tue, Jan 17, 2012 at 4:07 PM, Ben Dale wrote: > > > > > Ashish, > > > > On 17/01/2012, at 1:19 PM, ashish verma wrote: > > > > > In our SRX deployment I am seeing an issue where client does not > receive > > a > > > ICMP message back after getting denied by the policy. > > > > > > I can see that packet got dropped by the policy and SRX generates the > > > tcp-rst but client does not receive anything. > > > > Can you confirm that your policy action is "reject" and not "deny"? > > Otherwise the traffic will be dropped silently. > > > > Cheers, > > > > Ben > > > > > ___ > 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] RPM MIB
Here is piece of perl script from my Cacti server that polls RPM data: my $jnxRpmResCalcAverage = '.1.3.6.1.4.1.2636.3.50.1.3.1.5'; my $jnxRpmResCalcPkToPk = '.1.3.6.1.4.1.2636.3.50.1.3.1.6'; This should give you an idea. Probe name is most probably encoded in OID. Nick On Wed, Mar 21, 2012 at 1:21 PM, Shiva S Narayana wrote: > Hi, Has anyone implemented RPM in juniper M/MX or J series routers ? I'm > trying to find a way to pollthe RPM probe results via SNMP. The problem is > that, the MIBs are proprietyto Juniper and the snmp mibwalk results doesn't > correlate probe-name if you have multiple probes. > > tested in junos 9.3R4. Any help is appreciated. > > Thanks > ___ > 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] EX-UM-2X4SFP- 2-port 10G SFP+ / 4-port 1G SFP Uplink Module
Mike, this is really interesting. I haven't noticed that you were talking about 3300. Sorry for answering the question you were not really asking :) Please share your findings with the list. If you discuss this topic with your SE, it is worth asking if EX3300 suffers from the same problem as EX3200 when ports ge-0/1/0-ge-0/1/3 were sharing resources with last 4 ports on the ge-0/0 PIC. I also wonder how it looks from the configuration point of view. Like, do you have interfaces ge-0/1/0 and xe-0/1/1 at the same time? thanks nick On Mon, Feb 27, 2012 at 8:39 PM, Mike Williams wrote: > That is certainly the way it is for the 3200 and 4200 > > http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/task/configuration/uplink-module-ex3200-ex4200-sfp-plus-mode-setting-cli.html > > However it seems the 3300 is a different beast, or at least that's what I > hope! > From the datasheet on > > http://www.juniper.net/us/en/products-services/switching/ex-series/ex3300/#literature > > " > Uplink > • Fixed 4-port uplinks which can be individually configured as GbE > (SFP) or 10GbE (SFP+) ports. > " > > I've yet to find documentation detailing exactly how you go about that > though. > > On Monday 27 February 2012 14:25:12 Nick Kritsky wrote: > > As far as I remember you have to explicitly select 10g or 1g mode on PIC > > level for EX uplink module. This automatically rules out any mixed mode > > setup. > > > > NK > > > > 2012/2/21 Timh Bergström > > > > > On Tue, Feb 21, 2012 at 12:03 PM, Mike Williams > > > > > > wrote: > > > > On Tuesday 21 February 2012 08:33:53 Jeff Wheeler wrote: > > > > > > > > The built in uplink ports in the EX3300. Do they support running 2 at > > > > > > 10Gb > > > > > > > (for VC) and 2 at 1Gb for regular ethernet? > > > > I'm sure I've seen it written that all four ports can be used at > 10Gb, > > > > > > if true > > > > > > > that would support my belief mixed mode operation is supported too. > > > > > > Afaik two of the four 10Gb ports are pre-configured for VC, the other > > > two can be used for ethernet out of the box, or you can use one for VC > > > and three for ethernet or the other way round, no problems (at least > > > that's what the juniper SE told me when I bought mine). > > > > -- > Mike Williams > Senior Infrastructure Architect > Comodo CA Ltd > Office Tel Europe: +44 (0) 161 8747070 > Fax Europe: +44 (0) 161 8771767 > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX-UM-2X4SFP- 2-port 10G SFP+ / 4-port 1G SFP Uplink Module
As far as I remember you have to explicitly select 10g or 1g mode on PIC level for EX uplink module. This automatically rules out any mixed mode setup. NK 2012/2/21 Timh Bergström > On Tue, Feb 21, 2012 at 12:03 PM, Mike Williams > wrote: > > On Tuesday 21 February 2012 08:33:53 Jeff Wheeler wrote: > > > > The built in uplink ports in the EX3300. Do they support running 2 at > 10Gb > > (for VC) and 2 at 1Gb for regular ethernet? > > I'm sure I've seen it written that all four ports can be used at 10Gb, > if true > > that would support my belief mixed mode operation is supported too. > > Afaik two of the four 10Gb ports are pre-configured for VC, the other > two can be used for ethernet out of the box, or you can use one for VC > and three for ethernet or the other way round, no problems (at least > that's what the juniper SE told me when I bought mine). > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [m10i] PIC-FPC throughput
Thanks, Peter, Jared, that's exactly what I needed to know. I have noticed the "oversubscribed 4:1" words in IQ2 description, but could not found explicit statement of how much traffic can this PIC handle. Vendors do not like to admit such drawbacks in their products :) best regards Nick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] [m10i] PIC-FPC throughput
Hi all, >From the Juniper documentation I know that there is a throughput limitation of 3.2 Gbps per FPC on m10i routers. Does it mean that there is 800Mbps limitation on each PIC inserted in PIC slot on given FPC? Or is it an aggregate limitation. To give you the real life example - should I be worried if total usage on 4 interfaces of ge-0/0/* wants to go over 1G, if the total usage of ge-0/*/* is still below 2G. If that matters, the PIC in question is IQ2. any help is very good. thanks Nick Kritsky ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] traffic load balancing between Juniper and Cisco equipment
Martin, Actually, taking closer look at the picture, i have this horrible idea which might be completely off-topic: why don't you forget about m10i and do all load-balancing between 3750 and 1820. Then you can even play around with EIGRP (oh blasphemy!) and it's un-equal load-balancing. It's always nice to have equipment from the same vendor on both sides of tricky setup. hope that helps nick On Mon, Aug 22, 2011 at 4:11 AM, Martin T wrote: > Is it possible to load-balance traffic between a Juniper M10i and > Cisco 1812 using two different last-mile(ADSL2+) providers? Topology > should be like this: > > http://img803.imageshack.us/img803/8766/loadb.png > > Idea is to use both ADSL2+ links simultaneously in order to achieve > better speed. In case on of the link fails, the traffic should use the > available ADSL2+ path. Is such load-balancing doable using the Juniper > PE router and Cisco CPE? If yes, what are the optimal/easiest > technologies to achieve the goals I described? > > > regards, > martin > ___ > 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] "ping: sendto: Operation not permitted" in LAN
"inconsistency"? I would say "gaping security hole". I wonder how many routers out there are setup to pass any IP packet with ACK bit turned on. Nick On Fri, Aug 19, 2011 at 5:50 PM, Stefan Fouant < sfou...@shortestpathfirst.net> wrote: > Hi Saku, > > 'tcp-established' or any of the other TCP bit-field match conditions do > assume an implied TCP, but they aren't actually checking to see if the > protocol is actually TCP. Therefore, they are simply looking for a bit to > be on or off at a specific offset where those fields would be if the packet > was actually TCP. > > What this means is that if the packet is anything other than TCP, and a > protocol match type of TCP is not specified, other packets may match if the > bit is set at that particular offset. > > This isn't really an "inconsistency" as you say and there are no real > useful applications here... This is why the Juniper documentation and other > literature is explicit to point out that you should always use a 'protocol > tcp' match when using these bit-field conditions... > > HTHs. > > Stefan Fouant > JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI > Technical Trainer, Juniper Networks > http://www.shortestpathfirst.net > http://www.twitter.com/sfouant > > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vrrp issue with ipv6
2 masters looks like split-brain to me. If two persons cannot agree on
something - chances are they cannot hear each other. Did you verify the
connectivity?
like running tcpdump on both MX and see if there is a difference?
On Wed, Aug 3, 2011 at 5:17 AM, Mehmet Akcin wrote:
> Hello,
>
> I am experiencing a weird issue on mx240 running version 10.4R4.5;
>
> I've 2 mxs connected to each other and vrrp is setup and these routers are
> connected to EX4200.
>
> for ipv4 all seems fine.
>
> for v6 i see both router1 and router2 as active master.
>
> r1
> ae0.110 up 0 backup Active D 3.020 lcl
>vip
>mas
> ae0.110 up 0 master Active A
>vip
>vip
> r2
> ae0.110 up 0 master Active A 0.597 lcl
>vip
> ae0.110 up 0 master Active A 0.088 lcl
>vip
>vip
>
>
> in logs of r1 all seems normal
>
> in r2 logs there is a weird
>
> ug 3 00:15:09 vrrp packet sent out on ifl 70 ver 1 group 0
> Aug 3 00:15:09 vrrp packet absorbed on ifl 70 ver 0 group 0
> Aug 3 00:15:09 vrrp packet absorbed on ifl 73 ver 0 group 0
> Aug 3 00:15:09 vrrp packet sent out on ifl 72 ver 1 group 0
> Aug 3 00:15:09 vrrp packet absorbed on ifl 71 ver 0 group 0
> Aug 3 00:15:09 vrrp packet absorbed on ifl 69 ver 0 group 0
> Aug 3 00:15:09 vrrp packet sent out on ifl 73 ver 1 group 0
>
>
> my re filters for v4
>
> term vrrp {
> from {
> interface-group 1;
> destination-address {
> 224.0.0.18/32;
> }
> }
> then accept;
> }
>
> my re filters for v6 is
>
> term allow-vrrp {
> from {
> next-header vrrp;
> }
> then accept;
>
>
>
> anyone has a clue what I am doing wrong here?
>
> mehmet
> ___
> 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
