Re: [j-nsp] SRX and MX Security

2015-12-27 Thread ashish verma 
http://www.juniper.net/documentation/en_US/junos13.3/topics/usage-guidelines/services-configuring-stateful-firewall-rules.html

For sync between the MS-MICs follow up directly with Juniper (there is a
solution but I have not tested it myself yet)

On Mon, Dec 28, 2015 at 8:22 AM, Santiago Martinez <
santiago.martinez...@gmail.com> wrote:

> Hi, there is no Inter chassis ha for the MX series with MS-cards . Also
> the number of supported IPSEC tunnel and tunnels per second is really
> low/bad. the pps is not as bad as the session but is nothing similar to
> what huawe or alcatel can do.
>
> regards
>
> santi
>
> Sent from my iPhone
>
> > On 27 Dec 2015, at 09:40, Ibariouen Khalid  wrote:
> >
> > Hi
> > we currenmly have an NS5400 firewalls (two FW in active /passive mode);
> we
> > are thinking to replace it with MS-MIC/MPC on existing MX-960.
> > can you please tell me if we can have redudancy with MX in this case ?
> > for your information we have NAT and IP-Sec.
> > i'm asking because in NS5400 we have HA port , and i'm wondering if in
> case
> > we use MX how redudancy and session sync will take place ?
> > can you please advise the fesability of the solution.
> > it"s urgent
> > Thanks a lot
> > ___
> > 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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 IPSEC VPN

2015-04-29 Thread ashish verma 
We are running IPSEC on MXs quite extensively and it has been fairly stable.
SRXs are good for IPSEC but depending on your performance requirement they
may not be able to scale well. MX80 IPSEC performance is much better than
SRX.
Configuration wise very similar as M7i or J series.

On Wed, Apr 29, 2015 at 10:12 PM, Stepan Kucherenko t...@megagroup.ru
wrote:

 I do.

 And would recommend you to stick to SRX instead. It'll probably be much
 cheaper as well.

 MX/MS-MIC works but I've spent too much time to get to that point. It's
 less documented, less used so Google can't help you, it's different, it
 doesn't play well with others, it was probably designed with a different
 use case in mind, and so on and so on.

 I wish someone said that a year ago somewhere so I wouldn't do that myself.

 Or you can get it, help Juniper to debug their problems, write blog posts
 about it somewhere and make it more useful for others, your choice :-)





 On 29.04.2015 14:51, Drew Weaver wrote:

 Does anyone have any real world experience in using MS-MIC-16G in an MX80
 in order to create VPN tunnels?

 We are considering using an MX80 for a AWS direct connect and we want to
 make sure that we can also have a VPN backup incase the physical link goes
 down.

 Thanks in advance.
 -Drew
 ___
 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

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

Re: [j-nsp] LACP accept-data

2015-01-19 Thread ashish verma 
yes we use it, haven't faced any problems. You wont be able to ping the
VRRP IP otherwise, required for testing etc.

On Tue, Jan 20, 2015 at 12:33 AM, Daniel Roesen d...@cluenet.de wrote:

 Hi,

 On Mon, Jan 19, 2015 at 12:06:23PM +, Adam Vitkovsky wrote:
  Is anyone using the accept-data knob under the lacp config on AE
  interfaces running as L3 please? Should be safe right?

 Yes. Why shouldn't it?

 Best regards,
 Daniel

 --
 CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
 ___
 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] SRX IPv6 VRRP

2014-08-12 Thread ashish verma 
There is an ER 057607 for this issue. Another option is to use IPv6 router
advertisements instead of VRRP.


On Tue, Aug 12, 2014 at 7:57 PM, Laurent CARON lca...@unix-scripts.info
wrote:

 Hi,

 I'm currently deploying SRX110/210/240.

 After having configured the IPv4 part, i'm willing to configure IPv6 VRRP.

 It however seems the functionnality is severely broken in many points:

 [1] states:
 - VRRP for IPv6 will not work if the Branch SRX platform is processing
 IPv6 in flow mode.
 - If the SRX is processing IPv6 in packet mode...However, even in this
 state, the SRX will not be able to process any packets, which are forwarded
 to the VIP address.

 This is quite not useful.

 The 'solution' offered on [1] is to set the interface in promisc
 mode...which:
 1/ is not really a good advice since all packets will hit the PFE
 2/ is not possible if you are using aggregated (ae) interfaces

 How did you guys solve this issue ?

 Thanks


 [1]: http://kb.juniper.net/InfoCenter/index?page=content;
 id=KB23988actp=searchviewlocale=en_USsearchid=1258894870731
 ___
 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] SRX IPv6 VRRP

2014-08-12 Thread ashish verma 
I don't have any details on the ETA. /64 is not bad if it solves your
problem and I guess most of the people use /64 as minimum.


On Wed, Aug 13, 2014 at 7:03 AM, Eugeniu Patrascu eu...@imacandi.net
wrote:

 On Tue, Aug 12, 2014 at 11:21 PM, Laurent CARON lca...@unix-scripts.info
 wrote:

 On 12/08/2014 22:15, Darren O'Connor wrote:

 You mean to say you're not using /64 on your subnet?


 Is it a crime ? ;)


 Is this fixed in any release? I'm planning on using a pair of SRX240 to do
 just that - IPv6 VRRP.

 Thanks.

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

Re: [j-nsp] SRX Adding Second ISP

2014-02-18 Thread ashish verma 
May be something like below would help.

show configuration security nat
source {
pool isp-1 {
address {
   x.x.x.x/x;
}
}
pool isp-2 {
address {
   y.y.y.y/y;
}
}
   rule-set TRUST-TO-UNTRUST {
from zone TRUST;
to zone UNTRUST;
rule nat-isp1 {
match {
source-address [ server-ip1 server-ip2 ];
}
then {
source-nat {
  pool {
   isp-1;
}
}
rule nat-isp2 {
match {
source-address [ server-ip3 server-ip4 ];
}
then {
source-nat {
  pool {
   isp-2;
}
}

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

Re: [j-nsp] Power adapter spec for AX411?

2014-01-13 Thread ashish verma 
btw it seem ax411 will be EOL soon..


On Sun, Jan 12, 2014 at 9:51 PM, Mark Menzies m...@deimark.net wrote:

 Same here. POE is the way to go.

 Mark Menzies
 sent via mobile device, please excuse errors
 On 12 Jan 2014 02:14, OBrien, Will obri...@missouri.edu wrote:

  I just used PoE. You can get a PoE injector pretty easily.
 
  On Jan 11, 2014, at 1:20 PM, Chris Woodfield rek...@semihuman.com
   wrote:
 
   Anyone know what type of power adapter (apart from ordering one
 directly
  from Juniper) I’d need to power an AX411 wireless AP? Or would I be
 better
  off simply getting an inline POE splitter?
  
   -C
   ___
   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
 
 ___
 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] family inet6 on st0.x

2013-08-07 Thread ashish verma 
I think you would need to run GRE over ipsec for ipv6 support.
On Aug 6, 2013 3:06 AM, Mike Williams mike.willi...@comodo.com wrote:

 Hey all,

 Am I being dense, or now that 'family inet6' can be configured on an st0.x
 interface, does it not actually work?


 I've configured the following on a pair of J6350 clusters;

 set interfaces st0 unit 634 description rmdcccjs-dwdcccjs
 set interfaces st0 unit 634 family inet mtu 1500
 set interfaces st0 unit 634 family inet address 10.xxx.xxx.135/31
 set interfaces st0 unit 634 family inet6 mtu 1500
 set interfaces st0 unit 634 family inet6 address 2a02::87/64
 set security ike gateway rmdcccjs-dwdcccjs ike-policy tunnel-pol
 set security ike gateway rmdcccjs-dwdcccjs address 178.xxx.xxx.251
 set security ike gateway rmdcccjs-dwdcccjs external-interface reth1.500
 set security ike gateway rmdcccjs-dwdcccjs version v2-only
 set security ipsec vpn rmdcccjs-dwdcccjs bind-interface st0.634
 set security ipsec vpn rmdcccjs-dwdcccjs ike gateway rmdcccjs-dwdcccjs
 set security ipsec vpn rmdcccjs-dwdcccjs ike proxy-identity local
 10.xxx.xxx.135/31
 set security ipsec vpn rmdcccjs-dwdcccjs ike proxy-identity remote
 10.xxx.xxx.134/31
 set security ipsec vpn rmdcccjs-dwdcccjs ike proxy-identity service any
 set security ipsec vpn rmdcccjs-dwdcccjs ike ipsec-policy tunnel-pol
 set security ipsec vpn rmdcccjs-dwdcccjs establish-tunnels immediately
 set security zones security-zone ipsec_vpn interfaces st0.634
 set routing-instances ipsec interface st0.634
 set routing-instances ipsec protocols ospf area 0.0.0.0 interface st0.634
 set routing-instances ipsec protocols ospf3 area 0.0.0.0 interface st0.634


 Where 10.xxx.xxx.134/31 and 2a02::87/64 are appropriately swapped/changed
 at the other end.
 The devices are entirely flow-mode (security forwarding-options family
 inet6 mode flow-based).
 One cluster is 12.1X45-D10, the other 12.1X44-D15.5.
 The MTU between the devices is at least 1800 bytes all the way through.
 reth1.500 is also in the ipsec_vpn zone, and all intra-zone traffic is
 permitted.
 I've even had host-inbound-traffic set to all all.


 IPv4 works fine, but IPv6 just, well, doesn't.

 Can't ping the link-local or global addresses across the tunnel, OSPF3
 hellos are being being sent but not received.
 'monitor traffic interface st0.634' says OSPFv2 hellos are coming In and
 Out, and unknown protocol (0x006c) is going Out only.


 Pretty much the only documentation I can find is for IPSec over IPv6 (as
 in, v6 gateway addresses).
 Nowt about configuring IPv6 on the tunnel interface.


 I don't mind if anyone does prove I'm being dense!

 Thanks

 --
 Mike Williams
 ___
 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] SRX 3600 dropped packets - how to debug?

2013-05-28 Thread ashish verma 
See if this article helps you (juniper login required)

http://kb.juniper.net/InfoCenter/index?page=contentid=KB16509smlogin=true


On Tue, May 28, 2013 at 2:41 AM, Phil Mayers p.may...@imperial.ac.ukwrote:

 On 05/27/2013 03:45 PM, OBrien, Will wrote:

  Are you using any alg?


 Ah ha... thanks for the nudge. The ALG settings are SRX-defaults:

 admin@srx-eval show security alg status
 ALG Status :
   DNS  : Enabled
   FTP  : Enabled
   H323 : Disabled
   MGCP : Disabled
   MSRPC: Enabled
   PPTP : Enabled
   RSH  : Enabled
   RTSP : Disabled
   SCCP : Disabled
   SIP  : Disabled
   SQL  : Enabled
   SUNRPC   : Enabled
   TALK : Enabled
   TFTP : Enabled
   IKE-ESP  : Disabled

 Disabling the DNS ALG significantly reduces the rate of counter
 increments. Presumably the other traffic is other, less-used ALGs.

 So, the ALG(s) are suspect.

 That said, I can't believe the firewall was *actually* dropping 1500pps of
 DNS traffic; we'd have widespread problems reported, surely. So, it seems
 that maybe ALG-processed traffic is being counted under packets dropped
 for show security flow statistics?

 A brief test from a linux box behind the firewall shows it can do
 glibc-style getaddrinfo() calls (A and  lookup from same UDP socket
 back-to-back) and both requests and replies are forwarded with the ALG
 enabled, so I'm disinclined to believe it's *actually* dropping.

 Does it seem reasonable that the counter is in error?

 __**_
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://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] Juniper SRX 3400 Clustering

2013-05-02 Thread ashish verma 
It is needed to have dual control links.


On Wed, May 11, 2011 at 9:17 PM, Altaf Ahmad aah...@bmc.com.sa wrote:

 Hi Experts,

 ** **

 I did configure the clustering of SRX 3400 chassis without installing
 SRX3K-CRM Module and it went successful. Could anyone please let tell me
 that then what is the purpose of CRM? Even in Juniper SRX3400 hardware
 guide I read that this module is necessary for the clustering.  But I am
 achieving the clustering feature without  installing the module. 

 ** **

 ** **

 Kind Regards,

 ** **

 [image: Description: cid:image005.png@01CBC300.A254E4C0] * Altaf Ahmad** *
 *|** **Senior Solutions Designer*

 *   **CCIE # 28697 (RS), CCIE SP (Written), CCSP*

  

 *Business Management Company **(BMC)*

  

 Anouf Building, Ihsaa St. Malaz Dist., P.O. Box 25650, Riyadh 11476, KSA**
 **

 )*:* +966  561 538336 *|** ** *(*: *+966 1 4793 247 Extension 594   *|** *
 *7**:* +966 1 4790 878 * *
 *Email:*  aah...@bmc.com.sa wala...@bmc.com.sa  | *URL:*  www.bmc.com.sa
 

 ** **

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

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

Re: [j-nsp] Confusion about DSCP marking and rewrite rules

2013-04-01 Thread ashish verma 
Ingress ipv6 marking is supported on MX. You need to use 'then traffic
class'.
On Apr 1, 2013 2:25 AM, Mark Tinka mark.ti...@seacom.mu wrote:

 On Monday, January 14, 2013 10:55:11 AM Per Granath wrote:

  On egress you may apply a rewrite rule to a class (on an
  interface). Essentially, this means you cannot rewrite
  on ingress.

 On IQ2 and IQ2E PIC's, you can remark on ingress with the
 ToS Translation Tables feature.

 On the MX running Trio line cards, you can remark on ingress
 with an ingress firewall filter, but sadly, this doesn't
 support EXP or IPv6 DSCP bits.

 I like the ToS Translation Tables, but it's limited to
 platforms that run those line cards (which is not to say
 that an IQ2 or IQ2E PIC in an MX-FPC will work - never
 tried).

 Mark.

 ___
 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] Help needed with IPSEC VPN on J-Series

2013-03-21 Thread ashish verma 
Commit full?

Also do you a have static route for the peer gateway IP?
I tried the deactivate, commit, reactivate, commit method…no such luck :(







On 2013-03-20 2:12 PM, Gabriel Blanchard g...@teksavvy.ca wrote:

Same thing here, that or I had to

deactivate security vpn name
commit
and reactivate.
commit

On 13-03-20 02:03 PM, Bjørn Tore wrote:
 As I mentioned offline - I once had to reboot an SRX 240 after changing
IPSEC config, to make things come up. Might not be the case here, but
with the code quality these days - who knows..

 Bjørn Tore @ mobil

 Den 20. mars 2013 kl. 18:57 skrev Patrick Dickey
dickeypj...@yahoo.com:

 I'd start to suspect the other side of the tunnel. What is your peer
device?



 On Mar 20, 2013, at 11:55 AM, Bill Sandiford
b...@telnetcommunications.com wrote:

 So I added the following configuration in.  The syntax was a little
 different than what you sent, but basically the same thing (I think).

 show configuration security policies
 from-zone trust to-zone trust {
   policy policy1 {
   match {
   source-address any;
   destination-address any;
   application any;
   }
   then {
   permit;
   }
   }
 }
 default-policy {
   permit-all;
 }



 Šbut still not working :(




 On 2013-03-20 12:29 PM, Aaron Dewell aaron.dew...@gmail.com wrote:


 You'll also need a policy which allows traffic from trust to trust,
i.e.:

 set security policies from-zone trust to-zone trust match
source-address
 any
 set security policies from-zone trust to-zone trust match
 destination-address any
 set security policies from-zone trust to-zone trust match protocol
any
 set security policies from-zone trust to-zone trust then permit

 Cross-interface traffic is not allowed by default even within the
same
 zone.

 On Mar 20, 2013, at 10:16 AM, Bill Sandiford wrote:
 For the most part this J-series has always just acted as a router
 without
 any tunnels per se.  As such, I have always had all interfaces in
the
 trust zone, as follows

 zones {
  security-zone trust {
  tcp-rst;
  host-inbound-traffic {
  system-services {
  any-service;
  }
  protocols {
  all;
  }
  }
  interfaces {
  all;
  }
  }
 }

 Will this accomplish what you are suggesting?







 On 2013-03-20 11:52 AM, Patrick Dickey dickeypj...@yahoo.com
wrote:

 I don't remember if the J series behaves exactly like the SRXs
when it
 comes
 to IPSec, but if it is make sure to put the st0.x interface into a
 security
 zone and have a security policy allowing the traffic.

 I believe that's only a requirement if you're running the enhanced
 services/security code on the J, but I think you have to be to get
 IPSec.

 HTH


 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net
 [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Bill
 Sandiford
 Sent: Wednesday, March 20, 2013 8:47 AM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] Help needed with IPSEC VPN on J-Series

 Hi All,

 I need some help with an IPSEC tunnel that I just can't seem to get
 working
 on a J-6350.  I have been able to get the tunnels to come up, but
can't
 seem
 to pass traffic over the tunnels

 I've done the usual things.  I've created an st0.0 interface and
bound
 it
 to
 the tunnel using the bind-interface command.  I've created a static
 route
 and pointed it at the st0.0 interface.  I just can't seem to get
 traffic
 to
 pass over the tunnel.

 Any help or suggestions would be appreciated.  I'm also willing to
put
 a
 $$$
 bounty on this for anyone that is willing to help me get it
working via
 teamviewer.

 Regards,
 Bill


 ___
 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

 ___
 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

___
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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NAT on MX5?

2012-12-13 Thread ashish verma 
You can only do 1:1 NAT. One to many is not supported until the new service
mic is ready.


On Fri, Dec 14, 2012 at 4:25 PM, Luca Salvatore l...@ninefold.com wrote:

 Ermm  Feel weird asking this but can I do NAT on a MX5?
 It doesn't seem have the features:


 # set services ?
 Possible completions:
 + apply-groups Groups from which to inherit configuration data
 + apply-groups-except  Don't inherit configuration data from these groups
  rpm  Real-time performance monitoring

 Where's my NAT?
 ___
 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] NAT on MX5?

2012-12-13 Thread ashish verma 
I am running 11.4r6 and got the below option.

root@mx1# set services ?
Possible completions:
 adaptive-services-pics  Adaptive Services PIC daemon configuration
 application-identification
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
 captive-portal-content-delivery  Configuration for captive portal and
content delivery service
 flow-monitoring  Configure flow monitoring
 flow-tap Configure flow-tap parameters
 ids  Configure the intrusion detection system
 ipsec-vpnConfigure IPSec VPN service
 l2tp Configure Layer 2 Tunneling Protocol service
 mobile-ipMobile IPv4 options
 nat  Configure Network Address Translation
 ptsp Packet Triggered Subscribers Policy services
configuration
 radius-flow-tap  Configure radius triggered flow-tap parameters
 rpm  Real-time performance monitoring
 service-device-pools  Configure service device pools
 service-interface-pools  Configure service interface pools
 service-set  Define a service set
 softwire Configure softwire services
 stateful-firewallConfigure stateful firewall services


On Fri, Dec 14, 2012 at 4:37 PM, Luca Salvatore l...@ninefold.com wrote:

 Yeah I know that... but its not even showing up in the config...

 ** **

 Luca

 ** **

 *From:* ashish verma [mailto:ashish.s...@gmail.com]
 *Sent:* Friday, 14 December 2012 4:35 PM
 *To:* Luca Salvatore
 *Cc:* juniper-nsp@puck.nether.net
 *Subject:* Re: [j-nsp] NAT on MX5?

 ** **

 You can only do 1:1 NAT. One to many is not supported until the new
 service mic is ready.

 ** **

 On Fri, Dec 14, 2012 at 4:25 PM, Luca Salvatore l...@ninefold.com wrote:
 

 Ermm  Feel weird asking this but can I do NAT on a MX5?
 It doesn't seem have the features:


 # set services ?
 Possible completions:
 + apply-groups Groups from which to inherit configuration data
 + apply-groups-except  Don't inherit configuration data from these groups
  rpm  Real-time performance monitoring

 Where's my NAT?
 ___
 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] ACL behaviour

2012-11-30 Thread ashish verma 
BGP needs to be allowed in loopback JCL if you have one applied. Otherwise
the peer wont come up.


On Fri, Nov 30, 2012 at 5:36 PM, Ali Sumsam
ali+juniper...@eintellego.netwrote:

 Hi,
 There is an ACL on a Cisco router which doesn't have a statement which
 allows the BGP peering IPs through the interface (where the ACL is
 applied). However, the BGP is still getting established.

 I am doing the same thing on Juniper, and the BGP peering is not coming up.
 If I allow the BGP peer IP in the Juniper firewall filter, it lets the BGP
 come up.

 My assumption is that Cisco doesn't apply the ACL on the traffic that is
 generated by the router itself. Is this the reason of the above behavior?
 Or is there something else? Please comment.

 Regards,
 *Ali Sumsam CCIE*
 *Network Engineer - Level 3*
 eintellego Pty Ltd
 a...@eintellego.net ; www.eintellego.net

 Phone: 1300 753 383 ; Fax: (+612) 8572 9954

 Cell +61 (0)410 603 531

 facebook.com/eintellego
 PO Box 7726, Baulkham Hills, NSW 1755 Australia

 The Experts Who The Experts Call
 Juniper - Cisco – Brocade - IBM
 ___
 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] unidirectional L2 port mirror

2012-11-22 Thread ashish verma 
Hi Paul

I have noticed the same behavior as well. If you configure Layer 3 port
mirroring then you will see traffic in both directions.



On Wed, Oct 24, 2012 at 7:07 AM, Paul Vlaar p...@vlaar.net wrote:

 I'm trying to do basic L2 port mirroring based on the Juniper document
 called MX Series Ethernet Services Routers Layer 2 Configuration Guide
 Release 10.1.  I have the following config for L2 port mirroring on an
 MX80 running 12.2R1.3.

 The port-mirroring configuration:

 mx80 show configuration forwarding-options port-mirroring family vpls
 output {
 interface ge-1/3/2.0;
 }

 Note that family vpls is synonymous to family bridge according to
 the documentation, and that family bridge can't be opted here.

 This is the interface that connects the analyzer server:

 mx80 show configuration interfaces ge-1/3/2
 encapsulation ethernet-bridge;
 unit 0 {
 family bridge;
 }

 This is the interface I'd like to port mirror, both in and out:

 mx80 show configuration interfaces ge-1/0/2
 encapsulation ethernet-bridge;
 unit 0 {
 family bridge {
 filter {
 input mirror;
 output mirror;
 }
 }
 }

 This is the firewall filter that calls the port-mirror directive:

 mx80 show configuration firewall family bridge filter mirror
 term all {
 then {
 accept;
 port-mirror;
 }
 }

 Interface ge-1/0/2 is part of a bridge domain:

 mx80 show bridge domain interface ge-1/0/2.0

 Bridge domain: VLAN100, Index: 2
 Logical  OuterInnerSequence  Logical
 InterfaceVLAN VLAN NoFlags
 ge-1/0/2.0 0

 Interface ge-1/3/2 is also part of a bridge domain:

 mx80 show bridge domain interface ge-1/3/2.0

 Bridge domain: analyzers, Index: 4
 Logical  OuterInnerSequence  Logical
 InterfaceVLAN VLAN NoFlags
 ge-1/3/2.0

 All seems well:

 mx80 show forwarding-options port-mirroring
 Instance Name: global_instance
   Instance Id: 1
   Input parameters:
 Rate  : 1
 Run-length: 1
 Maximum-packet-length : 0
   Output parameters:
 Family  State Destination  Next-hop
 vplsupge-1/3/2.0


 On the analyzer box, I do a tcpdump on the corresponding interface and I
 ping the server connected to ge-1/0/2.0 from a server that is not
 directly connected to the MX80, and I look for ICMP request and reply:

 [root@analyzer]# tcpdump -n -i igb0 -e | grep -i icmp | egrep -i
 'reply|request'
 15:48:23.661173 00:1b:21:84:d7:a6  80:71:1f:c6:34:f0, ethertype 802.1Q
 (0x8100), length 102: vlan 100, p 0, ethertype IPv4, x.x.158.13 
 y.y.198.213: ICMP echo reply, id 50552, seq 0, length 64
 15:48:24.662304 00:1b:21:84:d7:a6  80:71:1f:c6:34:f0, ethertype 802.1Q
 (0x8100), length 102: vlan 100, p 0, ethertype IPv4, x.x.158.13 
 y.y.198.213: ICMP echo reply, id 50552, seq 1, length 64
 15:48:25.663276 00:1b:21:84:d7:a6  80:71:1f:c6:34:f0, ethertype 802.1Q
 (0x8100), length 102: vlan 100, p 0, ethertype IPv4, x.x.158.13 
 y.y.198.213: ICMP echo reply, id 50552, seq 2, length 64

 (IP addresses have been anonymized)

 I see only the ICMP *reply* coming out of the port, not the request.
 Note that all traffic is tagged with VLAN 100.

 Then I ping from a host that is connected in the same bridge domain as
 ge-1/0/2 and in the same subnet, connected to ge-1/3/0.0, and I see:

 [root@analyzer]# tcpdump -n -i igb0 -e | grep -i icmp | egrep -i
 'reply|request'
 15:52:52.982512 00:1b:21:86:a5:22  00:1b:21:84:d7:a6, ethertype IPv4
 (0x0800), length 98: x.x.158.5  x.x.158.13: ICMP echo request, id 6679,
 seq 0, length 64
 15:52:52.982612 00:1b:21:84:d7:a6  00:1b:21:86:a5:22, ethertype 802.1Q
 (0x8100), length 102: vlan 100, p 0, ethertype IPv4, x.x.158.13 
 x.x.158.5: ICMP echo reply, id 6679, seq 0, length 64

 So there I *am* seeing the request as plain IPv4, and the reply as well
 which is tagged with VLAN 100 like before.

 Anyone have any clue as to why I am not seeing traffic going into the
 port when it originates from outside the router, but only the outbound?

 Am I missing something here?

 Thanks,

 ~paul





 ___
 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] SRX IPSEC performance

2012-09-16 Thread ashish verma 
Great that helps a lot!
I will try testing the 11.4 code as well.

On Mon, Sep 17, 2012 at 8:52 AM, Mike Devlin gossa...@meeksnet.ca wrote:

 Unfortunately, no forcing the traffic of a tunnel an SPU just isnt capable.

 The hashing of tunnels to SPCs also changes depending on the number of
 SPC, and the slots they are located in.  Code also plays a factor.  there
 was a more recent code 11.4 something release in May that did more a round
 robin distribution of the tunnels, instead of the hashing.  It was designed
 to take into account, what if, an SPC failed

 I was running the SPC in combo mode, since it was a 3600, and my company
 didnt want to pay the additional fee to have it flipped into dedicated
 mode.  5800s, you just need 2 SPCs (3SPUs for flows, 1 for control) to
 achieve dedicated mode, 3600 needs a license.

 We were however configured in a fashion that the combo mode spc had
 nothing landing on it.

 reth0 interface was not configured with vlan tagging, but had 2 ips signed
 to reth0.0 interface in the same /28 IP space.
 in the ike config, where you specified the remote peer address (pretty
 sure its the gateway config, not logged into a box at the moment to verify)
 there is a hidden config you can use which is local-address, which allowed
 us to specify which of the 2 assigned to reth0.0 that association would
 use.

 I dont remember exactly what i used for an mtu, but i did do up all my
 math, so that i could minimize any fragmentation at any stage, since it
 will obviously reduce performance and throughput.  i think it was 1450 on
 the reth interface, then subtracted the IPSEC headers, and all the other
 headers, and set the st0 mtu to that value.

 the process was a painful learning experience, and was sadly with
 production traffic.  Took weeks of troubleshooting with A-TAC.


 On Sat, Sep 15, 2012 at 11:10 PM, ashish verma ashish.s...@gmail.comwrote:

 Hi Mike, Devin

 Thanks for your replies.

 Mike, Do you have the CP running in dedicated mode ? What packet size did
 you use for testing?

 kmd is quite useful in identifying which SPC will be used for the
 specific tunnel. Is there a way we can force an IPSEC to terminate on a
 required SPC to load balance better?

 Thanks again.


 On Sun, Sep 16, 2012 at 12:49 PM, Mike Devlin gossa...@meeksnet.cawrote:

 So i have personally achieved 1.6G throughput per SPC on and SRX3600 on
 10.4R9.2 code line.

 I was required to push 3.5G from a single source, which required the use
 of a hidden command in what i remember being the gateway config.

 i also had to pop out to the shell, and use kmd -T ip1:ip2

 The ips required here are those of the IKE association.  We in the end,
 needed 2 IPs on both sides to split the traffic across 3 SPCs, and it
 required substantial planning to get these numbers.

 Going to 12 code, which i never got to test, i had an elaborate plan to
 attempt equal cost load balancing across multiple IPSEC VPNs on 5800s, but
 was unfortunately laid off before i got to work out the finer details of it.




 On Fri, Sep 14, 2012 at 8:49 AM, Devin Kennedy 
 devinkennedy...@hotmail.com wrote:

 Hi Ashish:

 I recently tested the SRX3400 for IPsec tunnel setup rates and was able
 to
 setup 3600 tunnels using IxVPN testing tool.  I only sent traffic
 across the
 tunnels for 1 minute but the testing was successful.  We were running
 4x SPC
 and 2xNPC in our configuration.  We were using one GE WAN interface as
 well.
 Our primary purpose was just to test that number of IPsec tunnels that
 we
 needed for a future implementation.


 Devin


 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net
 [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of ashish verma
 Sent: Thursday, September 13, 2012 5:35 PM
 To: juniper-nsp
 Subject: [j-nsp] SRX IPSEC performance

 Hi All,

 Has anyone here done IPSEC performance tests for SRX3k and share your
 results?
 Juniper claims that with 1400bytes of packet with 2SPC and 1NPC VPN
 throughput is 3Gbps. How much have you achieved?

 Ashish
 ___
 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





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

Re: [j-nsp] SRX IPSEC performance

2012-09-15 Thread ashish verma 
Hi Mike, Devin

Thanks for your replies.

Mike, Do you have the CP running in dedicated mode ? What packet size did
you use for testing?

kmd is quite useful in identifying which SPC will be used for the specific
tunnel. Is there a way we can force an IPSEC to terminate on a required SPC
to load balance better?

Thanks again.


On Sun, Sep 16, 2012 at 12:49 PM, Mike Devlin gossa...@meeksnet.ca wrote:

 So i have personally achieved 1.6G throughput per SPC on and SRX3600 on
 10.4R9.2 code line.

 I was required to push 3.5G from a single source, which required the use
 of a hidden command in what i remember being the gateway config.

 i also had to pop out to the shell, and use kmd -T ip1:ip2

 The ips required here are those of the IKE association.  We in the end,
 needed 2 IPs on both sides to split the traffic across 3 SPCs, and it
 required substantial planning to get these numbers.

 Going to 12 code, which i never got to test, i had an elaborate plan to
 attempt equal cost load balancing across multiple IPSEC VPNs on 5800s, but
 was unfortunately laid off before i got to work out the finer details of it.




 On Fri, Sep 14, 2012 at 8:49 AM, Devin Kennedy 
 devinkennedy...@hotmail.com wrote:

 Hi Ashish:

 I recently tested the SRX3400 for IPsec tunnel setup rates and was able to
 setup 3600 tunnels using IxVPN testing tool.  I only sent traffic across
 the
 tunnels for 1 minute but the testing was successful.  We were running 4x
 SPC
 and 2xNPC in our configuration.  We were using one GE WAN interface as
 well.
 Our primary purpose was just to test that number of IPsec tunnels that we
 needed for a future implementation.


 Devin


 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net
 [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of ashish verma
 Sent: Thursday, September 13, 2012 5:35 PM
 To: juniper-nsp
 Subject: [j-nsp] SRX IPSEC performance

 Hi All,

 Has anyone here done IPSEC performance tests for SRX3k and share your
 results?
 Juniper claims that with 1400bytes of packet with 2SPC and 1NPC VPN
 throughput is 3Gbps. How much have you achieved?

 Ashish
 ___
 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



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

[j-nsp] SRX IPSEC performance

2012-09-13 Thread ashish verma 
Hi All,

Has anyone here done IPSEC performance tests for SRX3k and share your
results?
Juniper claims that with 1400bytes of packet with 2SPC and 1NPC VPN
throughput is 3Gbps. How much have you achieved?

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

Re: [j-nsp] SRX Static NAT - Not working in both directions

2012-09-08 Thread ashish verma 
are you using routing instance?


On Sat, Sep 8, 2012 at 11:01 AM, Patrick Dickey dickeypj...@yahoo.comwrote:

 I'm a little confused here. Where does the 192.168.17.16 network reside?

 The static NAT will only NAT the 192.168.35.200 IP when its initiating
 traffic to the FROM zone in the static NAT configuration, not just
 generally.
 What does a flow from the 192.168.32.x/24 network look like when trying to
 get to the 192.168.35.200 (or 192.168.32.5). How about in the reverse?

 Patrick

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net
 [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Oliver Garraux
 Sent: Friday, September 07, 2012 5:08 PM
 To: Brent Jones
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] SRX Static NAT - Not working in both directions

 Brent, Patrick,

 Thanks for the replies.

 When I change the rule-set to apply to traffic from the user zone, I'm
 seeing the same behavior.  The source address on traffic from the desktop
 (192.168.35.200) out to the rest of the network isn't being NAT'ed.  I also
 can't initiate connections to 192.168.32.5 from the rest of my network.

 I've also tried putting both the user and trust zones in the rule-set.
  In that scenario, I can connect to 192.168.32.5 from outside, but the
 outgoing traffic from 192.168.35.200 still isn't NAT'ed.

 Thanks,

 Oliver

 -

 Oliver Garraux
 Check out my blog:  www.GetSimpliciti.com/blog Follow me on Twitter:
 twitter.com/olivergarraux


 On Fri, Sep 7, 2012 at 5:34 PM, Brent Jones br...@brentrjones.com wrote:
  Try to apply the static NAT policy to zone 'user' and see how that goes.
 
  On Fri, Sep 7, 2012 at 12:22 PM, Oliver Garraux oli...@g.garraux.net
 wrote:
  Hey,
 
  I recently bought an SRX and have been trying the different NAT
  configuration options to become more familar with JunOS.
 
  Static NAT isn't operating quite as I'd expect from the documentation.
   My understanding is that static NAT should be bidirectional, in that
  it should translate connections going in both directions.
 
  I'm using 192.168.32.0/24 on the interface connected to the rest of
  my network (ge-0/0/0.100), and 192.168.35.0/24 on vlan.200 on my SRX.
  ge-0/0/0.100 is in the trust zone, and vlan.200 is in the user
  zone.
 
  static {
  rule-set user_to_trust {
  from zone trust;
  rule desktop1 {
  match {
  destination-address 192.168.32.5/32;
  }
  then {
  static-nat prefix 192.168.35.200/32;
  }
  }
  }
  }
  proxy-arp {
  interface ge-0/0/0.100 {
  address {
  192.168.32.5/32;
  }
  }
  }
 
 
  I'm only seeing it translate connections coming in to the destination
  address (192.168.32.5).  The source address on connections initiated
  by the static-nat address (192.168.35.200 - the address on the
  desktop sitting behind my SRX) are not being translated to
  192.168.32.5.  Am I misunderstanding how static NAT works?
 
  I've tried using an IP that is routed to the SRX (where no proxy-arp
  should have been required in that situation).  I also don't see the
  address being translated when I look at these flows in show security
  flow session, so I don't think this is an issue with proxy-arp.  I'm
  permitting all traffic between the user and trust zones (in both
  directions) in my security policies.
 
  Here's one of the flow entries when I try to ping from 192.168.35.200
  to 192.168.17.16
 
  Session ID: 21626, Policy name: permit-all/5, Timeout: 16, Valid
In: 192.168.35.200/25622 -- 192.168.17.16/1280;icmp, If: vlan.200,
  Pkts: 1, Bytes: 60
Out: 192.168.17.16/1280 -- 192.168.35.200/25622;icmp, If:
  ge-0/0/0.100, Pkts: 0, Bytes: 0
 
  Any ideas?
 
  Thanks,
 
  Oliver
 
  -
 
  Oliver Garraux
  Check out my blog:  www.GetSimpliciti.com/blog Follow me on Twitter:
  twitter.com/olivergarraux
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/juniper-nsp
 
 
 
  --
  Brent Jones
  br...@brentrjones.com
 ___
 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

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

[j-nsp] SIP with SRX.

2012-08-28 Thread ashish verma 
Hi All,

Just looking for some recommendations on enabling SIP on SRX platform.
Are people using SIP ALG and does it behave as intended or have defined
specific policies to allow the flow?

If someone could give their working policies for reference that would be
great.

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

Re: [j-nsp] SIP with SRX.

2012-08-28 Thread ashish verma 
Do you have ALG enabled or disabled on 11.2 ?

FYI - We are running 3600.

On Tue, Aug 28, 2012 at 9:47 PM, Charlie Allom char...@mediasp.com wrote:

 On Tue, Aug 28, 2012 at 09:27:59PM +1000, ashish verma 
 ashish.s...@gmail.com wrote:
 
  Just looking for some recommendations on enabling SIP on SRX platform.
  Are people using SIP ALG and does it behave as intended or have defined
  specific policies to allow the flow?
 
  If someone could give their working policies for reference that would be
  great.

 YMMV: Without knowing the internals too much, I've found 11.2R7.4 on
 branch models to just work, whereas 10.4 did not so much.

   C.
 --
  http://mediasp.com/

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

Re: [j-nsp] jncip-sp lab study buddy

2012-07-09 Thread ashish verma 
I think there is no lab for JNCIP now a days.

On Mon, Jul 9, 2012 at 11:16 PM, Nikolay Abromov nabro...@gmail.com wrote:

 Dear All,

 I am looking for tech buddy to discuss SP topics and labs for JNCIP. Please
 let me know if anyone is interested. Skype_id: nabromov


 Best Regards,
 Nik
 ___
 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] Packet mode mpls (was Layer 2 feature on srx)

2012-04-11 Thread ashish verma 
Here is some explanation.

Branch SrX Series Services Gateways process packets using flow-based
forwarding by default. For the next several releases, the flow module will
support only IP traffic. When MPLS is configured, there is no way of
knowing if an IP packet entering the services gateway will require MPLS
encapsulation until the packet is processed, so enabling MPLS can be used
to force an SrX Series or J Series device to forward all IPv4 traffic in
packet mode.

security {

}

forwarding-options {
   family {

mpls {

  mode packet-based;
   }

} }

On Tue, Apr 10, 2012 at 5:37 PM, Pavel Lunin plu...@senetsy.ru wrote:

 Phil Mayers wrote:

 On 04/10/2012 06:17 AM, Doug Hanks wrote:
 
  In the context of packet-mode, the family mpls is analogous to inet.
  This
  is correct.
 
 
  Not sure I understand this.
 
  analogous implies what, here? That enabling packet-mode for MPLS
  implicitly enables it for IPv4?
 

 Yep. Same for ISO.


 
  If that's the case, why is there also a family inet option?
 

 Looks like first they meant to have different options for different
 families allowing to simultaneously have some in flow and some in packet
 mode. But it's already about… 4 years passed, I think, and it's still this
 way. Any family turned into packet mode turns the whole box. Sort of the
 same stuff as 'say per-packet mean per-flow' LB.

 There might be a difference for inet6 (I am not sure) since some version,
 in which the stateful processing for IPv6 was added. I just remember I
 needed to explicitly set the packet mode for it playing around something
 implied IPv6, otherwise it didn't work (or rather worked in flow-mode but I
 had no zones/policies). Must repeat, I'm not sure.
 ___
 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] Layer 2 feature on srx

2012-04-09 Thread ashish verma 
Are you missing zones/policies since it is SRX?

On Mon, Apr 9, 2012 at 7:05 PM, bruno bruno.juni...@gmail.com wrote:

 hello expert,
 i use two srx210h to test some Layer 2 networking features on MX Series
 routers. the topo is very simple
 PC1---SRX1SRX2PC2.  the link in srx1---srx2 is set to trunk mode.
 PC1 and PC2 is belong to vlan 100.  PC1 can't ping PC2.


 interfaces {
ge-0/0/1 {
description TO-SRX2;
vlan-tagging;
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list [ 100 200 ];
}
}
}
fe-0/0/4 {
unit 0 {
family bridge {
interface-mode access;
vlan-id 100;
}
}
}
irb {
unit 100 {
description GW For VLAN 100;
family inet {
address 100.1.1.254/24;
}
}
unit 200 {
description GW For VLAN 200;
family inet {
address 200.1.1.254/24;
}
}
}
 }
 security {
forwarding-options {
family {
mpls {
mode packet-based;
}
}
}
 }
 bridge-domains {
vlan_100 {
vlan-id 100;
routing-interface irb.100;
}
vlan_200 {
vlan-id 200;
routing-interface irb.200;
}
 }



 --
 Best Regards,
 Bruno
 ___
 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] tcp reset on srx

2012-03-31 Thread ashish verma 
FYI

it turned out to be a bug..
PR# 730288

On Thu, Mar 22, 2012 at 1:26 AM, Nick Kritsky nick.krit...@gmail.comwrote:

 This can happen if you are using policy-based IPSEC and if the outgoing
 interface of RST packet is not included in encryption domain.

 NK

 On Tue, Jan 17, 2012 at 11:01 AM, ashish verma ashish.s...@gmail.comwrote:

 Yes it is reject.
 Just found out that it is only over the IPSEC tunnel. Without IPSEC tunnel
 it seems to be working.

 On Tue, Jan 17, 2012 at 4:07 PM, Ben Dale bd...@comlinx.com.au wrote:

 
  Ashish,
 
  On 17/01/2012, at 1:19 PM, ashish verma wrote:
 
   In our SRX deployment I am seeing an issue where client does not
 receive
  a
   ICMP message back after getting denied by the policy.
  
   I can see that packet got dropped by the policy and SRX generates the
   tcp-rst but client does not receive anything.
 
  Can you confirm that your policy action is reject and not deny?
   Otherwise the traffic will be dropped silently.
 
  Cheers,
 
  Ben
 
 
 ___
 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

[j-nsp] tcp reset on srx

2012-01-16 Thread ashish verma 
Hi All,

In our SRX deployment I am seeing an issue where client does not receive a
ICMP message back after getting denied by the policy.

I can see that packet got dropped by the policy and SRX generates the
tcp-rst but client does not receive anything.

Here is the traceoption log

Jan 16 18:59:25 18:59:24.1596505:CID-01:FPC-08:PIC-00:THREAD_ID-11:RT:
  pak processing end.

Jan 16 18:59:25
18:59:24.1596527:CID-01:FPC-08:PIC-00:THREAD_ID-11:RT:Denied by policy
150,*generating
icmp/tcp-rst*

Jan 16 18:59:25 18:59:24.1596538:CID-01:FPC-08:PIC-00:THREAD_ID-11:RT:
 packet dropped, denied by policy

Jan 16 18:59:25 18:59:24.1596549:CID-01:FPC-08:PIC-00:THREAD_ID-11:RT:
 packet dropped,  policy deny.

Anyone else has seen this issue or have any suggestions?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] bgp under routing instance.

2011-11-30 Thread ashish verma 
Hi All,

I am having trouble turning up BGP under routing-instance. Could someone
please help?

Here are the relevant configuration of lab setup. It is direct connectivity
between a J-series and Cisco. Also it works fine if I move the BGP
configurations out of the routing instance.

show routing-instances | display set
set routing-instances ri-beyondcorp instance-type virtual-router
set routing-instances ri-beyondcorp interface ge-0/0/0.113
set routing-instances ri-beyondcorp routing-options router-id 120.29.219.78
set routing-instances ri-beyondcorp routing-options autonomous-system 41264
set routing-instances ri-beyondcorp protocols bgp family inet unicast
set routing-instances ri-beyondcorp protocols bgp group test type external
set routing-instances ri-beyondcorp protocols bgp group test traceoptions
file bgp-trace
set routing-instances ri-beyondcorp protocols bgp group test traceoptions
flag all
set routing-instances ri-beyondcorp protocols bgp group test local-address
120.29.219.78
set routing-instances ri-beyondcorp protocols bgp group test import
BEYONDCORP-IN
set routing-instances ri-beyondcorp protocols bgp group test family inet
unicast
set routing-instances ri-beyondcorp protocols bgp group test family inet any
set routing-instances ri-beyondcorp protocols bgp group test export
BEYONDCORP-OUT
set routing-instances ri-beyondcorp protocols bgp group test peer-as 65003
set routing-instances ri-beyondcorp protocols bgp group test local-as 41264
set routing-instances ri-beyondcorp protocols bgp group test neighbor
120.29.219.77 description internet-bc

set interfaces ge-0/0/0 per-unit-scheduler
set interfaces ge-0/0/0 vlan-tagging
set interfaces ge-0/0/0 unit 112 vlan-id 112
set interfaces ge-0/0/0 unit 112 family inet address 3.3.1.1/24
set interfaces ge-0/0/0 unit 112 family inet6 address 2002:4860:1:1::2/127
set interfaces ge-0/0/0 unit 113 vlan-id 113
set interfaces ge-0/0/0 unit 113 family inet address 120.29.219.78/30

*BGP Trace logs*

Dec  1 02:16:12.200327 task_addr_local: task BGP_65003_41264.120.29.219.77
address 120.29.219.78
Dec  1 02:16:12.200373 task_connect: task BGP_65003_41264.120.29.219.77+179
addr 120.29.219.77+179task_timer_reset: reset
BGP_65003_41264.120.29.219.77+179_Connect
Dec  1 02:16:12.200384 task_timer_set_oneshot_latest: timer
BGP_65003_41264.120.29.219.77+179_Connect interval set to 2:28
Dec  1 02:16:12.200392 task_timer_dispatch: returned from
BGP_65003_41264.120.29.219.77+179_Connect, rescheduled in 2:28
Dec  1 02:17:27.109123 task_process_events: connect ready for
BGP_65003_41264.120.29.219.77+179
Dec  1 02:17:27.109161 bgp_connect_complete: error connecting to
120.29.219.77 (External AS 65003): Socket is not connected
Dec  1 02:17:27.109169 bgp_close_socket: peer 120.29.219.77 (External AS
65003)
Dec  1 02:17:27.109177 task_close: close socket 24 task
BGP_65003_41264.120.29.219.77+179
Dec  1 02:17:27.109184 task_reset_socket: task
BGP_65003_41264.120.29.219.77+179 socket 24
Dec  1 02:17:27.109206 bgp_event: peer 120.29.219.77 (External AS 65003)
old state Connect event OpenFail new state Idle
Dec  1 02:17:27.109280 bgp_event: peer 120.29.219.77 (External AS 65003)
old state Idle event Start new state Active
Dec  1 02:18:03.038570 120.29.219.77 (External AS 65003): import eval flag
set (config change)
Dec  1 02:18:40.200382 task_timer_dispatch: calling
BGP_65003_41264.120.29.219.77_Connect, late by 0.000
Dec  1 02:18:40.200423 bgp_connect_timeout:
BGP_65003_41264.120.29.219.77_Connect
Dec  1 02:18:40.200432 bgp_connect_start: peer 120.29.219.77 (External AS
65003)
Dec  1 02:18:40.200439 bgp_event: peer 120.29.219.77 (External AS 65003)
old state Active event ConnectRetry new state Connect
Dec  1 02:18:40.200525 task_get_socket: domain AF_INET  type SOCK_STREAM
 protocol 0  socket 28
Dec  1 02:18:40.200539 task_set_socket: task BGP_65003_41264.120.29.219.77
socket 28
Dec  1 02:18:40.200559 task_set_option_internal: task
BGP_65003_41264.120.29.219.77 socket 28 option NonBlocking(8) value 1
Dec  1 02:18:40.200569 task_set_option_internal: task
BGP_65003_41264.120.29.219.77 socket 28 option ReUseAddress(3) value 1
Dec  1 02:18:40.200619 task_set_option_internal: task
BGP_65003_41264.120.29.219.77 socket 28 option PathMTUDiscovery(26) value 0
Dec  1 02:18:40.200630 task_set_option_internal: task
BGP_65003_41264.120.29.219.77 socket 28 option RoutingTable(27) value 4
Dec  1 02:18:40.200640 task_set_option_internal: task
BGP_65003_41264.120.29.219.77 socket 28 option TOS(16) value 192
Dec  1 02:18:40.200649 task_set_option_internal: task
BGP_65003_41264.120.29.219.77 socket 28 option DontRoute(5) value 1
Dec  1 02:18:40.200658 task_set_option_internal: task
BGP_65003_41264.120.29.219.77 socket 28 option IifRestrict(36) value 1
Dec  1 02:18:40.200666 task_set_option_internal: task
BGP_65003_41264.120.29.219.77 socket 28 option TTL(15) value 1
Dec  1 02:18:40.200685 task_addr_local: task BGP_65003_41264.120.29.219.77
address 120.29.219.78
Dec  1 02:18:40.200725

Re: [j-nsp] bgp under routing instance.

2011-11-30 Thread ashish verma 
I think thats for flow-base JUNOS version.
I am using 9.3R4 which is packet based.

On Thu, Dec 1, 2011 at 1:13 PM, Giuliano Medalha giuli...@wztech.com.brwrote:

 are you using J-Series as a router ?

 http://juniper.cluepon.net/Enabling_packet_based_forwarding

 On Thu, Dec 1, 2011 at 00:05, ashish verma ashish.s...@gmail.com wrote:

 Hi All,

 I am having trouble turning up BGP under routing-instance. Could someone
 please help?

 Here are the relevant configuration of lab setup. It is direct
 connectivity
 between a J-series and Cisco. Also it works fine if I move the BGP
 configurations out of the routing instance.

 show routing-instances | display set
 set routing-instances ri-beyondcorp instance-type virtual-router
 set routing-instances ri-beyondcorp interface ge-0/0/0.113
 set routing-instances ri-beyondcorp routing-options router-id
 120.29.219.78
 set routing-instances ri-beyondcorp routing-options autonomous-system
 41264
 set routing-instances ri-beyondcorp protocols bgp family inet unicast
 set routing-instances ri-beyondcorp protocols bgp group test type external
 set routing-instances ri-beyondcorp protocols bgp group test traceoptions
 file bgp-trace
 set routing-instances ri-beyondcorp protocols bgp group test traceoptions
 flag all
 set routing-instances ri-beyondcorp protocols bgp group test local-address
 120.29.219.78
 set routing-instances ri-beyondcorp protocols bgp group test import
 BEYONDCORP-IN
 set routing-instances ri-beyondcorp protocols bgp group test family inet
 unicast
 set routing-instances ri-beyondcorp protocols bgp group test family inet
 any
 set routing-instances ri-beyondcorp protocols bgp group test export
 BEYONDCORP-OUT
 set routing-instances ri-beyondcorp protocols bgp group test peer-as 65003
 set routing-instances ri-beyondcorp protocols bgp group test local-as
 41264
 set routing-instances ri-beyondcorp protocols bgp group test neighbor
 120.29.219.77 description internet-bc

 set interfaces ge-0/0/0 per-unit-scheduler
 set interfaces ge-0/0/0 vlan-tagging
 set interfaces ge-0/0/0 unit 112 vlan-id 112
 set interfaces ge-0/0/0 unit 112 family inet address 3.3.1.1/24
 set interfaces ge-0/0/0 unit 112 family inet6 address 2002:4860:1:1::2/127
 set interfaces ge-0/0/0 unit 113 vlan-id 113
 set interfaces ge-0/0/0 unit 113 family inet address 120.29.219.78/30

 *BGP Trace logs*


 Dec  1 02:16:12.200327 task_addr_local: task BGP_65003_41264.120.29.219.77
 address 120.29.219.78
 Dec  1 02:16:12.200373 task_connect: task
 BGP_65003_41264.120.29.219.77+179
 addr 120.29.219.77+179task_timer_reset: reset
 BGP_65003_41264.120.29.219.77+179_Connect
 Dec  1 02:16:12.200384 task_timer_set_oneshot_latest: timer
 BGP_65003_41264.120.29.219.77+179_Connect interval set to 2:28
 Dec  1 02:16:12.200392 task_timer_dispatch: returned from
 BGP_65003_41264.120.29.219.77+179_Connect, rescheduled in 2:28
 Dec  1 02:17:27.109123 task_process_events: connect ready for
 BGP_65003_41264.120.29.219.77+179
 Dec  1 02:17:27.109161 bgp_connect_complete: error connecting to
 120.29.219.77 (External AS 65003): Socket is not connected
 Dec  1 02:17:27.109169 bgp_close_socket: peer 120.29.219.77 (External AS
 65003)
 Dec  1 02:17:27.109177 task_close: close socket 24 task
 BGP_65003_41264.120.29.219.77+179
 Dec  1 02:17:27.109184 task_reset_socket: task
 BGP_65003_41264.120.29.219.77+179 socket 24
 Dec  1 02:17:27.109206 bgp_event: peer 120.29.219.77 (External AS 65003)
 old state Connect event OpenFail new state Idle
 Dec  1 02:17:27.109280 bgp_event: peer 120.29.219.77 (External AS 65003)
 old state Idle event Start new state Active
 Dec  1 02:18:03.038570 120.29.219.77 (External AS 65003): import eval flag
 set (config change)
 Dec  1 02:18:40.200382 task_timer_dispatch: calling
 BGP_65003_41264.120.29.219.77_Connect, late by 0.000
 Dec  1 02:18:40.200423 bgp_connect_timeout:
 BGP_65003_41264.120.29.219.77_Connect
 Dec  1 02:18:40.200432 bgp_connect_start: peer 120.29.219.77 (External AS
 65003)
 Dec  1 02:18:40.200439 bgp_event: peer 120.29.219.77 (External AS 65003)
 old state Active event ConnectRetry new state Connect
 Dec  1 02:18:40.200525 task_get_socket: domain AF_INET  type SOCK_STREAM
  protocol 0  socket 28
 Dec  1 02:18:40.200539 task_set_socket: task BGP_65003_41264.120.29.219.77
 socket 28
 Dec  1 02:18:40.200559 task_set_option_internal: task
 BGP_65003_41264.120.29.219.77 socket 28 option NonBlocking(8) value 1
 Dec  1 02:18:40.200569 task_set_option_internal: task
 BGP_65003_41264.120.29.219.77 socket 28 option ReUseAddress(3) value 1
 Dec  1 02:18:40.200619 task_set_option_internal: task
 BGP_65003_41264.120.29.219.77 socket 28 option PathMTUDiscovery(26) value
 0
 Dec  1 02:18:40.200630 task_set_option_internal: task
 BGP_65003_41264.120.29.219.77 socket 28 option RoutingTable(27) value 4
 Dec  1 02:18:40.200640 task_set_option_internal: task
 BGP_65003_41264.120.29.219.77 socket 28 option TOS(16) value 192
 Dec  1 02:18:40.200649 task_set_option_internal: task

Re: [j-nsp] bgp under routing instance.

2011-11-30 Thread ashish verma 
Just wanted to mention one more thing. Link between Juniper and Cisco is a
trunk as seen in the interface config below.

BGP on vlan 112 works fine (outside routing instance)
BGP on vlan 113 doesn't (inside routing instance)

If I disable BGP on vlan 112 then BGP inside routing instance comes up fine.



On Thu, Dec 1, 2011 at 1:25 PM, ashish verma ashish.s...@gmail.com wrote:

 I think thats for flow-base JUNOS version.
 I am using 9.3R4 which is packet based.


 On Thu, Dec 1, 2011 at 1:13 PM, Giuliano Medalha 
 giuli...@wztech.com.brwrote:

 are you using J-Series as a router ?

 http://juniper.cluepon.net/Enabling_packet_based_forwarding

 On Thu, Dec 1, 2011 at 00:05, ashish verma ashish.s...@gmail.com wrote:

 Hi All,

 I am having trouble turning up BGP under routing-instance. Could someone
 please help?

 Here are the relevant configuration of lab setup. It is direct
 connectivity
 between a J-series and Cisco. Also it works fine if I move the BGP
 configurations out of the routing instance.

 show routing-instances | display set
 set routing-instances ri-beyondcorp instance-type virtual-router
 set routing-instances ri-beyondcorp interface ge-0/0/0.113
 set routing-instances ri-beyondcorp routing-options router-id
 120.29.219.78
 set routing-instances ri-beyondcorp routing-options autonomous-system
 41264
 set routing-instances ri-beyondcorp protocols bgp family inet unicast
 set routing-instances ri-beyondcorp protocols bgp group test type
 external
 set routing-instances ri-beyondcorp protocols bgp group test traceoptions
 file bgp-trace
 set routing-instances ri-beyondcorp protocols bgp group test traceoptions
 flag all
 set routing-instances ri-beyondcorp protocols bgp group test
 local-address
 120.29.219.78
 set routing-instances ri-beyondcorp protocols bgp group test import
 BEYONDCORP-IN
 set routing-instances ri-beyondcorp protocols bgp group test family inet
 unicast
 set routing-instances ri-beyondcorp protocols bgp group test family inet
 any
 set routing-instances ri-beyondcorp protocols bgp group test export
 BEYONDCORP-OUT
 set routing-instances ri-beyondcorp protocols bgp group test peer-as
 65003
 set routing-instances ri-beyondcorp protocols bgp group test local-as
 41264
 set routing-instances ri-beyondcorp protocols bgp group test neighbor
 120.29.219.77 description internet-bc

 set interfaces ge-0/0/0 per-unit-scheduler
 set interfaces ge-0/0/0 vlan-tagging
 set interfaces ge-0/0/0 unit 112 vlan-id 112
 set interfaces ge-0/0/0 unit 112 family inet address 3.3.1.1/24
 set interfaces ge-0/0/0 unit 112 family inet6 address
 2002:4860:1:1::2/127
 set interfaces ge-0/0/0 unit 113 vlan-id 113
 set interfaces ge-0/0/0 unit 113 family inet address 120.29.219.78/30

 *BGP Trace logs*


 Dec  1 02:16:12.200327 task_addr_local: task
 BGP_65003_41264.120.29.219.77
 address 120.29.219.78
 Dec  1 02:16:12.200373 task_connect: task
 BGP_65003_41264.120.29.219.77+179
 addr 120.29.219.77+179task_timer_reset: reset
 BGP_65003_41264.120.29.219.77+179_Connect
 Dec  1 02:16:12.200384 task_timer_set_oneshot_latest: timer
 BGP_65003_41264.120.29.219.77+179_Connect interval set to 2:28
 Dec  1 02:16:12.200392 task_timer_dispatch: returned from
 BGP_65003_41264.120.29.219.77+179_Connect, rescheduled in 2:28
 Dec  1 02:17:27.109123 task_process_events: connect ready for
 BGP_65003_41264.120.29.219.77+179
 Dec  1 02:17:27.109161 bgp_connect_complete: error connecting to
 120.29.219.77 (External AS 65003): Socket is not connected
 Dec  1 02:17:27.109169 bgp_close_socket: peer 120.29.219.77 (External AS
 65003)
 Dec  1 02:17:27.109177 task_close: close socket 24 task
 BGP_65003_41264.120.29.219.77+179
 Dec  1 02:17:27.109184 task_reset_socket: task
 BGP_65003_41264.120.29.219.77+179 socket 24
 Dec  1 02:17:27.109206 bgp_event: peer 120.29.219.77 (External AS 65003)
 old state Connect event OpenFail new state Idle
 Dec  1 02:17:27.109280 bgp_event: peer 120.29.219.77 (External AS 65003)
 old state Idle event Start new state Active
 Dec  1 02:18:03.038570 120.29.219.77 (External AS 65003): import eval
 flag
 set (config change)
 Dec  1 02:18:40.200382 task_timer_dispatch: calling
 BGP_65003_41264.120.29.219.77_Connect, late by 0.000
 Dec  1 02:18:40.200423 bgp_connect_timeout:
 BGP_65003_41264.120.29.219.77_Connect
 Dec  1 02:18:40.200432 bgp_connect_start: peer 120.29.219.77 (External AS
 65003)
 Dec  1 02:18:40.200439 bgp_event: peer 120.29.219.77 (External AS 65003)
 old state Active event ConnectRetry new state Connect
 Dec  1 02:18:40.200525 task_get_socket: domain AF_INET  type SOCK_STREAM
  protocol 0  socket 28
 Dec  1 02:18:40.200539 task_set_socket: task
 BGP_65003_41264.120.29.219.77
 socket 28
 Dec  1 02:18:40.200559 task_set_option_internal: task
 BGP_65003_41264.120.29.219.77 socket 28 option NonBlocking(8) value 1
 Dec  1 02:18:40.200569 task_set_option_internal: task
 BGP_65003_41264.120.29.219.77 socket 28 option ReUseAddress(3) value 1
 Dec  1 02:18:40.200619 task_set_option_internal