[j-nsp] mx80 napt-44 with ms-mic on 13.2R5

[ryanL]

has anyone been successful here? i'm getting the following error, even
though juniper's docs seem to indicate this is supported on the ms-mic with
13.2.

my ref guides are:
http://www.juniper.net/techpubs/en_US/junos13.2/information-products/topic-collections/config-guide-services/index.html?features-ms-mic.html
http://www.juniper.net/techpubs/en_US/junos13.2/topics/example/nat-nat44-config-ms-mpc.html

ry@iad1-er2# show | compare
[edit]
+  services {
+  service-set SSET1 {
+  nat-rules NAT-RULE1;
+  interface-service {
+  service-interface ms-0/2/0;
+  }
+  }
+  nat {
+  pool NP2 {
+  address /28;
+  port {
+  automatic;
+  }
+  }
+  rule NAT-RULE1 {
+  match-direction input;
+  term term-1 {
+  from {
+  source-address {
+  10.0.0.0/8;
+  }
+  destination-address {
+  10.0.0.0/8;
+  }
+  }
+  then {
+  no-translation;
+  }
+  }
+  term term-2 {
+  from {
+  source-address {
+  10.0.0.0/8;
+  }
+  }
+  then {
+  translated {
+  source-pool NP2;
+  translation-type {
+  napt-44;
+  }
+  }
+  }
+  }
+  }
+  }
+  }
[edit interfaces]
+   ms-0/2/0 {
+   unit 0 {
+   family inet;
+   }
+   }

[edit]
ry@iad1-er2# commit check
[edit services]
  'service-set SSET1'
translation type not supported on ms-interface
error: configuration check-out failed

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

Re: [j-nsp] T4000 power architecture

[Sam Silvester]

Bumping for good measure...

So JTAC are suggesting it's either the PEM or the midplane, but I was
hoping to get some more information so I can validate what I'm being told -
which, currently, is very little. Basically the suggestion is "replace the
PEM, if that doesn't work replace the chassis". I'd like to avoid
whack-a-mole if possible; for example, if I knew that all of the FPCs were
fed via the PEM via a central bus on the midplane, then we don't have to
worry about replacing the PEM and can go straight ahead with organising a
chassis swap.

I don't suppose somebody happens to have a spare T4000 chassis or PEM lying
around and could take a photo of the connectors between the PEM and the
midplane? I'm still trying to get an idea of how power is distributed from
the PEM to the actual FPC slots.

The exact same questions has been posed to JTAC multiple times, but no
answer has been forthcoming. I really hope the nagging suspicion I have
that nobody in Juniper knows this information is incorrect but in the
meantime I'm posting here in the hope I can figure it out from some
pictures.

Google image search isn't helping me find any clear photos of the rear of
the PEM or the midplane :/

Sam


On Thu, Sep 11, 2014 at 8:06 AM, Sam Silvester 
wrote:

> Hi Aqeel - thanks for the reply.
>
> Agree 100% - the problem is, we only seem to be getting power to FPC0 from
> one PEM... have a look below (and also note that FPC1 is fine, as are the
> rest of the FPCs).
>
> The question is - are we looking at a PEM fault here, or a midplane fault?
> As per previous discussion, the FPC itself seems fine, as moving it to
> another slot resolves the issue. Putting another card into slot 0 yields
> the same result as below.
>
> PEM 0 status:
>   State  Online
>   Temperature32 degrees C / 89 degrees F
>   DC Input:  OK
>   Voltage(V)  Current(A)  Power(W)  Load(%)
>   INPUT 0   54.750   4.312  2369
>   INPUT 1   54.500   6.000  327   13
>   INPUT 2   54.625  11.750  641   26
>   INPUT 3   54.750   6.125  335   13
>   INPUT 4   54.250  10.500  569   23
>   INPUT 5   54.500   6.062  330   13
>   DC Output   Voltage(V)  Current(A)  Power(W)  Load(%)
>   FPC 0 55.062   8.625  474   31
>   FPC 1 55.250   4.062  224   14
>
> <...snip...>
>
> PEM 1 status:
>   State  Online
>   Temperature30 degrees C / 86 degrees F
>   DC Input:  OK
>   Voltage(V)  Current(A)  Power(W)  Load(%)
>   INPUT 0   54.500   3.250  1777
>   INPUT 1   54.625   3.375  1847
>   INPUT 2   54.500  12.437  677   28
>   INPUT 3   54.500   5.125  279   11
>   INPUT 4   54.625  12.062  658   27
>   INPUT 5   54.375   2.750  1496
>   DC Output   Voltage(V)  Current(A)  Power(W)  Load(%)
>   FPC 0  0.000   0.00000
>   FPC 1 55.125   4.500  248   16
>
> <...snip...>
>
>
>
> On Wed, Sep 10, 2014 at 8:48 PM, aqeel ahmed  wrote:
>
>> Hi
>>
>> Though aimed for redundancy If system has both power supplies installed
>> then it will automatically load balance and in case one power supply goes
>> down then whole system will be on single power supply left working.
>>
>> For further details you can refer to following juniper document.
>>
>>
>> http://www.juniper.net/techpubs/en_US/release-independent/junos/information-products/topic-collections/hardware/t-series/t4000/hwguide/t4000-hwguide.pdf
>>
>> Regards
>>
>>
>>
>>   On Wednesday, September 10, 2014 5:16 AM, Sam Silvester <
>> sam.silves...@gmail.com> wrote:
>>
>>
>> Howdy,
>>
>> Can anybody shed any light on how the PEMs on a T4000 actually distribute
>> power to each FPC slot?
>>
>> Have the case of a single FPC slot that is showing power being received
>> from only one of the PEMs, whilst all the other FPC slots are load sharing
>> as expected.
>>
>> Replacing the FPC shows the same issue, so we're pretty happy that it's
>> "slot specific".
>>
>> What I'm curious about is if the midplane has individual 'traces' (for
>> lack
>> of a better term) for supplying power to each FPC from the two PEMs, or if
>> there is a common bus shared between all the FPCs from each PEM. The
>> reason
>> I ask is if the PEM only has a single connection to the midplane,
>> replacing
>> it seems pointless and instead it looks like we're better off replacing
>> the
>> midplane. If the PEM has individual outputs to each slot, then replacing
>> the PEM seems like a reasonable approach.
>>
>> I've been pointed at the following document (
>>
>> http://www.juniper.net/documentat

Re: [j-nsp] MX5 BNG licensing

[Шепелев Андрей]

so you mean that, if i only want *per subscriber session* accounting i can
buy only S-MX80-SA-FP and subscriber licence?

hmm ... sounds interesting

2014-09-24 3:21 GMT+06:00 Wojciech Janiszewski <
wojciech.janiszew...@gmail.com>:

> Hi Андрей,
>
> In addition to ordinary per-subscriber AAA you may also configure
> per-service accounting for which the S-MX80-SSM-FP license is required.
>
> Regards,
> Wojciech
>
> 2014-09-22 5:20 GMT+02:00 Шепелев Андрей :
>
>> HI!
>> Wojciech Janiszewski - can you explain in more details about S-MX80-SSM-FP
>> license.
>> What do you mean "license is not necessary if you only need
>> per-subscriber AAA."
>>
>> thx
>>
>> 2014-09-22 3:46 GMT+06:00 Wojciech Janiszewski <
>> wojciech.janiszew...@gmail.com>:
>>
>>> Hi Octavio,
>>>
>>> IIRC the S-MX80-SSM-FP license is not necessary if you only need
>>> per-subscriber AAA. The S-MX80-SSM-FP is required if you need per-service
>>> accounting or need to change variables within profile via Radius, or
>>> require COA, RID or SRC.  In addition you might require SA-nnnK license
>>> according to the number of subscribers connected.
>>>
>>> Regards,
>>> Wojciech
>>>
>>> 2014-09-21 8:14 GMT+02:00 Octavio Alfageme :
>>>
>>> > Hello everyone,
>>> >
>>> > MX5 has two licenses related to subscriber management:
>>> >
>>> > * S-MX80-SA-FP - Subscriber Management Feature Pack License on MX80
>>> Series
>>> > * S-MX80-SSM-FP - Subscriber Service Management Feature Packet License
>>> > (RADIUS/SRC Based Service Activation and Deactivation) Per-Service
>>> > Accounting Features for Subscribers, MX80 Series
>>> >
>>> > I would like to manage my subscribers' service from a RADIUS server.
>>> Do you
>>> > know if I need both licenses or only the second one? I believe they are
>>> > incremental, but I would like somebody to confirm it.
>>> >
>>> > Thanks in advance
>>> >
>>> > Kind regards
>>> >
>>> > Octavio
>>> >
>>> ___
>>> 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] MX5 BNG licensing

[Wojciech Janiszewski]

Hi Андрей,

In addition to ordinary per-subscriber AAA you may also configure
per-service accounting for which the S-MX80-SSM-FP license is required.

Regards,
Wojciech

2014-09-22 5:20 GMT+02:00 Шепелев Андрей :

> HI!
> Wojciech Janiszewski - can you explain in more details about S-MX80-SSM-FP
> license.
> What do you mean "license is not necessary if you only need
> per-subscriber AAA."
>
> thx
>
> 2014-09-22 3:46 GMT+06:00 Wojciech Janiszewski <
> wojciech.janiszew...@gmail.com>:
>
>> Hi Octavio,
>>
>> IIRC the S-MX80-SSM-FP license is not necessary if you only need
>> per-subscriber AAA. The S-MX80-SSM-FP is required if you need per-service
>> accounting or need to change variables within profile via Radius, or
>> require COA, RID or SRC.  In addition you might require SA-nnnK license
>> according to the number of subscribers connected.
>>
>> Regards,
>> Wojciech
>>
>> 2014-09-21 8:14 GMT+02:00 Octavio Alfageme :
>>
>> > Hello everyone,
>> >
>> > MX5 has two licenses related to subscriber management:
>> >
>> > * S-MX80-SA-FP - Subscriber Management Feature Pack License on MX80
>> Series
>> > * S-MX80-SSM-FP - Subscriber Service Management Feature Packet License
>> > (RADIUS/SRC Based Service Activation and Deactivation) Per-Service
>> > Accounting Features for Subscribers, MX80 Series
>> >
>> > I would like to manage my subscribers' service from a RADIUS server. Do
>> you
>> > know if I need both licenses or only the second one? I believe they are
>> > incremental, but I would like somebody to confirm it.
>> >
>> > Thanks in advance
>> >
>> > Kind regards
>> >
>> > Octavio
>> >
>> ___
>> 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] Egress policer on EX3300

[Mike Gonnason]

What version are you running?

Have you examined:
http://www.juniper.net/documentation/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html


On Tue, Sep 23, 2014 at 1:10 PM, Robert Hass  wrote:

> Hi
> Is egress policing or shaping supported on EX3300 platform ?
>
> I tried to configure policing 2Mbps for port ge-0/0/0, but receiving error
> at commit:
>
> Referenced filter 'Police-2M' can not be used as policer not supported
> on egress
> error: configuration check-out failed
>
> Input filters commiting & works without problems.
>
> My config:
>
> interfaces {
> ge-0/0/0 {
> unit 0 {
> family ethernet-switching {
> filter {
> input Police-2M;
> output Police-2M;
> }
> }
> }
> }
> }
> firewall {
> family ethernet-switching {
> filter Police-2M {
> term Default {
> then policer 2Mbps;
> }
> }
> }
> policer 2Mbps {
> if-exceeding {
> bandwidth-limit 2m;
> burst-size-limit 100k;
> }
> then discard;
> }
> }
>
>
> Rob
> ___
> 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] Egress policer on EX3300

[Lee Pedder]

On 23 Sep 2014 22:16, "Robert Hass"  wrote:
>
> Hi
> Is egress policing or shaping supported on EX3300 platform ?
>
> I tried to configure policing 2Mbps for port ge-0/0/0, but receiving error
> at commit:
>
> Referenced filter 'Police-2M' can not be used as policer not supported
> on egress
> error: configuration check-out failed
>

You will need to configure an outbound shaper under the class-of-service
interface stanza.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 Sampling - High CPU

[Graham Brown]

12.3R8 and 13.3R4 are due out anytime now with the fixes in place. I think
there are many people waiting for these two releases...

Cheers,

Graham Brown
Twitter - @mountainrescuer 
LinkedIn 

On 24 September 2014 03:18, Justin M. Streiner 
wrote:

> Sounds like you are running into bugs PR963060 or PR671136.
>
> This is supposed to be fixed in 12.3R8 which is supposed to be released
> very soon.
>
> We ran into this behavior on a pair of MX480s and had to disable sampling
> for the time being.
>
> jms
>
>
> On Tue, 23 Sep 2014, Ritz Rojas wrote:
>
>  We have a few MX80s (MX80-48T) that we're looking to deploy in certain
>> applications where they'll be taking full Internet tables (v4 and v6).  We
>> also have a need to gather flow data on our routers, and have noticed an
>> interesting trend in the lab.
>>
>> We are not using an MS-MIC currently.
>>
>> This test box is running 12.3R7.7 at the moment, but we've seen this same
>> thing in 11.4 too.
>>
>> When set up with full Internet routes and sampling is enabled, each time a
>> commit is made for any change at all, RPD and sampled take turns grinding
>> the CPU up to 100%, for up to 5-10 minutes or more post-commit, and we see
>> changes to BGP policy sometimes stall and take a decent amount of time (on
>> the order of several minutes or more) to actually take effect.
>>
>> First RPD will climb up to almost 100% CPU utilization, chew it for a few
>> minutes, then it'll go down and sampled will climb up to almost 100% for
>> it's couple minutes turn and chew a bit.  Then sampled goes back down and
>> RPD takes back over to 100% for a few more minutes.  Eventually it all
>> finally calms back down and normalizes back to expected levels.
>>
>> Turn off sampling, and any CPU spikes post-commit are only on the order of
>> seconds, not minutes, and any policy changes take effect pretty much
>> immediately.
>>
>> We've seen this regardless of how flow is configured; we've configured
>> flow
>> with a "simple" config, as well as inline jflow, pretty much with the same
>> results.  We're curious if anyone's had any of these same problems with
>> jflow killing the CPU on MX80s (yeah, I know these PPC boxes are pretty
>> weak sisters), and if there's any fix beyond the usual "Doctor, it hurts
>> when I do this, what should I do?".  "Don't do that!".
>>
>> It's a nice feature, shame that using it seems to come with this heavy a
>> price.
>>
>> As an aside, we also see a bit of a slowdown in the RIB/FIB
>> learning/purging on BGP session turnup/reset, which we're well aware is a
>> known issue with sampling enabled, so I won't be shocked if this is just
>> "how it is".  I'd love to be wrong.
>>
>> Here's our sampling config, quick and dirty, regular and inline jflow, in
>> case we're missing something.
>>
>> "Normal" Sampling:
>>
>> router> show configuration forwarding-options
>> sampling {
>>input {
>>rate 8192;
>>run-length 0;
>>max-packets-per-second 2;
>>}
>>family inet {
>>output {
>>flow-server x.x.x.x {
>>port x;
>>version 5;
>>}
>>}
>>}
>> }
>>
>> router> show configuration interfaces xe-0/0/0
>> unit xxx {
>>vlan-id xxx;
>>family inet {
>>sampling {
>>input;
>>output;
>>}
>> }
>>
>>
>> Inline Jflow Sampling:
>>
>> router> show configuration forwarding-options
>> sampling {
>>instance {
>>BLAH-INSTANCE {
>>input {
>>rate 5000;
>>}
>>family inet {
>>output {
>>flow-server x.x.x.x {
>>port ;
>>autonomous-system-type origin;
>>no-local-dump;
>>version-ipfix {
>>template {
>>BLAH-TEMPLATE;
>>}
>>}
>>}
>>inline-jflow {
>>source-address x.x.x.x;
>>}
>>}
>>}
>>}
>>}
>> }
>>
>> router> show configuration chassis
>> tfeb {
>>slot 0 {
>>sampling-instance BLAH-INSTANCE;
>>}
>> }
>>
>>
>> router> show configuration services
>> flow-monitoring {
>>version-ipfix {
>>template BLAH-TEMPLATE {
>>flow-active-timeout 10;
>>flow-inactive-timeout 10;
>>template-refresh-rate {
>>packets 1;
>>seconds 10;
>>}
>>option-refresh-rate {
>>packets 1;
>>seconds 10;
>>}
>>ipv4-template;
>>}
>>}
>> }
>>
>>
>> router> show configuration interfaces xe-0/0/0
>> unit xxx {
>>vlan-id xxx;
>>family inet {
>>sampling

[j-nsp] Egress policer on EX3300

[Robert Hass]

Hi
Is egress policing or shaping supported on EX3300 platform ?

I tried to configure policing 2Mbps for port ge-0/0/0, but receiving error
at commit:

Referenced filter 'Police-2M' can not be used as policer not supported
on egress
error: configuration check-out failed

Input filters commiting & works without problems.

My config:

interfaces {
ge-0/0/0 {
unit 0 {
family ethernet-switching {
filter {
input Police-2M;
output Police-2M;
}
}
}
}
}
firewall {
family ethernet-switching {
filter Police-2M {
term Default {
then policer 2Mbps;
}
}
}
policer 2Mbps {
if-exceeding {
bandwidth-limit 2m;
burst-size-limit 100k;
}
then discard;
}
}


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

Re: [j-nsp] MX80 Sampling - High CPU

[Justin M. Streiner]

Sounds like you are running into bugs PR963060 or PR671136.

This is supposed to be fixed in 12.3R8 which is supposed to be released 
very soon.


We ran into this behavior on a pair of MX480s and had to disable sampling 
for the time being.


jms

On Tue, 23 Sep 2014, Ritz Rojas wrote:


We have a few MX80s (MX80-48T) that we're looking to deploy in certain
applications where they'll be taking full Internet tables (v4 and v6).  We
also have a need to gather flow data on our routers, and have noticed an
interesting trend in the lab.

We are not using an MS-MIC currently.

This test box is running 12.3R7.7 at the moment, but we've seen this same
thing in 11.4 too.

When set up with full Internet routes and sampling is enabled, each time a
commit is made for any change at all, RPD and sampled take turns grinding
the CPU up to 100%, for up to 5-10 minutes or more post-commit, and we see
changes to BGP policy sometimes stall and take a decent amount of time (on
the order of several minutes or more) to actually take effect.

First RPD will climb up to almost 100% CPU utilization, chew it for a few
minutes, then it'll go down and sampled will climb up to almost 100% for
it's couple minutes turn and chew a bit.  Then sampled goes back down and
RPD takes back over to 100% for a few more minutes.  Eventually it all
finally calms back down and normalizes back to expected levels.

Turn off sampling, and any CPU spikes post-commit are only on the order of
seconds, not minutes, and any policy changes take effect pretty much
immediately.

We've seen this regardless of how flow is configured; we've configured flow
with a "simple" config, as well as inline jflow, pretty much with the same
results.  We're curious if anyone's had any of these same problems with
jflow killing the CPU on MX80s (yeah, I know these PPC boxes are pretty
weak sisters), and if there's any fix beyond the usual "Doctor, it hurts
when I do this, what should I do?".  "Don't do that!".

It's a nice feature, shame that using it seems to come with this heavy a
price.

As an aside, we also see a bit of a slowdown in the RIB/FIB
learning/purging on BGP session turnup/reset, which we're well aware is a
known issue with sampling enabled, so I won't be shocked if this is just
"how it is".  I'd love to be wrong.

Here's our sampling config, quick and dirty, regular and inline jflow, in
case we're missing something.

"Normal" Sampling:

router> show configuration forwarding-options
sampling {
   input {
   rate 8192;
   run-length 0;
   max-packets-per-second 2;
   }
   family inet {
   output {
   flow-server x.x.x.x {
   port x;
   version 5;
   }
   }
   }
}

router> show configuration interfaces xe-0/0/0
unit xxx {
   vlan-id xxx;
   family inet {
   sampling {
   input;
   output;
   }
}


Inline Jflow Sampling:

router> show configuration forwarding-options
sampling {
   instance {
   BLAH-INSTANCE {
   input {
   rate 5000;
   }
   family inet {
   output {
   flow-server x.x.x.x {
   port ;
   autonomous-system-type origin;
   no-local-dump;
   version-ipfix {
   template {
   BLAH-TEMPLATE;
   }
   }
   }
   inline-jflow {
   source-address x.x.x.x;
   }
   }
   }
   }
   }
}

router> show configuration chassis
tfeb {
   slot 0 {
   sampling-instance BLAH-INSTANCE;
   }
}


router> show configuration services
flow-monitoring {
   version-ipfix {
   template BLAH-TEMPLATE {
   flow-active-timeout 10;
   flow-inactive-timeout 10;
   template-refresh-rate {
   packets 1;
   seconds 10;
   }
   option-refresh-rate {
   packets 1;
   seconds 10;
   }
   ipv4-template;
   }
   }
}


router> show configuration interfaces xe-0/0/0
unit xxx {
   vlan-id xxx;
   family inet {
   sampling {
   input;
   output;
   }
}
___
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] MX80 Sampling - High CPU

[Ritz Rojas]

We have a few MX80s (MX80-48T) that we're looking to deploy in certain
applications where they'll be taking full Internet tables (v4 and v6).  We
also have a need to gather flow data on our routers, and have noticed an
interesting trend in the lab.

We are not using an MS-MIC currently.

This test box is running 12.3R7.7 at the moment, but we've seen this same
thing in 11.4 too.

When set up with full Internet routes and sampling is enabled, each time a
commit is made for any change at all, RPD and sampled take turns grinding
the CPU up to 100%, for up to 5-10 minutes or more post-commit, and we see
changes to BGP policy sometimes stall and take a decent amount of time (on
the order of several minutes or more) to actually take effect.

First RPD will climb up to almost 100% CPU utilization, chew it for a few
minutes, then it'll go down and sampled will climb up to almost 100% for
it's couple minutes turn and chew a bit.  Then sampled goes back down and
RPD takes back over to 100% for a few more minutes.  Eventually it all
finally calms back down and normalizes back to expected levels.

Turn off sampling, and any CPU spikes post-commit are only on the order of
seconds, not minutes, and any policy changes take effect pretty much
immediately.

We've seen this regardless of how flow is configured; we've configured flow
with a "simple" config, as well as inline jflow, pretty much with the same
results.  We're curious if anyone's had any of these same problems with
jflow killing the CPU on MX80s (yeah, I know these PPC boxes are pretty
weak sisters), and if there's any fix beyond the usual "Doctor, it hurts
when I do this, what should I do?".  "Don't do that!".

It's a nice feature, shame that using it seems to come with this heavy a
price.

As an aside, we also see a bit of a slowdown in the RIB/FIB
learning/purging on BGP session turnup/reset, which we're well aware is a
known issue with sampling enabled, so I won't be shocked if this is just
"how it is".  I'd love to be wrong.

Here's our sampling config, quick and dirty, regular and inline jflow, in
case we're missing something.

"Normal" Sampling:

router> show configuration forwarding-options
sampling {
input {
rate 8192;
run-length 0;
max-packets-per-second 2;
}
family inet {
output {
flow-server x.x.x.x {
port x;
version 5;
}
}
}
}

router> show configuration interfaces xe-0/0/0
unit xxx {
vlan-id xxx;
family inet {
sampling {
input;
output;
}
}


Inline Jflow Sampling:

router> show configuration forwarding-options
sampling {
instance {
BLAH-INSTANCE {
input {
rate 5000;
}
family inet {
output {
flow-server x.x.x.x {
port ;
autonomous-system-type origin;
no-local-dump;
version-ipfix {
template {
BLAH-TEMPLATE;
}
}
}
inline-jflow {
source-address x.x.x.x;
}
}
}
}
}
}

router> show configuration chassis
tfeb {
slot 0 {
sampling-instance BLAH-INSTANCE;
}
}


router> show configuration services
flow-monitoring {
version-ipfix {
template BLAH-TEMPLATE {
flow-active-timeout 10;
flow-inactive-timeout 10;
template-refresh-rate {
packets 1;
seconds 10;
}
option-refresh-rate {
packets 1;
seconds 10;
}
ipv4-template;
}
}
}


router> show configuration interfaces xe-0/0/0
unit xxx {
vlan-id xxx;
family inet {
sampling {
input;
output;
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP Peer formatting

[Eugeniu Patrascu]

On Tue, Sep 23, 2014 at 7:11 AM, Ben Dale  wrote:

>
> Love your work Phil : )
>
> That's a heck of a lot simpler/cleaner than the recursive monstrosity I've
> been putting together!
>
> Changes have been pulled into github, so if you're running 11.4 or
> earlier, give it another try now.
>
>
Wee, it works now :)

Thank you.

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

Re: [j-nsp] BGP Peer formatting

[Michael Loftis]

For me at least, peer column needs to be wider (IPv6!) and duration
does too ( less than 1w you get a format like "2d 22:22:40")

On Mon, Sep 22, 2014 at 9:11 PM, Ben Dale  wrote:
>
> On 23 Sep 2014, at 1:48 pm, Phil Shafer  wrote:
>
>> Ben Dale writes:
>>> Okay, one small caveat to this script - it looks like the use of mutable 
>>> variables (mvar
>>> and set) was only introduced in SLAX 1.1 / Junos 12.2, so it's actually not 
>>> going to wo
>>> rk on older versions of Junos.
>>>
>>> I know 11.4 is the trusted choice for most people on MX at the moment, so 
>>> when I get som
>>> e time I'll attempt a mind-bending re-write using the older immutable var 
>>> format.
>>
>> In this case, you don't need the mvars.  Let sum() do the iteration:
>>
>>for-each ($neighbour-list/bgp-peer) {
>> jcs:printf("%-20s%-15s%-12s%-10s%-10s%-10s%-10s%-5s",
>>peer-address,
>>peer-as,
>>peer-state,
>>elapsed-time,
>>   sum(bgp-rib/active-prefix-count),
>>   sum(bgp-rib/received-prefix-count),
>>   sum(bgp-rib/accepted-prefix-count),
>>description);
>>}
>>
>> Thanks,
>> Phil
>
> Love your work Phil : )
>
> That's a heck of a lot simpler/cleaner than the recursive monstrosity I've 
> been putting together!
>
> Changes have been pulled into github, so if you're running 11.4 or earlier, 
> give it another try now.
>
> Ben
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp