Re: [j-nsp] MX104 limitation
Hi, As Nitzan suggested, I deactivated the inline jflow and the traffic has increased. Now I ask, what is the real forwarding capacity of this box? 40G in + 40G out? (now it didn't reach 40G in total) Javier. 2017-03-20 12:15 GMT-03:00 Javier Rodriguez : > Nitzan, thank you very much, I'll keep that in mind. > Anyway I can not understand how the router "eats" the packets without > being counted That gives me panic! > I can't find discarded packets anywhere! > > JR. > > 2017-03-20 2:31 GMT-03:00 Nitzan Tzelniker : > >> We saw a limitation around 40Gbps when running MX80 with RE based jflow >> (inline works good ) we didnt got good explanation why it limit the traffic >> so try to disable some features and see if it help >> >> Nitzan >> >> On Mon, Mar 20, 2017 at 6:14 AM, Javier Rodriguez < >> rodriguezsot...@gmail.com> wrote: >> >>> Mmm no, I think it doesn't work on MX80 / MX104. >>> >>> JR. >>> >>> >>> 2017-03-19 23:14 GMT-03:00 Olivier Benghozi >> >: >>> >>> > What about bypass-queuing-chip on MIC interfaces ? Would it work on >>> > MX80/104 ? >>> > >>> > > On 20 march 2017 at 01:32, Saku Ytti wrote : >>> > > >>> > > Ok that's only 31Gbps total, without having any actual data, my best >>> > > guess is that you're running through QX. Only quick reason I can come >>> > > up for HW to limit on so modest traffic levels. >>> > > >>> > > On 20 March 2017 at 02:25, Javier Rodriguez < >>> rodriguezsot...@gmail.com> >>> > wrote: >>> > >> Soku, >>> > >> >>> > >> Maybe there was a misunderstanding , the inbound traffic on fpc2's >>> LAG >>> > was >>> > >> 4Gbps , and the outbound traffic was 27Gbps aprox. That outbound >>> traffic >>> > >> enters by the fpc1 and fpc0. >>> > >> It's IMIX traffic, the average packet size is 1250Bytes (out) >>> 200Bytes >>> > (in). >>> > >> I tried to see dropped packets with "show precl-eng 5 statistics " >>> and >>> > "show >>> > >> mqchip 0 drop stats" at pfe shell but it's 0. Does it save >>> historical >>> > data? >>> > >> >>> > >> >>> > >> <--27G-- | | <--27G-- >>> > >> |FPC2 FPC 0/1 | >>> > >> --4G--> | | --4G--> >>> > >> >>> > >> Regards, >>> > >> >>> > >> Javier. >>> > >> >>> > >> >>> > >> 2017-03-19 20:43 GMT-03:00 Saku Ytti : >>> > >>> >>> > >>> Hey, >>> > >>> >>> > >>> There aren't multiple FPCs on the box really, there is only single >>> MQ >>> > >>> chip out of where all ports sit, usually MIC ports behind >>> additional >>> > >>> IX chip, which is not congested. It's architecturally single >>> linecard >>> > >>> fabricless box. >>> > >>> You're saying you're pushing on the 4x10GE fixed ports 31+31Gbps, >>> e.g. >>> > >>> 62Gbps? It might be possible on (perhaps artificially) unfortunate >>> > >>> cell alignment that it could be congested on so low values. Are all >>> > >>> the packets same size, i.e is this lab scenario or just IMIX >>> traffic? >>> > >>> MQ pfe exceptions and MQ=>LU counters might be interesting to see. >>> > >>> >>> > >>> If you use QX chip, 62Gbps would be really good, QX chip is not >>> > >>> dimensioned for line rate _unidir_ (i.e. can't do even 40Gbps). If >>> you >>> > >>> don't know if you're using QX or not, just deactive whole >>> > >>> class-of-service and scheduer config in interfaces. >>> > >>> >>> > >>> On 20 March 2017 at 01:26, Javier Rodriguez < >>> rodriguezsot...@gmail.com >>> > > >>> > >>> wrote: >>> > Hi, >>> > >>> > Thanks for your reply Saku. >>> > The problem is that fpc2 (fixed ports) can't overcome 31Gbps (in + >>> > out) >>> > with 6Mpps. The graph shows a straight line as if it were being >>> > limited. >>> > I have moved some interfaces from LAG to fpc1 and fpc0 and the >>> traffic >>> > has >>> > incresed. (It only has a tunnel-service in fpc0 of 1g) >>> > It's as if it were being limited by the MQ, but I do not see >>> discarded >>> > packages, or I do not know where to look at them. >>> > >>> > JR. >>> > >>> > 2017-03-19 6:53 GMT-03:00 Saku Ytti : >>> > >>> > > Hey Javier, >>> > > >>> > > >>> > > MX104 and MX80 (1st gen Trio MQ/LU) should do about 55Mpps and >>> 75Gbps >>> > > (in+out). >>> > > >>> > > On 19 March 2017 at 09:12, Javier Rodriguez < >>> > rodriguezsot...@gmail.com> >>> > > wrote: >>> > >> Hi everyone, >>> > >> >>> > >> I need a bit of your knowledge. >>> > >> I have a MX104 as PE router with 4 LAGs. >>> > >> One LAG facing to P router on FPC2 (fixed ports). The other LAGs >>> > >> distributed in FPC0 and FPC1. >>> > >> The problem is that traffic is being limited when reach 28G >>> out/ 4G >>> > >> in >>> > >> (31Gbps total). >>> > >> I changed one interface (10G) of the LAG (to P router) to FPC1 >>> and >>> > >> the >>> > >> traffic has grown a little more. >>> > >> >>> > >> Where is the limitation? In the MQ chip? >>> > >> Where can I see those discarded packages? >>> > >> How much traffic will the router support on FPC2? >
Re: [j-nsp] flowspec in logical-systems
Try: show firewall | match flowspec Sometimes the filter names aren't what you expect when dealing with logical-systems. The ones I see are prepended with __LSYSNAME/ to you might find them names __LSYSNAME/__flowspec_ On Wed, Mar 22, 2017 at 09:07:22PM +0200, Michail Litvak wrote: > Hi all, > > Did anybody tried to use flowspec in the logical-system ? > The BGP session with flowspec family is up and receiving appropriate NLRI, > the inetflow.0 table exists in the LS with appropriate values: > > But no firewall filter __flowspec_default_inet__ exists in the LS. > > >1. > >admin@lab-2> show firewall filter logical-system LS4 > __flowspec_default_inet__ > >2. > >error: filter name inconsistent with logical router ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACX control plane filter
Had already been answered in the thread:
"The script is building only /32 "local" prefixes.
Your suggestion is building "direct" prefixes and when matching at the
FTF, you can achieve "undesired" results."
Best Regards,
Krasi
On 22 March 2017 at 20:00, Eduardo Schoedler wrote:
> have you tried to do a prefix-list like this?
>
>
> {master}[edit]
> regress@R1-RE0# *show policy-options | no-more*
> prefix-list router-ipv4 {
> apply-path "interfaces <*> unit <*> family inet address <*>";
> }
>
>
> --
> Eduardo Schoedler
>
>
> Em seg, 20 de mar de 2017 às 06:24, Johan Borch
> escreveu:
>
> > Hi
> >
> > Do anyone have a control plane filter for ACX they can share? :) they
> don't
> > seem to support using standard loopback filters.
> >
> > Johan
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> --
> Eduardo Schoedler
> ___
> 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] ACX control plane filter
You probably don't want to protect customer LANs same way as you want
to protect your control-plane.
On 22 March 2017 at 20:12, Eduardo Schoedler wrote:
> Better example:
>
> {master}[edit]
> jnpr@R1-RE0# *show policy-options prefix-list router-ipv4*
> apply-path "interfaces <*> unit <*> family inet address <*>";
>
> {master}[edit]
> jnpr@R1-RE0# *show policy-options prefix-list router-ipv4 | display
> inheritance*
> ##
> ## apply-path was expanded to:
> ## 192.168.0.0/30;
> ## 10.8.0.0/31;
> ## 192.0.2.0/26;
> ## 192.0.2.64/26;
> ## 10.3.255.1/32;
> ## 172.19.90.0/23;
> ##
> apply-path "interfaces <*> unit <*> family inet address <*>";
>
>
>
>
> Em qua, 22 de mar de 2017 às 15:00, Eduardo Schoedler
> escreveu:
>
>> have you tried to do a prefix-list like this?
>>
>>
>> {master}[edit]
>> regress@R1-RE0# *show policy-options | no-more*
>> prefix-list router-ipv4 {
>> apply-path "interfaces <*> unit <*> family inet address <*>";
>> }
>>
>>
>> --
>> Eduardo Schoedler
>>
>>
>> Em seg, 20 de mar de 2017 às 06:24, Johan Borch
>> escreveu:
>>
>> Hi
>>
>> Do anyone have a control plane filter for ACX they can share? :) they don't
>> seem to support using standard loopback filters.
>>
>> Johan
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>> --
>> Eduardo Schoedler
>>
> --
> Eduardo Schoedler
> ___
> 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
[j-nsp] flowspec in logical-systems
Hi all, Did anybody tried to use flowspec in the logical-system ? The BGP session with flowspec family is up and receiving appropriate NLRI, the inetflow.0 table exists in the LS with appropriate values: 1. logical-system: LS4 2. 3. inetflow.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 4. + = Active Route, - = Last Active, * = Both 5. 6. 172.16.22.139,*/term:N/A 7. *[BGP/170] 00:00:37, localpref 100, from 172.16.24.36 8. AS path: I, validation-state: unverified 9. Fictitious But no firewall filter __flowspec_default_inet__ exists in the LS. 1. admin@lab-2> show firewall filter logical-system LS4 __flowspec_default_inet__ 2. error: filter name inconsistent with logical router I'd appreciate any feedback. -- WBR, Michail ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACX control plane filter
Better example:
{master}[edit]
jnpr@R1-RE0# *show policy-options prefix-list router-ipv4*
apply-path "interfaces <*> unit <*> family inet address <*>";
{master}[edit]
jnpr@R1-RE0# *show policy-options prefix-list router-ipv4 | display inheritance*
##
## apply-path was expanded to:
## 192.168.0.0/30;
## 10.8.0.0/31;
## 192.0.2.0/26;
## 192.0.2.64/26;
## 10.3.255.1/32;
## 172.19.90.0/23;
##
apply-path "interfaces <*> unit <*> family inet address <*>";
Em qua, 22 de mar de 2017 às 15:00, Eduardo Schoedler
escreveu:
> have you tried to do a prefix-list like this?
>
>
> {master}[edit]
> regress@R1-RE0# *show policy-options | no-more*
> prefix-list router-ipv4 {
> apply-path "interfaces <*> unit <*> family inet address <*>";
> }
>
>
> --
> Eduardo Schoedler
>
>
> Em seg, 20 de mar de 2017 às 06:24, Johan Borch
> escreveu:
>
> Hi
>
> Do anyone have a control plane filter for ACX they can share? :) they don't
> seem to support using standard loopback filters.
>
> Johan
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> --
> Eduardo Schoedler
>
--
Eduardo Schoedler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACX control plane filter
have you tried to do a prefix-list like this?
{master}[edit]
regress@R1-RE0# *show policy-options | no-more*
prefix-list router-ipv4 {
apply-path "interfaces <*> unit <*> family inet address <*>";
}
--
Eduardo Schoedler
Em seg, 20 de mar de 2017 às 06:24, Johan Borch
escreveu:
> Hi
>
> Do anyone have a control plane filter for ACX they can share? :) they don't
> seem to support using standard loopback filters.
>
> Johan
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
Eduardo Schoedler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] It is about cisco command
I mean operationally difference from JunOS to IOS/IOS-XR. In each case, policy must exist in config, but must not be applied to customer to achieve what you want. So I do not understand your need for Cisco to implement 'test', I do not understand what is missing, operationally. On 22 March 2017 at 15:38, Brijesh Patel wrote: > I believe so many diffrence between IOS and IOS-Xr. I am not 100% sure what > ares. Sorry > > On Wed, Mar 22, 2017 at 1:25 PM, Saku Ytti wrote: >> >> On 22 March 2017 at 14:58, Tomasz Mikołajek wrote: >> > You can use test policy when policy statment is commiteted. Is in active >> > configuration. If is not commited You get error: Policy referencje but >> > not >> > defined. >> >> Quite. Which is why I'm struggling to understand what is the >> difference to IOS/IOS-XR? >> >> -- >> ++ytti > > -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] It is about cisco command
I was writting about Junos not IOS. W dniu śr., 22.03.2017 o 14:58 Saku Ytti napisał(a): > I mean operationally difference from JunOS to IOS/IOS-XR. In each > case, policy must exist in config, but must not be applied to customer > to achieve what you want. > > So I do not understand your need for Cisco to implement 'test', I do > not understand what is missing, operationally. > > On 22 March 2017 at 15:38, Brijesh Patel wrote: > > I believe so many diffrence between IOS and IOS-Xr. I am not 100% sure > what > > ares. Sorry > > > > On Wed, Mar 22, 2017 at 1:25 PM, Saku Ytti wrote: > >> > >> On 22 March 2017 at 14:58, Tomasz Mikołajek > wrote: > >> > You can use test policy when policy statment is commiteted. Is in > active > >> > configuration. If is not commited You get error: Policy referencje but > >> > not > >> > defined. > >> > >> Quite. Which is why I'm struggling to understand what is the > >> difference to IOS/IOS-XR? > >> > >> -- > >> ++ytti > > > > > > > > -- > ++ytti > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] It is about cisco command
I believe so many diffrence between IOS and IOS-Xr. I am not 100% sure what ares. Sorry On Wed, Mar 22, 2017 at 1:25 PM, Saku Ytti wrote: > On 22 March 2017 at 14:58, Tomasz Mikołajek wrote: > > You can use test policy when policy statment is commiteted. Is in active > > configuration. If is not commited You get error: Policy referencje but > not > > defined. > > Quite. Which is why I'm struggling to understand what is the > difference to IOS/IOS-XR? > > -- > ++ytti > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] It is about cisco command
On 22 March 2017 at 14:58, Tomasz Mikołajek wrote: > You can use test policy when policy statment is commiteted. Is in active > configuration. If is not commited You get error: Policy referencje but not > defined. Quite. Which is why I'm struggling to understand what is the difference to IOS/IOS-XR? -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] It is about cisco command
You can use test policy when policy statment is commiteted. Is in active configuration. If is not commited You get error: Policy referencje but not defined. Tomasz W dniu śr., 22.03.2017 o 13:32 Saku Ytti napisał(a): > On 22 March 2017 at 13:57, Brijesh Patel wrote: > > Look like time being there is no option in cisco IOS...Unless IOS copy > Junos > > test policy features > > I'm not sure I fully understand. You cannot use the JNPR test command, > if policy committed. Just like the IOS command. In both cases, > you can query which routes match the route-map/policy. So in both > cases you need to create the policy, not attach to customer, then view > what routes hit them, then attach to customer if happy with results. > > > -- > ++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] It is about cisco command
On 22 March 2017 at 13:57, Brijesh Patel wrote: > Look like time being there is no option in cisco IOS...Unless IOS copy Junos > test policy features I'm not sure I fully understand. You cannot use the JNPR test command, if policy isn't committed. Just like the IOS command. In both cases, you can query which routes match the route-map/policy. So in both cases you need to create the policy, not attach to customer, then view what routes hit them, then attach to customer if happy with results. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] It is about cisco command
Thanks Guys for responding.. Look like time being there is no option in cisco IOS...Unless IOS copy Junos test policy features On Wed, Mar 22, 2017 at 12:01 AM, Saku Ytti wrote: > On 21 March 2017 at 23:13, Brijesh Patel wrote: > > In juniper test command will test before apply to neighbour > > > > Where in cisco , once you implement command go into nvram so bit not give > > answer. > > You don't need to apply the route-map to any neighbour, but it does > need to exist. It's not perfect, but it might be survivable. > > -- > ++ytti > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
