What do see if you run show chassis hardware on the ex?
Also try show interface diagnostics optics ge-0/1/x to ensure you're receiving
signal.
Have you tried different combinations of negotiate on off between both switches?
Juniper gear generally accepts a lot more third party optics than you
I don't believe an EX VC fiber port will work in James' provider-offered
VPLS scenario for the reason that VPLS uses MAC learning to operation, and
I believe the VC-ports on the EX assume a directly connected VC port from
a neighboring EX. However, if the provider was offering him a pseudo wire
Awesome! Thanks Chuck
On 6/25/12 9:13 AM, Chuck Anderson c...@wpi.edu wrote:
On Mon, Jun 25, 2012 at 06:23:36AM +, Paul Zugnoni wrote:
It had its limitations, though:
* This was on 10.1. No ISSU available, so couldn't set a high SLA
* No SNMP polling was available then of the fiber
Two things:
1. The configuration for interfaces on your member 1 switch has been truncated.
Just make sure the config is actually there and similar to the ports you were
using to plug in for testing (i.e. that they are in the same vlan, etc. Do you
learn mac addresses on member 1 when the
FWIW, check that you don't have igmp-snooping enabled on the EX for the VLANs
where you have IS-IS traffic; it'll eat your Hello's. Having point-to-point
configured can obfuscate the cause of your original problem.
On Feb 24, 2012, at 13:55 , Kevin Wormington wrote:
Thanks to all that replied.
do
have a device connected that's configured with IGMP Querier. @Payam: We've also
seen ISIS hellos blocked by EX ports in an IGMP-snooping VLAN.
Paul Zugnoni
On Jan 12, 2012, at 16:58 , Payam Chychi wrote:
hey John,
i believe juniper filters out macs when igmp snooping is enabled on the vlan
to have a means of
detecting the make of the far-end device on a DAC cable connection and lock out
the port if the local and distal ends are both $sinister_vendor but the DAC
cable is from $other_vendor (and maybe already patented!).
Paul Zugnoni
On Jan 6, 2012, at 14:59 , Chuck Anderson wrote
remaining
front-of-chassis optical ports as configured inet or switched ports.
I've also had success forming a VC between EX4200s' SFP+ VCP ports through a
DWDM network over 30 miles away, though I wouldn't recommend this for a
permanent reliable solution.
Paul Zugnoni
On Jan 3, 2012, at 09:36
After upgrading from 10.1 to 10.4R1.9 on a set of our dual-RE2000 MX960's we
observed that the re1's fxp's were no longer IP-reachable. Console and session
to other-route-engine both work fine, as does GRES. Same behavior on multiple
dual-RE MXs. JTAC has confirmed the group config as OK, but
a backup-router configured in the re1 group?
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Zugnoni
Sent: Saturday, March 19, 2011 12:21 PM
To: juniper-nsp
Cc: Richard A Steenbergen
Subject: Re: [j-nsp] 10.0
Hope a 2-week later reply is still relevant for you:
I've had good experience with 10.0S1.1 and 10.1R3.7 in setups that include your
3 requirements below. As noted earlier in the thread, upgrades on a EX VC are
not hitless, so keep that in mind. The VC will not provide HA for a code
upgrade.
a 2821) terminates a bunch of lan-to-lan ipsec tunnels (VTI style) to 1841s
all over the place. box is completely VRFed, no global table, all the tunnels
land in the INTERNET vrf and pop out in customer vlans, each their own vrf.
10-30Mbit
One of the large drawbacks on SRX has been lack of
12 matches
Mail list logo
