Hi Aaron,
I'd say it is not relevant for ISSU. Different hw revisions might have
different chips or capacitors here or there , but functionally they should
be the same.
Regards,
Wojciech
śr., 23 sty 2019, 16:55: Aaron Gould napisał(a):
> Does ISSU require same *Rev* of RE ?
>
>
>
> ...and is
On 1/22/19 11:18 AM, Martin T wrote:
Hi,
how does Junos choose the source address for RE generated traffic
addresses to direct neighbors if the application(for example ping
utility) does not bind to specific address? Does it choose the first
address configured on the egress interface which
> On Jan 23, 2019, at 10:23 AM, Saku Ytti wrote:
>
> On Wed, 23 Jan 2019 at 17:01, Jason Lixfeld wrote:
>
>> Now that I’m looking at the right box, yes! More importantly, on et-0/0/2 @
>> mx1:
>>
>> Input errors:
>>Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards:
Does ISSU require same *Rev* of RE ?
...and is there any reason why I would NOT want to run different Rev of RE
in my MX960 ?
Is it ok to run different rev of RE ? I have REV 17 as RE0 and REV 15 as
RE1. Is this ok?
root> show chassis hardware models | grep Routing
Routing Engine 0
A few elements:
EX2300: Broadcom instead of Marvel, CPU and memory are now decent (no more slow
commits). Fans seem to be just a little more noisy than the 2200.
- Worse (compared to EX2200): no VRF ; Virtual-Chassis now needs a licence
(honour based) ; less space for ACL/firewall-filters
On Wed, 23 Jan 2019 at 17:01, Jason Lixfeld wrote:
> Now that I’m looking at the right box, yes! More importantly, on et-0/0/2 @
> mx1:
>
> Input errors:
> Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0, L3
> incompletes: 0, L2 channel errors: 0, L2 mismatch
Anyone used ex2300 switches? Curious if they are as painfully slow as the
2200 for commits? Any other feedback? Do they seem to be noisy or quiet?
Any issues with them?
Thanks
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
This is somewhat embarrassing. I was looking at the wrong side of the test when
I initially observed the issue and I didn’t clue into that till now, so some of
the previous claims are false.
Just for completeness, here’s the actual test topology:
[ Tx Tester ] - et-0/0/2 - [ mx1 ] - et-0/0/0 -
As per the requestor original message, I read that the packets are not
counted on INGRESS
There is a diff between received packets and the receive counter
Regards
alexander
-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Saku Ytti
On Tue, 22 Jan 2019 at 20:17, Jason Lixfeld wrote:
> Transmitting exactly 100 million 64 byte UDP packets. SPORT: 49184 DPORT: 7.
Ok so ingress interface shows 100M packets coming in, but egress
interface shows only 76M packets going out?
And nothing in 'show int egress extensive'?
What
> On Jan 22, 2019, at 4:06 PM, Olivier Benghozi
> wrote:
>
> My 2 cents: it could be interesting to check if running the system in
> hyper-mode makes a difference (that should normally be expected).
Same results after enabling hyper-mode
___
Hey,
> On Jan 22, 2019, at 2:42 PM, adamv0...@netconsultings.com wrote:
>
> Maybe any of the show commands in the below, if they show any drops?
> https://kb.juniper.net/InfoCenter/index?page=content=KB26519=FIREWALL=LIST
>
>
Look at default-address-selection option description:
https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/junos-software-system-management-source-address-local-tcp-ip-packets-configuring.html
For IPv4: If this option is not enabled, and destination is directly
connected
On Thu, 17 Jan 2019 at 18:09, Saku Ytti wrote:
> It boggles my mind which network has _common case_ where
> bandwidth is most indicative of best SPT.
Hi Saku,
I've worked on several small networks where you don't have equal
bandwidth links in the network. I don't mean U/ECMP, I mean a ring
On Wed, 16 Jan 2019 at 15:06, Event Script wrote:
>
> In the process of adding 100G, LAGs with multiple 100G, and to be prepared
> for 400G, looking for feedback on setting ospf reference-bandwidth to 1T.
>
> Please let me know if you have had any issues with this, or if it has been
> a smooth
On Mon, 21 Jan 2019 at 20:09, Jason Lixfeld wrote:
>
> Hi all,
>
> I’m doing some RFC2544 tests through an MX204. The tester is connected to
> et-0/0/2, and the test destination is somewhere out there via et-0/0/0. 64
> byte packets seem to be getting dropped, and I’m trying to find where on
16 matches
Mail list logo
