Re: [j-nsp] JunOS forwarding IPv6 packets with link-local source

[Daniel Verlouw via juniper-nsp]

Hi,

On Thu, May 16, 2024 at 8:22 PM Antti Ristimäki via juniper-nsp
 wrote:
> I thought this issue had been resolved already years ago, but I
> noticed that JunOS still happily forwards IPv6 packets with link-local
> source address towards remote destinations. This of course violates
> RFC4291. Also recent JunOS releases seem broken, tested with e.g. 21.4
> and 23.2.

on MX:
set forwarding-options family inet6 source-checking

refer to: 
https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/source-checking-edit-forwarding-options.html

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

Re: [j-nsp] ACX5448 & ACX710 - Update!

[Daniel Verlouw]

Hi Mark,

On Wed, Jul 29, 2020 at 4:24 PM Mark Tinka  wrote:
> I'm not sure I can be that patient, so I'm sniffing at Nokia's new
> Metro-E product line. The problem is so far, as with Juniper and Cisco,
> they've gone down the Broadcom route (some boxes shipping with Qumran,
> others with Jericho 2, and on-paper, they are already failing some of
> our forwarding requirements.

which Nokia platform are you looking at? 7250 IXR is also
Qumran/Jericho, Nokia is just hiding it everywhere they can...

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

Re: [j-nsp] BPDUs over EVPN?

[Daniel Verlouw]

> Are there vendor implementations?

Yes, am running in production on MX, ASR9K and NCS5500. Interops
nicely too, for the most part.
Believe Arista and others have working implementations too.

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

Re: [j-nsp] BPDUs over EVPN?

[Daniel Verlouw]

Hi,

On Fri, Oct 18, 2019 at 11:45 AM Gert Doering  wrote:
> If yes, is this something people do over EVPN?

as an extension to 'plain' EVPN, yes. It's called EVPN-VPWS, RFC 8214.
Basically EVPN without the MAC learning.

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

Re: [j-nsp] prsearch missing in inaction

[Daniel Verlouw]

Hi,

On Thu, May 9, 2019 at 1:54 PM Richard McGovern via juniper-nsp
 wrote:
> Nathan, I am not sure what you want to hear, or what would make you 
> satisfied, but YES Juniper [IT?] did screw-up, and a restore from back-up 
> was/is not possible.  So this situation is now being worked on, unfortunately 
> at a not so fast pace.  I hope you decide to stay with Juniper, as I feel 
> there are far worse things one could be concerned about than this.

You're downplaying the issue with the wrong arguments imho. For a lot
of us it is an important tool in our daily routine and in fact
offloads work from both our (operational/design) teams -and- yours.
I'm willing to bet the amount of time JTAC and local account teams
have had and are going to spend on customer queries due to the tool
being unavailable, far outweighs the cost of a small team of
developers to fix this within a few weeks.
And yes, agreed, mistakes are a fact of life, that's how we all
(hopefully) learn to improve. But why it takes 6+ months to fix
something as seemingly trivial as this is beyond me.

And yes, we and many others have bitched and moaned about it to our
local account teams, including the whole website layout and
accessibility to key technical information getting worse and worse on
every iteration. The account team agrees, confirms they receive the
same feedback from other customers, they relay the feedback to the
people in charge, and a few days later we get the next "new and
improved" website infested with even more marketing B/S... To me these
are some of the signs the company isn't prioritising correctly and
isn't truly listening to its customers.

Luckily your competitors aren't doing much better ;-)

BR, Daniël.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Simple v4 vs v6 traffic measurement

[Daniel Verlouw]

Tim,

On Tue, Oct 31, 2017 at 9:00 PM, Tim St. Pierre
 wrote:
> Can anyone suggest a simple way to measure interface traffic by address
> family?  Currently, I'm measuring interface traffic using SNMP queries and
> just grabbing the in / out bit byte counters.

check out 
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/forwarding-class-accounting-edit-interfaces.html
(only on MX/MPC)
IIRC there's a separate MIB too.

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

Re: [j-nsp] Junos CoS - ingress hierarchical policer

[Daniel Verlouw]

On Thu, May 18, 2017 at 12:44 PM, Saku Ytti  wrote:
> Why would you run policer, if shaper is available.

on egress, agreed, but the OP mentioned he wants to do ingress
policing. Not many platforms support ingress shaping afaik.

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

Re: [j-nsp] Juniper MPC-3D-16XGE-SFPP/SCBE2 incompatibility?

[Daniel Verlouw]

On Tue, Jan 10, 2017 at 7:45 PM, Brandon Ross  wrote:
> I have a colleague trying to use a MPC-3D-16XGE-SFPP with SCBE2s and getting
> an "FPC misconfiguration" message in 'show chassis fpc' on an MX. It works
> fine with SCBE, just not SCBE2, they tell me.
>
> Does anyone have any experience with this?  I searched all over the place
> but can find no documentation that says which SCBs are compatible with this
> MPC, does anyone know of any docs to that effect?

all MPC cards should work, but make sure you're running in enhanced
services mode.

set chassis network-services enhanced-ip or -ethernet
(reboot after commit)

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

Re: [j-nsp] What version of Junos is best for bgp.

[Daniel Verlouw]

Hi,

On Fri, Sep 16, 2016 at 11:38 AM, Mark Tinka  wrote:
> I'd suggest 14.2R7. It's been through the wash a few times and is
> scent-free...

One word of caution for 14.2R7: I have an open case where the box
stops both logging & sending SNMP traps for link flaps. Issue occurs
right after an upgrade. I can consistently re-produce this in our lab
on multiple devices. Restarting the mib2d process fixes the problem.
Waiting for the PR

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

Re: [j-nsp] RVSP signaled L3VPN and RRs

[Daniel Verlouw]

On Thu, Aug 18, 2016 at 5:46 PM, raf  wrote:
> Hum my RRs do NHS, and I don't think I could easily change this.

if your RRs do NHS for l3vpn routes, it will break the fowarding path;
- in your scenario, your PEs don't have RSVP LSPs towards your RRs
- and even if they would (for example if you run LDP on your RRs):
your RRs don't have VRFs, so the inner VPN label lookup would fail

> Without NHS this is effectively not needed as I already have the loopbacks
> of all my PEs in inet.3 populated via RSVP.

PEs have inet.3 populated via RSVP in your case, the RRs don't. That's
why you change the RIB resolution for bgp.l3vpn.0 on the RRs, so it
can correctly resolve and reflect the l3vpn routes. You don't change
the resolution on the PEs, because you want them to use the RSVP LSPs
in inet.3

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

Re: [j-nsp] RVSP signaled L3VPN and RRs

[Daniel Verlouw]

Hi,

On Thu, Aug 18, 2016 at 5:13 PM, raf  wrote:
> I've changed resolution of bgp.inet.0 to inet.0 on RRs and PEs.

you only need to do this on your RRs, not on your PEs. And make sure
your RRs don't set NHS.

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

Re: [j-nsp] ACX50xx l2circuit counters

[Daniel Verlouw]

Hi Nathan,

On Mon, Jun 20, 2016 at 6:03 AM, Nathan Ward  wrote:
> Does anyone have and tricks to make l2circuit counters work properly, or, is 
> this a lost cause?

on ACX1k/2k/4k, you have to explicitly enable per unit statistics
collection. We simply enable it on all units using an apply-group;

set groups per-unit-statistics interfaces <*> unit <*> statistics
set interfaces apply-groups per-unit-statistics

Not sure if this is also needed on the 5k, so give it a try...

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

Re: [j-nsp] RE-S-X6-64G-BB

[Daniel Verlouw]

Hi,

On Wed, May 25, 2016 at 7:06 PM, Saku Ytti  wrote:
> Longer time before it's end of support, better resell value on top of
> normal better scale and convergence.

definitely good and valid points, however are you willing to deploy
(what I consider) bleeding-edge code in your network to support the
latest and greatest HW? I'm most certainly not, have plenty of issues
today with so-called 'stable' releases...

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

Re: [j-nsp] Full routes on MX5

[Daniel Verlouw]

Hi,

On Tue, Apr 26, 2016 at 3:31 PM, Mark Tinka  wrote:
> That said, I think the MX104 feels even slower - I think having to
> commit a configuration on multiple RE's just doubly slows things down.

have you considered using the [system commit fast-synchronize] option?
Allows the config to commit simultaneously on both REs.

Also [system commit persist-groups-inheritance] may help if you
(extensively) use apply-groups (at the expense of some memory usage).

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

Re: [j-nsp] ACX5048 - vlan-map conflict with routing-instance with vlan-id tags

[Daniel Verlouw]

Hi Aaron,

On Thu, Apr 21, 2016 at 10:20 PM, Aaron  wrote:
> agould@eng-lab-5048-1# commit
> [edit vlans vlan10]
>   'interface ge-0/0/38.17'
> l2ald ACX: On a bd, for each ifd only one ifl can be added
> [edit vlans]
>   Failed to parse vlan hierarchy completely
> error: configuration check-out failed

that's a different issue from the vlan-swap problem you had, and is
actually a known limitation described in the manual/rel.notes;

"A bridge domain cannot have two or more logical interfaces that
belong to the same physical interface."

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

Re: [j-nsp] ACX5048 - vlan-map conflict with routing-instance with vlan-id tags

[Daniel Verlouw]

Hi Aaron,

On Thu, Apr 21, 2016 at 7:48 PM, Aaron  wrote:
> [edit vlans vlan10 interface]
>   'ge-0/0/38.17'
> interface with input/output vlan-maps cannot be added to a 
> routing-instance with a vlan-id/vlan-tags configured
> error: commit failed: (statements constraint check failed)

The error msg is pretty clear :) did you try my first suggestion which
was simply to remove the input/output-vlan-maps ? So:

set interfaces ge-0/0/38 flexible-vlan-tagging
set interfaces ge-0/0/38 encapsulation flexible-ethernet-services
set interfaces ge-0/0/38 unit 17 encapsulation vlan-bridge
set interfaces ge-0/0/38 unit 17 vlan-id 17
set vlans vlan10 interface ge-0/0/38.17
set vlans vlan10 l3-interface irb.10
set vlans vlan10 vlan-id 10

I'm fairly sure this worked when we PoC'd it (don't have my notes
handy, and we didn't go for the ACX5k in the end, so can't try it
again). The interface is automatically config'd for a vlan swap
to/from vlan 10 in this case.

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

Re: [j-nsp] ACX5048 - vlan-map conflict with routing-instance with vlan-id tags

[Daniel Verlouw]

Hi Aaron,

On Tue, Apr 19, 2016 at 10:43 PM, Aaron  wrote:
> Goal, to do tagging on ge-0/0/38 for 802.1q vlan tags of 10 and 17 and also,
> put those tagged frames into the SAME vlan/bridge-domain so that they can
> use the same ip subnet on the irb.10 interface that sits atop that vlan.

if memory serves me well, you can simply leave out the
input-/output-vlan-map from the interface config. It will
automatically be normalized to the vlan-id specified under your [edit
vlans vlan10] config. Check with 'show int extensive' and you should
see an implicit vlan swap operation. Or; remove the vlan-id and
explicitly define an input-/output-vlan-map on all interfaces part of
this bridge domain.

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

Re: [j-nsp] access-internal routes

[Daniel Verlouw]

Hi,

On Wed, Mar 30, 2016 at 10:41 PM, Aaron  wrote:
> what are these routes (access-internal) ?  i'm seeing them actually being
> sent over my MPLS L3VPN into my other pe's as /32 routes.  very interesting.
> and seemingly very inefficient and busy.  not sure that I like the idea of
> host routes for 10's of thousands of hosts being injected into my mpls vpn
> all over my network.  i'm thinking this is happening possible from dhcp
> relay on my acx5048.  how do I turn off the /32 route injection at the
> acx5048 ?

what does your VRF export policy look like? Sounds like you're
permitting all routes from all protocols and tagging them with RT
community. Try changing your VRF export policy to reject the
access-internal routes prior to accepting all the rest (or
permit e.g. only bgp and connected and reject everything else).

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

Re: [j-nsp] ACX5048 - protect remote access (telnet, ssh, http, snmp)

[Daniel Verlouw]

Hi,

On Fri, Apr 1, 2016 at 9:52 PM, Aaron  wrote:
> agould@eng-lab-acx5048-1# commit confirmed 1 [edit interfaces lo0 unit 0
> family inet]
>   'filter'
> Referenced filter 'local_acl' can not be used as default/physical
> interface specific with lo0 not supported on ingress loopback interface
> error: configuration check-out failed

ACX does not support lo0 filter presently, which sucks. Good news is
that it's on the roadmap for sometime this year I believe. No clue why
they left it out in the first place...
As an alternative, you can apply input filter either to all your L3
interfaces, or use a fwd table filter.
E.g. permit trusted src to your infra, deny non-trusted src to your
infra, permit everything else for transit.

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

Re: [j-nsp] Optimizing the FIB on MX

[Daniel Verlouw]

Hi,

On Mon, Feb 22, 2016 at 6:53 PM, Saku Ytti  wrote:
> On pre-Trio it would disable egress filters, but on Trio it won't.

yup, Trio always uses the egress proto family, whereas DPC would use
the ingress (i.e. mpls) when vrf-table-label is used.
One more reason to love Trio :-)

> I'd really want per CE labels + aggregate label for connected network.

while a bit cumbersome, that's possible today, using something along
the lines of:

set policy-options policy-statement direct-per-VRF from protocol direct
set policy-options policy-statement direct-per-VRF then
label-allocation per-table

set policy-options policy-statement per-CE then label-allocation per-nexthop
set policy-options policy-statement per-CE then accept

set routing-instances  vrf-table-label # set default to per-table
set routing-instances  routing-options label allocation per-CE
# override to per-CE by default
set routing-instances  vrf-export [ direct-per-VRF  ]  # revert to per-table for directly
connected


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

Re: [j-nsp] ip(v6) options

[Daniel Verlouw]

Hi,

On Thu, Jan 28, 2016 at 10:37 PM, Saku Ytti  wrote:
> Anyone remember from top of their head if or not Trio originally
> punted transit IP packets with IP options through lo0 filter or not?

http://kb.juniper.net/InfoCenter/index?page=content=KB30719=search

just came online. Coincidence? :-)

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

Re: [j-nsp] IPv4 Filter for ECN/CWR tcp bit (RFC3168)

[Daniel Verlouw]

Hi Jonas,

On Fri, Nov 27, 2015 at 2:20 PM, Jonas Frey (Probe Networks)
 wrote:
> Does anybody have any idea if its possible to filter for such traffic?

have you looked at the firewall flexible match conditions? (avail in
14.2 for MX/MPC).

https://www.juniper.net/techpubs/en_US/junos14.2/topics/concept/firewall-filter-flexible-match-conditions-overview.html

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

Re: [j-nsp] End of M-series hardware with BGP Fulltable

[Daniel Verlouw]

Hi,

On Mon, Nov 17, 2014 at 9:24 PM, Joerg Staedele j...@tnib.de wrote:
 Currently i only know about a enhanced SSB for M20 which is available and has 
 16MB so this limit will not be reached in the near future but all other 
 (older) models only have 8MB (fixed on the board, not replacable!) and there 
 are no upgrades available (as far as i know).

for the M7i and M10i there's the enhanced CFEB, basically (IIRC) a
Trio-based/-like CFEB, along with plenty more memory.

BR, Daniel.

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

Re: [j-nsp] End of M-series hardware with BGP Fulltable

[Daniel Verlouw]

On Mon, Nov 17, 2014 at 9:41 PM, Daniel Verlouw dan...@shunoshu.net wrote:
 for the M7i and M10i there's the enhanced CFEB, basically (IIRC) a
 Trio-based/-like CFEB, along with plenty more memory.

I-chip based that is...
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX is just not there (was Re: EX4550 L2Circuit/VPN to MX80/lt Interface)

[Daniel Verlouw]

Hej Mark,

On Thu, Nov 13, 2014 at 5:10 PM, Mark Tinka mark.ti...@seacom.mu wrote:
 I'd deploy vMX as a route reflector. I was actually
 evaluating vRR a few months ago, but it still had a long way
 to go, so went with Cisco's CSR1000v (which is, basically,
 IOS XE) instead.

would you be able to elaborate on your experience with vRR ? We’re
about to re-evaluate our RR deployment and going ‘virtual / PC-based’
is certainly high on our list. Too bad there's hardly any info on vRR
around, or I'm looking in the wrong place (which is not terribly hard
after yet another poor redesign of jnpr.net)

Other than being used as RR, I (so far) fail to see how vMX would be
deployed in carrier networks such as ours. Virtualized DCs, yes,
maybe, but that’s whole different ball game.

BR, Daniel.

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

Re: [j-nsp] ACX is just not there (was Re: EX4550 L2Circuit/VPN to MX80/lt Interface)

[Daniel Verlouw]

Hi,

 For starters, at least when we evaluated it last year, there was no switching 
 or IRB support.

there is now, bridge-domains + IRB with L3VPN is what we use without a problem.

We have a few hundred ACX deployed for our mobile backhaul and will
ramp up that number over the next few months. It does have its quirks
related to Broadcom ASIC limitations (indeed CoS is one thing,
firewall filters another), but overall, for mobile, it's a nice
platform at a low cost point. I could see the ACX work for our L2
metro business as well from a functionality point of view, but there
the port density kills it. I echo the sentiment of others, Juniper
really dropped the ball here. The gap between ACX and MX is simply far
too large.

What are others using for let's say MPLS + 12x 1GE + 4x 10GE ?
- 7210 SAS-M
- 3600X 24CX
- higher density ASR920 will be around I understand?
- any others to consider presently?

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

[j-nsp] bgp metric-out igp and CPU utilization

[Daniel Verlouw]

Hi list,

before i open a tac case, wondering if anyone has seen something similar;

when we enable 'metric-out igp offset delay-med-update' towards a full-table 
downstream bgp customer (exporting ~400k prefixes), CPU % of rpd process spikes 
through the roof (mostly in kqread state), overall RE CPU % constantly stays 
well above 60% and BGP convergence seems to take forever in this state. And 
this is just on a single neighbor.
With 'metric-out fixed value' all is ok, and RE CPU % is in the 5-10% range.

'show task accounting' is showing high user run time for 'RT' and the BGP peer 
group on which we enabled the igp-based setting.
'rtsockmon -t rpd' appears to show no excessive route churn or oscillation for 
both igp-based and fixed value cases.


'show krt queue' is not showing any 'stuck' routes.
IGP (IS-IS) and RSVP-based LSPs are stable.


config bits;

[routing-options]
med-igp-update-interval 10;

[protocols bgp group IPTcust]
metric-out igp offset delay-med-update
or;
metric-out fixed value



This is on MX960 with 10.4R10.7. 

Any ideas?

--
Daniel.


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

Re: [j-nsp] Update on 10.4R9 stability for MX?

[Daniel Verlouw]

Hi,

On Thu, May 10, 2012 at 1:59 AM, Richard A Steenbergen r...@e-gerbil.net 
wrote:
 There is a serious issue with MPLS RSVP auto-bandwidth in 10.4R9, which
 can cause the reservation calculations to be off by quite a bit. The
 least broken code we've found so far is 10.4S9, I'm surprised they
 haven't done an R10 yet.

do you have a PR for this? What are the circumstances? Haven't seen
this, but to be honest, haven't paid very close attention to it :)

I was told that R10 should be available early May, possibly even this week...

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

Re: [j-nsp] Update on 10.4R9 stability for MX?

[Daniel Verlouw]

On Wed, May 9, 2012 at 9:13 PM, Clarke Morledge chm...@wm.edu wrote:
 I am curious to know about anyone's experience with 10.4R9 over the past few
 months.  I have DPC only currently; i.e. no MPC hardware -- and no
 MultiServices.

I've been hit by:
PR570168 - RE crash triggered by deletion and recreation of multiple
vt/lsi IFLs in quick successions. I saw this once right after an
upgrade. Nice that both RE's crash simultaneously...
PR724638 - cosd crash

but other than that, i haven't seen any major issues.

  --Daniel.

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

Re: [j-nsp] 10.4R9 on MX stable?

[Daniel Verlouw]

Hi,

On Fri, Feb 17, 2012 at 17:18, Paul Stewart p...@paulstewart.org wrote:
 Has anyone got 10.4R9 running on MX platform in production yet?  I'm looking
 for any feedback as JTAC is recommending we go to this release.

hopefully I can share some results on Tuesday...looks fine in the lab
so far, but then again, so did 10.4R8  :P

10.4R8 contained many fixes we were waiting for, so 10.4R7 was a no-go for us.

*keeps fingers crossed*

   --Daniel.

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

Re: [j-nsp] Junos 10.4R8 on MX (PR 701928)

[Daniel Verlouw]

Hi,

On Tue, Jan 24, 2012 at 08:25, Daniel Roesen d...@cluenet.de wrote:
 Daniel (waiting for over a year now for a 10.4 without major bugs...)

same here...

Am I the only one who finds it extremely annoying and disturbing that
critical bugs get *introduced* this far down into an E-EOL train!?
And where's the technical bulletin that alerts all of us?
Interesting that j-nsp is a better source of information than
JTAC...

BR, Daniel (2)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] In Search of the Optimal RE Protect Filter - A Journey

[Daniel Verlouw]

Hi guys,

To revive this thread; does anyone know how to check what type of
packets are being matched when using an family any input filter on lo0
?

You can't seem to use log as action and the from clause only allows
some protocol independent matches;

daniel@lab# set firewall family any filter test term test from ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
+ forwarding-class Match forwarding class
+ forwarding-class-except  Do not match forwarding class
 interfaceMatch interface name
 interface-setMatch interface in set
+ packet-lengthMatch packet length
+ packet-length-except  Do not match packet length
[edit]

daniel@lab# set firewall family any filter test term test then ?
Possible completions:
  accept   Accept the packet
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  countCount the packet in the named counter
  discard  Discard the packet
  forwarding-class Classify packet to forwarding class
  loss-priorityClassify packet to loss-priority
  next Continue to next term in a filter
  policer  Name of policer to use to rate-limit traffic
 three-color-policer  Police the packet using a three-color-policer
[edit]

The docs say layer 2 control packets, but which ones? Are all
non-IP packets matched against this family any filter?

http://www.juniper.net/techpubs/en_US/junos10.4/topics/example/policy-layer-2-incoming-packet-rate-limit-setting.html

There's even an example in RFC6192 :-) http://www.faqs.org/rfcs/rfc6192.html

Anyone using this? Pros/cons?

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

Re: [j-nsp] In Search of the Optimal RE Protect Filter - A Journey

[Daniel Verlouw]

On Fri, Aug 26, 2011 at 17:38, Clarke Morledge chm...@wm.edu wrote:
 I would love to be proven wrong on this, but I do not think you can use
 family any filters on the lo0 interface.

well, it does commit on M and MX running 10.4;

set firewall family any filter test term test then accept count counter
set interfaces lo0 unit 0 family any filter input test
commit

and counter immediately starts increasing;

run show firewall filter test

Filter: test
Counters:
NameBytes  Packets
counter  4812   19

I'm really wondering what exactly it is matching on, is it all
non-IP or only some specific layer 2 (control) packets?

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

Re: [j-nsp] ECMP vs LAG and OAM vs BFD

[Daniel Verlouw]

On Fri, Jul 22, 2011 at 22:14, Stefan Fouant
sfou...@shortestpathfirst.net wrote:
 Regarding BFD's capabilities to determine member state of individual member
 links, this is not currently supported by BFD.  Take a look at IETF Draft
 'Bidirectional Forwarding Detection (BFD) for Interface' which was just
 released a few weeks ago. It is designed to meet these requirements -
 http://tools.ietf.org/html/draft-chen-bfd-interface-00

IOS XR (at least on the ASR9k) supports BFD over individual member
links. Saw it in the lab, seemed to work fine. Not sure if it's
implementation is based on this draft though, or if it's a proprietary
one.

  --Daniel.

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

Re: [j-nsp] Back-reference in JunOS regular expressions

[Daniel Verlouw]

Hi,

On Wed, Jul 13, 2011 at 15:18, Michael Hallgren m.hallg...@free.fr wrote:
 I can't find a firm statement in the JunOS documentation, and some
 tests makes me believe it's not implemented. Or am I mistaken with
 the syntax? (I can use back-reference in 'replace', etc, etc...)

see https://puck.nether.net/pipermail/juniper-nsp/2010-July/017473.html

Not supported. I requested an ER back then, don't think it ever got
implemented...

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

Re: [j-nsp] New J-net publications: Secure the routing engine and Useful tips/tricks

[Daniel Verlouw]

Hi,

On Wed, Jun 22, 2011 at 02:01, Harry Reynolds ha...@juniper.net wrote:
 Hey all, Please pardon the wide distribution. I recall seeing postings on 
 this list regarding current best practices for securing Juniper Networks 
 Routing Engines via firewall filters.

just briefly skimmed over it, good stuff!

Perhaps I'm nitpicking here, but my first thought when seeing the
following term was; this will allow anyone to access all open TCP
ports, simply by modifying their host outbound TTL so that the packets
arrive with TTL=1 at the router.

term accept-traceroute-tcp {
from {
destination-prefix-list {
router-ipv4;
router-ipv4-logical-systms;
}
protocol tcp;
ttl 1;
}
then {
policer management-1m;
count accept-traceroute-tcp;
accept;
}
}

Perhaps I misread the rest of the config or maybe I'm being paranoid,
but this something I would definitely not recommend :-)

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

[j-nsp] RSVP automesh

[Daniel Verlouw]

Hi list,

Has anyone played around with RSVP/MPLS automesh feature and can share
some experiences and/or example configs? I believe it was introduced
in 10.1, but can't find anything in the release notes and docs aren't
very clear either;

http://www.juniper.net/techpubs/en_US/junos10.1/topics/task/configuration/rsvp-automatic-mesh.html


Regards,

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

Re: [j-nsp] Optimal BFD settings for BGP-signaled VPLS?

[Daniel Verlouw]

On Jan 17, 2011, at 11:50 PM, Keegan Holley wrote:
 Of course I can't find the link now, but just last night I read that prior
 to JunOS 9.4 echo mode required a command to be entered in order to move BFD
 to the forwarding plane.  In or after 9.4 a new daemon was created to allow
 BFD to run in the forwarding plane and that became the default.  I don't
 have time now but I will post the link later.

help topic routing-options ppm

still not echo mode though, it's async, regardless of where it's running, RE or 
PFE. As Steinar said, echo mode is not supported.

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

Re: [j-nsp] Filtering the export of VRF routes with iBGP export filters....

[Daniel Verlouw]

On Tue, 2010-08-31 at 08:44 -0600, David Ball wrote:
 Thanks Krasimir.  I'd run across that knob previously, but my understanding
 is that the functionality provided by vpn-apply-export is enabled when a
 router is configured as a route-reflector, which mine are already.  Will
 give it a whirl anyways, though.

my understanding is that you only need vpn-apply-export on an RR if its
also acting as a PE and you need to filter the routes from local VRFs.
Reflected routes shouldn't be affected afaik.

In any case, I couldn't get a policy with a match on 'rib bgp.l3vpn.0'
to work at all, so I'm interested to see your config if you get it to
work.

  --Daniel.


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

[j-nsp] AS-path regexp clue needed

[Daniel Verlouw]

Hi,

can someone give me some clue on how to translate the following Cisco
regexp to Junos ? 

ip as-path access-list 1 permit ^([0-9]+)(_\1)*$

(this uses pattern recall to match AS paths whose first AS number in the
path is repeated zero or more times; basically to make sure certain
customers prepend their own AS number only).

IOS-to-Junos translator is unable to parse this and JTAC, well, let's
just say they don't seem to get it -at all-.

Of course, I could write a regexp per customer, but obviously this
doesn't scale very well.

  --Daniel.

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

Re: [j-nsp] AS-path regexp clue needed

[Daniel Verlouw]

On Thu, 2010-07-29 at 14:45 +0200, KJ wrote:

 http://www.juniper.net/techpubs/software/junos/junos74/swconfig74-policy/html/policy-extend-match-config3.html

I'm familiar with the manual, thank you.

I'm not sure what operator you're specifically aiming at, but stuff like
[1-65535]* doesn't work despite the manual saying 
Range of AS numbers to match a single AS number. The issue seems to be
a lack of pattern recall operators in Junos (\n as in POSIX regular
expressions).

  --Daniel.

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

Re: [j-nsp] Firewall Filters and BFD

[Daniel Verlouw]

On Jun 10, 2010, at 4:59 PM, Thomas Eichhorn wrote:
 Has somebody here an idea what to allow or maybe even
 a working configuration for this?


this works for us (for both singlehop and multihop paths):

term allow-bfd-control {
from {
source-prefix-list {
 insert prefix list(s) with allowed BFD neighbors
}
protocol udp;
source-port 49152-65535;
destination-port [ 3784 4784 ];
}
then accept;
}
[... other lo0 terms ]

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

Re: [j-nsp] vulnerability fix not available for 8.5 ?

[Daniel Verlouw]

On Fri, 2010-01-08 at 07:36 -0500, Eric Van Tol wrote:
 Wait, what?  Can anyone confirm the removal of GE-SX-B drivers?

9.5R3.7 seems to work fine with a non-EFPC and PE-1GE-SX-B:

FEB  REV 10   710-002503   removedFEB-M5-S
FPC 0   
  PIC 0  REV 02   750-003163   removedPE-1GE-SX-B
  PIC 1  REV 05   750-003163   removedPE-1GE-SX-B

ge-0/0/0upup  
ge-0/1/0upup  

   --Daniel.

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

Re: [j-nsp] show route advertising-protocol on IPv6 peers

[Daniel Verlouw]

On Wed, 2010-01-06 at 14:04 -0600, Richard A Steenbergen wrote:
 Yeah I've seen that behavior for years now, never got around to opening
 a case on it though. If you specify the table in your show route command
 (either inet.0 or inet6.0) it will return the results quickly, it's 
 only slow if you don't request a specific table.

thanks for the tip Richard, that seems to work! I've added this to the
case notes, so hopefully they'll come up with a fix.

   --Daniel.

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

Re: [j-nsp] JUNOS vulnerability with malformed TCP packets

[Daniel Verlouw]

On Thu, 2010-01-07 at 08:04 -0500, Paul Stewart wrote:
 Anyone know why some issues identified as early as January 2009 are only
 being released now almost a year later? 

someone forgot to hit the 'send' button? ;) 

Interestingly enough, all of the PRs mentioned in these bulletins are
not available for the general public... :/


   --Daniel.

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

Re: [j-nsp] show route advertising-protocol on IPv6 peers

[Daniel Verlouw]

On Wed, 2009-12-16 at 16:39 +0100, Daniel Verlouw wrote:
 It's most obvious with IPv6 neighbors receiving a full feed (+/- 2400
 prefixes) from us, whereas the same command with an IPv4 neighbor
 receiving a full feed (300k prefixes) is almost instantaneous.

funny enough, I just ran into the same issue with an IPv4 peer receiving
only a single default route from us. Still working with JTAC, but so far
nothing useful..

   --Daniel.

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

[j-nsp] show route advertising-protocol on IPv6 peers

[Daniel Verlouw]

Hi all,

has anyone ever seen the behaviour below? I've been going back and forth
with JTAC for months now without any result (which seems to be the norm
nowadays...). We just upgraded a few M-series boxes from 9.3 to 9.5R3
and the issue still persists. It seems the issue was introduced in one
of the earlier 9.x releases.

dan...@x show route advertising-protocol bgp ipv6 neighbor
error: timeout communicating with routing daemon

Dec 16 16:20:23.671 2009  X mgd[73749]: %INTERACT-6-UI_CMDLINE_READ_LINE: 
User 'daniel', command 'show route advertising-protocol bgp ipv6 neighbor '
Dec 16 16:21:23.659 2009  X mgd[73749]: %DAEMON-5-UI_READ_TIMEOUT: Timeout 
on read of peer 'routing'

It's most obvious with IPv6 neighbors receiving a full feed (+/- 2400
prefixes) from us, whereas the same command with an IPv4 neighbor
receiving a full feed (300k prefixes) is almost instantaneous.

Cheers,
   Daniel.

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

Re: [j-nsp] Urgent downgrade pic

[Daniel Verlouw]

On Wed, 2009-11-11 at 15:19 +0530, chandrasekaran iyer wrote:
Has anyone downgraded the PIC? how to do it? Which PICs are
 supported by 6.1 release.

downgrade the PIC? What exactly do you want to achieve? And I'm more
curious about why you would want to run JUNOS version that's EOLd over 5
years ago?

  --Daniel.

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

Re: [j-nsp] ISIS Case Study in JNCIP..Summarization into Backbone

[Daniel Verlouw]

On Fri, 2009-09-18 at 01:16 -0700, Hoogen wrote:
 Now from my understanding of the question I need to deny the longer more
 specific routes... on R5 filter saying 172.16.40/29 longer the reject...

yes it is quite common to suppress the more specifics. A more scalable
approach would be to use the 'aggregate-contributor' match condition to
suppress the more specifics, e.g.:

term accept-aggregates {
  from {
protocol aggregate;
  }
  to level 2;
  then accept;
}
term reject-more-specifics {
  from {
aggregate-contributor;
  }
  to level 2;
  then reject;
}


   --Daniel.

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

Re: [j-nsp] MPLS VPN Load-balancing

[Daniel Verlouw]

Hi Harry,

On Aug 12, 2009, at 6:50 PM, Harry Reynolds wrote:
T-series platforms with e-fpcs and MX can hash on multiple MPLS  
labels while *also* hashing on L3 and l4.


This seems to jive with the docs at:

http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-collections/config-guide-policy/policy-configuring-load-balancing-based-on-mpls-labels.html


the following document mentions multiple labels + payload hashing is  
supported on M320 and T-series:


http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-collections/config-guide-mpls-applications/mpls-configuring-load-balancing-for-mpls-lsps.html 



There's no mention of I-chip based systems (M120 or MX) on this page.  
Does this imply those can also hash only on the first label + payload ?


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

Re: [j-nsp] JUNOS IS-IS QoS

[Daniel Verlouw]

On Fri, 2009-07-31 at 16:43 +0500, mas...@nexlinx.net.pk wrote:
 So does it mean that ISIS
 traffic is always treated as BE. Is there anything else that is hardcoded
 for ISIS QoS?

IS-IS is mapped to the NC forwarding class (queue 3).

Check
http://www.juniper.net/techpubs/software/junos/junos93/swconfig-cos/default-routing-engine-protocol-queue-assignments.html

  --Daniel.

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

Re: [j-nsp] RPD soft assertion failed

[Daniel Verlouw]

On Wed, 2009-05-27 at 19:01 +0200, Daniel Verlouw wrote:
 JTAC has decoded the core dumps and on initial analysis it appears to  
 match PR 448745 - RPD core at krt_inh_lock_internal. The PR doesn't  
 mention 9.3 as affected though. I'll keep the list posted on any  
 progress.

JTAC is now saying this is a different trigger for PR/300407 which was
closed in 9.3R1, PR is re-opened. They're recommending a downgrade as a
workaround.

In the meantime, we've seen several occurences on another M-series as
well.

  --Daniel.

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

[j-nsp] RPD soft assertion failed

[Daniel Verlouw]

Hi,

anyone else seeing messages similar to the following? We started seeing
several of these after upgrading one of our M120s to 9.3R3.8 last night.

May 27 10:28:05.806 2009  jun1.bit-1 rpd[1149]: %
DAEMON-3-RPD_ASSERT_SOFT: Soft assertion failed rpd[1149]: file
../../../../../src/juniper/usr.sbin/rpd/rt/rt_table.c, line 4732:
rt_notbest_sanity: Path selection failure on 80.92.176.0/20,
recovering..., daemon continued running
May 27 10:28:05.868 2009  jun1.bit-1 rpd[1149]: %
DAEMON-3-RPD_ASSERT_SOFT: Soft assertion failed rpd[1149]: file
../../../../../src/juniper/usr.sbin/rpd/rt/rt_table.c, line 4732:
rt_notbest_sanity: Path selection failure on 80.92.176.0/24,
recovering..., daemon continued running
May 27 10:28:06.290 2009  jun1.bit-1 rpd[1149]: %
DAEMON-3-RPD_ASSERT_SOFT: Soft assertion failed rpd[1149]: file
../../../../../src/juniper/usr.sbin/rpd/rt/rt_table.c, line 4732:
rt_notbest_sanity: Path selection failure on 94.25.208.0/22,
recovering..., daemon continued running
May 27 10:28:27.771 2009  jun1.bit-1 /kernel: %KERN-6: pid 12767 (rpd),
uid 0: exited on signal 6 (core dumped)
May 27 10:28:27.838 2009  jun1.bit-1 rpd[1149]: %
DAEMON-3-RPD_TASK_CHILDKILLED: gcore[12767] terminated by SIGABRT with
core

dan...@jun1.bit-1 show system core-dumps 
/var/crash/*core*: No such file or directory
-rw-rw  1 root  wheel  411795456 May 27 10:28 /var/tmp/rpd.core.1

I'm not seeing any weird AS paths on these prefixes. I've just opened a
JTAC case...

--Daniel.

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

Re: [j-nsp] RPD soft assertion failed

[Daniel Verlouw]

Hi Richard,

On May 27, 2009, at 5:16 PM, Richard A Steenbergen wrote:

I had a similar issue (well the exact same message, but I'm assuming
different root causes) back in 8.2R2. It turned out to be PR99220, and
was mostly cosmetic (minus the big scary log message that looked  
like a

rpd core dump to the noclings).


JTAC has decoded the core dumps and on initial analysis it appears to  
match PR 448745 - RPD core at krt_inh_lock_internal. The PR doesn't  
mention 9.3 as affected though. I'll keep the list posted on any  
progress.



A soft assert doesn't break anything and
gives you a nice coredump to work with, open a case and they should be
able to identify the problem easily.


absolutely, luckily there's no operational impact whatsoever.

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

Re: [j-nsp] RE : RPD soft assertion failed

[Daniel Verlouw]

Hi David,

On May 27, 2009, at 9:18 PM, david@orange-ftgroup.com david@orange-ftgroup.com 
 wrote:
Do you have some configuration at this level edit protocols bgp  
path-selection ?


no, it's empty.

Did the RPD restart ? It seems that yes : %KERN-6: pid 12767  
(rpd),uid 0: exited on signal 6 (core dumped)


no, rpd actually does not restart:

dan...@jun1.bit-1 show system processes detail wide | match rpd
 1149 0 1   0   4  0 410136 kqread  3:02AM  ??  S  
97:48.47 /usr/sbin/rpd -N


dan...@jun1.bit-1 show system uptime
Current time: 2009-05-27 21:56:30 CEST
System booted: 2009-05-27 03:01:52 CEST (18:54:38 ago)

in fact, there appears to be no impact at all besides a core dump  
being generated. We don't see any dropped adjacencies etc.


Please, give us feedback regarding to the root cause, when you will  
have more info? We've planned to use 9.3R3.8, too ;-)


I'll definitely follow-up on-list once we have some more news from  
JTAC. Oddly enough, up until now, every prefix being logged along with  
each coredump is originated from Eastern Europe/Russia, AS9198 being  
the top talker.


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

Re: [j-nsp] SNMP traps for exceeding policer configuration

[Daniel Verlouw]

On Feb 25, 2009, at 9:34 PM, Stefan Fouant wrote:

I'd like to tragger some sort of alert when the traffic exceeds my
policer configuration and packets start being discarded.  I looked
through JUNIPER-FIREWALL-MIB and didn't see anything along the lines
of what I'm looking for.

Anyone else implement anything along similar lines?


have a look at  
enterprises 
.juniperMIB 
.jnxMibs.jnxFirewalls.jnxFirewallCounterTable.jnxFirewallCounterEntry  
(1.3.6.1.4.1.2636.3.5.2)


E.g.:

dan...@jun1.lab show configuration interfaces xe-1/0/0.189 family  
inet policer

input po-xe-1/0/0.189;

dan...@jun1.lab show policer | match po-xe-1/0/0.189
po-xe-1/0/0.189-xe-1/0/0.189-log_int-i   170604

using SNMP:

jnxFWCounterDisplayFilterName. 
38.112.111.45.120.101.45.49.47.48.47.48.46.49.56.57.45.120.101.45.49.47.48.47.48.46.49.56.57.45.108.111.103.95.105.110.116.45.105.38.112.111.45.120.101.45.49.47.48.47.48.46.49.56.57.45.120.101.45.49.47.48.47.48.46.49.56.57.45.108.111.103.95.105.110.116.45.105.3 
 = po-xe-1/0/0.189-xe-1/0/0.189-log_int-i


jnxFWCounterDisplayName. 
38.112.111.45.120.101.45.49.47.48.47.48.46.49.56.57.45.120.101.45.49.47.48.47.48.46.49.56.57.45.108.111.103.95.105.110.116.45.105.38.112.111.45.120.101.45.49.47.48.47.48.46.49.56.57.45.120.101.45.49.47.48.47.48.46.49.56.57.45.108.111.103.95.105.110.116.45.105.3 
 = po-xe-1/0/0.189-xe-1/0/0.189-log_int-i


jnxFWCounterPacketCount. 
38.112.111.45.120.101.45.49.47.48.47.48.46.49.56.57.45.120.101.45.49.47.48.47.48.46.49.56.57.45.108.111.103.95.105.110.116.45.105.38.112.111.45.120.101.45.49.47.48.47.48.46.49.56.57.45.120.101.45.49.47.48.47.48.46.49.56.57.45.108.111.103.95.105.110.116.45.105.3 
 = 170604


Works like a charm.

   --Daniel.

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

Re: [j-nsp] bgp maxas-limit - JUNOS equivalent ???

[Daniel Verlouw]

On Fri, 2009-02-20 at 12:00 +, Berislav Todorovic wrote:
 I'm wondering if there is a way to limit the AS path length in JUNOS.
 Yeah, bgp maxas-limit is available in JUNOSe, as well as in Cisco IOS,
 but I can't find any reference to it for JUNOS (M/MX/T Series).
 
 Any info will be greatly appreciated.

define an AS path regex, eg .{75,}, and match on it using a policy.

  --Daniel.

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

Re: [j-nsp] bgp as-path

[Daniel Verlouw]

On Nov 14, 2008, at 8:38 PM, SunnyDay wrote:

but what if  i have  4509:65001:4356:65444
will it  remove both private or only 65001 and when it checks the  
next (4356) stops and does not remove 65444



remove-private will only remove leading (left-hand) private ASNs, so  
in your example,  65001 -and- 65444 will not be removed.


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

Re: [j-nsp] default TTE for entries in the ARP table/cache

[Daniel Verlouw]

On Jun 20, 2008, at 5:55 PM, Judd, Michael (Michael) wrote:

What is Juniper's default TTE for entries in the ARP table/cache ?



RTFM?

http://www.juniper.net/techpubs/software/junos/junos85/swconfig85-system-basics/id-10920970.html 



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

Re: [j-nsp] ICMPv6 6PE network

[Daniel Verlouw]

On Jun 4, 2008, at 3:46 AM, snort bsd wrote:

Any ideas?



[EMAIL PROTECTED] set protocols mpls ?
  [...]
  ipv6-tunneling   Allow MPLS LSPs to be used for tunneling IPv6  
traffic


?

--
Daniel Verlouw, Network Engineer
BIT BV | [EMAIL PROTECTED] | +31 318 648688
DV244-RIPE | GPG: FAAF 6061 50DC 8E82 7343  8273 CC60 3A06 48ED 5D99

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

Re: [j-nsp] Load Balancing IPv6 Traffic Flows

[Daniel Verlouw]

On May 20, 2008, at 9:57 PM, Stefan Fouant wrote:
 I'm wondering if anyone else has seen any similar problems and are
 there any gotchya's when configuring load-balancing for IPv6 traffic.


you cannot match on family inet and inet6 in one term, 8.5 returns the  
following error:

[edit policy-options]
[EMAIL PROTECTED] commit check
[edit]
   'policy-options'
 Policy error: Policy-statement load-balance, term prefixes:  
unable to merge prefix-list v6_routes because of different address  
family
error: configuration check-out failed

You need to split your policy into two separate terms, one matching on  
family inet and the other on family inet6, e.g.:

[edit policy-options policy-statement load-balance]
[EMAIL PROTECTED] show
term v4_prefixes {
 from {
 prefix-list-filter v4_routes orlonger;
 }
 then {
 load-balance per-packet;
 }
}
term v6_prefixes {
 from {
 family inet6;
 prefix-list-filter v6_routes orlonger;
 }
 then {
 load-balance per-packet;
 }
}

Hope this helps.

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

Re: [j-nsp] netscreen Vpn

[Daniel Verlouw]

On Wed, 2008-05-14 at 16:12 +0300, M.Mihailidis wrote:
 Anyone knows why is this??

on the general tab, change the mode-config method to push instead of the
default pull.

-Daniel.

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

Re: [j-nsp] forwarding-options hash-key family inet6

[Daniel Verlouw]

On Tue, 2008-03-25 at 05:11 -0500, Kevin Day wrote:
 It also seems to work okay, and do what was expected. Is anyone else  
 using it without problem?

layer-3 + layer-4 is the default hash setting for inet6.

-- 
Daniel Verlouw, Network Engineer
BIT BV | [EMAIL PROTECTED] | +31 318 648688
DV244-RIPE | GPG: FAAF 6061 50DC 8E82 7343  8273 CC60 3A06 48ED 5D99

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