Re: [j-nsp] EX 8200 deployment
I really appreciate all for their inputs. Thanks a lot.
Is there any caveat in RTG, Can we easily get rid of STP running?? do you
recommend it or not??
Is there any special socket required for powering this chassis up?? as we
need industrial sockets in case of Cisco 6500.
regards,
Muhammad Fahad Khan
JNCIP - M/T # 834
IT Specialist
Global Technology Services, IBM
fa...@pk.ibm.com
+92-321-2370510
+92-301-8247638
Skype: fahad-ibm
http://www.linkedin.com/in/muhammadfahadkhan
http://fahad-internetworker.blogspot.com
http://www.visualcv.com/g46ptnd
On Tue, Mar 23, 2010 at 4:16 AM, Richard A Steenbergen r...@e-gerbil.netwrote:
On Mon, Mar 22, 2010 at 11:35:19PM +0300, Alexandre Snarskii wrote:
EX-series (at least [34]200) has the same local vlan significance
principle that applies, for example, to OSM-equipped 6500/Sup2:
you can create chassis-wide vlan, and it will be used on all LAN
cards, but you still can reuse the same vlan id on OSM subinterface,
and the idea is actually stolen from some old recipe on how to run
6500/sup2 Vlan as a part of VRF.
In case of ex-series it's even better - there are no 'internal vlan'
allocation that happens in case of 65xx/76xx.
That is indeed a fair bit better than the 6500/7600 vlan model, I guess
EX's vlan support isn't quite as bad as I thought. I swear I tested this
on EX4200 when we first got one (2 years ago) and I have a very strong
memory of this behavior not working this way, but damned if I can find
the emails with the test results to prove it.
On 6500, when you do something like this:
interface TenGigabitEthernet1/1.101
encapsulation dot1Q 101
ip address 1.2.3.4 255.255.255.0
It simply creates vlan 101 as an internal vlan, which consumes vlan 101
across the entire chassis and blocks the creation of another vlan 101
anywhere else. Of course if you didn't do a subinterface but simply
slapped an IP directly on the physical interface, it would simply pick a
pseudo-random vlan ID to use, like so:
crisco6509#sh vlan internal usage
VLAN Usage
901 TenGigabitEthernet8/2.901
910 TenGigabitEthernet4/2.910
1606 TenGigabitEthernet8/2.1606
2201 TenGigabitEthernet8/2.2201
4032 TenGigabitEthernet3/4
4033 TenGigabitEthernet3/3
4034 TenGigabitEthernet3/2
4035 TenGigabitEthernet3/1
...
So... I'm wondering how much of this counter issue is really a hardware
limitation, and how much is just design limitation. For example, would
it be possible for Juniper to implement ethernet switching as
essentially a multi-port ccc, like so:
interfaces {
xe-1/0/0 {
vlan-tagging;
unit 101 {
family inet {
address 1.2.3.1/24;
}
}
unit 201 {
vlan-id 201;
family ethernet-switching;
}
}
xe-2/0/0 {
vlan-tagging;
unit 101 {
family inet {
address 2.3.4.1/24;
}
}
unit 201 {
vlan-id 201;
family ethernet-switching;
}
}
}
vlans {
blah {
interface {
xe-1/0/0.201;
xe-2/0/0.201;
}
}
}
To me this seems like a much more natural way of handling mixed L2 and
L3 configs on a single port anyways, and it could potentially let you
have everything on a port which could be properly counted. Extra bonus
points if there was a way to strip the vlan tag before putting it into
the multi-port ccc so you could do vlan translation, but I don't know
if that is possible in hardware (there is certainly no input-vlan-map to
pop the vlan like on MX/etc, but this will be a problem when they get
around to implementing mpls l2circuits).
The funny thing about the above configuration is that it doesn't seem to
be complaining about the lack of a vlan-id under vlan blah, only about
the mixing vlan-tagging and family ethernet-switching. :)
Now say I took the above scenario and made it:
vlans {
blah {
interface {
xe-1/0/0.201;
xe-2/0/0.201;
...
}
l3-interface vlan.201;
}
}
Today they don't have working counters on vlan.201, and Juniper claims
it is a hardware limitation they can't solve without some hackery like
firewall filter counters applied to each interface, but... If I can get
xe-1/0/0.101 counters today, could I also get xe-1/0/0.201 counters in
the above configuration? Possibly those could be added up internally to
make a virtual vlan.201 counter, but worst case I could definitely do
the additionl on my side post-SNMP collection.
--
Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 8200 deployment
Tore Anderson wrote: * Richard A Steenbergen Correct. I actually found some old gripes about this when I searched j-nsp after noticing the problem, but it is a big enough issue that I think it needs to be repeated again (and again and again, until it gets fixed :P). I'll be happy to join the choir on this one. I reported the problem back in March 2009, got PR 435648 opened, but haven't heard anything more since then. My workaround is to terminate the customer VLANs that needs counters for accounting purposes on the EX-es' upstream routers instead, which are MX-es with standard vlan-tagged family inet sub-interfaces. That works well enough but it's not as tidy as I would have preferred. Best regards, chiming in here - we need to do the same, and we also ended up terminating L3 on our MXes when we'd really want to do it on the 8200s, yet the stupid messed up RVI counters don't allow us to do so. Oh, there's more, btw. You can't do vlan members [ 2-2999 ] on a trunk port if you don't use ALL of those vlans. It won't commit, which means you have to use vlan members all, which in turn messes up your one-interface-RVIs (that you have to use because you need to trunk some vlans on that port in addition to the family inet RVI)... gah. Promising boxes, but they really messed up some points by looking to closely at how vendors B C are doing it. That being said, we do use them in the data center, but they'd better get around fixing these things. Kind regards, Felix -- Felix Schüren Head of Network --- Host Europe GmbH - http://www.hosteurope.de Welserstraße 14 - 51149 Köln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678 Geschäftsführer: Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller (*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt. Mobilfunknetzen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX deployment / issues
Means UTM has issues as well ?? How about the support of multicast ?? Has any one experienced running any multicast based application across this Firewall?? regards Muhammad Fahad Khan JNCIP - M/T # 834 IT Specialist Global Technology Services, IBM fa...@pk.ibm.com +92-321-2370510 +92-301-8247638 Skype: fahad-ibm http://www.linkedin.com/in/muhammadfahadkhan http://fahad-internetworker.blogspot.com http://www.visualcv.com/g46ptnd On Tue, Mar 23, 2010 at 2:16 PM, Cian Brennan cian.bren...@redbrick.dcu.iewrote: On Mon, Mar 22, 2010 at 10:05:46AM -0700, Hoogen wrote: I think the EX thread was really good and the feedback was awesome. I would like hear about similar experiences while deploying SRX Series gateways, I am assuming I would hear a lot on the branch boxes SRX 210,240,650 I would also love to hear feedback on SRX 3000/5000 if people have been using it in their setup, problems that their facing, improvements and general deployment scenario that have been used. We've had rather a lot of difficulty with the URL filtering/Virus scanning causing crashes on the 210. And with the URL filtering failing to recover if the websense server went down on the same platform. -Hoogen ___ 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] SRX deployment / issues
I've had some serious issues with both my SRX 210 and 2x240s. The SRX210 I have here at home was having all kinds of issues reconnecting if there was an ADSL drop. A restart routing command would fix this. This issue seems to have been mostly fixed in 10.0R2 and 10.1R1. The pair of SRX240s on the other hand are still having issues. I recently setup a cluster with 10.1R1 which was all working fine in the lab, but after 10 ours of production all traffic simply stopped. I've logged into the devices via the console and cannot find any errors. No idea what is going on here. Not to mention the issues with ethernet switching and clustering... Oh and no support for packet based traffic in clusters, so no IPv6 at all. The older SSG line will have to keep me going until juniper fix some of these issues! Michael. - Original Message - From: Hoogen [mailto:hooge...@gmail.com] To: juniper-nsp@puck.nether.net Sent: Tue, 23 Mar 2010 04:05:46 +1100 Subject: [j-nsp] SRX deployment / issues I think the EX thread was really good and the feedback was awesome. I would like hear about similar experiences while deploying SRX Series gateways, I am assuming I would hear a lot on the branch boxes SRX 210,240,650 I would also love to hear feedback on SRX 3000/5000 if people have been using it in their setup, problems that their facing, improvements and general deployment scenario that have been used. -Hoogen ___ 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] Speed/Duplex Issue
Hi folks... We just cut in another couple of EX4200's into production overnight. These are the first deployments that don't have pure GigE ports - several ports 100/full. When I did the configuration I set the ether-options for 100/full ... most of the ports are facing Cisco switches. All the ports that were hard coded would not come up at all - the minute I removed the ether-options they came up and appear to be ok. Is this normal? Also, I'm wondering how you verify what duplex the port is running at? Sorry for basic question but for the life of me I can't find this in the output or the docs...;) Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX deployment / issues
I know there was/is an issue on the older code versions of sessions being built with the incorrect time out (if I recall correctly it was 48 hours). It's easy to see though all one would have to do is look at a type of session that you know would have a short duration time (such as ICMP or UDP) and if you see a extremely large number then you've got an issue. In the past on the netscreen platform I've seen various issues with the NATAGER process (the process responsible for session table clean up) but so far at least in my experience I haven't ran into an like that on the SRX platform. -Tim Eberhard On Tue, Mar 23, 2010 at 7:21 AM, Fahad Khan fahad.k...@gmail.com wrote: Seems to be looking some thing wrong with session table?? any one faced same thing with SRX650?? regards, Muhammad Fahad Khan JNCIP - M/T # 834 IT Specialist Global Technology Services, IBM fa...@pk.ibm.com +92-321-2370510 +92-301-8247638 Skype: fahad-ibm http://www.linkedin.com/in/muhammadfahadkhan http://fahad-internetworker.blogspot.com http://www.visualcv.com/g46ptnd On Tue, Mar 23, 2010 at 5:10 PM, Michael Dale md...@dalegroup.net wrote: I've had some serious issues with both my SRX 210 and 2x240s. The SRX210 I have here at home was having all kinds of issues reconnecting if there was an ADSL drop. A restart routing command would fix this. This issue seems to have been mostly fixed in 10.0R2 and 10.1R1. The pair of SRX240s on the other hand are still having issues. I recently setup a cluster with 10.1R1 which was all working fine in the lab, but after 10 ours of production all traffic simply stopped. I've logged into the devices via the console and cannot find any errors. No idea what is going on here. Not to mention the issues with ethernet switching and clustering... Oh and no support for packet based traffic in clusters, so no IPv6 at all. The older SSG line will have to keep me going until juniper fix some of these issues! Michael. - Original Message - From: Hoogen [mailto:hooge...@gmail.com] To: juniper-nsp@puck.nether.net Sent: Tue, 23 Mar 2010 04:05:46 +1100 Subject: [j-nsp] SRX deployment / issues I think the EX thread was really good and the feedback was awesome. I would like hear about similar experiences while deploying SRX Series gateways, I am assuming I would hear a lot on the branch boxes SRX 210,240,650 I would also love to hear feedback on SRX 3000/5000 if people have been using it in their setup, problems that their facing, improvements and general deployment scenario that have been used. -Hoogen ___ 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
[j-nsp] BPDU Question
Hi folks .. thanks to those who replied offline to my last question (speed/duplex) - the answer was sitting right in front of me the whole time lol I have a new problem ... with our EX4200's we face many customer switches and I need to filter BPDU's out. In the Cisco world we would setup a port just like this: interface GigabitEthernet3/2 description xxx switchport switchport access vlan 66 switchport mode access switchport nonegotiate no ip address no cdp enable no mop enabled spanning-tree bpdufilter enable What is the equivalent to this in Juniper? I tried setting up bpdu protect one some interfaces but when it does see a BPDU packet it shuts the port down - we can't have that occur ... we just want to filter out BPDU's... Thanks ;) Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BPDU Question
What is the answer? :) --Original Message-- From: Paul Stewart Sender: juniper-nsp-boun...@puck.nether.net To: juniper-nsp@puck.nether.net Subject: [j-nsp] BPDU Question Sent: Mar 23, 2010 10:21 AM Hi folks .. thanks to those who replied offline to my last question (speed/duplex) - the answer was sitting right in front of me the whole time lol I have a new problem ... with our EX4200's we face many customer switches and I need to filter BPDU's out. In the Cisco world we would setup a port just like this: interface GigabitEthernet3/2 description xxx switchport switchport access vlan 66 switchport mode access switchport nonegotiate no ip address no cdp enable no mop enabled spanning-tree bpdufilter enable What is the equivalent to this in Juniper? I tried setting up bpdu protect one some interfaces but when it does see a BPDU packet it shuts the port down - we can't have that occur ... we just want to filter out BPDU's... Thanks ;) Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Sent via BlackBerry by ATT ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BPDU Question
Hi Paul,
We've faced the same problem in the past and we created a firewall filter which
does what you want:
{master:0}[edit firewall family ethernet-switching filter BPDU_FILTER]
term 1 {
from {
destination-mac-address {
01:80:c2:00:00:00;
}
}
then {
discard;
count BPDU_FILTER;
}
}
term 2 {
then accept;
}
This is applied to the interface input filter.
Additionally, we disable the port in MSTP like 'prototocols mstp interface XXX
disable' so it does not send BPDU's to the customer.
I think with the newer JunOS versions there might be a better/smarter option
though.. :)
Regards,
Niels
-Oorspronkelijk bericht-
Van: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] Namens Paul Stewart
Verzonden: dinsdag 23 maart 2010 15:21
Aan: juniper-nsp@puck.nether.net
Onderwerp: [j-nsp] BPDU Question
Hi folks .. thanks to those who replied offline to my last question
(speed/duplex) - the answer was sitting right in front of me the whole time
lol
I have a new problem ... with our EX4200's we face many customer switches
and I need to filter BPDU's out. In the Cisco world we would setup a port
just like this:
interface GigabitEthernet3/2
description xxx
switchport
switchport access vlan 66
switchport mode access
switchport nonegotiate
no ip address
no cdp enable
no mop enabled
spanning-tree bpdufilter enable
What is the equivalent to this in Juniper? I tried setting up bpdu
protect one some interfaces but when it does see a BPDU packet it shuts the
port down - we can't have that occur ... we just want to filter out
BPDU's...
Thanks ;)
Paul
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Tenzij schriftelijk anders is overeengekomen, zijn op al onze
rechtsbetrekkingen de Algemene Voorwaarden van Intermax van toepassing. Deze
zijn middels deze directe link
http://www.intermax.nl/algemenevoorwaardenintermax.pdf in te zien en/of kunnen
op verzoek worden toegezonden. Toepasselijkheid van eventuele inkoop- of andere
voorwaarden van opdrachtgever dan wel van derden wordt dan ook uitdrukkelijk
van de hand gewezen. Nederlands recht is exclusief van toepassing.
De informatie verzonden met dit E-mail bericht is uitsluitend bestemd voor de
geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is
verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking
van deze informatie aan derden is niet toegestaan. Intermax staat niet in voor
de juiste en volledige overbrenging van de inhoud van een verzonden E-mail,
noch voor tijdige ontvangst daarvan.
Please consider the environment before printing this e-mail.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Low power warning
Hi, I am running into these errors on a virtual-chassis with 2 EX4200's: Mar 22 16:14:20 chas[796]: link 1 SFP receive power low warning set Mar 22 16:14:40 chas[796]: link 1 SFP receive power low warning cleared Does anyone know how I can link this to the interface these messages come from? It doesn't seem to appear anywhere in the logfiles. Regards, Wouter ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Low power warning
On Tue, Mar 23, 2010 at 03:48:21PM +0100, Wouter van den Bergh wrote: Mar 22 16:14:20 chas[796]: link 1 SFP receive power low warning set Mar 22 16:14:40 chas[796]: link 1 SFP receive power low warning cleared Does anyone know how I can link this to the interface these messages come from? It doesn't seem to appear anywhere in the logfiles. try: show interfaces diagnostics optics ge-x/y/z where x/y/z is where you have SFP interfaces, and look for low values in the Receiver signal average optical power field. Unfortunately, you can't run the command without specifying each specific interface, one at a time--oh wait! That now works in 10.1R1! show interfaces diagnostics optics shows output for each of the interfaces that has DOM capabilities. Not sure when they enhanced that, but it didn't do that in 9.5R2. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 firewall only filters on physical ingress/egress?
JTAC have confirmed that the port has to be crossed to have the filter come into effect. Hence why L2 vlan filters (VACLs) have their input/output meaning reversed. Not sure if my previous email makes sense, but thought I would update here anyway. Regards, C. On Thu, Mar 11, 2010 at 01:25:27AM +, Charlie Allom wrote: Hello, has anyone come up against this with the EX4200's? That a firewall filter will only affect a packet traversing a physical interface.. ==trunk==[port A] (RVI A)..(RVI B) [port B]--access-- ^ filter applied here | I was expecting the filter on 'input' on RVI B to block traffic, but it only works entirely when you filter on its 'output'. Else the host behind [port B] gets the SYN, SYNACKs back, and /then/ it is blocked by the ethernet-switching or inet filter. The docs don't mention this, except they never give an example of filtering on an RVI, just physical routed interfaces. But they DO say you can do it.. page 1368 of the Software Guide for EX Series Ethernet Switches, Release 10.0. What gives? (I have a case open with JTAC but it's hopeless trying to convince them to grasp and replicate, so far) C. -- 020 7729 4797 http://blog.playlouder.com/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- 020 7729 4797 http://blog.playlouder.com/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 8200 deployment
On Mon, Mar 22, 2010 at 02:16:36PM -0500, Richard A Steenbergen wrote:
protocols {
connections {
interface-switch test {
interface xe-1/0/0.101;
interface xe-1/0/1.101;
}
}
}
Well for everyone woh asked, I tried the following on an EX8208 under
10.1R1, and it didn't work:
interfaces {
ae0 {
vlan-tagging;
mtu 9216;
...
unit 69 {
vlan-id 69;
family ccc;
}
}
ae2 {
vlan-tagging;
mtu 9216;
...
unit 69 {
vlan-id 69;
family ccc;
}
}
}
protocols {
connections {
interface-switch test {
interface ae0.69;
interface ae2.69;
}
}
}
Which of course errors because MPLS is still required to use CCC (who
knows why that has never been fixed :P):
r...@router# commit check
re1:
[edit protocols connections]
'interface-switch test'
CCC: Connection test error MPLS must be enabled to use CCC
error: configuration check-out failed
So turn on something in protocol MPLS to shut it up, which of course
turns on the log-filling no license nag (even though I do have an
advanced feature license, and the documentation says MPLS is included in
the AFL, go figure):
Mar 23 18:27:42.298 re1.router alarmd[734]: %DAEMON-4: Alarm cleared:
License color=YELLOW, class=CHASSIS, reason=Multi Protocol Label
Switching usage requires a license
And now the ccc looks like it should be up:
Connection/CircuitTypeSt Time last up # Up
trans
test if-sw Up Mar 23 18:18:55
1
ae0.69intf Up
ae2.69intf Up
# Paths
Time EventInterface/LabelRcv Xmt
Mar 23 18:18:56 CCC status update
Mar 23 18:18:55 Interface up ae2.69
Mar 23 18:18:55 Interface up ae0.69
Mar 23 18:18:55 CCC status update
Mar 23 18:18:55 Interface up ae2.69
Mar 23 18:18:55 Interface up ae0.69
But no packets are passed through it, and the interface counters for
both sides show 0 packets received. Of course the correct way to
configure this on every other platform would be vlan-ccc rather than
just ccc, but on EX there is no vlan-ccc option and the ccc config
commits without error.
--
Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Low power warning
On Tue, Mar 23, 2010 at 11:27:22AM -0400, Chuck Anderson wrote: On Tue, Mar 23, 2010 at 03:48:21PM +0100, Wouter van den Bergh wrote: Mar 22 16:14:20 chas[796]: link 1 SFP receive power low warning set Mar 22 16:14:40 chas[796]: link 1 SFP receive power low warning cleared Does anyone know how I can link this to the interface these messages come from? It doesn't seem to appear anywhere in the logfiles. try: show interfaces diagnostics optics ge-x/y/z where x/y/z is where you have SFP interfaces, and look for low values in the Receiver signal average optical power field. Unfortunately, you can't run the command without specifying each specific interface, one at a time--oh wait! That now works in 10.1R1! show interfaces diagnostics optics shows output for each of the interfaces that has DOM capabilities. Not sure when they enhanced that, but it didn't do that in 9.5R2. Hrm... The lack of ability to do show interfaces diagnostic optics and see all interfaces has been on my bitch-list for the last 3+ years. I had just given up hope that they were ever going to do anything to fix it (or support the reverse order show interface xe-0/0/0 diagnostics optics for that matter), so I had stopped even checking... But after reading this email I just went back and checked a bunch of boxes, and it actually IS working on MX on every version of code we're running (9.4R3 being the oldest). Guess they slipped it in when we weren't looking. I also just checked our lab EX4200 for the accuracy of the DOM readings (currently running 10.1R1), and the news there is... less good. Both of the interfaces are perfectly good working LR XFPs that work just fine in MX: Physical interface: xe-0/1/0 Laser bias current: 35.138 mA Laser output power: 0.5540 mW / -2.56 dBm Module temperature: 32 degrees C / 90 degrees F Laser rx power: 0.5460 mW / -2.63 dBm ... Laser output power high alarm : Off Laser output power low alarm : On Laser output power high warning : Off Laser output power low warning: On ... Tx data not ready alarm : Off Tx not ready alarm: Off Tx laser fault alarm : Off Tx CDR loss of lock alarm : On Rx not ready alarm: On Rx loss of signal alarm : On Rx CDR loss of lock alarm : On Apparently my transmit power of -2.56dBm (perfectly normal and in spec) is setting off the low power alarm low, and even though I have link and am passing packets, I have complete loss of signal too. The next one is even worse: Physical interface: xe-0/1/1 Laser bias current: 42.375 mA Laser output power: 0.4670 mW / -3.31 dBm Module temperature: 37 degrees C / 99 degrees F Laser rx power: 0.0016 mW / -27.96 dBm -27.96dBm is absurdly out of spec for LR, there is no possible way this link could be up if it was within even 10dB of being that low. But that is still better than our EX8200 DOM under 10.1R1: Physical interface: xe-0/0/0 Laser bias current: 0.000 mA Laser output power: 0. Module temperature: 0 degrees C / 32 degrees F Module voltage: 0. V Receiver signal average optical power : 0. etc etc etc all 0's for everything... -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS 9.6R3.8 on MX
On Mon, Mar 15, 2010 at 02:21:57PM -0400, Eric Van Tol wrote: Hi all, Any experiences with 9.6R3.8 on MX? I have 9.5R4.3 installed on some newly acquired MX boxes, per the advice of this list. However, I Oh btw, a word a warning about 9.5R4 after everyone has hyped it up on this list as the most stable code available for MX. I recently discovered a nasty little bug where having bgp accept-remote-nexthop turned on causes rpd to crash if the interface your eBGP neighbor is connected to flaps (PR 500062). Unfortunately Juniper is refusing to build a fix for 9.5 because 9.5 has reached the end of engineering support. The funny part is that technically 9.5 reached the end of engineering support (on 2/15/2010), 4 days before 9.5R4 was even released (on 2/19/2010). I guess technically that means 9.5R4 was never supported at all. Great job guys, really. :) FYI as a workaround turning off accept-remote-nexthop keeps rpd from crashing (oh and btw when it does crash, it somehow wipes out a bunch of directly connected interface routes from the krt in the process, requiring you to manually remove and re-add the interface configs to restore normal routing on them). -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Speed/Duplex Issue
On Tuesday 23 March 2010 08:50:01 pm Paul Stewart wrote: When I did the configuration I set the ether-options for 100/full ... most of the ports are facing Cisco switches. All the ports that were hard coded would not come up at all - the minute I removed the ether-options they came up and appear to be ok. Did you hard-code the speed/duplex setting on both the Juniper and Cisco switches, or just the Juniper's? We've been happy with auto-nego'ing all connections, including with upstreams. Life has been much easier going that route. I can't remember the last time anything good came out of hard-coding these settings, or when we last did that, for that matter. Is this normal? Also, I'm wondering how you verify what duplex the port is running at? Sorry for basic question but for the life of me I can't find this in the output or the docs...;) [edit] t...@lab# run show interfaces ge-0/1/3 | match Duplex Link-level type: Ethernet, MTU: 9014, Speed: 1000mbps, Duplex: Full-Duplex, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled [edit] t...@lab# The above is taken off an EX3200. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
