Re: [j-nsp] MS-DPC and netflow.

2010-07-16 Thread Peter Krupl
Hi Chris, Luca, David (Posted a reply off list),

Im running Junos 10.1R1.8.
The current configuration  im using is shown below. 

The configuration is accepted, and I see some flow exports to my collector.

But the traffic received at the collector is arriving at an interval og about 
60 seconds,
and it seems the data is the same. I suspect that is only template information, 
and not
actual flow data.

1. 
Do I (have to)/(can i) specify which interfaces should be included in the flow 
export ?

2.
As my box is running as PE, I think the mpls-ipv4 template is the one to use, 
am I correct ?

3.
The license for flow accounting called SA-ACCT-5M did not contain any license 
keys. Do I need to obtain an activation key somehow ? Maybe this is why I don't 
se any flows.?



---CONFIG---
chassis {
 .
fpc 1 {
.
pic 1 {
tunnel-services {
bandwidth 10g;
}
adaptive-services {
service-package layer-3;
}
}
}
network-services ip;
}
interfaces {
.
sp-1/1/0 {
unit 0 {
family inet;
family inet6;
family mpls;
}
}
.
}
forwarding-options {
sampling {
input {
rate 1;
run-length 1;
}
family mpls {
output {
flow-server 213.173.238.99{
port 9990;
source-address 89.233.99.193;
version9 {
template {
mpls-ipv4;
}
}
}
interface sp-1/1/0 {
source-address 89.233.99.193;
}
}
}
}
}

services {
flow-monitoring {
version9 {
template ipv4 {
ipv4-template;
}
template ipv6 {
ipv6-template;
}
template mpls {
mpls-template;
}
template mpls-ipv4 {
mpls-ipv4-template;
}
}
}
.
}

---CONFIG---

Kind Regards,
Peter Krupl


-Original Message-
From: Chris Tracy [mailto:ctr...@es.net] 
Sent: Thursday, July 15, 2010 7:55 PM
To: bit gossip
Cc: Peter Krupl; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MS-DPC and netflow.

Peter, Luca,

I believe you need to be running 9.6 or later in order to use the config that 
Luca provided below.

Prior to 9.6, you will only find 'input', 'output' and 'traceoptions' under 
forwarding-options { sampling { ... } }.  After 9.6, you will find 'family 
inet' and 'family inet6' under that level -- but not in earlier releases.  In 
either case, under output { ... }, older JUNOS seems to use 'cflowd' while 
newer JUNOS uses the 'flow-server' keyword.

The advantage is that after 9.6, you can output IPv4 and IPv6 flow data to the 
same collector IP address/port.  e.g. apply multiple templates to a single 
collector.  Before 9.6, you had to apply the IPv4 template to one cflowd IP, 
and the IPv6 (or MPLS) template to another cflowd IP.

Another cool thing you can do after 9.6 is per-FPC sampling instances.  For 
example, you can do

forwarding-options {
   sampling {
  instance {
 xyz {
input { ... }
family inet { ... }
family inet6 { ... }
 }
  }
   }
}
chassis {
   fpc X {
  sampling-instance xyz;
   }
}

I haven't really seen a reason to use this type of config yet, but if you are 
somehow max'ing out the resources of a single MS-DPC, it looks like you could 
potentially use this syntax to dedicate one MS-DPC to one or more FPCs, another 
MS-DPC to another set of FPCs, etc.

For completeness, here is a working example from JUNOS 9.3.  Just make sure you 
are doing sampling somewhere in your firewall filters (e.g. you might sample 
all inbound on every interface).  You need to be careful not to sample the same 
flow twice (on each router) or else your flow records will show double 
packets/octets.

interfaces {
sp-1/0/0 {
unit 0 {
family inet;
family inet6;
family mpls;
}
}
}
forwarding-options {
sampling {
input {
family inet {
rate 1;
run-length 0;
max-packets-per-second 65000;
}
family inet6 {
rate 1;
run-length 0;
max-packets-per-second 65000;
}
}
output {
cflowd 10.0.0.1 {
port ;
version9 {
template {
ipv4;
}
}
no-local-dump;

Re: [j-nsp] MS-DPC and netflow.

2010-07-16 Thread bit gossip
Peter,
the config provided is working fine on 10.2R1.8
Sampling must indeed be enabled at logical interface level with
something like this:
ge-3/0/7 {
link-mode full-duplex;
unit 0 {
family inet {
sampling {
input;
}
address 1.1.1.1/30;
}   
}   
}

or also with a firewall filter.
Thanks,
Luca.

On Fri, 2010-07-16 at 08:01 +0200, Peter Krupl wrote:
 Hi Chris, Luca, David (Posted a reply off list),
 
 Im running Junos 10.1R1.8.
 The current configuration  im using is shown below. 
 
 The configuration is accepted, and I see some flow exports to my collector.
 
 But the traffic received at the collector is arriving at an interval og about 
 60 seconds,
 and it seems the data is the same. I suspect that is only template 
 information, and not
 actual flow data.
 
 1. 
 Do I (have to)/(can i) specify which interfaces should be included in the 
 flow export ?
 
 2.
 As my box is running as PE, I think the mpls-ipv4 template is the one to use, 
 am I correct ?
 
 3.
 The license for flow accounting called SA-ACCT-5M did not contain any 
 license keys. Do I need to obtain an activation key somehow ? Maybe this is 
 why I don't se any flows.?
 
 
 
 ---CONFIG---
 chassis {
  .
 fpc 1 {
 .
 pic 1 {
 tunnel-services {
 bandwidth 10g;
 }
 adaptive-services {
 service-package layer-3;
 }
 }
 }
 network-services ip;
 }
 interfaces {
 .
 sp-1/1/0 {
 unit 0 {
 family inet;
 family inet6;
 family mpls;
 }
 }
 .
 }
 forwarding-options {
 sampling {
 input {
 rate 1;
 run-length 1;
 }
 family mpls {
 output {
 flow-server 213.173.238.99{
 port 9990;
 source-address 89.233.99.193;
 version9 {
 template {
 mpls-ipv4;
 }
 }
 }
 interface sp-1/1/0 {
 source-address 89.233.99.193;
 }
 }
 }
 }
 }
 
 services {
 flow-monitoring {
 version9 {
 template ipv4 {
 ipv4-template;
 }
 template ipv6 {
 ipv6-template;
 }
 template mpls {
 mpls-template;
 }
 template mpls-ipv4 {
 mpls-ipv4-template;
 }
 }
 }
   .
 }
   
 ---CONFIG---
 
 Kind Regards,
 Peter Krupl
 
 
 -Original Message-
 From: Chris Tracy [mailto:ctr...@es.net] 
 Sent: Thursday, July 15, 2010 7:55 PM
 To: bit gossip
 Cc: Peter Krupl; juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] MS-DPC and netflow.
 
 Peter, Luca,
 
 I believe you need to be running 9.6 or later in order to use the config that 
 Luca provided below.
 
 Prior to 9.6, you will only find 'input', 'output' and 'traceoptions' under 
 forwarding-options { sampling { ... } }.  After 9.6, you will find 'family 
 inet' and 'family inet6' under that level -- but not in earlier releases.  In 
 either case, under output { ... }, older JUNOS seems to use 'cflowd' while 
 newer JUNOS uses the 'flow-server' keyword.
 
 The advantage is that after 9.6, you can output IPv4 and IPv6 flow data to 
 the same collector IP address/port.  e.g. apply multiple templates to a 
 single collector.  Before 9.6, you had to apply the IPv4 template to one 
 cflowd IP, and the IPv6 (or MPLS) template to another cflowd IP.
 
 Another cool thing you can do after 9.6 is per-FPC sampling instances.  For 
 example, you can do
 
 forwarding-options {
sampling {
   instance {
  xyz {
 input { ... }
 family inet { ... }
 family inet6 { ... }
  }
   }
}
 }
 chassis {
fpc X {
   sampling-instance xyz;
}
 }
 
 I haven't really seen a reason to use this type of config yet, but if you are 
 somehow max'ing out the resources of a single MS-DPC, it looks like you could 
 potentially use this syntax to dedicate one MS-DPC to one or more FPCs, 
 another MS-DPC to another set of FPCs, etc.
 
 For completeness, here is a working example from JUNOS 9.3.  Just make sure 
 you are doing sampling somewhere in your firewall filters (e.g. you might 
 sample all inbound on every interface).  You need to be careful not to sample 
 the same flow twice (on each router) or else your flow records will show 
 double packets/octets.
 
 interfaces {
 sp-1/0/0 {
 unit 0 {
 family inet;
 

Re: [j-nsp] Juniper RANCID

2010-07-16 Thread David DeSimone
Stefan Schlesinger s...@ono.at wrote:

 I'm trying to get RANCID to work with jlogin on my SRX100. I
 configured my router.db and .cloginrc. The following command
 can login to the router, but it doesn't backup anything.
 
   $ bin/jlogin -f .cloginrc 192.168.0.13

Check what's in rancid's logs directory to get a hint as to what is
failing.

Also I suggest you test with jlogin -c 'show version' to see what
happens when jlogin tries to run a command and collect output.

99% of rancid's problems stem from failing to be able to detect the
device's prompt correctly, so it can't tell when it is supposed to be
submitting commands.  That said, your device's prompt doesn't look
unusual so I'm not sure why it would fail.

Perhaps rancid is not recognizing a particular command's output, which
is something that your logs will tell you.

-- 
David DeSimone == Network Admin == f...@verio.net
  I don't like spinach, and I'm glad I don't, because if I
   liked it I'd eat it, and I just hate it. -- Clarence Darrow


This email message is intended for the use of the person to whom it has been 
sent, and may contain information that is confidential or legally protected. If 
you are not the intended recipient or have received this message in error, you 
are not authorized to copy, distribute, or otherwise use this message or its 
attachments. Please notify the sender immediately by return e-mail and 
permanently delete this message and any attachments. Verio, Inc. makes no 
warranty that this email is error or virus free.  Thank you.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] Juniper RANCID

2010-07-16 Thread Stefan Fouant
 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of David DeSimone
 Sent: Friday, July 16, 2010 3:40 AM
 To: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Juniper RANCID
 
 99% of rancid's problems stem from failing to be able to detect the
device's
 prompt correctly, so it can't tell when it is supposed to be submitting
 commands.  That said, your device's prompt doesn't look unusual so I'm not
 sure why it would fail.

I think the problem is that it's *not* failing.  As others have pointed out,
jlogin is working as expected given the input the user has provided - it's
doing what he's asked of it and that is simply to automate the login.

In order to do anything beyond that he is going to need to pass along
commands as input to the jlogin command as either a single string using the
argument -c or via a command file using the argument -x.  See additional
information from the jlogin manpages below:

-c
Command to be run on each router list on the command-line. Multiple commands
maybe listed by separating them with semicolons (;). The argument should be
quoted to avoid shell expansion.

-x 
Similar to the -c option; -x specifies a file with commands to run on each
of the routers. The commands must not expect additional input, such as 'copy
rcp startup-config' does.

HTHs.

Stefan Fouant, CISSP, JNCIEx2
www.shortestpathfirst.net
GPG Key ID: 0xB5E3803D

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


Re: [j-nsp] MS-DPC and netflow.

2010-07-16 Thread Paolo Lucente
Hi Peter,

On Fri, Jul 16, 2010 at 08:01:34AM +0200, Peter Krupl wrote:

 2.
 As my box is running as PE, I think the mpls-ipv4 template is the one to use, 
 am I correct ?

It depends what you are trying to do with the NetFlow export; if
you are a SP and are sampling public internet traffic ingress at
all edge interfaces (ie. facing peers, transits and customers) or
ingress/egress at some edge interfaces (ie. facing only peers and
transits), you can go with the ipv4 template. Otherwise feel free
to elaborate on your scenario.

Cheers,
Paolo

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


Re: [j-nsp] Juniper RANCID

2010-07-16 Thread Stefan Schlesinger
On Jul 16, 2010, at 03:11 , ck wrote:

 your output is expected behavior. jlogin is just an expect script that logs 
 into the devices.
 
 if you're configuration is complete (with cron job/etc and you just want to 
 test you can run the following /blah/blah/rancid/bin/rancid-run to run rancid

Thank you everyone. I finally got it working. :-)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


[j-nsp] SRX CPU utilization reaches 100%

2010-07-16 Thread Fahad Khan
Hi folks,

I faced that SRX CPU utilization reaches to 100% suddenly after configuring
three policies with address groups of 90 addresses. And then the telnet
session was also broken for 2 mins approx but resume after that time.

has any body experienced this? I am using junos 10.0R3.10 (recommended
version)

Please reply urgently

thanks and regards,

Muhammad Fahad Khan
JNCIP - M/T # 834
IT Specialist
Global Technology Services, IBM
fa...@pk.ibm.com
+92-301-8247638
Skype: fahad-ibm
http://www.linkedin.com/in/muhammadfahadkhan
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


[j-nsp] MX240 running 10.1R1.8

2010-07-16 Thread Philip Palanchi

Two weeks ago we fired up two new mx240's running 10.1R1.8 and shortly after I 
noticed a large (and growing!) log file:

file list /var/log/pfed_event_trace.log

Well it seems to be a bug in EX series with backup RE.  However it must be more 
widespread because we have MX with no backup RE!  Eventually it will cause a 
filesystem full issue. Thought I would pass this along to you all.

PSN-2010-03-690
https://www.juniper.net/alerts/viewalert.jsp?actionBtn=SearchtxtAlertNumber=PSN-2010-03-690viewMode=view

KB16810   (SEE KB FOR FULL DETAILS)


Thanks,
Phil

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


Re: [j-nsp] SRX CPU utilization reaches 100%

2010-07-16 Thread Fahad Khan
Yes, it came back to normal with in this time and this is SRX3600 in chassis
cluster.

regards,

Muhammad Fahad Khan
JNCIP - M/T # 834
IT Specialist
Global Technology Services, IBM
fa...@pk.ibm.com
+92-301-8247638
Skype: fahad-ibm
http://www.linkedin.com/in/muhammadfahadkhan



On Fri, Jul 16, 2010 at 5:44 PM, Stefan Fouant 
sfou...@shortestpathfirst.net wrote:

  -Original Message-
  From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
  boun...@puck.nether.net] On Behalf Of Fahad Khan
  Sent: Friday, July 16, 2010 7:52 AM
  To: juniper-nsp@puck.nether.net
  Subject: [j-nsp] SRX CPU utilization reaches 100%
 
  I faced that SRX CPU utilization reaches to 100% suddenly after
 configuring
  three policies with address groups of 90 addresses. And then the telnet
  session was also broken for 2 mins approx but resume after that time.
 
  has any body experienced this? I am using junos 10.0R3.10 (recommended
  version)

 Does the CPU remain at 100%, or just for two minutes and then fall to a
 more
 acceptable level?  Is this an SRX 100 by any chance?

 Stefan Fouant, CISSP, JNCIEx2
 www.shortestpathfirst.net
 GPG Key ID: 0xB5E3803D


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


[j-nsp] Enumerate All Possible VPN Tunnels? Really?

2010-07-16 Thread Crist Clark
I've got what I think should be a fairly vanilla hub-and-spoke
VPN configuration. The hub is a Cisco ASA (really, it eventually
should be dual hub, but wait until I get one working before I
worry about that) and one of the spokes is a SRX (10.1).

I can get a single tunnel up between the SRX and the ASA without
much problem. However, we have a situation where there are
multiple non-contiguous networks at each site. At the hub and
other spokes, we just enumerate all of the networks at the remote
site and the networks at the local side, and the device builds
individual tunnels between the various networks as needed with
a single configuration entry.

Doesn't seem to work that way on the SRX (JUNOS). I started with
a route-based VPN. That's how I got my one quick tunnel up, but
the SRX side would always say the tunnels were associated
locally with 0.0.0.0/0 and remotely with the same. This lead to
the problem that the SRX would try to cram traffic from local_netX
and remote_netY down a VPN that had been negotiated in IKE Phase 2
as between local_netA and remote_netB.

I talked to JTAC about this, and their solution was going to be
to enumerate every possible combination of tunnels,

security {
ipsec {
vpn vpn_1-cfg {
ike {
proxy-identity {
local local_netA;
remote remote_netB;
}
}
}
}
}

Which does not scale. The tech said maybe policy-based would be
better. So I went to the site-to-site VPN tool on the Juniper
support page to see what it would say. I put two networks in
either side of the tunnel and it spit out a configuration with
EIGHT security policies, one in each direction for the four ways
you can pair the two networks at each site. And that's still not
really working right.

Neither of these is solutions is scalable. There's got to be a
better way to do this, right?


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