Re: [j-nsp] ACX50xx l2circuit counters

[Aaron]

Sounds great.  Sharing is good.

 

Do you know status of either of these with ACX5048 ?  MC-LAG and basic Virtual 
Chassis ?

 

Also, yes Nathan I think I see that snmp firewall thing… thanks…  I run both 
D20 and D50 in my lab….

 

agould@eng-lab-5048-1> show version

fpc0:

--

Hostname: eng-lab-5048-1

Model: acx5048

Junos: 15.1X54-D20.7

 

agould@eng-lab-5048-1> show snmp mib walk .1 | grep jnxFW

 

{master:0}

agould@eng-lab-5048-1>

 

{master:0}

agould@eng-lab-5048-1> show snmp mib get ascii 
jnxFWCounterByteCount.12.112.114.111.116.101.99.116.45.53.48.52.56.20.112.114.111.116.101.99.116.45.53.48.52.56.45.99.111.117.110.116.101.114.2

jnxFWCounterByteCount."protect-5048"."protect-5048-counter".2 No such instance

 

{master:0}

agould@eng-lab-5048-1> show snmp mib get 
jnxFWCounterByteCount.12.112.114.111.116.101.99.116.45.53.48.52.56.20.112.114.111.116.101.99.116.45.53.48.52.56.45.99.111.117.110.116.101.114.2

jnxFWCounterByteCount.12.112.114.111.116.101.99.116.45.53.48.52.56.20.112.114.111.116.101.99.116.45.53.48.52.56.45.99.111.117.110.116.101.114.2
 No such instance


*

 

{master:0}

agould@eng-lab-5048-2> show version

fpc0:

--

Hostname: eng-lab-5048-2

Model: acx5048

Junos: 15.1X54-D50.13

 

 

{master:0}

agould@eng-lab-5048-2> show snmp mib get ascii 
jnxFWCounterByteCount.12.112.114.111.116.101.99.116.45.53.48.52.56.20.112.114.111.116.101.99.116.45.53.48.52.56.45.99.111.117.110.116.101.114.2

jnxFWCounterByteCount."protect-5048"."protect-5048-counter".2 = 581646

 

{master:0}

agould@eng-lab-5048-2>

 

{master:0}

agould@eng-lab-5048-2> show snmp mib get 
jnxFWCounterByteCount.12.112.114.111.116.101.99.116.45.53.48.52.56.20.112.114.111.116.101.99.116.45.53.48.52.56.45.99.111.117.110.116.101.114.2

jnxFWCounterByteCount.12.112.114.111.116.101.99.116.45.53.48.52.56.20.112.114.111.116.101.99.116.45.53.48.52.56.45.99.111.117.110.116.101.114.2
 = 581646

 

{master:0}

agould@eng-lab-5048-2>

 

{master:0}

agould@eng-lab-5048-2> show firewall

 

Filter: protect-5048

Counters:

NameBytes  Packets

protect-5048-counter   581646 7480

 

 

 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Giuliano Medalha]

Very good !!!

Giuliano Cardozo Medalha
Systems Engineer
+55 (17) 3011-3811
+55 (17) 98112-5394
JUNIPER J-PARTNER ELITE
giuli...@wztech.com.br
http://www.wztech.com.br/



​
WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2016 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos  eventuais  documentos anexos
são confidenciais e para conhecimento exclusivo do destinatário. Se o
leitor  desta  mensagem  não  for o seu destinatário,
fica desde já notificado de que não poderá  divulgar,  distribuir ou, sob
qualquer forma, dar conhecimento a terceiros das informações e do conteúdo
dos documentos anexos. Neste caso, favor comunicar imediatamente
o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida
apague-o.


CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are
solely for the intended recipient and may contain confidential or
privileged information. If you are not the intended recipient, any review,
transmission,  dissemination or other use of this information is
prohibited. If you have received this communication in error, please notify
the sender immediately and delete the material from any computer, including
any copies.

On Tue, Jun 21, 2016 at 3:29 PM, Aaron  wrote:

> So far my acx5048's are working nicely... I just swung a dual 10 gig
> connected Cisco uBR10K with 4,000+ cable modem subscribers behind a pair of
> my acx5048's...  been running nice for a few weeks now... pumping
> multi-gigabits of traffic through there during peak time
>
> - Aaron
>
>
> ___
> 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] ACX50xx l2circuit counters

[Aaron]

So far my acx5048's are working nicely... I just swung a dual 10 gig
connected Cisco uBR10K with 4,000+ cable modem subscribers behind a pair of
my acx5048's...  been running nice for a few weeks now... pumping
multi-gigabits of traffic through there during peak time

- Aaron


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Giuliano Medalha]

Good !!!

Lets share here on this list any new details about configuration, ok ?

Are you using D50 version ?  It is pretty stable right now to us.

But we are asking for the development a lot of new features and they are
listening to us.

Thanks a lot,

Att,

Giuliano

Giuliano Cardozo Medalha
Systems Engineer
+55 (17) 3011-3811
+55 (17) 98112-5394
JUNIPER J-PARTNER ELITE
giuli...@wztech.com.br
http://www.wztech.com.br/



​
WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2016 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos  eventuais  documentos anexos
são confidenciais e para conhecimento exclusivo do destinatário. Se o
leitor  desta  mensagem  não  for o seu destinatário,
fica desde já notificado de que não poderá  divulgar,  distribuir ou, sob
qualquer forma, dar conhecimento a terceiros das informações e do conteúdo
dos documentos anexos. Neste caso, favor comunicar imediatamente
o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida
apague-o.


CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are
solely for the intended recipient and may contain confidential or
privileged information. If you are not the intended recipient, any review,
transmission,  dissemination or other use of this information is
prohibited. If you have received this communication in error, please notify
the sender immediately and delete the material from any computer, including
any copies.

On Tue, Jun 21, 2016 at 3:24 PM, Aaron <aar...@gvtc.com> wrote:

>
>
> Hey , that worked , thanks !  seems that I have to do it at the unit
> level, I didn’t see that I could do it on the phy int level.
>
>
>
> {master:0}
>
> agould@blcn-h-5048> show interfaces ge-0/0/36 | grep pack
>
> Input packets : 33
>
> Output packets: 0
>
>
>
> {master:0}
>
> agould@blcn-h-5048> show interfaces ge-0/0/36 | grep pack
>
> Input packets : 33
>
> Output packets: 0
>
>
>
> {master:0}
>
> agould@blcn-h-5048> show interfaces ge-0/0/36 | grep pack
>
> Input packets : 33
>
> Output packets: 0
>
>
>
> {master:0}
>
> agould@blcn-h-5048> show interfaces ge-0/0/36 | grep pack
>
> Input packets : 33
>
> Output packets: 0
>
>
>
> {master:0}
>
> agould@blcn-h-5048> show interfaces ge-0/0/36 | grep pack
>
> Input packets : 33
>
> Output packets: 0
>
>
>
> {master:0}
>
> agould@blcn-h-5048> configure
>
> Entering configuration mode
>
>
>
> {master:0}[edit]
>
> agould@blcn-h-5048# set interfaces ge-0/0/36 unit 0 statistics
>
>
>
> {master:0}[edit]
>
> agould@blcn-h-5048# commit
>
> configuration check succeeds
>
> commit complete
>
>
>
> {master:0}[edit]
>
> agould@blcn-h-5048# exit
>
> Exiting configuration mode
>
>
>
> {master:0}
>
> agould@blcn-h-5048> show interfaces ge-0/0/36.0 | grep pack
>
> Input packets : 18232
>
> Output packets: 2
>
>
>
> {master:0}
>
> agould@blcn-h-5048> show interfaces ge-0/0/36.0 | grep pack
>
>     Input packets : 20857
>
> Output packets: 2
>
>
>
>
>
>
>
>
>
>
>
> *From:* Giuliano Medalha [mailto:giuli...@wztech.com.br]
> *Sent:* Monday, June 20, 2016 4:40 PM
> *To:* Aaron <aar...@gvtc.com>
> *Cc:* Nathan Ward <juniper-...@daork.net>; jnsp list <
> juniper-nsp@puck.nether.net>
> *Subject:* Re: [j-nsp] ACX50xx l2circuit counters
>
>
>
> Hum ... I think in ACX you will need to explicit use statistics command ...
>
> set interfaces xe-0/0/1 statistics
>
>
> Giuliano Cardozo Medalha
> Systems Engineer
> +55 (17) 3011-3811
>
> +55 (17) 98112-5394
> JUNIPER J-PARTNER ELITE
> giuli...@wztech.com.br
> http://www.wztech.com.br/
>
>
> ​
>
> WZTECH is registered trademark of WZTECH NETWORKS.
> Copyright © 2016 WZTECH NETWORKS. All Rights Reserved.
>
> IMPORTANTE:
> As informações deste e-mail e o conteúdo dos  eventuais  documentos anexos
> são confidenciais e para conhecimento exclusivo do destinatário. Se o
> leitor  desta  mensagem  não  for o seu destinatário,
> fica desde já notificado de que não poderá  divulgar,  distribuir ou, sob
> qualquer forma, dar conhecimento a terceiros das informações e do conteúdo
> dos documentos anexos. Neste caso, favor comunicar imediatamente
> o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida
> apague-o.
>
>
> CONFIDENTIALITY NOTICE:
>
> The information transmitted in this email message and any attachments are
> solely for the intended recipient and may contain confidential or
> pri

Re: [j-nsp] ACX50xx l2circuit counters

[Aaron]

 

Hey , that worked , thanks !  seems that I have to do it at the unit level, I 
didn’t see that I could do it on the phy int level.

 

{master:0}

agould@blcn-h-5048> show interfaces ge-0/0/36 | grep pack

Input packets : 33

Output packets: 0

 

{master:0}

agould@blcn-h-5048> show interfaces ge-0/0/36 | grep pack

Input packets : 33

Output packets: 0

 

{master:0}

agould@blcn-h-5048> show interfaces ge-0/0/36 | grep pack

Input packets : 33

Output packets: 0

 

{master:0}

agould@blcn-h-5048> show interfaces ge-0/0/36 | grep pack

Input packets : 33

Output packets: 0

 

{master:0}

agould@blcn-h-5048> show interfaces ge-0/0/36 | grep pack

Input packets : 33

Output packets: 0

 

{master:0}

agould@blcn-h-5048> configure

Entering configuration mode

 

{master:0}[edit]

agould@blcn-h-5048# set interfaces ge-0/0/36 unit 0 statistics

 

{master:0}[edit]

agould@blcn-h-5048# commit

configuration check succeeds

commit complete

 

{master:0}[edit]

agould@blcn-h-5048# exit

Exiting configuration mode

 

{master:0}

agould@blcn-h-5048> show interfaces ge-0/0/36.0 | grep pack

Input packets : 18232

Output packets: 2

 

{master:0}

agould@blcn-h-5048> show interfaces ge-0/0/36.0 | grep pack

Input packets : 20857

Output packets: 2

 

 

 

 

 

From: Giuliano Medalha [mailto:giuli...@wztech.com.br] 
Sent: Monday, June 20, 2016 4:40 PM
To: Aaron <aar...@gvtc.com>
Cc: Nathan Ward <juniper-...@daork.net>; jnsp list <juniper-nsp@puck.nether.net>
Subject: Re: [j-nsp] ACX50xx l2circuit counters

 

Hum ... I think in ACX you will need to explicit use statistics command ...



set interfaces xe-0/0/1 statistics






Giuliano Cardozo Medalha
Systems Engineer
+55 (17) 3011-3811

+55 (17) 98112-5394
JUNIPER J-PARTNER ELITE
giuli...@wztech.com.br <mailto:giuli...@wztech.com.br> 
http://www.wztech.com.br/




​

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2016 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos  eventuais  documentos anexos são 
confidenciais e para conhecimento exclusivo do destinatário. Se o leitor  desta 
 mensagem  não  for o seu destinatário, 
fica desde já notificado de que não poderá  divulgar,  distribuir ou, sob 
qualquer forma, dar conhecimento a terceiros das informações e do conteúdo dos 
documentos anexos. Neste caso, favor comunicar imediatamente 
o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida 
apague-o. 


CONFIDENTIALITY NOTICE:

The information transmitted in this email message and any attachments are 
solely for the intended recipient and may contain confidential or privileged 
information. If you are not the intended recipient, any review, transmission,  
dissemination or other use of this information is prohibited. If you have 
received this communication in error, please notify the sender immediately and 
delete the material from any computer, including any copies.

 

On Mon, Jun 20, 2016 at 6:37 PM, Aaron <aar...@gvtc.com 
<mailto:aar...@gvtc.com> > wrote:

Yeah, strange my subinterface doesn't show any packets out, but the phy int 
shows currently 17 mbps going out right now...

Maybe these counters are broken on the subint... I tried walking with snmp but 
I still didn't see any traffic for the subinterface used on the l2circuit

agould@blcn-h-5048> show interfaces ge-0/0/12 statistics
Physical interface: ge-0/0/12, Enabled, Physical link is Up
  Interface index: 650, SNMP ifIndex: 521
  Link-level type: Ethernet-CCC, MTU: 1514, LAN-PHY mode, Speed: 1000mbps, BPDU 
Error: None, MAC-REWRITE Error: None, Loopback: Disabled,
  Source filtering: Disabled, Flow control: Disabled, Auto-negotiation: 
Enabled, Remote fault: Online, Media type: Copper
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x4000
  Link flags : None
  CoS queues : 8 supported, 8 maximum usable queues
  Current address: 20:4e:71:45:12:34, Hardware address: 20:4e:71:45:12:34
  Last flapped   : 2016-05-25 14:38:24 CDT (3w5d 01:55 ago)
  Statistics last cleared: Never
  Input rate : 17802616 bps (1633 pps)
  Output rate: 0 bps (0 pps)
  Input errors: 0, Output errors: 0
  Active alarms  : None
  Active defects : None
  Interface transmit statistics: Disabled

  Logical interface ge-0/0/12.0 (Index 557) (SNMP ifIndex 523)
Flags: Up SNMP-Traps 0x4004000 Encapsulation: Ethernet-CCC
Input packets : 68
Output packets: 0
Protocol ccc, MTU: 1514
  Flags: Is-Primary

{master:0}

agould@blcn-h-5048> show l2circuit connections brief
Layer-2 Circuit Connections:

Legend for connection status (St)


Legend for interface status
Up -- operational
Dn -- down
Neighbor: 10.101.0.1
Interface Type  St Time last up  # Up trans
ge-0/0/12.0(vc 1) rmt   Up May 25 14:38:24 2016   1


- Aa

Re: [j-nsp] ACX50xx l2circuit counters

[Adam Vitkovsky]

> Saku Ytti
> Sent: Monday, June 20, 2016 6:13 PM
>
> I'm not pointing at JNPR, other vendors do it too. But these cheap/dense
> boxes have tons of things that don't work, and can't work and there isn't any
> clean nice page which lists all gotchas. I think it's marketing, marketing 
> fears
> that if all non-working stuff is listed, people won't buy the kit, even if 
> they
> actually could live without those.
>
> I wonder how many would skip buying ACX5k if they knew all the control-
> plane protecting challenges, or inability to do IPV4+IPV6 filter in same
> interface, list is long. But it's same in competitors.
> If JNPR would list them, people might unfairly assume vendor who does not,
> is superior.
>
> We really should have community pages documenting devices and their
> limitations. Like dpreview for networking kit :/
>
/rant.
Nah, regarding HW limitations, for 99% of folks ignorance is bliss,
What I've learned over the years is, you get what you pay for. (There's a 
reason why some routers are cheaper).
rant/.


adam






Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Mark Tinka]

On 21/Jun/16 13:31, Saku Ytti wrote:


> All IP/L3 stuff is done on internal I-Chip, evolution from IP2.
> EZchip2 is there just for L2, QoS or something like that. Ironically,
> the EZchip2 itself could have done it for sure, but perhaps not at an
> acceptable rate.

Possibly - I can't say for sure.

One of the reasons I was slightly put off back then was because the DPC
did not support simple DSCP marking on ingress, using the firewall
filter feature that was available in the code. That was down to EZchip.
But then again, our customers did not require the use-case those days,
so I did not test for it.

Experience has taught me to always test for this (and other things) when
looking at new vendors, new line cards or new routers.

> This is absolutely fantastic and BRCM would probably require much
> larger volume to respin anything.

Probably, but in our case, it had nothing to do with volume. We only
ordered 100 units to start (although the number blew up a couple of
years later).

I think they did it because we were the first global customer looking to
run IP/MPLS all the way into the Metro-E Access on an unproven platform,
in a network that already had an established Layer 2 Metro-E Access
backbone, when the rest of the world could not fathom the idea of doing
this at all.

It is possible they may not have re-spun Nile if IP/MPLS in the Access
was established, and we were just a new entrant :-).

Mark.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Saku Ytti]

On 21 June 2016 at 14:23, Mark Tinka  wrote:

Hey,

> Take Policy Map for the MX, for example. I worked with Juniper for 2
> years to develop this feature, and was lucky it could be done on the
> Trio because of that design. They can't do it on any other M-series, for
> instance, and certainly not the DPC's which are external chips. It's not
> a feature they foresaw when developing the Trio, but they managed to
> make it work without sacrificing performance after-the-fact.

You could do it in every NPU, NPU is run-to-completion, you give it
real software to run, and it does something. You're only limited by
time.

All IP/L3 stuff is done on internal I-Chip, evolution from IP2.
EZchip2 is there just for L2, QoS or something like that. Ironically,
the EZchip2 itself could have done it for sure, but perhaps not at an
acceptable rate.

> When I started testing the ME3600X/3800X in 2009, the Nile chip did not
> support QPPB. After working with Cisco for 6 months, I managed to
> convince them to re-spin the ASIC before they started manufacturing the
> box for general shipping. But such opportunities are few and far between
> (basically, non-existent), and I wouldn't bank on them being the norm,
> ever. Which is why flexibility in the future is easier with an in-house
> chip, even if it's not always guaranteed.

This is absolutely fantastic and BRCM would probably require much
larger volume to respin anything.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Mark Tinka]

On 21/Jun/16 12:34, Saku Ytti wrote:

> I don't understand. In either case, nothing can be fixed in the
> hardware after it enters the box.

I didn't say fixing issues in the hardware, I said "fixing issues", most
of which can be done via software because the chip was given the ability
to in the first place, based on all the experience the vendor has had in
the industry.


> This can be said to pretty much every ASIC/pipeline box, they can't do
> everything.

I didn't say I want everything, I said it didn't do what I wanted.

Another box did do what I wanted, so I went with that. But more often
than not, the boxes that haven't been able to meet at least 95% of my
requirements tended to be external chips. I can't ignore that however
much I try.


> This is certainly part of the reason vendors don't want to communicate
> openly, if customers decide product is inferior based on the logo on
> the chip. I guess same reason why they don't document clearly the
> limitations, they know that lot of customers won't actually use the
> boxes like that, but might not buy the box out of fear if the issues
> were listed.
> Vendor's openness depends on customers doing informed, fact based decisions.

I have not been looking at merchant silicon for a long time. Only in the
last 3 years, really, when Cisco were considering it for the ASR920 at
first. Even Cisco, themselves, decided against it because of label depth
limitations when considering their SR implementation for the portfolio.

It might not come out on-list, but I do a lot "fact-based" testing and
research before I decide on purchasing a box. I don't like to get too
much into this detail on-list because things change very quickly in this
area, and there is no point holding on to that data for too long when
your purchasing cycle is high.

I prefer to distill the basics and keep my eye on the prize. I'd not
take my lack of emphasis on the finer details on-list as being ignorant
about how I reach my decisions.

Ultimately, we are running a business, and given my position, I need to
balance that at all times.


> It can't be manipulated after the hardware has been made. It does what
> it can do.

I'm referring to the preparations that were made beforehand, that
provide some flexibility later on.

Many an in-house chip have been developed without a feature in mind, but
when asked, it could be done because of the initial design. Other times,
even though the chip can support it, the vendor does not want to do it
because they are committing time and resources on the next-generation
platform.

Take Policy Map for the MX, for example. I worked with Juniper for 2
years to develop this feature, and was lucky it could be done on the
Trio because of that design. They can't do it on any other M-series, for
instance, and certainly not the DPC's which are external chips. It's not
a feature they foresaw when developing the Trio, but they managed to
make it work without sacrificing performance after-the-fact.

When I started testing the ME3600X/3800X in 2009, the Nile chip did not
support QPPB. After working with Cisco for 6 months, I managed to
convince them to re-spin the ASIC before they started manufacturing the
box for general shipping. But such opportunities are few and far between
(basically, non-existent), and I wouldn't bank on them being the norm,
ever. Which is why flexibility in the future is easier with an in-house
chip, even if it's not always guaranteed.

The idea is to give yourself the best chance possible, rather than
resigning yourself to binary outcomes.

> Are you implying Cisco would say to you they don't give you feature
> and forwarding performance stamp of approval to ASR9k, because it's
> not their chip? If this is the communication you receive, I can
> understand your position.

No, it means that I am more inclined to using the ASR9000 in specific
situations and not others, knowing what I know about the platform since
it launched, and where it is today.

It also means I know the right questions to ask (from experience) so I
do not waste my time testing things that don't matter to me.

Mark.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Chuck Anderson]

On Tue, Jun 21, 2016 at 01:37:37PM +0300, Saku Ytti wrote:
> On 21 June 2016 at 13:31, Nathan Ward  wrote:
> 
> > I haven’t looked in ages, but didn’t Richard Steenbergen run a wiki for 
> > this sort of info?
> 
> Yeah but he's wearing suits now and has no time for such shenanigans.
> Job has copy of the data. But community (I don't exclude myself here)
> contribution to the site were less than stellar. Unsure if it's the
> wiki format or what.

I wanted (still want) to contribute but could never get an account.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Saku Ytti]

On 21 June 2016 at 13:31, Nathan Ward  wrote:

> I haven’t looked in ages, but didn’t Richard Steenbergen run a wiki for this 
> sort of info?

Yeah but he's wearing suits now and has no time for such shenanigans.
Job has copy of the data. But community (I don't exclude myself here)
contribution to the site were less than stellar. Unsure if it's the
wiki format or what.

I'm thinking more of a site like dpreview, not open text, but database
with fields and value to the fields. To facilitate easy comparison
between devices.



-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Saku Ytti]

On 21 June 2016 at 13:24, Mark Tinka  wrote:

> I would not say it's better, but the vendors have much more leeway in
> fixing issues when it's their own silicon vs. something they can't
> change after it enters the box.

I don't understand. In either case, nothing can be fixed in the
hardware after it enters the box.

> The ME2600X from Cisco, which is/was a good little FTTH box, was such
> for me. I ended up ditching it because they could not do a lot of things
> I expected due to the Broadcom chip they had in there. Suffice it to
> say, the box was pulled from the portfolio a year later.

This can be said to pretty much every ASIC/pipeline box, they can't do
everything.

> I look at both; now as much as the future.

This is certainly part of the reason vendors don't want to communicate
openly, if customers decide product is inferior based on the logo on
the chip. I guess same reason why they don't document clearly the
limitations, they know that lot of customers won't actually use the
boxes like that, but might not buy the box out of fear if the issues
were listed.
Vendor's openness depends on customers doing informed, fact based decisions.

> The point is that if the chip was designed in-house from the ground-up
> (which the vendors can admit to), and that features can be flexibly

Which we already determined, we can't really know if it's true or not.

> manipulated in-house (which the vendors can admit to as well), I'm fine
> with that. It has worked for me thus far.

It can't be manipulated after the hardware has been made. It does what
it can do.

> In-house design does mean external IP was not used. It means that
> feature and forwarding performance have the vendor's stamp of approval,
> which I have never got from a vendor when they 100% outsource the silicon.

Are you implying Cisco would say to you they don't give you feature
and forwarding performance stamp of approval to ASR9k, because it's
not their chip? If this is the communication you receive, I can
understand your position.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Nathan Ward]

> On 21/06/2016, at 05:20, Santiago Martinez  
> wrote:
> 
> Hi Saku, I agree having a small db with features limitations and scalability 
> will be great and saves us lot of headache.
> regards
> santi


I haven’t looked in ages, but didn’t Richard Steenbergen run a wiki for this 
sort of info?

--
Nathan Ward
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Mark Tinka]

On 21/Jun/16 12:09, Saku Ytti wrote:

> >From Cisco own stuff is
> CSR-1, QFP (well, both are built on Tensilica)
> Magic FPGA gen1+gen2
> Most catalysts (Are all?)
>
> Merchant stuff is:
> ASR9k
> ISRs
> Lot of nexuses
>
>> I know that while I'm not aware of the full list of what might not work,
>> I know there is bound to be a lot of surprises.
> Why would different logo on chip imply better applicability for your
> application?

I would not say it's better, but the vendors have much more leeway in
fixing issues when it's their own silicon vs. something they can't
change after it enters the box.

The ME2600X from Cisco, which is/was a good little FTTH box, was such
for me. I ended up ditching it because they could not do a lot of things
I expected due to the Broadcom chip they had in there. Suffice it to
say, the box was pulled from the portfolio a year later.


>  I think you maybe extrapolating too much data from your
> experience/anecdotes.

In our world (certainly mine), experience gives you a lot - after all
the slideware, snake oil and incorrect documentation.

And yes, that experience includes pre-purchase testing.


> Regardless of the logo, you need to do your due diligence and know
> exactly that everything you're going to need, work /NOW/, not 6 months
> from now.

I look at both; now as much as the future.


> That seems very flexible definition. How do we define merchant and
> custom, how much IP can you buy, before it becomes merchant? Is EZchip
> NP3c custom or merchant? Is Alcatel FP3 custom or merchant?
> Would we know if Juniper had bought 20% 60% 90% of IP for Trio from
> someone? I don't believe they did, but would we know? Would it matter?

Well, we don't really.

The point is that if the chip was designed in-house from the ground-up
(which the vendors can admit to), and that features can be flexibly
manipulated in-house (which the vendors can admit to as well), I'm fine
with that. It has worked for me thus far.

In-house design does not mean external IP was not used. It means that
feature and forwarding performance have the vendor's stamp of approval,
which I have never got from a vendor when they 100% outsource the silicon.

Mark.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Mark Tinka]

On 21/Jun/16 12:09, Saku Ytti wrote:
> On 21 June 2016 at 09:41, Mark Tinka  wrote:
>
> Hey,
>
>> To be honest, as I've said a few times before, I'm still nowhere being
>> comfortable buying a router that uses merchant silicon.
> Aren't devices merchant, own ASIC/NPU is an exception.
>
> >From Cisco own stuff is
> CSR-1, QFP (well, both are built on Tensilica)
> Magic FPGA gen1+gen2
> Most catalysts (Are all?)
>
> Merchant stuff is:
> ASR9k
> ISRs
> Lot of nexuses
>
>> I know that while I'm not aware of the full list of what might not work,
>> I know there is bound to be a lot of surprises.
> Why would different logo on chip imply better applicability for your
> application?

I would not say it's better, but the vendors have much more leeway in
fixing issues when it's their own silicon vs. something they can't
change after it enters the box.

The ME2600X from Cisco, which is/was a good little FTTH box, was such
for me. I ended up ditching it because they could not do a lot of things
I expected due to the Broadcom chip they had in there. Suffice it to
say, the box was pulled from the portfolio a year later.


>  I think you maybe extrapolating too much data from your
> experience/anecdotes.

In our world (certainly mine), experience gives you a lot - after all
the slideware, snake oil and incorrect documentation.

And yes, that experience includes pre-purchase testing.


> Regardless of the logo, you need to do your due diligence and know
> exactly that everything you're going to need, work /NOW/, not 6 months
> from now.

I look at both; now as much as the future.


> That seems very flexible definition. How do we define merchant and
> custom, how much IP can you buy, before it becomes merchant? Is EZchip
> NP3c custom or merchant? Is Alcatel FP3 custom or merchant?
> Would we know if Juniper had bought 20% 60% 90% of IP for Trio from
> someone? I don't believe they did, but would we know? Would it matter?

Well, we don't really.

The point is that if the chip was designed in-house from the ground-up
(which the vendors can admit to), and that features can be flexibly
manipulated in-house (which the vendors can admit to as well), I'm fine
with that. It has worked for me thus far.

In-house design does mean external IP was not used. It means that
feature and forwarding performance have the vendor's stamp of approval,
which I have never got from a vendor when they 100% outsource the silicon.

Mark.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Nathan Ward]

> On 21/06/2016, at 19:00, Daniel Verlouw  wrote:
> 
> Hi Nathan,
> 
> On Mon, Jun 20, 2016 at 6:03 AM, Nathan Ward  wrote:
>> Does anyone have and tricks to make l2circuit counters work properly, or, is 
>> this a lost cause?
> 
> on ACX1k/2k/4k, you have to explicitly enable per unit statistics
> collection. We simply enable it on all units using an apply-group;
> 
> set groups per-unit-statistics interfaces <*> unit <*> statistics
> set interfaces apply-groups per-unit-statistics
> 
> Not sure if this is also needed on the 5k, so give it a try…

Hi, catching up on this.

Yep, thanks for this. Our SE also followed up internally and came back to us 
this morning with a similar thing which works fine. Trying to find out why it’s 
not enabled by default - we suspect maybe some scaling limitations, which 
hopefully I’ll be able to share. We currently only have maybe 15 sub interfaces 
on the whole box so it’s not a problem.. for now.

Also worth noting, the D20 software we had doesn’t expose firewall counters to 
SNMP, you have to upgrade to D50 (which from memory was a May release).

--
Nathan Ward

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Saku Ytti]

On 21 June 2016 at 09:41, Mark Tinka  wrote:

Hey,

> To be honest, as I've said a few times before, I'm still nowhere being
> comfortable buying a router that uses merchant silicon.

Aren't devices merchant, own ASIC/NPU is an exception.

>From Cisco own stuff is
CSR-1, QFP (well, both are built on Tensilica)
Magic FPGA gen1+gen2
Most catalysts (Are all?)

Merchant stuff is:
ASR9k
ISRs
Lot of nexuses

> I know that while I'm not aware of the full list of what might not work,
> I know there is bound to be a lot of surprises.

Why would different logo on chip imply better applicability for your
application? I think you maybe extrapolating too much data from your
experience/anecdotes.
Regardless of the logo, you need to do your due diligence and know
exactly that everything you're going to need, work /NOW/, not 6 months
from now.

> Outside of that, I'm not touching a router that is not based on custom
> silicon.

That seems very flexible definition. How do we define merchant and
custom, how much IP can you buy, before it becomes merchant? Is EZchip
NP3c custom or merchant? Is Alcatel FP3 custom or merchant?
Would we know if Juniper had bought 20% 60% 90% of IP for Trio from
someone? I don't believe they did, but would we know? Would it matter?

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Daniel Verlouw]

Hi Nathan,

On Mon, Jun 20, 2016 at 6:03 AM, Nathan Ward  wrote:
> Does anyone have and tricks to make l2circuit counters work properly, or, is 
> this a lost cause?

on ACX1k/2k/4k, you have to explicitly enable per unit statistics
collection. We simply enable it on all units using an apply-group;

set groups per-unit-statistics interfaces <*> unit <*> statistics
set interfaces apply-groups per-unit-statistics

Not sure if this is also needed on the 5k, so give it a try...

BR, Daniel.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Mark Tinka]

On 20/Jun/16 19:12, Saku Ytti wrote:

> I'm not pointing at JNPR, other vendors do it too. But these
> cheap/dense boxes have tons of things that don't work, and can't work
> and there isn't any clean nice page which lists all gotchas. I think
> it's marketing, marketing fears that if all non-working stuff is
> listed, people won't buy the kit, even if they actually could live
> without those.
>
> I wonder how many would skip buying ACX5k if they knew all the
> control-plane protecting challenges, or inability to do IPV4+IPV6
> filter in same interface, list is long. But it's same in competitors.
> If JNPR would list them, people might unfairly assume vendor who does
> not, is superior.
>
> We really should have community pages documenting devices and their
> limitations. Like dpreview for networking kit :/

To be honest, as I've said a few times before, I'm still nowhere being
comfortable buying a router that uses merchant silicon.

I know that while I'm not aware of the full list of what might not work,
I know there is bound to be a lot of surprises.

That said, I am considering Arista's core switches for my 100Gbps
upgrade, which I am happy to do because the only difficult thing those
switches have to do is load balancing of LAG's. I doubt Broadcom can
cock that up, but I will test first anyway.

Outside of that, I'm not touching a router that is not based on custom
silicon.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Giuliano Medalha]

Hum ... I think in ACX you will need to explicit use statistics command ...


set interfaces xe-0/0/1 statistics



Giuliano Cardozo Medalha
Systems Engineer
+55 (17) 3011-3811
+55 (17) 98112-5394
JUNIPER J-PARTNER ELITE
giuli...@wztech.com.br
http://www.wztech.com.br/



​
WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2016 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos  eventuais  documentos anexos
são confidenciais e para conhecimento exclusivo do destinatário. Se o
leitor  desta  mensagem  não  for o seu destinatário,
fica desde já notificado de que não poderá  divulgar,  distribuir ou, sob
qualquer forma, dar conhecimento a terceiros das informações e do conteúdo
dos documentos anexos. Neste caso, favor comunicar imediatamente
o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida
apague-o.


CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are
solely for the intended recipient and may contain confidential or
privileged information. If you are not the intended recipient, any review,
transmission,  dissemination or other use of this information is
prohibited. If you have received this communication in error, please notify
the sender immediately and delete the material from any computer, including
any copies.

On Mon, Jun 20, 2016 at 6:37 PM, Aaron  wrote:

> Yeah, strange my subinterface doesn't show any packets out, but the phy
> int shows currently 17 mbps going out right now...
>
> Maybe these counters are broken on the subint... I tried walking with snmp
> but I still didn't see any traffic for the subinterface used on the
> l2circuit
>
> agould@blcn-h-5048> show interfaces ge-0/0/12 statistics
> Physical interface: ge-0/0/12, Enabled, Physical link is Up
>   Interface index: 650, SNMP ifIndex: 521
>   Link-level type: Ethernet-CCC, MTU: 1514, LAN-PHY mode, Speed: 1000mbps,
> BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,
>   Source filtering: Disabled, Flow control: Disabled, Auto-negotiation:
> Enabled, Remote fault: Online, Media type: Copper
>   Device flags   : Present Running
>   Interface flags: SNMP-Traps Internal: 0x4000
>   Link flags : None
>   CoS queues : 8 supported, 8 maximum usable queues
>   Current address: 20:4e:71:45:12:34, Hardware address: 20:4e:71:45:12:34
>   Last flapped   : 2016-05-25 14:38:24 CDT (3w5d 01:55 ago)
>   Statistics last cleared: Never
>   Input rate : 17802616 bps (1633 pps)
>   Output rate: 0 bps (0 pps)
>   Input errors: 0, Output errors: 0
>   Active alarms  : None
>   Active defects : None
>   Interface transmit statistics: Disabled
>
>   Logical interface ge-0/0/12.0 (Index 557) (SNMP ifIndex 523)
> Flags: Up SNMP-Traps 0x4004000 Encapsulation: Ethernet-CCC
> Input packets : 68
> Output packets: 0
> Protocol ccc, MTU: 1514
>   Flags: Is-Primary
>
> {master:0}
>
> agould@blcn-h-5048> show l2circuit connections brief
> Layer-2 Circuit Connections:
>
> Legend for connection status (St)
> 
>
> Legend for interface status
> Up -- operational
> Dn -- down
> Neighbor: 10.101.0.1
> Interface Type  St Time last up  # Up trans
> ge-0/0/12.0(vc 1) rmt   Up May 25 14:38:24 2016   1
>
>
> - Aaron
>
>
>
> ___
> 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] ACX50xx l2circuit counters

[Aaron]

Yeah, strange my subinterface doesn't show any packets out, but the phy int 
shows currently 17 mbps going out right now...

Maybe these counters are broken on the subint... I tried walking with snmp but 
I still didn't see any traffic for the subinterface used on the l2circuit

agould@blcn-h-5048> show interfaces ge-0/0/12 statistics
Physical interface: ge-0/0/12, Enabled, Physical link is Up
  Interface index: 650, SNMP ifIndex: 521
  Link-level type: Ethernet-CCC, MTU: 1514, LAN-PHY mode, Speed: 1000mbps, BPDU 
Error: None, MAC-REWRITE Error: None, Loopback: Disabled,
  Source filtering: Disabled, Flow control: Disabled, Auto-negotiation: 
Enabled, Remote fault: Online, Media type: Copper
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x4000
  Link flags : None
  CoS queues : 8 supported, 8 maximum usable queues
  Current address: 20:4e:71:45:12:34, Hardware address: 20:4e:71:45:12:34
  Last flapped   : 2016-05-25 14:38:24 CDT (3w5d 01:55 ago)
  Statistics last cleared: Never
  Input rate : 17802616 bps (1633 pps)
  Output rate: 0 bps (0 pps)
  Input errors: 0, Output errors: 0
  Active alarms  : None
  Active defects : None
  Interface transmit statistics: Disabled

  Logical interface ge-0/0/12.0 (Index 557) (SNMP ifIndex 523)
Flags: Up SNMP-Traps 0x4004000 Encapsulation: Ethernet-CCC
Input packets : 68
Output packets: 0
Protocol ccc, MTU: 1514
  Flags: Is-Primary

{master:0}

agould@blcn-h-5048> show l2circuit connections brief
Layer-2 Circuit Connections:

Legend for connection status (St)


Legend for interface status
Up -- operational
Dn -- down
Neighbor: 10.101.0.1
Interface Type  St Time last up  # Up trans
ge-0/0/12.0(vc 1) rmt   Up May 25 14:38:24 2016   1


- Aaron



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Aaron]

Just fyi about protecting I've got v4 and v6 mpls l3vpn (6vpe) dual stacked 
on my acx5048 and I've accomplished protecting control plane from external ssh 
for public ipv4 and ipv6 addresses and also from local customers hitting 
fe80::/10 link local on subscriber facing irb

Seems to be working on the inet and inet6 firewall acl attached to vrf 
routing-instance

- Aaron 


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Jason Healy]

On Jun 20, 2016, at 1:12 PM, Saku Ytti  wrote:
> 
> If JNPR would list them, people might unfairly assume vendor who does
> not, is superior.
> 
> We really should have community pages documenting devices and their
> limitations. Like dpreview for networking kit :/

I would love such a thing.  I just joined this list because of frustrations 
we're having with IPv6 feature parity on the QFX5100.  We've run into 
undocumented issues and then sales tells us it was never supposed to do what 
we're asking for and it would be an "enhancement" to add the functionality.

And that's just the bugs that could be fixed in software.  Hardware issues are 
even worse.

Jason
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[Santiago Martinez]

Hi Saku, I agree having a small db with features limitations and scalability 
will be great and saves us lot of headache.
regards
santi


> On 20 Jun 2016, at 10:12, Saku Ytti  wrote:
> 
> I'm not pointing at JNPR, other vendors do it too. But these
> cheap/dense boxes have tons of things that don't work, and can't work
> and there isn't any clean nice page which lists all gotchas. I think
> it's marketing, marketing fears that if all non-working stuff is
> listed, people won't buy the kit, even if they actually could live
> without those.
> 
> I wonder how many would skip buying ACX5k if they knew all the
> control-plane protecting challenges, or inability to do IPV4+IPV6
> filter in same interface, list is long. But it's same in competitors.
> If JNPR would list them, people might unfairly assume vendor who does
> not, is superior.
> 
> We really should have community pages documenting devices and their
> limitations. Like dpreview for networking kit :/
> 
>> On 20 June 2016 at 18:43, raf  wrote:
>>> Le 20/06/2016 à 06:03, Nathan Ward a écrit :
>>> 
>>> Hi all,
>>> 
>>> I’m deploying some ACX5048 boxes, doing l2circuits from subinterfaces off
>>> to BNGs and so on.
>>> 
>>> We’re wanting to get counters for each l2circuit, or each subinterface,
>>> but as soon as a an l2circuit is attached to a subint, we lose all counters.
>>> 
>>> We can achieve what we want, more or less, by writing a ccc family
>>> firewall filter that matches anything and accepts+counts. It works, but it’s
>>> certainly a bit of a hack.
>>> 
>>> Does anyone have and tricks to make l2circuit counters work properly, or,
>>> is this a lost cause?
>>> 
>>> Have asked JTAC about this, and am waiting on a response for ~ 1 week now.
>> 
>> Well I guess this will be a lost cause :/
>> I have to use firewall counter as well for counting sub interface or vlan
>> interface, which it less corner case in my opinion. It may be a chipset
>> limitation ?
>> 
>> --
>> Raphael Mazelier
>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> 
> -- 
>  ++ytti
> ___
> 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] ACX50xx l2circuit counters

[Saku Ytti]

I'm not pointing at JNPR, other vendors do it too. But these
cheap/dense boxes have tons of things that don't work, and can't work
and there isn't any clean nice page which lists all gotchas. I think
it's marketing, marketing fears that if all non-working stuff is
listed, people won't buy the kit, even if they actually could live
without those.

I wonder how many would skip buying ACX5k if they knew all the
control-plane protecting challenges, or inability to do IPV4+IPV6
filter in same interface, list is long. But it's same in competitors.
If JNPR would list them, people might unfairly assume vendor who does
not, is superior.

We really should have community pages documenting devices and their
limitations. Like dpreview for networking kit :/

On 20 June 2016 at 18:43, raf  wrote:
> Le 20/06/2016 à 06:03, Nathan Ward a écrit :
>>
>> Hi all,
>>
>> I’m deploying some ACX5048 boxes, doing l2circuits from subinterfaces off
>> to BNGs and so on.
>>
>> We’re wanting to get counters for each l2circuit, or each subinterface,
>> but as soon as a an l2circuit is attached to a subint, we lose all counters.
>>
>> We can achieve what we want, more or less, by writing a ccc family
>> firewall filter that matches anything and accepts+counts. It works, but it’s
>> certainly a bit of a hack.
>>
>> Does anyone have and tricks to make l2circuit counters work properly, or,
>> is this a lost cause?
>>
>> Have asked JTAC about this, and am waiting on a response for ~ 1 week now.
>>
>
> Well I guess this will be a lost cause :/
> I have to use firewall counter as well for counting sub interface or vlan
> interface, which it less corner case in my opinion. It may be a chipset
> limitation ?
>
> --
> Raphael Mazelier
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX50xx l2circuit counters

[raf]

Le 20/06/2016 à 06:03, Nathan Ward a écrit :

Hi all,

I’m deploying some ACX5048 boxes, doing l2circuits from subinterfaces off to 
BNGs and so on.

We’re wanting to get counters for each l2circuit, or each subinterface, but as 
soon as a an l2circuit is attached to a subint, we lose all counters.

We can achieve what we want, more or less, by writing a ccc family firewall 
filter that matches anything and accepts+counts. It works, but it’s certainly a 
bit of a hack.

Does anyone have and tricks to make l2circuit counters work properly, or, is 
this a lost cause?

Have asked JTAC about this, and am waiting on a response for ~ 1 week now.



Well I guess this will be a lost cause :/
I have to use firewall counter as well for counting sub interface or 
vlan interface, which it less corner case in my opinion. It may be a 
chipset limitation ?


--
Raphael Mazelier
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] ACX50xx l2circuit counters

[Nathan Ward]

Hi all,

I’m deploying some ACX5048 boxes, doing l2circuits from subinterfaces off to 
BNGs and so on.

We’re wanting to get counters for each l2circuit, or each subinterface, but as 
soon as a an l2circuit is attached to a subint, we lose all counters.

We can achieve what we want, more or less, by writing a ccc family firewall 
filter that matches anything and accepts+counts. It works, but it’s certainly a 
bit of a hack.

Does anyone have and tricks to make l2circuit counters work properly, or, is 
this a lost cause?

Have asked JTAC about this, and am waiting on a response for ~ 1 week now.

--
Nathan Ward

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp