Re: [j-nsp] Cut-through forwarding statistics on QFX5100

2017-06-22 Thread Vincent Bernat
 ❦ 22 juin 2017 00:28 +0200, Thomas Bellman  :

> We have a QFX5100 on which we have enabled cut-throug forwarding
> ('set forwarding-options cut-through').  Now I am curious about
> how effective that is.  Is there any statistics one can dig out
> about how often the switch is able to do cut-through, and how
> often it has to fall back to store-and-forward?  I haven't found
> anything in 'show interfaces extensive', nor any other promising
> 'show' command.

Related question: why isn't cut-through the default mode? Is there any
downside of this mode (apart from forwarding invalid frames which
shouldn't matter much nowaday)?
-- 
Identify bad input; recover if possible.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cut-through forwarding statistics on QFX5100

2017-06-22 Thread Chris via juniper-nsp


On 22/06/2017 11:27 PM, Nelson, Brian wrote:

Model: qfx5100-96s-8q
Junos: 14.1X53-D42.3

user@qfx5100-96s# set forwarding-options cut-through ?
Possible completions:
   <[Enter]>Execute this command

accounting   Configure accounting of traffic
analyzer Analyzer options

+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups


Appears to be present on 16.1:

me@switch# set forwarding-options ?
Possible completions:
> access-security  Access security configuration
> accounting   Configure accounting of traffic
> analyzer Analyzer options
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  cut-through  Enable cut-through forwarding
> dhcp-relay   Dynamic Host Configuration Protocol relay 
configuration
> enhanced-hash-keySelect data used in the hash key for Enhanced IP 
Forwarding Engines

> family   Protocol family
> hash-key Select data used in the hash key
> helpers  Port forwarding configuration
> ip-options-protocol-queue  IP Options protocol logical queue parameters
> load-balance Configure load-balancing attributes on the 
forwarding path

> local-bias   Turn on local bias functionality
  no-load-balance-label-capability  Disable load balance label capability
> port-mirroring   Configure port mirroring of traffic
> storm-control-profiles  Storm control profile for this instance
  vrf-fallback Enable vrf-fallback forwarding. This will 
restart PFE


me@switch# run show version
fpc0:
--
Hostname: core
Model: qfx5100-48s-6q
Junos: 16.1R3.10 limited
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] SRX NAT rule component limit

2017-06-22 Thread Network Geek
Hi,

In this particular case, the sources are not located in the same location
hence their IP address is not adjacent to each other hence summarization is
not an option unfortunately.

I am a bit surprised if Juniper has not worked on this very limited
capacity yet even after quite some time, reason why I come to you guys to
confirm. Unfortunately I can't test it myself on my production devices
until my change window.

Appreciate if those who know could pop up and clear my doubt hence help me
save my time.

Thanks

On 21 Jun 2017 11:35 p.m., "Mike Azevedo" 
wrote:

> I haven't tested this so I didn't respond to the group.  I believe the
> limit still exists.  However, you can summarize and do 8 supernets or
> ranges in your NAT statements.  If you just have tons of discontiguous
> addresses you would need multiple rules within the rule-set where each rule
> has the 8 addresses or address ranges / summaries.
>
> thx
> mike
> enfopoint
>
> On Wed, Jun 21, 2017 at 12:19 AM, Network Geek 
> wrote:
>
>> Hi guys,
>>
>> Nice to join this amazing group. This is my first posting where I'd like
>> to
>> seek for help on information about SRX NAT rule.
>>
>> I know from the past on SRX3600 that when I created NAT rule, I could only
>> have 8 source-address at maximum. Same for the destination-address.
>>
>> I have tried to Google about this limitation for Junos12.1X46-D40.2 for
>> SRX1400 ... and for Junos15.1X49-D60.7 for SRX1500 to no avail.
>> So far when I create NAT rule, I limit the source and destination
>> addresses
>> to 8 lines respectively. But I currently have a requirement for which I
>> have tons of sources. If the limit is now bigger for the above versions,
>> I'd like to maximise each of my NAT rules.
>>
>> So appreciate if anyone can confirm how many sources I can have on NAT
>> rule
>> for the above versions of Junos.
>>
>> Cheers
>> ___
>> 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] Cut-through forwarding statistics on QFX5100

2017-06-22 Thread Nelson, Brian
Model: qfx5100-96s-8q
Junos: 14.1X53-D42.3

user@qfx5100-96s# set forwarding-options cut-through ?
Possible completions:
  <[Enter]>Execute this command
> accounting   Configure accounting of traffic
> analyzer Analyzer options
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> dhcp-relay   Dynamic Host Configuration Protocol relay configuration
> enhanced-hash-keySelect data used in the hash key for Enhanced IP 
> Forwarding Engines
> family   Protocol family
> hash-key Select data used in the hash key
> helpers  Port forwarding configuration
> load-balance Configure load-balancing attributes on the forwarding 
> path
> local-bias   Turn on local bias functionality
  no-load-balance-label-capability  Disable load balance label capability
> port-mirroring   Configure port mirroring of traffic
> storm-control-profiles  Storm control profile for this instance
  vrf-fallback Enable vrf-fallback forwarding. This will restart PFE
  |Pipe through a command

Brian Nelson
Dept of CS
UTD

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Brant Ian Stevens
Sent: Thursday, June 22, 2017 10:24 AM
To: Aaron Gould 
Cc: juniper-nsp@puck.nether.net; 'Thomas Bellman' 
Subject: Re: [j-nsp] Cut-through forwarding statistics on QFX5100

It is readily available in 17.2; not sure about earlier versions.

branto@host# set forwarding-options ?
Possible completions:
 > access-security  Access security configuration
 > accounting   Configure accounting of traffic
 > analyzer Analyzer options
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these 
+ groups
   cut-through  Enable cut-through forwarding
 > dhcp-relay   Dynamic Host Configuration Protocol relay 
configuration
 > enhanced-hash-keySelect data used in the hash key for Enhanced IP 
Forwarding Engines
 > family   Protocol family
 > hash-key Select data used in the hash key
 > helpers  Port forwarding configuration
 > ip-options-protocol-queue  IP Options protocol logical queue parameters
 > load-balance Configure load-balancing attributes on the 
forwarding path
 > local-bias   Turn on local bias functionality
 > port-mirroring   Configure port mirroring of traffic
 > storm-control-profiles  Storm control profile for this instance
   vrf-fallback Enable vrf-fallback forwarding. This will 
restart PFE

> Aaron Gould 
> June 22, 2017 at 10:21 AM
> Sorry I don't have an answer... but interestingly, I see this as a hidden 
> command on the cousin ACX5048... is it hidden in the QFX5100 or in plain view 
> using the ? after set forwarding-option ?
>
> I haven't used it nor committed it further so I don't know of its 
> functionality on this ACX5048
>
> {master:0}[edit]
> agould@eng-lab-5048-1# run show version
> fpc0:
> --
> 
> Hostname: eng-lab-5048-1
> Model: acx5048
> Junos: 15.1X54-D20.7
>
> ...
>
> agould@eng-lab-5048-1# set forwarding-options ?
> Possible completions:
>> accounting   Configure accounting of traffic
> + apply-groups Groups from which to inherit configuration data
> + apply-groups-except  Don't inherit configuration data from these 
> + groups
>> dhcp-relay   Dynamic Host Configuration Protocol relay configuration
>> family   Protocol family
>fast-reroute-priority  Fast-reroute repair priority
>> hash-key Select data used in the hash key
>> helpers  Port forwarding configuration
>no-load-balance-label-capability  Disable load balance label 
> capability
>> port-mirroring   Configure port mirroring of traffic
>> sampling Statistical traffic sampling options
>> storm-control-profiles  Storm control profile for this instance
> {master:0}[edit]
> agould@eng-lab-5048-1# set forwarding-options cut-through
>
> {master:0}[edit]
> agould@eng-lab-5048-1# show | compare
> [edit]
> +  forwarding-options {
> +  cut-through;
> +  }
>
>
> - Aaron Gould
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> Thomas Bellman  June 21, 2017 at 6:28 PM 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> We have a QFX5100 on which we have enabled cut-throug forwarding ('set 
> forwarding-options cut-through'). Now I am curious about how effective 
> that is. Is there any statistics one can dig out about how often the 
> switch is able to do cut-through, and how often it has to fall back to 
> stor

Re: [j-nsp] Cut-through forwarding statistics on QFX5100

2017-06-22 Thread Brant Ian Stevens

It is readily available in 17.2; not sure about earlier versions.

branto@host# set forwarding-options ?
Possible completions:
> access-security  Access security configuration
> accounting   Configure accounting of traffic
> analyzer Analyzer options
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  cut-through  Enable cut-through forwarding
> dhcp-relay   Dynamic Host Configuration Protocol relay 
configuration
> enhanced-hash-keySelect data used in the hash key for Enhanced IP 
Forwarding Engines

> family   Protocol family
> hash-key Select data used in the hash key
> helpers  Port forwarding configuration
> ip-options-protocol-queue  IP Options protocol logical queue parameters
> load-balance Configure load-balancing attributes on the 
forwarding path

> local-bias   Turn on local bias functionality
> port-mirroring   Configure port mirroring of traffic
> storm-control-profiles  Storm control profile for this instance
  vrf-fallback Enable vrf-fallback forwarding. This will 
restart PFE



Aaron Gould 
June 22, 2017 at 10:21 AM
Sorry I don't have an answer... but interestingly, I see this as a hidden 
command on the cousin ACX5048... is it hidden in the QFX5100 or in plain view 
using the ? after set forwarding-option ?

I haven't used it nor committed it further so I don't know of its functionality 
on this ACX5048

{master:0}[edit]
agould@eng-lab-5048-1# run show version
fpc0:
--
Hostname: eng-lab-5048-1
Model: acx5048
Junos: 15.1X54-D20.7

...

agould@eng-lab-5048-1# set forwarding-options ?
Possible completions:

accounting   Configure accounting of traffic

+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups

dhcp-relay   Dynamic Host Configuration Protocol relay configuration
family   Protocol family

   fast-reroute-priority  Fast-reroute repair priority

hash-key Select data used in the hash key
helpers  Port forwarding configuration

   no-load-balance-label-capability  Disable load balance label capability

port-mirroring   Configure port mirroring of traffic
sampling Statistical traffic sampling options
storm-control-profiles  Storm control profile for this instance

{master:0}[edit]
agould@eng-lab-5048-1# set forwarding-options cut-through

{master:0}[edit]
agould@eng-lab-5048-1# show | compare
[edit]
+  forwarding-options {
+  cut-through;
+  }


- Aaron Gould


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Thomas Bellman 
June 21, 2017 at 6:28 PM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

We have a QFX5100 on which we have enabled cut-throug forwarding
('set forwarding-options cut-through'). Now I am curious about
how effective that is. Is there any statistics one can dig out
about how often the switch is able to do cut-through, and how
often it has to fall back to store-and-forward? I haven't found
anything in 'show interfaces extensive', nor any other promising
'show' command.

The dream would of course be to get counters for every combination
of ingress and egress interface, but I would be happy to get just
counters for just ingress or egress, or even just a total for the
entire system.

The switch is running Junos 17.2R1 if that matters.


- -- 
Thomas Bellman, National Supercomputer Centre, Linköping Univ., Sweden

"We don't understand the software, and ! bellman @ nsc . liu . se
sometimes we don't understand the hardware, !
but we can *see* the blinking lights!" ! Make Love -- Nicht Wahr!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJZSvMeAAoJEGqUdKqa3HTsuwUP/3YluYW/rUn9igIAd4Jvv/HI
g+Dnr6WuHejv9lKzVaZnsf8XuJkEzXpsVuEzGcBOyn10a77axltEhVwp/pUdPLM6
/tr04Z0P3at51sQUP3SCot+CxPhfVkJ4TB9j5HET5zouwRBTDFlvPhpRoWStaGjz
VV/5AlQDAD3xrw49ypFiJ+FQ122hj1Xz6EVzioDPf/zbtg86c8mxkhZPiaS+H2jE
Pf3H0hTDtL7YZSKlmevX0u2jiNJFALutgkvCNB8+vZjO2eYdjGEtdsrz4Nxw2Mkv
46Q8niW75jOovLmnkQj1iMyaG9DljXf76zl1jQyXlKWX97+pV88OQPqYWZOf3rUZ
dNZyyy+7kF0iMLOG1u/F8ufTm0PqXgbWtx4EaSjj7kwUNCxlv/IvuBnxsB4cv8dH
vzsy4hxpRkMMyqmHuXrPIdj24Dk9+vpxJgsZ/X6GsVkrTwrkghBTCTxovhuQq7RM
ZMN4rIVGwSBYE8tKFcM6Rfs/nHhfggvwBKGs7OuKlMoGia5F5bwTZTIRQkiGoWuY
ipLXVhk713eecn/Ftpr0TYA43H+8LlOMgFWhO+u0hcS0y2wi++lHvDFRxamsxz9G
by7sp6DH3twx7I7fT/8zFL+tSD7scIeF8g7f91oW3kX8KV8WJ6YnuLyfSUDHSf+y
n9bM0LvWv9FLfiX2S4dq
=JXYJ
-END PGP SIGNATURE-
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


--

--
Regards,
--
Brant I. Stevens, Pri

Re: [j-nsp] how to send SRX240 traffic/session logs to syslog server

2017-06-22 Thread Aaron Gould
Oh my gosh, guess what….Syslog traps were arriving at the server all along….but 
were going into /var/log/daemon.log  …and I was grepping on /var/log/syslog
:|

 

Thanks for all your suggestions…

 

At this point using just 2 statements for “set system syslog host …. 
source-address …”… I see WEBFILTER logs hitting /var/log/daemon.log on the 
server….

Now I will go back and see what you all suggested about the logs for sending 
the cli output for “show security flow session….”

 

Thanks again

-Aaron Gould

 

 

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

Re: [j-nsp] Cut-through forwarding statistics on QFX5100

2017-06-22 Thread Aaron Gould
Sorry I don't have an answer... but interestingly, I see this as a hidden 
command on the cousin ACX5048... is it hidden in the QFX5100 or in plain view 
using the ? after set forwarding-option ?

I haven't used it nor committed it further so I don't know of its functionality 
on this ACX5048

{master:0}[edit]
agould@eng-lab-5048-1# run show version
fpc0:
--
Hostname: eng-lab-5048-1
Model: acx5048
Junos: 15.1X54-D20.7

...

agould@eng-lab-5048-1# set forwarding-options ?
Possible completions:
> accounting   Configure accounting of traffic
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> dhcp-relay   Dynamic Host Configuration Protocol relay configuration
> family   Protocol family
  fast-reroute-priority  Fast-reroute repair priority
> hash-key Select data used in the hash key
> helpers  Port forwarding configuration
  no-load-balance-label-capability  Disable load balance label capability
> port-mirroring   Configure port mirroring of traffic
> sampling Statistical traffic sampling options
> storm-control-profiles  Storm control profile for this instance
{master:0}[edit]
agould@eng-lab-5048-1# set forwarding-options cut-through

{master:0}[edit]
agould@eng-lab-5048-1# show | compare
[edit]
+  forwarding-options {
+  cut-through;
+  }


- Aaron Gould


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


Re: [j-nsp] inject unresolvable static route via bgp

2017-06-22 Thread Alexander Dube
Hi Alex, 

yes, 2.2.2.2 is resolvable on the core router. 

Your hint with advertising the connected routes to the injection router, works 
like a charm and is a suitable solution for us. Thank you :) 

Best regards 
Alex 


Von: "Alexander Arseniev"  
An: "Alexander Dube" , "juniper-nsp" 
 
Gesendet: Donnerstag, 22. Juni 2017 14:27:12 
Betreff: Re: [j-nsp] inject unresolvable static route via bgp 



Hello, 

Is 2.2.2.2 resolvable on a core router then? 

Via in interface/connected subnet perhaps? 

If yes then announce all conected subnets from core router(s) via iBGP to Your 
VMX. 

Then configure Your statics on VMX with "resolve" knob, and announce them via 
iBGP back to core router(s). Your VMX will keep the original "protocol NH" as 
specified in VMX config. 


HTH 

Thx 
Alex 

On 22/06/2017 12:39, Alexander Dube wrote: 



Hello, 

we try to implement a route injection with a vmx to reduce the count of static 
routes on our core routers ( a very large amount ... ) 

I've the problem, that if i set a static route on the vmx, it will be 
advertised with the wrong next-hop ( self in this case ) 
The session between the vmx and our core router is ibgp currently. Even with 
multihop no-nexthop-change it isnt working 


For example: 

show routing-options static route 1.1.1.1/32 
next-hop 2.2.2.2; 
passive; 

This will result in: 

show route 1.1.1.1/32 detail 

inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) 
1.1.1.1/32 (1 entry, 1 announced) 
*Static Preference: 5 
Next hop type: Reject, Next hop index: 0 
Address: 0xa06fec4 
Next-hop reference count: 2 
State:  
Local AS: 123 
Age: 2:06 
Validation State: unverified 
Task: RT 
Announcement bits (3): 0-KRT 4-BGP_RT_Background 5-Resolve tree 4 
AS path: I 


show route advertising-protocol bgp 10.0.0.2 

inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) 
Prefix Nexthop MED Lclpref AS path 
* 1.1.1.1/32 Self 100 I 


Is there any way that the router is advertising the correct unmodified next-hop 
and not self? 
I know that that this is possible with modifying the next-hop via the export 
policy and this works very well, but in our specific case this would result 
into a more than 500k lines policy-statement... 

Kind regards 
Alex 

___
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] inject unresolvable static route via bgp

2017-06-22 Thread Alexander Arseniev

Hello,

Is 2.2.2.2 resolvable on a core router then?

Via in interface/connected subnet perhaps?

If yes then announce all conected subnets from core router(s) via iBGP 
to Your VMX.


Then configure Your statics on VMX with "resolve" knob, and announce 
them via iBGP back to core router(s). Your VMX will keep the original 
"protocol NH" as specified in VMX config.


HTH

Thx
Alex


On 22/06/2017 12:39, Alexander Dube wrote:

Hello,

we try to implement a route injection with a vmx to reduce the count of static 
routes on our core routers ( a very large amount ... )

I've the problem, that if i set a static route on the vmx, it will be 
advertised with the wrong next-hop ( self in this case )
The session between the vmx and our core router is ibgp currently. Even with 
multihop no-nexthop-change it isnt working


For example:

show routing-options static route 1.1.1.1/32
next-hop 2.2.2.2;
passive;

This will result in:

show route 1.1.1.1/32 detail

inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
1.1.1.1/32 (1 entry, 1 announced)
*Static Preference: 5
Next hop type: Reject, Next hop index: 0
Address: 0xa06fec4
Next-hop reference count: 2
State: 
Local AS: 123
Age: 2:06
Validation State: unverified
Task: RT
Announcement bits (3): 0-KRT 4-BGP_RT_Background 5-Resolve tree 4
AS path: I


show route advertising-protocol bgp 10.0.0.2

inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 1.1.1.1/32 Self 100 I


Is there any way that the router is advertising the correct unmodified next-hop 
and not self?
I know that that this is possible with modifying the next-hop via the export 
policy and this works very well, but in our specific case this would result 
into a more than 500k lines policy-statement...

Kind regards
Alex

___
juniper-nsp mailing listjuniper-...@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] inject unresolvable static route via bgp

2017-06-22 Thread Alexander Dube
Hello, 

we try to implement a route injection with a vmx to reduce the count of static 
routes on our core routers ( a very large amount ... ) 

I've the problem, that if i set a static route on the vmx, it will be 
advertised with the wrong next-hop ( self in this case ) 
The session between the vmx and our core router is ibgp currently. Even with 
multihop no-nexthop-change it isnt working 


For example: 

show routing-options static route 1.1.1.1/32 
next-hop 2.2.2.2; 
passive; 

This will result in: 

show route 1.1.1.1/32 detail 

inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) 
1.1.1.1/32 (1 entry, 1 announced) 
*Static Preference: 5 
Next hop type: Reject, Next hop index: 0 
Address: 0xa06fec4 
Next-hop reference count: 2 
State:  
Local AS: 123 
Age: 2:06 
Validation State: unverified 
Task: RT 
Announcement bits (3): 0-KRT 4-BGP_RT_Background 5-Resolve tree 4 
AS path: I 


show route advertising-protocol bgp 10.0.0.2 

inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) 
Prefix Nexthop MED Lclpref AS path 
* 1.1.1.1/32 Self 100 I 


Is there any way that the router is advertising the correct unmodified next-hop 
and not self? 
I know that that this is possible with modifying the next-hop via the export 
policy and this works very well, but in our specific case this would result 
into a more than 500k lines policy-statement... 

Kind regards 
Alex 

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