Re: [j-nsp] srx ipsec tunnel over mpls l3vpn

[Hugo Slabbert]

Is the other end of this also an SRX configured in a similar way, or 
something else?  This seems to contradict basically any Juniper docs on SRX 
around MPLS traffic re: flow/packet mode.  Specifically given that it's 
showing "drop" for MPLS traffic, I would be confused about how it's passing 
MPLS-encap'd traffic.


Can you pass other non-IPSEC IPv4 traffic from the SRX (or behind it) 
across the l3vpn to validate bidirectional traffic passing?


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Thu 2019-Jul-11 15:34:26 -0500, Aaron Gould  wrote:



Thanks Emille, Ummm, I may be misunderstanding you , but I don't think I
have change from SRX flow-mode default.  But I do have ldp neighbor up and
mpls forwarding is occurring via mpls l3vpn vrf .  and I do believe the
ike phase 1 and phase 2 is working over this mpls l3vpn within the srx
but I just don't seem to be able to ping from one side of the st0 tunnel
interface to the other.

See...

root@demo-srx300> show security flow status
 Flow forwarding mode:
   Inet forwarding mode: flow based
   Inet6 forwarding mode: drop
   MPLS forwarding mode: drop
   ISO forwarding mode: drop
   Enhanced route scaling mode: Disabled
 Flow trace status
   Flow tracing status: off
 Flow session distribution
   Distribution mode: RR-based
   GTP-U distribution: Disabled
 Flow ipsec performance acceleration: off
 Flow packet ordering
   Ordering mode: Hardware


root@demo-srx300> show route table mpls.0

mpls.0: 524 destinations, 524 routes (524 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0  *[MPLS/0] 04:51:07, metric 1
 Receive
1  *[MPLS/0] 04:51:07, metric 1
 Receive
2  *[MPLS/0] 04:51:07, metric 1
 Receive
13 *[MPLS/0] 04:51:07, metric 1
 Receive
16 *[VPN/0] 04:51:07
 to table one.inet.0, Pop
345552 *[LDP/9] 04:43:04, metric 3, tag 0
   > to 10.101.14.197 via ge-0/0/0.0, Swap 16507
345568 *[LDP/9] 04:43:04, metric 4, tag 0
   > to 10.101.14.197 via ge-0/0/0.0, Swap 16508
345584 *[LDP/9] 04:43:04, metric 2, tag 0
   > to 10.101.14.197 via ge-0/0/0.0, Swap 16512
345600 *[LDP/9] 04:43:04, metric 3, tag 0
   > to 10.101.14.197 via ge-0/0/0.0, Swap 16513
345616 *[LDP/9] 04:43:04, metric 3, tag 0
   > to 10.101.14.197 via ge-0/0/0.0, Swap 16516
345632 *[LDP/9] 04:43:04, metric 4, tag 0
   > to 10.101.14.197 via ge-0/0/0.0, Swap 16517
345648 *[LDP/9] 04:43:04, metric 3, tag 0
   > to 10.101.14.197 via ge-0/0/0.0, Swap 16518

root@demo-srx300> show route table mpls.0 terse

mpls.0: 524 destinations, 524 routes (524 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A V DestinationP Prf   Metric 1   Metric 2  Next hopAS path
* ? 0  M   0  1 Receive
* ? 1  M   0  1 Receive
* ? 2  M   0  1 Receive
* ? 13 M   0  1 Receive
* ? 16 V   0Table
* ? 345552 L   9  3>10.101.14.197
* ? 345568 L   9  4>10.101.14.197
* ? 345584 L   9  2>10.101.14.197
* ? 345600 L   9  3>10.101.14.197
* ? 345616 L   9  3>10.101.14.197
* ? 345632 L   9  4>10.101.14.197
* ? 345648 L   9  3>10.101.14.197
* ? 345664 L   9  7>10.101.14.197
* ? 345680 L   9  6>10.101.14.197
* ? 345696 L   9  7>10.101.14.197
* ? 345712 L   9  7>10.101.14.197
* ? 345728 L   9  6>10.101.14.197
* ? 345744 L   9  7>10.101.14.197

root@demo-srx300> show route table mpls.0 terse | count
Count: 528 lines

root@demo-srx300> show ldp neighbor
AddressInterface  Label space ID Hold time
10.101.14.197  ge-0/0/0.0 10.101.0.254:0   10

root@demo-srx300>



-Original Message-
From: Emille Blanc [mailto:emi...@abccommunications.com]
Sent: Thursday, July 11, 2019 3:04 PM
To: Aaron Gould; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] srx ipsec tunnel over mpls l3vpn

Based on what you described, it sounds like you already got your MPLS/LDP
running in a packet-mode routing-instance, as otherwise MPLS is dropped on

Re: [j-nsp] SRX300 Issue

[Hugo Slabbert]

Poster noted:


When connecting a laptop I can access the GW as well as the Internet
But the box itself is not even reaching the GW!


Sounds like either host-inbound-traffic or policies for the junos-host zone 
may be in order.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Thu 2019-Jan-17 08:39:20 +, Niall Donaghy  
wrote:


Hi Mohammad,

What Catalin said. Eg:

set security policies from-zone trust to-zone untrust policy permit-all match 
source-address any
set security policies from-zone trust to-zone untrust policy permit-all match 
destination-address any
set security policies from-zone trust to-zone untrust policy permit-all match 
application any
set security policies from-zone trust to-zone untrust policy permit-all then 
permit
set security zones security-zone trust interfaces ge-0/0/7.0

set security policies from-zone untrust to-zone trust policy permit-all match 
source-address any
set security policies from-zone untrust to-zone trust policy permit-all match 
destination-address any
set security policies from-zone untrust to-zone trust policy permit-all match 
application any
set security policies from-zone untrust to-zone trust policy permit-all then 
permit
set security zones security-zone untrust interfaces ge-0/0/0.0

Br,
Niall

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Catalin Dominte
Sent: 17 January 2019 00:07
To: Eldon Koyle ; Mohammad Khalil 

Cc: Juniper List 
Subject: Re: [j-nsp] SRX300 Issue

Check your security policies as nothing is allowed by default with the SRX.

Add permit statements, create security zones and add interfaces to security 
zones. Then it will work.

Catalin Dominte
Senior Network Consultant



Nocsult Ltd  | 2 Cambridge House  | Gogmore Lane | Chertsey | KT16 9AP | Phone: 
+44 (0)1628 302 007
VAT registration number: GB 180957674 |  Company registration number: 08886349
P Please consider the environment - Do you really need to print this email?

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the email and its 
attachments from all computers.

On 16/01/2019, 23:29, "juniper-nsp on behalf of Eldon Koyle" 
 wrote:

   Hello,

   I don't see any attachments.  It is possible that the list is
   configured to remove them.

   --
   Eldon

   On Wed, Jan 16, 2019 at 3:10 AM Mohammad Khalil  wrote:
   >
   > Dears
   > Hope this finds you well
   > I have been struggling with a new Juniper SRX300 since a while with no luck
   > The setup is so easy , static IP address from the WAN
   > When connecting a laptop I can access the GW as well as the Internet
   > But the box itself is not even reaching the GW!
   > I did also an upgrade for the firmware
   > Attached is the current conf file
   >
   > Appreciate ur input
   > ___
   > juniper-nsp mailing list juniper-nsp@puck.nether.net
   > https://puck.nether.net/mailman/listinfo/juniper-nsp
   ___
   juniper-nsp mailing list juniper-nsp@puck.nether.net
   https://puck.nether.net/mailman/listinfo/juniper-nsp

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




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




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

Re: [j-nsp] Interconnecting spines in spine & leaf networks [ was Re: Opinions on fusion provider edge ]

[Hugo Slabbert]

Thanks Hugo, what about leaf to leaf connection?  Is that good?


It Depends(tm).  I would start with asking why you want to interconnect 
your leafs.  Same question again about scaling out >2 as well as just what 
you're trying to accomplish with those links.  A use case could be 
something like MLAG/VPC/whatever to bring L2 redundancy down to the node 
attachment.  Personally I'm trying to kill the need for that (well, more 
just run L3 straight down to the host and be done with all layers of 
protocols and headers just to stretch L2 everywhere), but one battle at a 
time.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Thu 2018-Nov-15 07:31:30 -0600, Aaron1  wrote:


Thanks Hugo, what about leaf to leaf connection?  Is that good?

What about Layer 2 loop prevention?

Aaron


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

[j-nsp] Interconnecting spines in spine & leaf networks [ was Re: Opinions on fusion provider edge ]

[Hugo Slabbert]

This was all while talking about a data center redesign that we are 
working on currently.  Replacing ToR VC EX4550’s connected LAG to ASR9K 
with new dual QFX5120 leaf to single MX960, dual MPC7E-MRATE


I think we will connect each QFX to each mpc7e card.  Is it best practice to 
not interconnect directly between the two QFX’s ? If so why not.


Glib answer: because then it's not spine & leaf anymore ;)

Less glib answer:

1. it's not needed and is suboptimal

Going with a basic 3-stage (2 layer) spine & leaf, each leaf is connected 
to each spine.  Connectivity between any two leafs is via any spine to 
which they are both connected.  Suppose you have 2 spines, spine1 and 
spine2, and, say, 10 leaf switches. If a given leaf loses its connection to 
spine1, it would then just reach all other leafs via spine2.


If you add a connection between two spines, you do create an alternate 
path, but it's also not an equal cost or optimal path.  If we're going 
simple least hops / shortest path, provided leaf1's connection to spine1 is 
lost, in theory leaf2 could reach leaf1 via:


leaf2 -> spine1 -> spine2 -> leaf1

...but that would be a longer path than just going via the remaining:

leaf2 -> spine2 -> leaf2

...path.  You could force it through the longer path, but why?

2. What's your oversub?

The pitch on spine & leaf networks is generally their high bandwith, high 
availability (lots of links), and low oversubscription ratios.  For the 
sake of illustration let's go away from chassis gear for spines to a 
simpler option like, say, 32x100G Tomahawk spines.  The spines there have 
capacity to connect 32x leaf switches at line rate.  Whatever connections 
the leaf switches have to the spines do not have any further oversub 
imposed within the spine layer.


Now you interconnect your spines.  How many of those 32x 100G ports are you 
going to dedicate to spine interconnect?  2 links?  If so, you've now 
dropped the capacity for 2x more leafs in your fabric (and however many 
compute nodes they were going to connect), and you're also only providing 
200G interconnect between spines for 3 Tbps of leaf connection capacity.  
Even if you ignore the less optimal path thing from above and try to 
intentionally force a fallback path on spine:leaf link failure to traverse 
your spine xconnect, you can impose up to 15:1 oversub in that scenario.


Or you could kill the oversub and carve out 16x of your 32x spine ports for 
spine interconnects.  But now you've shrunk your fabric significantly (can 
only support 16 leaf switches)...and you've done so unnecessarily because 
the redundancy model is for leafs to use their uplinks through spines 
directly rather than using inter-spine links.


3. >2 spines

What if we leaf1 loses its connection to spine2 and leafx loses its 
connection to spine1?  Have we not created a reachability problem?


 spine1 spine2
/   \
  /  \
leaf1  leafx

Why, yes we have.  The design solution here is either >1 links between each 
leaf & spine (cheating; blergh) or a greater number of spines.  What's your 
redundancy factor?  Augment the above to 4x spines and you've significantly 
shrunk your risk of creating connectivity islands.


But if you've designed for interconnecting your spines, what do you for 
interconnecting 4x spines?  What about if you reach 6x spines?  Again: the 
model is that resilience is achieved at the leaf:spine interconnectivity 
rather than at the "top of the tree" as you would have in a standard 
hierarchical, 3-tier-type setup.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Tue 2018-Nov-06 12:38:22 -0600, Aaron1  wrote:


This is a timely topic for me as I just got off a con-call yesterday with my 
Juniper SE and an SP specialist...

They also recommended EVPN as the way ahead in place of things like fusion.  
They even somewhat shy away from MC-lag

This was all while talking about a data center redesign that we are working on 
currently.  Replacing ToR VC EX4550’s connected LAG to ASR9K with new dual 
QFX5120 leaf to single MX960, dual MPC7E-MRATE

I think we will connect each QFX to each mpc7e card.  Is it best practice to 
not interconnect directly between the two QFX’s ? If so why not.

(please forgive, don’t mean to hijack thread, just some good topics going on 
here)

Aaron


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

Re: [j-nsp] why is "show log messages | last 10" so slow?

[Hugo Slabbert]

On Mon 2018-Oct-29 16:28:12 +, Anderson, Charles R  wrote:

Why is "show log messages | last 10" so slow with a large log file when I 
can go to the shell and run "tail -10 /var/log/messages" much more 
quickly?


Because it's an action that is done after the pipe rather than being the 
action itself, so it's equivalent to `cat /var/log/messages | tail -n 10` 
not directly to `tail -n 10 /var/log/messages`.  It's a generic pipe action 
that can be applied to any text output, e.g. the output of a regular 
operational "show" command, but it's not a top-level command that does file 
processing itself like `tail` can.


Maybe JUNOS can borrow the implementation of the "tail" command to make it 
quicker.


They'd have to add a new top-level command or perhaps add a parameter to 
the `file show` operation, I'd think.  Probably doable, but not sure how 
much traction the feature request would get.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


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

Re: [j-nsp] Standard practice for customer eBGP peering traffic engineer

[Hugo Slabbert]

On Mon 2017-Nov-13 15:27:36 +, Nick Cutting <ncutt...@edgetg.com> wrote:

What is the benefit for a customer or a provider in doing this v.s just 
the customer prepending their own AS?


Prepending done customer side would be visible to anyone beyond that first 
BGP peering between the customer and provider, including any of the 
provider's other BGP customers.


Generally, these provider prepend communities would be targeted for 
external relationships.  So, example would be that you want to have 
provider X's customers send to you directly via provider X, but provider 
X's peering sucks so you want anyone who is *not* a direct customer of 
provider X to avoid routing through provider X.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


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

Re: [j-nsp] Can I have multiple route-based VPN over multiple st0 interfaces

[Hugo Slabbert]

On Fri 2017-Nov-03 02:37:30 +, M Abdeljawad <eng_mahmoo...@yahoo.com> 
wrote:



Hi
But the tunnels peering with non juniper firewalls, so I didnt assign st0 
interfaces an IP addresses.And since all st0 interfaces are unnumbered 
then I think one out of them will borrow the external interface IP 
address.


Gotcha.  Not a problem:

Just add `family inet` under the st0 units but do not put any addresses on 
them.  They will be exactly that: IP interfaces with no addresses on them.  
They don't pick up any IP address by default.  Now, if you're generating IP 
unreachables back to the other end, _some_ address will get plopped into 
the source IP field, which will follow usual source address selection 
criteria for the platform.


If you leave it unnumbered, just put `next-hop st0.x` in your static routes 
across to tunnels.


You can actually also cheat and stick whatever /31 you want on there (so 
pick something from your internal ranges) and next-hop to an IP in that 
subnet (e.g. 192.0.2.0/31 on your side, set 192.0.2.1 as the next-hop for 
the route).  It's a point-to-point interface, so Junos will just shove the 
packet across the interface since it has a connected route for that 
next-hop address.  The other party doesn't need to have any addresses 
configured on a virtual tunnel interface on their end for this to work.  
They could even have completely mismatched addresses and it should still 
work.


This also means that if you do generate ICMP unreachables back to the other 
party across the tunnel, they will be sourced from the IP you stick on the 
st0.x interface, in case that helps with any troubleshooting/debugging.


Cheers,

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


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

Re: [j-nsp] Can I have multiple route-based VPN over multiple st0 interfaces

[Hugo Slabbert]

On Fri 2017-Nov-03 00:57:47 +, M Abdeljawad via juniper-nsp 
<juniper-nsp@puck.nether.net> wrote:



Hi
I want to create three VPN tunnels with third party peers, I want to use 
route-based VPN with traffic selector as each tunnel has multiple 
destinations.So can I use multiple st0 interfaces "one for each tunnel"?


Yes; the routed IPSEC tunnels are bound to subinterfaces to st0, so e.g.  
st0.1 (unit 1), st0.2, st0.3, and so forth.  Set that interface or the IP 
on the other end as your next-hop for whatever traffic you want to push 
through that particular tunnel (or run a routing protocol across it if 
that's preferred) and go to town.



(As I have only one VPN tunnel up out of the three tunnels).


I don't understand this part.  I don't see anything that would prevent you 
from having all of the tunnels up simultaneously unless you want to 
intentionally shut them for some reason.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


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

Re: [j-nsp] STP in spine leaf architecture

[Hugo Slabbert]

On Fri 2017-Oct-27 18:04:36 +0200, Thomas Bellman <bell...@nsc.liu.se> wrote:


On 2017-10-26 18:11 (CEST), Hugo Slabbert wrote:


[...] in a general a spine & leaf setup should be L3 for interswitch
links, so any STP should be local to a given switch.  [...]
Here I'm just talking about a vanilla spine & leaf setup, not anything
Juniper-specific e.g. QFabric or VCF or whatnot.


You can also build a spine & leaf setup using TRILL och Shortest Path
Bridging (SPB), in which case you have a single large layer 2-domain.
Not using Juniper equipment, though, since Juniper supports neither
TRILL nor SPB...


A fair point; TRILL was only somewhat in the mix when we were evaluating 
options, but vendor support was hit and miss.  VXLAN ended up being a more 
common and "vetted" solution for L2 across a spine & leaf setup.



I'd be curious about more specific details from folks running QFX in
prod in this type of setup.


You are generally correct though.  Configure your swithc-to-switch
links as L3 ports (i.e. 'interface ... unit ... family inet/inet6',
not 'family ethernet-switching'), and some routing protocol like
OSPF, IS-IS or BGP.  BGP is fairly popular in datacenter settings,
but OSPF works fine as well, as should IS-IS.

Layer 2 domains should be kept to a single leaf switch, and thus you
don't need to run Spanning Tree at all.  And definitely not on your
links between spines and leafs, since that would block all but one of
the uplinks, and give you all the pains of Spanning Tree without any
of the benefits.  (You *might* want to run STP on your client ports and
configure them as edge ports with bpdu-block-on-edge, to protect against
someone misadvertently connecting two L2 client ports togethere.)


Yep; that's our CYA config.


(I don't run a pure spine-and-leaf network myself.  I am trying to
migrate towards one, but we still have several "impurities", and
have STP running in several places.)


We all still have lots of "dirty corners" in our networks ;)

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


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

Re: [j-nsp] Standard practice for customer eBGP peering traffic engineer

[Hugo Slabbert]

Could be they got the idea from a recent NANOG thread on this very topic:

https://mailman.nanog.org/pipermail/nanog/2017-October/092887.html

Won't that cause a loop inside of the provider once the other IBGP 
routers see their own AS number?


The actual prepend would be applied on export, so on the provider's edge 
facing peers, rather than having the prepend applied on initial import and 
floating around the provider's internal routing.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Thu 2017-Oct-26 10:16:42 +0700, Mark Tees <markt...@gmail.com> wrote:


Hi Craig,

They are probably referring to prepending the provider AS to certain
other eBGP neighbours not within the AS.

EG: Customer sends prefix X with community Y. Where provider chooses
to advertise prefix X to other eBGP neighbours if they match community
Y then prepend own AS.

https://us.ntt.net/support/policy/routing.cfm
http://tools.vocus.com.au/additionals/communities.htm
https://onestep.net/communities/as3356/

These are convenience methods to assist IP transit customers on
guiding traffic towards their prefixes.

--Mark


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

Re: [j-nsp] STP in spine leaf architecture

[Hugo Slabbert]

On Thu 2017-Oct-26 18:35:35 +0530, Mehul gajjar <mdgaj...@gmail.com> wrote:


Dear all,

Can anybody give me knowledge how Spanning tree behaviour in spine/leaf 
data center architecture where qfx as a spine and leaf too.


I haven't done spine/leaf networks with QFX, but in a general a spine & 
leaf setup should be L3 for interswitch links, so any STP should be local 
to a given switch.  i.e. you may have STP domains on a leaf's local L2 
domain, so on its edge ports / server-facing links, but that should not 
extend upwards in the topology unless I'm missing something.


Here I'm just talking about a vanilla spine & leaf setup, not anything 
Juniper-specific e.g. QFabric or VCF or whatnot.


If you're doing an overlay like VXLAN over top of the L3 underlay, then how 
loops are managed would be specific to the overlay, with the addendum that 
even if you manage to form a loop in the overlay somewhere/somehow, the 
TTLs in the L3 underlay should still have looped frames in the overlay TTL 
out.


I'd be curious about more specific details from folks running QFX in prod 
in this type of setup.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


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

Re: [j-nsp] Same configuration

[Hugo Slabbert]

On Thu 2017-Oct-19 17:38:43 +0500, sameer mughal <pcs.same...@gmail.com> 
wrote:



Hi All,

Can anyone update me that Is the same configuration on srx240h2 will work
on srx550 or need some modification?


Try it and see?

Depends on the extent of the config.  There are some things that are 
model-specific, such as which ports are used/hardcoded/available for 
chassis cluster links.  But, the 240 and 550 are both branch series, so I 
would not expect too much difference there, especially if you're just using 
a single unit rather than chassis cluster.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal



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

Re: [j-nsp] SRX - CPU utilization exceeds

[Hugo Slabbert]

On Mon 2017-Sep-18 10:07:36 +0200, Benoit Plessis <b.ples...@doyousoft.com> 
wrote:



Le 16/09/2017 à 07:48, sameer mughal a écrit :

Hi,

Can anyone please review the mentioned below logs and advice me Is this
issue critical and how can I fix this ?


Well your firewall is alerting that it is regurlarly out of ressources.

I would check if it's due to something you do (modifying configuration
at this time),
or if it's due to external conditions ("attacks" / scan / ..)

Depend on that and on the service impact i would try to simplify
configuration, update the software
or more probably start to look at upgrading the device since it kindof
look inadequat to your need.

Do you have some external monitoring in place with a graphing system to
look after you firewall ?


This can even just be throughput based, especially for flow services as 
opposed to just packet-mode forwarding.  I've had instances of this from 
e.g. pushing >50-60 Mbps of IPSEC on SRX100 boxes.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


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

Re: [j-nsp] /31 support on SRX tunnel interfaces

[Hugo Slabbert]

Is there any reason a /31 address would not work on a SRX tunnel interface 
(i.e. st0.1)


Shouldn't be; I've done /31s and /127s on GRE and st interfaces without 
issues on various SRXs.


The VPN is up, ping is allowed and both sides show outbound traffic but 
neither sides shows any inbound traffic.


Are the st interfaces in a security zone?  Are you pinging _to_ the remote 
SRX or _through_ it?  If the former, do you have host-inbound-traffic 
configured to permit it?  If the latter, do you have security policies 
configured to permit the traffic?


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


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

Re: [j-nsp] QFX 5100 uRPF

[Hugo Slabbert]

On Wed 2017-Mar-08 12:38:52 -0500, Brian Rak <b...@gameservers.com> wrote:


Is anyone successfully using rpf-check on QFX5100's?

I'm getting some really weird behavior.. If I enable uRPF, then 
disable it again, the device still appears to continue to enforce it. 
(Spoofed packets continue to be blocked).  I have to restart the 
device in order to fully remove RPF.


Also, whenever I enable rpf-check, a whole bunch of legitimate 
traffic starts getting dropped.  My guess is that this is related to 
the device having redundant uplinks, and an ECMP default route.  I 
can't really confirm this though, since RPF troubleshooting seems 
non-existent.


Mixing redundant / asymmetric paths and uRPF needs to be done carefully.  
Are you doing strict or loose RPF?  What legitimate traffic is being 
dropped (e.g. specific types/classes of traffic or seemingly random)?  Do 
you have an exception filter defined to log/catch/exclude certain traffic?  
E.g. on SRX used as CPE we needed to define an exception filter so that 
DHCP discover packets don't get dropped.


Is attempting to use RPF here a mistake?  I'd really prefer not to 
have to implement per-port ACLs.  We're on 16.1 currently, I'll 
probably try upgrading once JTAC fixes my account.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


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

Re: [j-nsp] how to disconnect/kill tcp session from juniper router

[Hugo Slabbert]

Always a good reference:

http://www.team-cymru.org/templates.html
http://www.cymru.com/gillsr/documents/junos-template.pdf

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Thu 2016-Nov-24 11:07:45 +, Alexander Arseniev <arsen...@btinternet.com> 
wrote:


Hello,

Someone is brute-forcing Your router password, and that is very 
common nowadays. Good loopback filter would prevent this.


In addition:

1/ You can only do "request system logout" for sessions that passed 
authentication+login+got TTY assigned. If You see "unsuccessful 
login" it means this session did not get past authentication. 
Unautheticated sessions got disconnected after 3 wrong password 
attempts, or 120 secs if there is no data flowing (from memory)


2/ Best practice is not to allow telnet at all. Use SSH instead. To 
disable telnet, make sure You do NOT have the "telnet" line under 
"[system services]" stanza.


3/ Also, You should be using:

3a/ loopback filter allowing SSH from trusted source IPs only. If You 
manage router via internet, and must keep remote access to it open to 
ANYONE that's not a good practice at all.


3b/ SSH public key authentication instead of password

3c/ backoff timer to fire after 3-5 unsuccessful login tries

3d/ inactivity timer to close hanging SSH sessions - to make sure You 
are not locked out of the router access because all TTYs are taken.


Thanks

Alex


On 21/11/2016 21:29, Aaron wrote:

I have an unauthorized telnet session attached to my router but it does not
show up under "show system users" and they have not successfully logged so
it doesn't seem that I can do the "request system logout.." thing


I do however so unsuccessful login attempts in syslog


How do I kill/disconnect this tcp session ?


me@j1> show system connections | grep ".23 "

tcp4   0  0  109.109.109.109.23
181.181.181.181.55436  ESTABLISHED

tcp4   0  0  *.23  *.*
LISTEN

tcp4   0  0  *.6023*.*
LISTEN

tcp4   0  0  *.6023*.*
LISTEN

udp4   0  0  128.0.0.1.123 *.*

udp4   0  0  *.123 *.*

udp4   0  0  *.6123*.*

udp4   0  0  *.6123*.*



{master:0}

me@j1> show system processes | grep "PID|telnet"

  PID  TT  STAT  TIME COMMAND

70193  ??  Is 0:00.00 telnetd



{master:0}

me@j1> start shell

% ps -awwux | grep telnet

root   70193  0.0  0.1  2128  1396  ??  Is1:34PM   0:00.00 telnetd

remote 70971  0.0  0.0   480   296  p5  R+3:19PM   0:00.00 grep telnet

%


- Aaron

___
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


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

Re: [j-nsp] ISG-2000 to ASA converstion

[Hugo Slabbert]

On Wed 2016-Oct-12 12:24:10 -0700, Payam Chychi <pchy...@gmail.com> wrote:


crazy questions... why?

normally its Cisco to Juniper specially when it comes to the 
vpn/firewall/security devices


ISGs are old.  If I were a betting man, I'd say it's hardware refresh time 
and the ASAs won the day in the comparison shopping or a POC face-off.  
Bonus points if the differentiator was UTM-type stuff or anything with 
"Source" or "Fire" in the name...


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal



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

Re: [j-nsp] Leaking OSPF routes into ISIS

[Hugo Slabbert]

On Thu 2016-Oct-06 14:10:17 +, Matthew Crocker <matt...@corp.crocker.com> 
wrote:

I found the issue,   export-customer-bgp had a reject clause to the route 
wasn’t getting to the export-ospf policy at all.


I generally create an explicit 'reject-all' policy and stick that at the 
end of policy lists, rather than nesting the reject within an existing 
policy.  It's a bit clearer.




Thanks Peter



--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal



On 10/6/16, 9:49 AM, "juniper-nsp on behalf of Matthew Crocker" 
<juniper-nsp-boun...@puck.nether.net on behalf of matt...@corp.crocker.com> wrote:


   Hello,

   I in the process of migrating from OSPF to ISIS for my interior routing.
I have one MX240 that needs to run OSPF to some legacy network gear.  I want 
that router to export the OSPF learned routes to its new ISIS neighbors.

   I have a policy-statement to export-ospf

   show policy-options policy-statement export-ospf
   term 1 {
   from {
   protocol ospf;
   }
   then accept;
   }


   I have added that to my isis protocol config

   show isis
   export [ export-direct export-statics export-customer-bgp export-ospf ];
   reference-bandwidth 10g;
   traffic-engineering {
   family inet {
   shortcuts;
   }
   family inet6 {
   shortcuts;
   }
   }
   interface xe-1/1/0.1151;
   interface xe-1/3/0.0;
   interface lo0.0;

   The routes are in OSPF but I don’t see them in the ISIS routes on the other 
routers.

   What am I missing?

   --
   Matthew Crocker
   President – Crocker Communications
   matt...@corp.crocker.com<mailto:matt...@corp.crocker.com>

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

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


signature.asc
Description: Digital signature
___
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

[Hugo Slabbert]

On Thu 2016-Aug-18 17:13:09 +0200, raf <r...@futomaki.net> wrote:


Hello list,

I know this topic has already discussed here but I got some trouble 
in getting these working properly.


I got a simple topology consisting of 4 PE routers, and 2 P routers 
acting as in-path RRs.


Picking the Ps are RRs seems weird.  Generally your Ps would just be in the 
IGP but be BGP free.  There's nothing "wrong" with it per se, it's just an 
odd choice as generally you want your Ps to be lightweight and just 
label-switch without carrying heavy tables, whereas making them RRs means a 
bunch of RE utilization, which is the opposite of that objective.


The NHS choice on the RRs is also an odd one.  Again, it's not necessarily 
"wrong" but it's not a standard choice and could lead to interesting 
behaviours.  That your saying you couldn't easily take off NHS from the RRs 
makes me wonder what the constraints are there.


If this were my environment, I'd want to take a step back and consider why 
I'm doing in-path RRs on P routers when I also appear to have constraints 
on that choice (not being able to toggle NHS easily) that could make my 
life more difficult.



For whatever reason I want to use RSVP as LSP signaling protocol.
I configured a full mesh of LSPs between PE only.

So there is a problem in resolving route of my L3vpn as there is no 
route in inet.3 for my RRs.


I've changed resolution of bgp.inet.0 to inet.0 on RRs and PEs.
(I ve read this is not the only method, but I don't to deploy LDP or 
to make LSPs between P and PEs).


It help and I can see all routing tables populated.

However I ve got strange issues resulting in data path being broken, 
but not on all VRFs ?! and lot of logs like this "Couldn't find MPLS 
tunnel for NH id"


What I've missed ?

--
Raphael Mazelier


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal



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

Re: [j-nsp] mixed interface, switching + routed

[Hugo Slabbert]

On Tue 2016-Jul-05 13:51:26 -0500, Josh Reynolds <j...@kyneticwifi.com> wrote:


Thanks Hugo, I'll try and give that a shot.

So basically setup an ethernet-switching interface on unit 0, port
mode trunk, native vlan as the current access vlan, member list
includes the new vlan? 


Exactly.  One thing to watch: If you include the native vlan as a member as 
well, it will show up as both tagged and untagged on the port.  IOW, 
untagged frames as well as frames tagged with your native vlan ID will be 
accepted and plopped in the right VLAN, but frames from the VLAN egressing 
the port will be tagged, iirc.  Yea...


I think I'm confused about how I would assign an RVI to this in that 
state.


Do you have a quick example config I might be able to work off of?


In a non-ELS setup, it would be something like:

interfaces {
ge-x/y/z {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members VLAN600;
}
native-vlan-id $your-native-vlan;
}
}
}
vlan {
unit 600 {
description "RVI for L3 in VLAN600"
family inet {
address a.b.c.d/mask;
}
}
}
}
vlans {
VLAN600 {
vlan-id 600;
l3-interface vlan.600;
}
}

Check after committing that VLAN membership is as you expect it:

`show ethernet-switching interfaces ge-x/y/z`


Thank you!


np

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


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

Re: [j-nsp] mixed interface, switching + routed

[Hugo Slabbert]

On Tue 2016-Jul-05 13:23:38 -0500, Josh Reynolds <j...@kyneticwifi.com> wrote:


EX4500


This would be done with flexible-ethernet-services on MX, but I don't 
believe it's supported to mix L2 and L3 on the same port on the EX4500.  
We've tried that on 4550, and you can't mix family ethernet-switching with 
e.g. vlan-tagging, which is what you would use for your L3 unit.


You could change the interface into a trunk, run your existing access vlan 
as native, and create an RVI for your L3 interface, but that may or may not 
cut it depending on what you need that L3 interface for.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal



On Tue, Jul 5, 2016 at 1:20 PM, Hugo Slabbert <h...@slabnet.com> wrote:


On Tue 2016-Jul-05 13:17:52 -0500, Josh Reynolds <j...@kyneticwifi.com>
wrote:


Hello,

I'm sure this is a fairly basic question, but I'm having trouble
finding a solution.

I have a port that is currently an ethernet switching port, set in
access mode that is tagging a vlan for upstream. This works fine. What
I'd like to do, is add a sub interface on the master port (say, unit
600 / vlan 600) that is a tagged/routed interface.

I've tried to do this a couple of ways now, and every time I seem to
get thrown a different error.

Anybody have any tips?



Support for this varies depending on what platform you are using.  You
haven't told us what equipment you're talking about.


Thanks :)


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

Re: [j-nsp] mixed interface, switching + routed

[Hugo Slabbert]

On Tue 2016-Jul-05 13:17:52 -0500, Josh Reynolds <j...@kyneticwifi.com> wrote:


Hello,

I'm sure this is a fairly basic question, but I'm having trouble
finding a solution.

I have a port that is currently an ethernet switching port, set in
access mode that is tagging a vlan for upstream. This works fine. What
I'd like to do, is add a sub interface on the master port (say, unit
600 / vlan 600) that is a tagged/routed interface.

I've tried to do this a couple of ways now, and every time I seem to
get thrown a different error.

Anybody have any tips?


Support for this varies depending on what platform you are using.  You 
haven't told us what equipment you're talking about.



Thanks :)


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


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

Re: [j-nsp] SRX Active/Active

[Hugo Slabbert]

On Sun 2016-Jun-26 20:51:41 -0700, Brian Spade <bitkr...@gmail.com> wrote:


Hi Alexandre,

Thanks for all the details.  I will check with our Juniper team and see
what's the latest on A/A vs A/P.  For most of our sites, we plan to just
use A/P.  But for the largest sites with multi-10Gbps egress, we want to
try A/A.


Aside from the other option listed of splitting the cluster into separate 
nodes, if your goal is multi-10G egress, you could also LAG 10G interfaces 
on the SRX northbound.  The config isn't super intuitive, but you can LAG 
reth child members in an A/P setup.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal



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

Re: [j-nsp] 6VPE routes learned and hidden - ACX5048

[Hugo Slabbert]

So, you're trying to leak between local VRFs on the same ACX?  With prefix 
1234:5678:0:7::/64 originating in "three" and you want to leak locally into 
"one"?


I know local leaking isn't possible on e.g. EX4550, but I don't know if 
that same limitation applies to the ACX.  If you *are* able to leak locally 
between VRFs, you'll need auto-export in the VRF to make it work:


https://www.juniper.net/documentation/en_US/junos15.1/topics/reference/configuration-statement/auto-export-edit-routing-options.html
https://www.juniper.net/documentation/en_US/junos12.3/topics/example/auto-export-configuring-verifying.html

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Tue 2016-Jun-07 15:34:50 -0500, Aaron <aar...@gvtc.com> wrote:


Next subtopic related to 6VPE in my ACX5048 please...

this is done on one ACX5048... so both vrf "three" and "one" are on same
ACX5048 PE

i advertise a ipv6 prefix into a vrf named "three" with RT 1:1 and 3:3

i try to receive that same ipv6 prefix into a vrf named "one" with RT 1:1...
it isn't showing up.  any idea why?

agould@eng-lab-5048-2# run show route advertising-protocol bgp 10.101.0.1
table three.inet6.0

three.inet6.0: 7 destinations, 15 routes (7 active, 0 holddown, 0 hidden)
 Prefix  Nexthop  MED LclprefAS path
* 1234:5678:0:7::/64  Self 100I

{master:0}[edit]
agould@eng-lab-5048-2# run show route receive-protocol bgp 10.101.0.1 table
one.inet6.0

one.inet6.0: 4 destinations, 12 routes (4 active, 0 holddown, 0 hidden)
 Prefix  Nexthop  MED LclprefAS path
 ::/0:::10.101.0.21001234 I
 :::10.101.0.532  10056789 I
 :::10.101.0.10   100139 I
* 1234:5678::/32  :::10.101.0.10   0   100I
* 1234:5678:0:5::/64  :::10.101.0.254  0   100?
* 1234:5678:0:6::/64  :::10.101.12.100 0   100?

{master:0}[edit]
agould@eng-lab-5048-2# run show route advertising-protocol bgp 10.101.0.1
table three.inet6.0 detail | grep arg
Communities: target:1:1 target:3:3

{master:0}[edit]
agould@eng-lab-5048-2#

{master:0}[edit]
agould@eng-lab-5048-2# run show route receive-protocol bgp 10.101.0.1 table
one.inet6.0 detail | grep arg
Communities: target:1:1
Communities: target:1:1
Communities: target:1:1
Communities: target:1:1
Communities: target:1:1
Communities: target:1:1


- Aaron



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

Re: [j-nsp] 6VPE routes learned and hidden - ACX5048

[Hugo Slabbert]

On Mon 2016-Jun-06 16:29:09 -0500, Aaron <aar...@gvtc.com> wrote:


Anyone know why these routes are hidden ?



I'm coming from an MX rather than ACX here, but do you have:

protocols {
mpls {
ipv6-tunneling;
}
}

?

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal




- Aaron



agould@eng-lab-5048-2# run show bgp summary

Groups: 1 Peers: 1 Down peers: 0

Table  Tot Paths  Act Paths SuppressedHistory Damp State
Pending

bgp.l3vpn.0

961961  0  0  0
0

bgp.l3vpn-inet6.0

  6  0  0  0  0
0

bgp.l2vpn.0

  0  0  0  0  0
0

Peer AS  InPkt OutPktOutQ   Flaps Last
Up/Dwn State|#Active/Received/Accepted/Damped...

10.101.0.164512372 24   0   0
8:36 Establ

 bgp.l3vpn.0: 961/961/961/0

 bgp.l3vpn-inet6.0: 0/6/6/0

 bgp.l2vpn.0: 0/0/0/0

 three.inet.0: 6/9/9/0

 three.inet6.0: 0/6/6/0



{master:0}[edit]

agould@eng-lab-5048-2# exit

Exiting configuration mode



{master:0}

agould@eng-lab-5048-2> show route table three.inet6.0



three.inet6.0: 7 destinations, 9 routes (3 active, 0 holddown, 6 hidden)

+ = Active Route, - = Last Active, * = Both



1234:5678:0:7::/64 *[Direct/0] 00:09:28

   > via irb.25

1234:5678:0:7::1/128

  *[Local/0] 00:10:45

 Local via irb.25

fe80::224e:7100:1945:d3a0/128

  *[Local/0] 00:10:45

 Local via irb.25



{master:0}

agould@eng-lab-5048-2> show route table three.inet6.0 hidden



three.inet6.0: 7 destinations, 9 routes (3 active, 0 holddown, 6 hidden)

+ = Active Route, - = Last Active, * = Both



::/0[BGP/170] 00:08:38, localpref 100, from 10.101.0.1

 AS path: 123 I, validation-state: unverified

 Unusable

   [BGP/170] 00:08:38, MED 32, localpref 100, from
10.101.0.1

 AS path: 12345 I, validation-state: unverified

 Unusable

   [BGP/170] 00:08:38, localpref 100, from 10.101.0.1

 AS path: 2468 I, validation-state: unverified

 Unusable

1234:5678::/32  [BGP/170] 00:08:38, MED 0, localpref 100, from
10.101.0.1

 AS path: I, validation-state: unverified

 Unusable

1234:5678:0:5::/64  [BGP/170] 00:08:38, MED 0, localpref 100, from
10.101.0.1

 AS path: ?, validation-state: unverified

 Unusable

1234:5678:0:6::/64  [BGP/170] 00:08:38, MED 0, localpref 100, from
10.101.0.1

 AS path: ?, validation-state: unverified

 Unusable



{master:0}

agould@eng-lab-5048-2> show route table three.inet6.0 hidden detail



three.inet6.0: 7 destinations, 9 routes (3 active, 0 holddown, 6 hidden)

::/0 (3 entries, 0 announced)

BGPPreference: 170/-101

   Route Distinguisher: 10.101.0.10:1

   Next hop type: Unusable, Next hop index: 0

   Address: 0x95365c4

   Next-hop reference count: 12

   State: 

   Local AS: 64512 Peer AS: 64512

   Age: 8:46

   Validation State: unverified

   Task: BGP_64512.10.101.0.1

   AS path: 123 I (Originator)

   Cluster list:  0.0.0.1

   Originator ID: 10.101.0.10

   Communities: target:1:1

   Import Accepted

   VPN Label: 16048

   Localpref: 100

   Router ID: 10.101.0.1

   Primary Routing Table bgp.l3vpn-inet6.0

BGPPreference: 170/-101

   Route Distinguisher: 10.101.0.5:1

   Next hop type: Unusable, Next hop index: 0

   Address: 0x95365c4

   Next-hop reference count: 12

   State: 

   Local AS: 64512 Peer AS: 64512

   Age: 8:46   Metric: 32

   Validation State: unverified

   Task: BGP_64512.10.101.0.1

   AS path: 12345 I (Originator)

   Cluster list:  0.0.0.1

   Originator ID: 10.101.0.5

   Communities: target:1:1

   Import Accepted

   VPN Label: 16019

   Localpref: 100

   Router ID: 10.101.0.1

   Primary Routing Table bgp.l3vpn-inet6.0

BGPPreference: 170/-101

   Route Distinguisher: 10.101.0.2:1

   Next hop type: Unusable, Next hop index: 0

   Address: 0x95365c4

   Next-hop reference count: 12

   State: 

   Local AS: 64512 Peer AS: 64512

   Age: 8:46

   Validation

Re: [j-nsp] SRX 1500

[Hugo Slabbert]

Fair enough; probably better stated as "*even* more fixed form factor" 
given room for one single-width card in the SRX1400 vs. 2x PIM slots on the 
1500.



1500 seems like a fair compromise


Agreed ;)

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Thu 2016-May-19 14:10:59 -0700, Brent Jones <br...@brentrjones.com> wrote:


The 1400's are basically a fixed form factor too - never saw much in the
way of an upgrade path (unless you just jump to 3400's).
1500 seems like a fair compromise

On Thu, May 19, 2016 at 2:06 PM, Hugo Slabbert <h...@slabnet.com> wrote:



On Thu 2016-May-19 14:03:31 -0700, Brent Jones <br...@brentrjones.com>
wrote:

I use SRX1400's, so if the 1500 is just a "newer, better. faster", I'm

interested.



More juice; more of a fixed form factor.  Also running 1400s and have not
yet toyed with the 1500s.
--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal




On Thu, May 19, 2016 at 12:57 PM, Maxwell Cole <
mcole.mailingli...@gmail.com


wrote:



Heya.


Has anyone used box yet?


http://www.juniper.net/us/en/products-services/security/srx-series/srx1500/
<

http://www.juniper.net/us/en/products-services/security/srx-series/srx1500/
>

It looks like a nice box 12 Copper 1G 4x 1G sfp and 4x 10g sfp+ 2mill fib
and 86x running Junos 15 at 11k msrp. Looks like it might be pretty
interesting for a small deploy depending on the speeds it can get in
packet
mode. Pick up a table or two on the sfp+ and an IX on the 1g sip.
Anyone comment on convergence time, feature set, commit time etc? I see
16G of ram which should be nice for its RIB but no info on the CPU
itself.
Is it a xeon?

Looks like a very interesting box but I have yet to hear anything about
it.

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





--
Brent Jones
br...@brentrjones.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp






--
Brent Jones
br...@brentrjones.com


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

Re: [j-nsp] SRX 1500

[Hugo Slabbert]

On Thu 2016-May-19 14:03:31 -0700, Brent Jones <br...@brentrjones.com> wrote:


I use SRX1400's, so if the 1500 is just a "newer, better. faster", I'm
interested.


More juice; more of a fixed form factor.  Also running 1400s and have not 
yet toyed with the 1500s. 


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal



On Thu, May 19, 2016 at 12:57 PM, Maxwell Cole <mcole.mailingli...@gmail.com

wrote:



Heya.

Has anyone used box yet?

http://www.juniper.net/us/en/products-services/security/srx-series/srx1500/
<
http://www.juniper.net/us/en/products-services/security/srx-series/srx1500/
>

It looks like a nice box 12 Copper 1G 4x 1G sfp and 4x 10g sfp+ 2mill fib
and 86x running Junos 15 at 11k msrp. Looks like it might be pretty
interesting for a small deploy depending on the speeds it can get in packet
mode. Pick up a table or two on the sfp+ and an IX on the 1g sip.
Anyone comment on convergence time, feature set, commit time etc? I see
16G of ram which should be nice for its RIB but no info on the CPU itself.
Is it a xeon?

Looks like a very interesting box but I have yet to hear anything about it.

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





--
Brent Jones
br...@brentrjones.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] vSRX Cluster ip-monitoring secondary address

[Hugo Slabbert]

In that case, you build a LAG on node0 that goes to a LAG on the switch, 
and a LAG on node1 that goes to a separate LAG on the switch.


Is that the setup you're having issues with?  e.g. (assuming a 2-member EX 
switch on the other end for simplicity's sake):


 |= - ge-0/0/0 <---> ge-0/0/0 -
srx1 | /   \
 |=   /-- ge-0/0/1 <---> ge-1/0/0 --- ae0 on some switch
 /
reth0 (w/ lacp)
 \
 |=   \-- ge-1/0/0 <---> ge-0/0/1 --- ae1 on some switch
srx2 | \   /
 |= - ge-1/0/1 <---> ge-1/0/1 -


We have that running in production without issue, though we are not using 
IP monitoring.


The key part is in that diagram is that the 2 LACP interfaces on the 
switch(es) are discrete; you don't have 1 LACP bundle for all 4x SRX 
interfaces together.  There is no actual aeX interface on the SRX chassis 
cluster; you just add LACP config to the reth, and the links are brought up 
sensibly given the LACP config on the other (switch) end with two discrete 
bundles:



show configuration interfaces reth0

description "Outside Shared Interface to EX Stack (ge-0/0/16 and ge-1/0/16)";
redundant-ether-options {
redundancy-group 1;
lacp {
active;
periodic fast;
}
}

Again, we're not running ip-monitoring, so I'm not sure if that is 
also/still problematic even with the LAGs sorted out.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Thu 2016-May-19 20:22:45 +0100, sukhjit.ha...@googlemail.com 
<sukhjit.ha...@googlemail.com> wrote:




Hi Hugo

No you have it wrong, say you wanted to double the links from node0 to switch 1 
or node1 to switch 2 because it was close to being utilised.

That's the design where static routing/ip-monitoring is not supported per the 
initial email I sent and due to issue that I described.

--
BR

Sukhjit Hayre
2xCCIE #40428 (SP, R/S)

Sent from iPhone


On 19 May 2016, at 19:51, Hugo Slabbert <h...@slabnet.com> wrote:

This is very delayed, but are you connecting up the reth members to a LAG?  e.g.

reth0 members are:
- srx1: ge-0/0/0
- srx2: ge-1/0/0

srx1  ge-0/0/0 <---> ge-a/b/c
/   \
   reth0 aeX some switch (or MC-LAG setup)
\   /
srx2  ge-1/0/0 <---> ge-x/y/z

That's not how reth's work.  The reth is not a LAG; ge-a/b/c and ge-x/y/z on 
the switch should be discrete interfaces, just running the same config (e.g. 
same access VLAN or trunks with same member VLANs).

Does that make sense?

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


On Mon 2015-Mar-16 20:47:33 +, Sukhjit Hayre <sukhjit.ha...@googlemail.com> 
wrote:

hi all,

I managed to resolve this issue as being down to the arp replies not being
deterministic from the switch port-channel facing the secondary SRX cluster
node1.

i.e they would use the incorrect physical interface from the port-channel
list, where the arp's are sourced from the lowest physical interface number
it seems from node1.

so to me it seems unless junos supports a valid way of not using the
physical interface mac-address i.e moving this mac-address to a second
rethX.X sub-interface then a dual legged design from each SRX to the
switches which could be running MC-LAG or vPC (or simple LACP to the same
switch) then ip-monitoring for this purpose would not be supported.

I would be surprised if this has not been considered, I am new to junos so
go easy on me ;)

br

On Mon, Mar 16, 2015 at 12:22 PM, Sukhjit Hayre <
sukhjit.ha...@googlemail.com> wrote:



I'm confused on where to physically or logically assign this address.

I have declared my secondary address in the ip-monitoring stanza but the
connected Router is receiving quite a few ARPs from this address because
it's trying to ICMP for IP-monitoring purposes

Issue is where do I expect the ARP to be received back on by Node1 as I
can see the reth1 child physical mac is being used to source the ARP and I
can the Router reply back to this MAC address

The source address from the primary reth1 (node0) is ICMP'd fine but not
the secondary this causes issues down the line as the ip-monitoring
pre-check fails hence the node1 chassis is not ready to take the data-plane
for one of my redundancy-groups in this case RG1

Any pointers on this would be appreciated

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


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

Re: [j-nsp] vSRX Cluster ip-monitoring secondary address

[Hugo Slabbert]

This is very delayed, but are you connecting up the reth members to a LAG?  
e.g.


reth0 members are:
- srx1: ge-0/0/0
- srx2: ge-1/0/0

srx1  ge-0/0/0 <---> ge-a/b/c
 /   \
reth0 aeX some switch (or MC-LAG setup)
 \   /
srx2  ge-1/0/0 <---> ge-x/y/z

That's not how reth's work.  The reth is not a LAG; ge-a/b/c and ge-x/y/z 
on the switch should be discrete interfaces, just running the same config 
(e.g. same access VLAN or trunks with same member VLANs).


Does that make sense?

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Mon 2015-Mar-16 20:47:33 +, Sukhjit Hayre <sukhjit.ha...@googlemail.com> 
wrote:


hi all,

I managed to resolve this issue as being down to the arp replies not being
deterministic from the switch port-channel facing the secondary SRX cluster
node1.

i.e they would use the incorrect physical interface from the port-channel
list, where the arp's are sourced from the lowest physical interface number
it seems from node1.

so to me it seems unless junos supports a valid way of not using the
physical interface mac-address i.e moving this mac-address to a second
rethX.X sub-interface then a dual legged design from each SRX to the
switches which could be running MC-LAG or vPC (or simple LACP to the same
switch) then ip-monitoring for this purpose would not be supported.

I would be surprised if this has not been considered, I am new to junos so
go easy on me ;)

br

On Mon, Mar 16, 2015 at 12:22 PM, Sukhjit Hayre <
sukhjit.ha...@googlemail.com> wrote:



I'm confused on where to physically or logically assign this address.

I have declared my secondary address in the ip-monitoring stanza but the
connected Router is receiving quite a few ARPs from this address because
it's trying to ICMP for IP-monitoring purposes

Issue is where do I expect the ARP to be received back on by Node1 as I
can see the reth1 child physical mac is being used to source the ARP and I
can the Router reply back to this MAC address

The source address from the primary reth1 (node0) is ICMP'd fine but not
the secondary this causes issues down the line as the ip-monitoring
pre-check fails hence the node1 chassis is not ready to take the data-plane
for one of my redundancy-groups in this case RG1

Any pointers on this would be appreciated




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


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

Re: [j-nsp] SNMP walk on JunOS from inside a routing instance

[Hugo Slabbert]

On Thu 2016-Apr-28 13:13:35 +0100, James Bensley <jwbens...@gmail.com> wrote:


On 28 April 2016 at 12:50, Dale Shaw <dale.shaw+j-...@gmail.com> wrote:

Hi James,
My memory's a bit hazy on this, but do you see everything you want to see if
you prefix the community string with a "@" in your cacti config?




Hi Dale,

As per my original email, I am prefixing the routing-instance name on
the SNMP get's;

snmpwalk -v 2c -c TEST-SNMP@SecretCommunity 10.254.242.1 .iso | grep ifDesc

Without the routing-instance name the SNMP gets timeout. I can prefix
it as default@SecretCommunity which will for example bring back all
the interfaces on the MX not in any VRf/routing-instance.

So it seems I have to specify a routing instance when using the config
from my original post, and I can specify "default@" to see interfaces
in the default table, I can also specify
A.Nother.Routing-Instance.Name@SecretCommunity and see interfaces in
that RI too, but nothing I can do seems to pull all interfaces when
making the SNMP get from within the RI when compared to making the get
from a host default.inet0.


Use a community of simply "@SecretCommunity", *WITHOUT* the actual RI 
specified.  That will pull everything.  It's a little weird, but it works.




Cheers,
James.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


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

Re: [j-nsp] RTBH

[Hugo Slabbert]

--
Hugo
cell: 604-617-3133

h...@slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on Signal)

On Thu 2016-Jan-14 22:10:46 +0100, Johan Borch  wrote:


Hi!

I have implemented RTBH in my small network of 8 routers. DFZ is running in
a L3VPN and each router has an multihop ibgp-session with my RTBH-router
and it works, but I have one thing that annoys me.

If I announce an offending IP to be black holed, only one of the routers
will point to the discard route. The other 7 will see the announced route
via BGP från the one that got it first I guess and send the traffic to that
one where is is discarded. 


Sounds like the router that receives the initial RTBH /32 is re-advertising 
that to your other peers, i.e.:


- RTBH box announces /32 with a.b.c.d/32 next-hop discard via BGP
- RTBH BGP peer #1 receives and installs the route
- that discard route on RTBH BGP peer #2 is picked up in its IGP export 
  policy, so it exports it into your IGP
- other RTBH BGP peers receive both the original BGP route from the RTBH 
  box as well as the route RTBH BGP peer #1 injected into your IGP
- IGP preference beats BGP, therefore remaining RTBH BGP peers prefer the 
  IGP route that peer #1 injected


Check your IGP export policy; you shouldn't be exporting the RTBH route 
into your IGP.



If I do show extensive on the route it is prefer
because of IGP. I can't figure out how to get each router to prefer the
discard localy. If I do local pref on one router the other 7 will send the
traffic there instead.

Every router has

route a.b.c.d/32 {
   discard;
   install;
   }

And from sending RTBH router, they are announced with next-hop a.b.c.d.

Idéas? :)

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


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

Re: [j-nsp] RTBH

[Hugo Slabbert]

On Fri 2016-Jan-15 18:58:08 +0100, Raphael Mazelier <r...@futomaki.net> wrote:


Le 15/01/16 17:40, Hugo Slabbert a écrit :

Sounds like the router that receives the initial RTBH /32 is
re-advertising that to your other peers, i.e.:

- RTBH box announces /32 with a.b.c.d/32 next-hop discard via BGP
- RTBH BGP peer #1 receives and installs the route
- that discard route on RTBH BGP peer #2 is picked up in its IGP export
  policy, so it exports it into your IGP
- other RTBH BGP peers receive both the original BGP route from the RTBH
  box as well as the route RTBH BGP peer #1 injected into your IGP
- IGP preference beats BGP, therefore remaining RTBH BGP peers prefer
the   IGP route that peer #1 injected

Check your IGP export policy; you shouldn't be exporting the RTBH route
into your IGP.


I can missing the point, but this seems ok to redistribute rtbh route 
in your IBGP, because you don't want to make session to your rtbh 
feeder on all your routers ?


Sure, but I didn't say that it's a problem to distribute/reflect the RTBH 
route via iBGP; I was specifically talking about injecting the RTBH route 
into your IGP (OSPF, IS-IS, etc.), which could lead to the types of issues 
reported by Johan originally.


Johan's topology had 8 BGP speakers, each with an iBGP session to the RTBH 
originating router.  These 8 routers were *already* receiving the RTBH 
route directly from the RTBH router itself on their discrete iBGP sessions, 
and should have received it with a next-hop of 'a.b.c.d' in Johan's setup, 
which by convention is probably 192.0.2.1.  So: job done as all of the iBGP 
peers to the RTBH already have a static discard next-hop for 192.0.2.1, 
which they resolve locally as the next-hop for the blackhole route received 
from the RTBH box.


The problem comes if one (or all) of those iBGP speakers peered with the 
RTBH box then take the BGP-learned RTBH route and, via a loose IGP (again, 
e.g. OSPF or IS-IS, *not* iBGP) export policy inject it into the *IGP*.  
Since IGP route preferences (or "administrative distance", depending on 
your platform) generally beat BGP or iBGP preference/distance unless you've 
fiddled with them, the router that advertises the RTBH route into the IGP 
will end up drawing all traffic for that prefix to itself; the exact 
symptoms Johan described.


And as generaly we configure IBGP session with next hop self, rtbh 
route are directed to the origin router. 


Right; it's fine to reflect RTBH routes rather than setting up discrete 
iBGP sessions from each BGP speaker to your RTBH box, but for simplicity's 
sake skip the NHS on them.


That's why the Niall setup is required, make an execption (do not nhs rtbh 
route) and set a next hop that is localy resolved, to discard.


Right; exactly; all good.  So, again:

Reflecting/re-exporting RTBH routes via iBGP: no problem, provided you 
handle your communities correctly and have the local discard /32.


Injecting the RTBH-learned route into your IGP: through the magic of 
protocol preferences / admin distances, the IGP-learned route from that 
injecting router beats everyone else's iBGP-learned route, and that 
injecting router now effectively becomes a traffic sink rather than letting 
each iBGP speaker discard the RTBH'd traffic locally.




--
Raphael Mazelier


--
Hugo

h...@slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on Signal)


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

Re: [j-nsp] juniper hack news

[Hugo Slabbert]

On Sun 2015-Dec-27 03:46:48 +, Scott Granados  
wrote:

So I wonder about your statements about the governments.  I would tend to 
agree and trust me there’s little about the scumbags in Washington (or 
insert your nations capitol here) that would surprise me but I’m not 
convinced.  There’s been a ton of bellyaching at least in the US and 
probably globally about strong cryptography.  For example here in the US 
the folks in jackboots are trying to convince us that strong cryptography 
was used in the Paris attacks and if we could only break the cyphers the 
world would be a  safer place. Maybe if we send all our snail mail on post 
cards as well.  But this bellyaching makes me think they aren’t nearly as 
good at this signals thing as we’re lead to believe.  So while I have 
heard of hacks before and it is absolutely with in the realm of 
possibility the NSA or whom ever has backdoors in everything but if they 
did would they cry so much about being able to get in the middle and do 
what spooks do?  Or is this complaining a false cover and they are so 
intertwined and back door hacked in to everything it doesn’t matter and 
they want to create a false sense to throw off potential baddies?  


I think an important factor here is that the current political 
"Cryptopocalypse" talk around crypto is not *just* about "strong 
cryptography" but more about end-to-end encryption schemes that leverage 
strong crypto.  Compromising Internet infrastructure points (or appliances 
that handle crypto for a large number of users e.g. this ScreenOS issue) 
results in a large amount of successfully compromised traffic per 
compromised host/vector, as the traffic of dozens, thousands, or millions 
of users may flow through those points.  Basically: there is good ROI on 
your exploit work.


The "problem" (from the perspectives of those wanting to eavesdrop) with 
e2e is that getting in the middle somewhere doesn't get you the cleartext 
anymore.  So, rather than being able to compromise ScreenOS or Junos or 
IOS/-XE/-XR and then getting a nice spigot of data from that, you need to 
do any of:


1) compromise the private keys of the specific users you are targeting and 
still pick up their traffic through existing taps of Internet transit 
traffic


2) compromise whatever myriad software/solutions are being used for e2e 
encryption by the targeted users, get the targeted users to use the 
compromised version of those applications/solutions, and still pick up 
their traffic through existing taps of Internet transit traffic


3) compromise the hosts/devices of the targeted users to get on-host, 
cleartext copies of the data post-decryption


That's a *lot* more work than being able to tap reams of data in flight on 
a specific nexus point and makes dragnet surveillance *much* less feasible 
as the time and costs involved would grow significantly.


Just my 2c.

This is something I’ve been very curious about and the Government’s 
ability to collect this intelligence fascinates me.  I also wonder, if in 
fact this was in the ScreenOS source code does that mean that an agency or 
2 has plants in Juniper?  I think something similar to this happened with 
a company producing SIM cards and a plant on the inside was able to gather 
information enabling the cards to be compromised by the NSA.  Wonder how 
far this is spread and how many vendors.


Excuse me while I go fashion a hat out of tin foil and stock up on canned 
goods.:)


Thank you
Scott



--
Hugo

h...@slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on textsecure & redphone)



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

Re: [j-nsp] juniper hack news

[Hugo Slabbert]

On Sat 2015-Dec-26 07:58:47 -0800, Chris Cappuccio <ch...@nmedia.net> 
wrote:



Hugo Slabbert [h...@slabnet.com] wrote:

>Does this affect any other juniper gear ?

Not as of this moment, no.  It's limited to ScreenOS.



Sorry, this is false. It's clear in the documentation that
JunOS was targeted as well.


Not by any means to discourage people from doing their own due diligence 
and vetting for themselves whether their gear is affected, but either you 
or I are reading different sources, or the holidays are affecting my 
reading comprehension even more than I thought...


http://forums.juniper.net/t5/Security-Incident-Response/Important-Announcement-about-ScreenOS/ba-p/285554


Q: What devices do these issues impact?

Administrative access (CVE-2015-7755) only affects devices running ScreenOS 
6.3.0r17 through 6.3.0r20.


VPN Decryption (CVE-2015-7756) only affects devices running ScreenOS 
6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20.


We strongly recommend that all customers update their systems and apply the 
patched releases with the highest priority
 


Q: Is the SRX or any other Junos®-based system affected by these issues?

These vulnerabilities are specific to ScreenOS. We have no evidence that 
the SRX or other devices running Junos are impacted at this time.



https://kb.juniper.net/InfoCenter/index?page=content=JSA10713=SIRT_1=LIST=true

Administrative Access (CVE-2015-7755) allows unauthorized remote 
administrative access to the device. Exploitation of this vulnerability 
can lead to complete compromise of the affected device.


This issue only affects ScreenOS 6.3.0r17 through 6.3.0r20.  No other 
Juniper products or versions of ScreenOS are affected by this issue.


...

VPN Decryption (CVE-2015-7756) may allow a knowledgeable attacker who can 
monitor VPN traffic to decrypt that traffic. It is independent of the 
first issue.


This issue affects ScreenOS 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 
6.3.0r20. No other Juniper products or versions of ScreenOS are affected by 
this issue.



https://adamcaudill.com/2015/12/17/much-ado-about-juniper/

This morning, Juniper Networks announced an out-of-cycle update for their 
ScreenOS firewall operating system (not the newer Junos[1]) to patch two 
unrelated issues (both identified as CVE-2015-7755):


Am I missing something that indicates this is known to affect Junos as 
well?


--
Hugo

h...@slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on textsecure & redphone)

[1] https://twitter.com/llorenzin/status/677663294132457472



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

Re: [j-nsp] juniper hack news

[Hugo Slabbert]

What he said ;-)
--
Hugo
h...@slabnet.com: email, xmpp/jabber
also on Signal

 From: Aaron Dewell <aaron.dew...@gmail.com> -- Sent: 2015-12-26 - 15:08 


>
> While that may be completely correct (while not completely provable, it is 
> entirely reasonable to assume it), the immediate question was whether this 
> particular vulnerability affected JunOS also, or only ScreenOS.
>
> The answer to that more narrow question is that it only affects ScreenOS.
>
> I think we can assume that most of the software we use today (Windows, MacOS, 
> IOS, JunOS, Linux, FreeBSD, etc.) all contain some form of government-induced 
> weakness.  Exactly what those are have yet to be discovered.  I for one am 
> confident that they all contain at least one if not many.
>
> However, the question asked only concerned this particular vulnerability, for 
> which JunOS is not affected.  The malicious code in question was introduced 
> into ScreenOS source code and not into JunOS.
>
>> On Dec 26, 2015, at 3:21 PM, Chris Cappuccio <ch...@nmedia.net> wrote:
>>
>> Hugo Slabbert [h...@slabnet.com] wrote:
>>>
>>> Am I missing something that indicates this is known to affect Junos as well?
>>>
>>
>> I just gave you a link to a formal NSA/GCHQ "TOP SECRET" documentation -- 
>> from
>> 2011 -- which says they are DOING IT. It only takes NSA ~90 days to develop
>> a new vulnerability in this class of software.
>>
>> I think the best we can hope is that Juniper was privately informed and has
>> quietly patched any JunOS vulnerabilities.
>>
>> Juniper has a lot of international business to lose from public
>> vulnerabilities in core Internet infrastructure. Cisco already took a large
>> hit.
>>
>> I don't know what else to say. Anyone who thinks that the NSA did not develop
>> this capability in 2011 needs to read. Anyone who thinks NSA can't develop
>> this capability again (once their old vulnerabilities are burned) does not
>> understand the class of this attacker.
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>




signature.asc
Description: PGP/MIME digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] juniper hack news

[Hugo Slabbert]

Does this affect any other juniper gear ?


Not as of this moment, no.  It's limited to ScreenOS.

--
Hugo

h...@slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on Signal)

On Mon 2015-Dec-21 10:45:04 -0600, Aaron  wrote:


Y'all know anything about this ?  Folks in my organization are concerned.
It seems to be that it only affects certain versions of Juniper Netscreen
ScreenOS.



Does this affect any other juniper gear ?



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





http://forums.juniper.net/t5/Security-Incident-Response/Important-Announceme
nt-about-ScreenOS/ba-p/285554






http://thehackernews.com/2015/12/hacking-juniper-firewall-security.html






Aaron



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


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

Re: [j-nsp] Collapsed MPLS CE/PE/P configuration

[Hugo Slabbert]

The original config also doesn't show any of your BGP config from inet.0, 
so it's hard to say what's missing.


IIRC, if you have vrf-target, you don't need vrf-export:

vrf-export export-direct;
vrf-target target:7849:13;

If you want to do explicit export policy via vrf-export, I believe you need 
to drop the vrf-target and instead create a vrf-import policy as well.


--
Hugo

h...@slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on Signal)

On Mon 2015-Dec-21 15:57:40 +, Phil Mayers  wrote:


On 21/12/15 15:42, Matthew Crocker wrote:


A ‘show run bgp sum’bgp.l3vpn.0  with 0 routes


That's what you want to focus on. Check the output of "show bgp nei" 
to ensure the inet-vpn-unicast is *actually* present on "NLRI for 
this session"; if not then correct this.


Remember if you're using a route-reflector you need to have it setup there.

If the NLRI is present then "show route receive-proto bgp  table 
bgp.l3vpn.0 all extensive" to check you're actually getting any 
routes but maybe rejecting them.


If there are no routes present, check "show route 
advertising-protocol bgp  table VRF.inet.0" at the sending side 
to check they're actually being redistributed.


Showing your full BGP config might help.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] Quick SRX host-inbound Question

[Hugo Slabbert]

On Tue 2015-Nov-17 17:52:11 +, Wayne Lee via juniper-nsp 
 wrote:


I thought you could create your own "service" and apply ports to that
specifically

I'm running into an issue where I don't want to allow-all on the
host-inbound but I do need a fair amount of unlisted ports to still
maintain access.

Does anyone remember if this is possible.  Still sorting through
documentation to validate my memory.

Thank you,


Yes you can configure a custom application and application-set with your

port ranges and apply that to a policy.


That's for security policy, not host-inbound-traffic.  For 
host-inbound-traffic, you are limited to the pre-configured system-services 
and protocols made available by JunOS:


http://www.juniper.net/documentation/en_US/junos12.1/topics/reference/specifications/zone-host-inbound-traffic-system-service-supported.html

If you want to allow something to the RE that's not listed in there, you'd 
have to allow all and then filter it down with a stateless filter on the 
loopback in the relevant routing-instance to control traffic to the RE, as 
per 
http://www.juniper.net/documentation/en_US/junos14.2/topics/concept/firewall-filter-stateless-basic-uses-for.html#jd0e63


But: host-inbound-traffic is for traffic destined for the RE, meaning 
services or protocols running on the RE.  What unlisted ports are you 
talking about that are for services/protocols running on the RE but which 
are not available under host-inbound-traffic under either system-services 
or protocols?


If you're talking about traffic transiting the SRX, then yes: custom 
application and/or application-set definitions + security policies would be 
your weapon of choice.  Note that you can be exposing absolutely *zero* 
services or protocols under host-inbound-traffic while still allowing 
through anything else you want in terms of transit traffic via security 
policies.




Regards


Wayne


--
Hugo

h...@slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on Signal)


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

Re: [j-nsp] Quick SRX host-inbound Question

[Hugo Slabbert]

On Wed 2015-Nov-18 09:03:46 +1100, Michael Gehrmann  
wrote:


You might have better luck with the junos-host zone.


...I knew there was something I forgot...thanks!

--
Hugo



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



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

Re: [j-nsp] RE-S-2000-4096

[Hugo Slabbert]

Anecdotally, we have an MX480 with RE-2000 in a very similar space as 
you're describing: taking in 4x full v4 tables, 3x full v6 tables, and a 
chunk of v4 and v6 peering routes at a couple of exchanges.  No issues.


--
Hugo

h...@slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on textsecure & redphone)

On Tue 2015-Oct-20 13:44:54 +0800, Chen Jiang  wrote:


RE-2000 could support about 10M route in RIB.

RE-2000 is X86 based RE and MX80/MX104 is PPC based RE.

From raw evaluation, in JUNOS PPC RE is about 1/3 performance vs. X86 RE
for same frequency,

On Wed, Oct 14, 2015 at 9:16 PM, Colton Conor 
wrote:


How many full routes can two RE-S-2000-4096 in a MX480 support? How limited
is this older card? How does it compare to the RE found in the MX104 or
built into the MX80?

On the MX480, when do most make the decision to upgrade from the
RE-S-2000-4096
to a RE-S-1800X4-16G? What does the extra processing and ram enabled on
this newer card?

Application would be peering on an internet exchange with content
providers, and 4 connections to Tier one networks.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp





--
BR!



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


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

Re: [j-nsp] QoS DNS

[Hugo Slabbert]

On Tue 2015-Sep-22 11:27:06 +0200, Johan Borch  wrote:


Hi

Do anyone have an example of how to shape for example DNS-trafik by port to
xx Mbps? :)


On what platform?  EX? SRX? MX? Something else?


(No I'm not trying to start a religious war ;))

Johan


--
Hugo


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

Re: [j-nsp] Disable telnet/ssh access from virtual routers

[Hugo Slabbert]

On Wed 2015-Jul-15 10:51:58 -0600, Stacy W. Smith st...@acm.org wrote:




On Jul 15, 2015, at 10:46 AM, Victor Sudakov v...@mpeks.tomsk.su wrote:

Stacy W. Smith wrote:

https://kb.juniper.net/InfoCenter/index?page=contentid=KB23547

The article states it applies to VRFs, but it also applies to routing instances of type 
virtual-router.



This lo0.x interface does not have to have an IP address, does it?


I haven't tested it myself, but I don't believe it has to have an IP address 
configured. It does have to have family inet/inet6 configured because that's 
where you apply the filter, but I don't think it has to have an address 
configured.


I can confirm that; no IP is needed on the lo0.x units in the VRs/VRFs.



--Stacy



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

[j-nsp] DHCPv6-PD server Access-Internal routes on Branch SRX

[Hugo Slabbert]

I'm not getting any responses on the Juniper forums, but am hoping this 
list may have some answers.


I'm labbing up a branch SRX as a DHCPv6 PD server as managed CPE for 
customer sites.  A /48 is routed to the SRX, and the SRX in turn would dish 
that out to a customer device via PD.  Our ideal deployment would be to 
just do PD with link-local only on the touchdown (i.e. no SLAAC, NDRA, or 
ia-na).


DHCPv6 PD works fine and the customer equipment gets the prefix  can set 
up a ::/0 route via RAs from the SRX.  The problem is that if the SRX's 
touchdown interface to the customer device has LL only, it doesn't install 
an Access-Internal route for the delegated prefix, and so the customer's PD 
prefix is unreachable.


If I add a GUA or ULA on the SRX's touchdown interface to the customer 
equipment and add that /64 under interface touchdown prefix stanza 
under router-advertisement, the access-internal route gets installed 
properly on the SRX when the customer dhcpv6 client gets its PD lease.


Is this expected behaviour?  Is running ia-pd with link-local not an 
accepted deployment model?  I flipped around the roles in the lab with a 
Cisco 867 acting as the PD server and the SRX100 as a client, and IOS is 
happy to install a route for the PD prefix with link-local only on the 
touchdown.


Test gear was an SRX110H2-VA. The behaviour was the same on all of the 
following:


- 12.1X44-D45.2
- 12.1X46-D35.1
- 12.1X47-D20.7
- 12.3X48-D10.3

--
Hugo

h...@slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319
1D77 9AB1 0FFD B178 313E

(also on textsecure  redphone)



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

Re: [j-nsp] VPN over ADSL With 4G Backup

[Hugo Slabbert]

Sorry for the long delay in replies.


We will have a non RFC1918 IP address at the hub and the spokes will get a
dynamic IP from the provider through ADSl 2+.


I haven't had to deal with dynamic IPs on SRX ipsec tunnel endpoints as 
I've been fortunate that we can maintain enough control of the links to 
require statics.  That said, I *believe* this should just change your IKE 
gateway configs on the hub to reference a dynamic gateway for each customer 
site rather than using a static destination gateway IP, e.g.:


security {
ike {
gateway spoke1 {
ike-policy spoke1-policy;
dynamic hostname spoke1.example.org;
external-interface ike-ext-interface;
}
}
}

Be sure to use aggressive mode in your IKE policy.


the spokes should have a 4G as backup  for the ADSL2+.

How the backup link should be configured.

I assume at the hub st0.x multipoint will be configured.


There are a few different ways to slice it.  Multipoint at the hub is one 
option.  I haven't run a multiple routed IPSEC setup on Junos, so I'm 
extrapolating a bit here and hopefully somebody will tell me I'm being an 
idiot if I veer to far off course.


If you're doing backup links, running a protocol, I would set up 2x 
multipoint VPN interfaces at the hub, banked off of different IPs (could be 
the same external interface with multiple IPs bound; use local-address 
a.b.c.d and local-identity inet a.b.c.d under the IKE gateway 
definitions on the hub to distinguish the two).  Point the primary link 
from the branches to the first multipoint st0.x interface at the hub, and 
the secondary branch links at the second multipoint st0.x interface at the 
hub.  Set your protocol interface metrics/costs so that the second 
multipoint st0.x  at the hub has a higher cost.  If you were to use just 
one multipoint st0.x at the hub, the hub would not have a way to 
distinguish route preferences between the primary and secondary links.


In terms of backup paths / failover:
Will you route *all* spoke site traffic through the hub?  Or just 
inter-site traffic, with e.g. regular public internet traffic going out the 
spoke's local provider's gateway?


If the former:
Create static /32 routes for the hub's IKE gateway IPs for the primary and 
secondary st0.x multipoint interfaces there (I'll just call them st0.0
(primary) and st0.1 (secondary) from here on).  The /32 route for st0.0's 
IKE gateway IP should go via your default gateway on the ADSL interface, 
with /32 route for st0.1's IKE gateway IP via the HSPA backup default 
gateway.  Actually; given that we're talking about DHCP on the ADSL, 
consider putting the ADSL and HSPA interfaces in their own discrete 
virtual-router routing-instances so that the 0/0 route picked up from DHCP 
on the ADSL gets installed in that VR, and the static 0/0 route for the 
HSPA can be isolated into its own VR.


Failover between primary and secondary are then handled by whatever 
protocol you run within the st0.x tunnels. 

If the latter (VPN tunnels for inter-site traffic only; public internet 
traffic egress locally at the branches), you'll still want static routes 
config'd on the branches for the 2x different IKE gateway IPs on the hub, 
but now you also need to handle failover locally.  My guess is your best 
bet for that would be RPM to monitor connectivity across your ADSL 
connection and pull that route in case of RPM failure.  I haven't done that 
either on a DHCP setup, so YMMV on the details of that implementation.


Hope that helps; I'd be curious to hear how this turns out.

--
Hugo

h...@slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319
1D77 9AB1 0FFD B178 313E

(also on textsecure  redphone)

On Sat 2015-Jun-13 11:39:11 +0300, Nc Aji aji14...@gmail.com wrote:


Appreciated your inputs.

To make it bit more clear.

We will have a non RFC1918 IP address at the hub and the spokes will get a
dynamic IP from the provider through ADSl 2+.

the spokes should have a 4G as backup  for the ADSL2+.

How the backup link should be configured.

I assume at the hub st0.x multipoint will be configured.

do you have any suggestions regarding the configurations.

Thx



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

Re: [j-nsp] L2 flooding

[Hugo Slabbert]

On Fri 2015-Jul-03 20:42:36 +0200, Johan Borch johan.bo...@gmail.com 
wrote:



Hi!

I have a L2 network with a core and a bunch of access switches, all juniper
EX. The links between the access switches and the core are marked with vlan
all and trunk.

Here's to my problem. I'm deploying a CEPH cluster and the cluster is
running on it's own vlan. This vlan only exists on the core and on one
other switch. The problem is that CEPH is very chatty and due the fact that
the core links accepts all vlan the core floods the traffic to all other
switches and fills upp the uplinks (even if the vlan don't exists on those
switches). Is there some way to mitigate this except the obvious to not run
vlan all on the uplinks and to move ceph-cluster to it's own switches?


mvrp?



Johan


--
Hugo

h...@slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319
1D77 9AB1 0FFD B178 313E


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

Re: [j-nsp] VPN over ADSL With 4G Backup

[Hugo Slabbert]

On Thu 2015-Jun-11 23:27:22 +0300, Nc Aji aji14...@gmail.com wrote:


Need to connect 250 Outlets by using ADSL Over internet


Static or DHCP at the outlets?


At the Head end We have public address need to have 4G as backup.


I can't parse this sentence.  I get that you have a non-RFC1918 IP at the 
hub, by need to have 4G as backup do you mean that the hub site has/needs 
4G backup or that the outlets/spokes will have/need 4G connections as 
backup to their primary ADSL connection?



Which VPN technologies to be used


We stick with routed IPSEC tunnels (stx.x).  Scales better; simpler 
management of routing policy; and policy VPNs are just too opaque for my 
liking.  That assumes that you have statics at the spokes, though, as doing 
routed ipsec tunnels with dynamic endpoints is a PITA.



Please suggest the juniper device model at spokes and HUB.


Probably best to talk to your SE.  The suggestions below are just 
approximations based on some assumptions of your setup, and requisite 
grains of salt are suggested.


Spokes:
SRX100 or 110 for the spokes.  I'm assuming since you said ADSL it's e.g.  
ADSL2+ or similar, so lower speeds (-le 15 mbps down) rather than higher 
rate VDSL2?  An SRX100 can handle crypto  stateful firewalling on that 
throughput without issue, so you don't have to step up to anything bigger 
like e.g. SRX210 or SRX240 unless you need GigE on the LAN or something.


You could also go for the SRX110H-VA with built-in ADSL/VDSL if you need to 
bring your own modem rather than the ADSL provider putting one in.



Hub:

Question of scale, really.  Size for throughput and site count and throw in 
your oversubscription ratio of choice, then go from there.  E.g. if you're 
doing 15 mbps ADSL per site @ 250 sites, that's a theoretical peak of ~3.7 
Gbps.  That said, I have my doubts about all of your sites simultaneously 
pinning their download, hence factoring in an oversub ratio.


At-a-glance SRX range comparo:
http://www.juniper.net/us/en/products-services/security/srx-series/compare/

For crypto on the hub site, you could pair that up with an SRX as well.  
For the throughput you're looking at, something like a larger branch 
(SRX550/650) would probably be fine.  You're still looking at a software 
router in those, so just be aware that pinning the control plane can hit 
your forwarding unless you step up to something in the high end / DC SRX 
range (1400 or higher).  Some people do MX's with encryption services PICs 
[1], which gets you a proper routing platform, but that's obviously a 
different price point.


If you're doing backup connections of some sort, a fairly clean way to 
handle that in a routed IPSEC tunnel solution would be 2x crypto tunnel 
interfaces (st) per site.  If you mean 4G at the branch, the two tunnels 
would have different external-interface settings defined.  If the 4G was at 
the head office (which would be interesting from a bandwidth perspective), 
there would be two different ike-gateway addresses defined, pointing at the 
two different H/O IPs.


You'd then want to check for liveness across those two tunnels, so run a 
protocol with appropriate metrics defined for the crypto interfaces.


Beware that if you don't do anything about it on the hub or spokes, 
asymmetric routing across the two different tunnels could cause you some 
grief as the SRX caches ingress/egress interfaces for flows and will by 
default drop traffic ingressing on diff interface than it expects (e.g.  
ADSL fails and traffic now comes in over the 4G tunnel).


You may need to either disable tcp syn-check and sequence check to deal 
with that [2][3][4][5], forgo flow processing  stateful firewalling and 
chuck everything coming in over the tunnels into selective packet mode, or 
separate routing from the IPSEC termination and use some tunneling to land 
traffic on a proper, external router.



Does anyone uses this setup and have success. SRX or J Series suites this
requirement?


Yes.


Thx


No problem.

--
Hugo

h...@slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319
1D77 9AB1 0FFD B178 313E
(also on textsecure  redphone)

[1] http://kb.juniper.net/InfoCenter/index?page=contentid=KB19733
[2] 
http://forums.juniper.net/t5/SRX-Services-Gateway/asymmetry-problem/td-p/250084
[3] 
http://www.juniper.net/techpubs/en_US/junos12.1/topics/example/session-tcp-packet-security-check-for-srx-series-disabling-cli.html

[4] http://kb.juniper.net/InfoCenter/index?page=contentid=KB25094
[5] http://kb.juniper.net/InfoCenter/index?page=contentid=KB21266


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

Re: [j-nsp] SRX FBF issue

[Hugo Slabbert]

On Fri 2015-Jun-05 19:11:16 +0300, Yuriy B. Borysov yokod...@yokodzun.kiev.ua 
wrote:


Hello!

I got a strange problem with Filter Based Forwarding on SRX 220.

I have two uplink:

show configuration interfaces ge-0/0/0.14
description uplink1;
vlan-id 14;
family inet {
   mtu 1500;
   address x.x.x.82/29;
   address x.x.x.85/29;
   address x.x.x.86/29;
}

show configuration interfaces ge-0/0/0.18
description uplink2;
vlan-id 18;
family inet {
   mtu 1500;
   address y.y.y.114/28;
   address y.y.y.117/28;
}


Default route on ge-0/0/0.14 (x.x.x.81).

I configure destination nat on y.y.y.114:
show security nat destination rule-set port-redirect rule test
match {
   destination-address y.y.y.y/32;
   destination-port 2555;
}
then {
   destination-nat pool test;
}



Run telnet y.y.y.114 2555 and I see a strange picture:

run show security flow session destination-port 2555
Session ID: 133327, Policy name: untrust-to-trust/11, Timeout: 14, Valid
 In: 213.160.143.26/21722 -- y.y.y.114/2555;tcp, If: ge-0/0/0.14, 
Pkts: 2, Bytes: 120
 Out: 10.100.0.252/25 -- 213.160.143.26/21722;tcp, If: ge-0/0/0.100, Pkts: 3, 
Bytes: 180
Total sessions: 1


Why inbound interface is ge-0/0/0.14 but not ge-0/0/0.18???



This is an issue with the interaction between FBF and flow route caching.  
When the packet ingresses ge-0/0/0.18, a route lookup is done for the 
source address within the routing table to which ge-0/0/0.18 belongs.  As 
you mentioned, the default route for that VR/table is out ge-0/0/0.14, so 
the cached flow route entry is entered as such and the flow session gets 
installed with ge-0/0/0.14 as the outside interface.


I haven't found a way around this outside of sticking ge-0/0/0.18 in a 
totally separate virtual-router with a default route via ge-0/0/0.18's 
gateway and then leaking interface routes between instances as needed.  
With ge-0/0/0.18 in its own VR with a default gateway pointing to its 
next-hop, the route lookup on initial packet ingress will pick up 
ge-0/0/0.18 as the egress interface on the return path.  It gets kinda 
messy, though, and I haven't really run it in production.


My past pings on this fell on deaf ears:
http://forums.juniper.net/t5/SRX-Services-Gateway/SRX110-Asymmetric-routing-with-FBF-and-remote-sourced-traffic/m-p/199115



Thanks!



No problem.




--
WBR, Yuriy B. Borysov
YOKO-UANIC | YOKO-RIPE  
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] Filtering rib-group imported direct routes?

[Hugo Slabbert]

Mark's message already covered the rib-group interface routes option, but I 
thought I'd chime in with the option of doing this through instance-import 
under the FBF itself without rib-groups.


Sorry; sent this earlier but from a non-list address.  Original message 
follows below:

--

You can apply import policy to rib-groups or otherwise use instance-import 
in the FBF.  Either one gives you more granularity than just straight-up 
interface route leaking.


For policy on rib-groups, you would do something like:

routing-options {
   interface-routes {
   rib-group {
   inet fbf-groups;
   }
   }
   ...
   rib-groups {
   fbf-groups {
   import-rib [ inet.0 lb1.inet.0 ]
   import-policy lb1-default-direct;
   }
   }
}
...
policy-options {
   policy-statement lb1-default-direct {
   term direct {
   from protocol direct;
   from interface xe-1/0/0.0
   then accept;
   }
   then reject;
   }
}

instance-import is more granular still.  Disclaimer: I've only used 
instance-import to leak routes from virtual-router instances to FBFs; I 
have not used it to leak routes from inet.0 to an FBF, so take this with a 
grain of salt.


For that you would skip the rib-groups and instead would do something like:

policy-options {
   policy-statement lb1-fbf-import {
   term inet0-default-direct {
   from {
   instance lb1;
   protocol direct;
   interface xe-1/0/0.0;
   }
   then accept;
   }
   term else-reject {
   then reject;
   }
   }
}
...
routing-instances {
   lb1 {
   instance-type forwarding;
   routing-options {
   static {
   route 0.0.0.0/0 next-hop 1.2.3.4;
   }
   instance-import lb1-fbf-import;
   }
   }
}

Cheers,

Hugo

Chris Woodfield rek...@semihuman.com wrote on Sat [2014-Nov-15 11:27:03 
-0800]:

Hi,

I’m currently managing a setup where we’re at our edge, we're punting packets 
to a routing-instance based on firewall matches in order to separate traffic 
between outside client traffic (which needs to be routed through the LB on 
return) and other internet-facing outbound. We have rib-groups configured for 
our routing-instances to import the direct and local routes, like the below 
(simplified) config example:

routing-options {
   interface-routes {
   rib-group {
   inet fbf-groups;
}
   }
   ...
   rib-groups {
   fbf-groups {
   import-rib [ inet.0 lb1.inet.0 ]
   }
   }
}
...
firewall {
   family inet {
   filter BOUNCE_TO_LB
   from {
protocol tcp;
   source-port [ 80 443 ];
   }
then {
   routing-instance lb1;
   }
   }
   }
}
...
routing-instances {
   lb1 {
   instance-type forwarding;
   routing-options {
   static {
   route 0.0.0.0/0 next-hop 1.2.3.4;
   }
   }
   }
}

The lb1 routing-instance is simply a default route to the LB's gateway IP 
which is a directly connected interface to the router.

(This design is documented here: 
https://www.juniper.net/documentation/en_US/junos12.3/topics/example/logical-systems-filter-based-forwarding.html)

The problem I'm having is that because this setup imports all direct and local 
routes into the routing instance, packets that are punted to the routing 
instance that are destined for other directly connected hosts bypass the 
default route and get forwarded directly to the end host. For example, if I 
have a host hanging off of interface xe-2/0/0 with address 2.2.3.4/24, and I 
look in the routing-instance's table, I see:

edge-rtr show route table lb1.inet.0

lb.inet.0: XXX destinations, XXX routes (XXX active, 0 holddown, X hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0  *[Static/5] 37w1d 15:53:29
to 1.2.3.4 via xe-1/0/0
2.2.3.4/24 *[Direct/0] 11w3d 10:42:47
via xe-2/0/0.0
2.2.3.1/32 *[Local/0] 11w3d 10:42:47
 Local via xe-2/0/0.0

So a packet with dest IP 2.2.3.4 goes directly to the host instead of going to 
the LB, which means it has the real host IP and not the VIP's IP as its source, 
which means no worky worky.

So the question I have is this - is there a way to filter the direct and local 
routes that are imported into a routing instance? In this case, I'd only want 
the direct route for the subnet containing 1.2.3.4, and no other direct routes.

Alternatively, would it be possible to *not* import any direct routes into the 
routing-instance (i.e. deleting the rib-groups syntax altogether) and instead 
add the direct and/or local route manually to the routing instance, so I can 
ensure that only the direct routes I need to resolve the next hop make it into 
the routing instance?

TIA,

-Chris





___
juniper-nsp mailing