Re: [j-nsp] Inter-racks switch routing recommended practice

[Wayne Tucker]

You should be able to run that many racks inside a single OSPF area -
in fact, multiple areas can result in a lot of type 3 LSAs if you do
not summarize properly.  You can improve initialization times and keep
the LSDB down to one LSA per router if you:

1.) Set the RVIs on the ToRs to passive (to keep type 2 LSAs from
being generated for the host subnets)
2.) Configure all of the ToR<->EX4550 links as point-to-point (ditto,
plus avoid the DR election delays)

At larger scales the frequency of LSA refreshes and SPF runs would
make multiple areas (or other solutions) worthwhile, but for these
platforms you're probably looking at hundreds of racks (or lots of
really flaky links ;) before that even begins to be a conern.

I can't think of anything BGP would provide that would be of
significant benefit based on what you've described - plus I believe it
requires additional licensing on those platforms.

:w




On Tue, Jun 4, 2013 at 7:24 PM, Ihsan Junaidi Ibrahim  wrote:
> Hi,
>
> I'm building an infrastructure which comprises of a few tens of racks with 
> Hadoop, Supermicro MicroCloud and whatnot running. Each rack probably will 
> have EX4200 or EX3300 ToR switch, individually at the moment, not VC-chained. 
> These switches will have a couple of EX4550 aggregating the circuits.
>
> My question is what would be the best routing protocol in this kind of 
> scenario?
>
> I'm thinking multi-areas OSPF/v3 but would a flat OSPF area 0 topology with 
> BGP make more sense? I don't have a lot of exposure in dense datacenter 
> routing so I'm bringing the conventional WAN routing thinking cap into the 
> picture.
>
> Thanks.
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] Assigning Forwarding Class and DSCP Value for Routing Engine–Generated Traffic

[Wayne Tucker]

On Wed, Oct 10, 2012 at 5:18 AM, Huan Pham  wrote:
> http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-cos/cos-assigning-fc-dscp-to-re-pkts.html
>
> Once I apply the Firewall Filter with QoS term on loopback interface, it
> does not seem to change the default behaviour.
>
> I tried  host-outbound-traffic  feature, which assign a forwarding class,
> and I can set DSCP for all traffic generated by RE, which works as it says,
> but I want a finer control.

Which revision are you running?  I believe this requires one of the
11.x releases on the MX(5|10|40|80).


> *This behaviour is not what I expected. Does anyone experience the same
> issue, please?*

I was able to get it working for everything except PPM generated
traffic (BFD, etc) which always went into the same queue.  I've
changed jobs since then so I don't have ready access to the configs I
used, but I believe the MX was one of the platforms where I ran into
trouble if I tried to use anything other than queue #3 for nc traffic.

Have you tried capturing the traffic from a different box?  It's
possible that the RE sees the traffic before the rewrite occurs.

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

Re: [j-nsp] Preventing direct routes from forming OSPF summaries

[Wayne Tucker]

On Thu, Aug 30, 2012 at 6:42 AM, Tore Anderson
 wrote:
> I have a OSPFv3 network that looks something like this (simplified):
>
> +-++-+
> |MX240|xe-0/0/0 ---(area 0)--- xe-0/0/0|MX240|
> +-++-+
> xe-0/1/0  xe-0/1/0
>|  |
> (area 1)   +--+(area 1)
>\-- xe-0/0/0|EX4500|xe-1/0/0 --/
>+--+
> ||
>(production stuff)
>
> I noticed that if the OSPF session between one MX and the EX goes down,
> that MX will continue to install the summary discard route, effectively
> blackholing all traffic destined for area 1.[snip]
>
> Is there a clever way to avoid this? I'm thinking along the lines of a
> knob that would make it so that a summary wouldn't pop into existence
> unless an active *ospf* route from inside the area-range exists.

None that I know of.  Depending on your overall design you might be able to:

1.) Number the transit links out of a different space.  You can
summarize (or suppress) them separately.
2.) Configure xe-0/0/0 in area 1 of both MXs as a secondary interface.
 That will allow them to exchange the LSDB for that area even when the
downlink to the EX is down.  There are other reasons that you'd
probably want that, anyhow.

Note: I haven't tested #2 with OSPFv3, but it has always worked fine
for me in v2.

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

Re: [j-nsp] SRX240H Cluster & SNMP

[Wayne Tucker]

I have a couple of SRX240H clusters running 11.2R6.  I also have an
SRX650 cluster running 11.2S6.  I don't see anything in my logs to
indicate that I'm getting errors and none of my graphs show signs of
failed polls.

I doubt it matters, but I'm polling the devices through their loopback
interfaces.  I also filter out some of the interfaces and filter
duplicates:

> show configuration snmp | display inheritance | except ##
filter-interfaces {
interfaces {
fxp2;
gre;
ipip;
lo0.16384;
lo0.16385;
lo0.32768;
lsi;
mtun;
pimd;
pime;
tap;
}
}
filter-duplicates;
[snip]

Does it seem to happen the most when there are lots of queries going
through?  Are you doing row-based or column-based queries (one
interface at a time or the same counter across several interfaces)?
The former is supposed to perform better (so, for instance, an
snmpwalk is fairly processor intensive).

Any signs of trouble on your control or fabric interfaces?

Has JTAC already had you enable tracing for SNMP?

:w



On Mon, Aug 20, 2012 at 8:51 AM, Eric Van Tol  wrote:
> All,
> Is there a version above 11.2 where SNMP works properly in a cluster?  Seems 
> that when running various versions (11.2R7.4 and 11.4R4.4, so far) on a 240H 
> cluster, SNMP doesn't work properly and starts spitting out 'noSuchObject' 
> errors on perfectly valid queries like when querying the interfaces MIB.  I 
> should also mention that the OIDs it seems to have a problem with are 
> primarily ones that have to do with the backup chassis in redundancy-group 0 
> (ge-5/0/0 through ge-5/0/15).  JTAC has thus far been unsuccessful at 
> assisting me.
>
> I have downgraded to 10.4R10.7 on a non-production cluster and it's working 
> successfully, but I really want to take advantage of the global address book. 
>  I can certainly live without it, but it does make things much easier.
>
> Thanks in advance,
> evt
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] Tricks for killing L2 loops in VPLS and STP "BPDU-less" situations?

[Wayne Tucker]

On Fri, Aug 17, 2012 at 8:08 AM, Clarke Morledge  wrote:
> We have had the unfortunate experience of having users plug in small
> mini-switches into our network that have the capability of filtering out
> (by-default) BPDUs while allowing other traffic through.  The nightmare
> situation is when a user plugs in such a switch accidentally into two of our
> EX switches.  Traffic will loop through the miscreant switch between the two
> EXs and without BPDUs it just looks like MAC addresses keep moving between
> the real source and the two EXs.

This is probably not the answer you're looking for, but the best
solution is to not bridge to your access switches.  Everything in the
EX series is capable of routing, so why not take advantage of that
functionality?

Barring that, your options are: storm control, MAC limiting, and MAC
move limiting.

I've never found storm control to be that useful.  It reduces the
volume of frames but usually not enough to cancel out all of the
negative effects.

MAC limiting with a reasonable MAC limit on a port can cause the port
to be disabled if too many addresses are seen coming from said port.

MAC move limiting is configured per VLAN.  It can detect a layer 2
loop with a smaller number of MAC addresses than MAC limiting would,
but my concern has always been that (as far as I can tell) there's no
way to determine which interface would end up being disabled - it
would be bad to have it pick a trunk between your core switches
instead of the trunk to the IDF.

None of these will ever be as effective as routing.


> In an MX environment running VPLS, this problem can happen easily as there
> are no BPDUs even to protect against loops in VPLS, particularly when your
> VPLS domain ties into a Spanning Tree domain downstream where your potential
> miscreant switch may appear.

I believe there was a thread on here within the last month about an
event script for the MX platform that would do just that.  Going back
to the first section, though, you should think thrice before doing
VPLS - Ivan PepeInjak has some good articles about the hazards of L2
across your wan on his blog.

HTH

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

Re: [j-nsp] Selective packet mode & local traffic

[Wayne Tucker]

On Fri, Aug 10, 2012 at 11:49 AM, Phil Mayers  wrote:
> Unless I'm missing a trick, apply-paths in a prefix list pulls the netmask in 
> when applied to interface ips. This is ok for lo0 filters, but not those on 
> transit interfaces.

Good point.  I remember seeing something about that but I don't
remember the context so I'm not sure whether it was a warning or a
workaround...

It could use some cleanup, but something like this should work:

put the following in /var/db/scripts/commit/local-addresses.slax

version 1.0;

ns junos = "http://xml.juniper.net/junos/*/junos";;
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";;
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";;

import "../import/junos.xsl";

match configuration {
var $top = .;
for-each (policy-options/prefix-list/apply-macro[name =
'local-addresses']) {
var $prefix-list-name = ../name;
for-each ($top/interfaces/interface/unit/family/inet/address) {
var $address = substring-before(name, "/");
 {
 {
 {
 $prefix-list-name;
 {
 $address _ "/32";
}
}
}
}
}
}
}

set system scripts commit allow-transients
set system scripts commit file local-addresses.slax
set policy-options prefix-list local-addresses apply-macro local-addresses

HTH

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

Re: [j-nsp] Information for expected fragmentation behavior on IPsec tunnel

[Wayne Tucker]

It should be dependent on the "df-bit" setting on the VPN.  I don't
remember which behavior is default, but setting it to "clear" may do
what you want.

:w


On Fri, Aug 10, 2012 at 12:36 PM, Terry Jones  wrote:
> Greetings All,
>
>
>
> Could someone please point me in the direction of some good information for
> a current setup I have and would like to know what the expected behavior is.
>
>
>
> I have a site-to-site VPN setup between two SRX's. I'm in a development lab
> that has a static NAT out to the internet through the corporate network.
> (The other lab I'm connecting to is not local). Our connection to the
> corporate network is to an ASA that DOES NOT support jumbo frames. I have
> jumbo frames configured on the st0 interface and all interfaces all the way
> back to the hosts on my side of the network. Same goes for the lab on the
> other side of the tunnel. So I have 9000 bytes configured end-to-end,
> however the transport the tunnel is configured across only supports std 1500
> bytes frames.
>
>
>
> The developers are sending 2000+ bytes sized packets that have the DF bit
> set (and it has to be as such for now).
>
>
>
> I am trying to determine the expected behavior. I've been told that the
> IPsec tunnel will fragment the traffic b/c it will not copy the DF bit from
> the original packet once it is encapsulated, however, I cannot ping through
> the tunnel with large packet sizes and the DF bit set. I've found a lot of
> information and have worked a lot with fragmentation, but can't find
> anything on this exact type of scenario.
>
>
>
> Thanks in advance for any input or information.
>
>
>
> Sincerely,
>
> Terry
>
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Static Route Names

[Wayne Tucker]

It doesn't show up anywhere but the configuration, but what about annotate?

edit routing-options static
annotate route 10.0.0.0/8 "insert comment here"

:w



On Fri, Aug 10, 2012 at 8:44 AM, GIULIANO (WZTECH)
 wrote:
> People,
>
> Besides the use of groups feature on JUNOS, how can name a static route ?
>
> IOS has an option 'name' for static routes ... how can we do the same thing
> in junos ?
>
> Is it possible ?
>
> There is some kind of description ?
>
> Thanks a lot,
>
> Giuliano
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Selective packet mode & local traffic

[Wayne Tucker]

You can probably achieve that using apply-path.  This book has several
good examples:

http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/securing-routing-engine/

:w


On Thu, Aug 9, 2012 at 7:37 AM, Mark Menzies  wrote:
> Yup, we can do selective packet mode using firewall filters.
>
> Its normally applied in the input direction however, note, it needs to be
> on all interfaces where we will see packets that we dont want to send to
> the flow module, ie the reply packets as well
>
> As for a script, sadly dont have one, however if you do get one, I would
> like to have a copy.  :)
>
> On 9 August 2012 15:13, Phil Mayers  wrote:
>
>> All,
>>
>> On the J-series and branch SRX, if you want to use selective packet mode
>> (because you want to do IPSec at the same time as MPLS, for example) then,
>> as I understand it, you need to exclude traffic *to* the box itself from
>> packet mode.
>>
>> Is this correct?
>>
>> Does anyone have a handy op-script that will build a prefix list of all
>> local IPs, to help with automating this?
>> __**_
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/**mailman/listinfo/juniper-nsp
>>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] mpls node-protection: LSP down

[Wayne Tucker]

I've never tried to use node-protection in conjunction with a strict
path - but I suspect the two features are incompatible since the
protection path would disregard the strict path.

Try changing the path from strict to loose.  That allows some
flexibility (though I believe every node in the path must be used, so
it will fail if the node goes down).

If you don't need to use that path, remove the primary statement on
the lsp configuration.

If you do need to use the strict path, configure an alternate strict
path and add it as a secondary under the lsp.  If you don't want it to
fail back automatically then list both as secondary paths.

:w




On Fri, Aug 10, 2012 at 2:02 AM, Mihai Gabriel  wrote:
> This is the topology:
> http://img52.imageshack.us/img52/5512/avpn.png
>
> Sorry
>
> On Fri, Aug 10, 2012 at 11:57 AM, Mihai Gabriel wrote:
>
>> Hello,
>>
>>  I am trying to test the node-protection feature in a lab using an MX5
>> router with logical-systems and I can't find the reason why is not
>> working.The topology I use is here:
>> http://imageshack.us/photo/my-images/849/avpn.png/
>> All routers are configured for mls,rsvp,ospf,link-protection, but when I
>> disable the interface between P1 and PE1, the LSP between PE1 and PE2 goes
>> down and stay that way:
>>
>> Before disabling the interface:
>>
>> mumulox@mx5t> show mpls lsp logical-system PE1 extensive
>> Ingress LSP: 1 sessions
>>
>> 192.168.1.2
>>   From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: pe1-to-pe2
>>   ActivePath: strict-path (primary)
>>   Node/Link protection desired
>>   LSPtype: Static Configured
>>   LoadBalance: Random
>>   Encoding type: Packet, Switching type: Packet, GPID: IPv4
>>   Revert timer: 1
>>  *Primary   strict-path  State: Up
>> Priorities: 7 0
>> OptimizeTimer: 1
>> SmartOptimizeTimer: 2
>> Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node
>> 10=SoftPreempt 20=Node-ID):
>>   192.168.5.1(flag=0x29) 172.22.210.2(flag=9 Label=301600)
>> 192.168.5.2(flag=0x29) 172.22.201.2(flag=9 Label=301472)
>> 192.168.5.3(flag=0x21) 172.22.206.2(flag=1 Label=301200)
>> 192.168.1.2(flag=0x20) 172.22.212.1(Label=3)
>>
>> mumulox@mx5t> show mpls path strict-path logical-system PE1
>> Path nameAddress strict/loose if-id
>> strict-path  172.22.210.2strict
>>
>> mumulox@mx5t> show rsvp session logical-system PE1
>> Ingress RSVP: 2 sessions
>> To  FromState   Rt Style Labelin Labelout LSPname
>> 192.168.1.2 192.168.1.1 Up   0  1 SE   -   301600
>> pe1-to-pe2
>> 192.168.5.2 192.168.1.1 Up   0  1 SE   -   301296
>> Bypass->172.22.210.2->172.22.201.2
>> Total 2 displayed, Up 2, Down 0
>>
>> mumulox@mx5t> show route table inet.3 logical-system PE1 192.168.1.2
>> extensive
>>
>> inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
>> 192.168.1.2/32 (1 entry, 1 announced)
>> State: 
>> *RSVP   Preference: 7/1
>> Next hop type: Router, Next hop index: 1048577
>> Address: 0x2c74010
>> Next-hop reference count: 7
>> Next hop: 172.22.210.2 via ge-1/1/7.100 weight 0x1,
>> selected
>> Label-switched-path pe1-to-pe2
>> Label operation: Push 301600
>> Label TTL action: prop-ttl
>> Next hop: 172.22.211.2 via ge-1/1/7.104 weight 0x8001
>> Label-switched-path Bypass->172.22.210.2->172.22.201.2
>> Label operation: Push 301472, Push 301296(top)
>> Label TTL action: prop-ttl, prop-ttl(top)
>> State: 
>> Local AS: 65512
>> Age: 4:33 Metric: 4
>> Task: RSVP
>> Announcement bits (1): 1-Resolve tree 1
>> AS path: I
>>
>> After disabling the interface:
>>
>> mumulox@mx5t> show mpls lsp extensive logical-system PE1
>> Ingress LSP: 1 sessions
>>
>> 192.168.1.2
>>   From: 192.168.1.1, State: Dn, ActiveRoute: 0, LSPname: pe1-to-pe2
>>   ActivePath: (none)
>>   Node/Link protection desired
>>   LSPtype: Static Configured
>>   LoadBalance: Random
>>   Encoding type: Packet, Switching type: Packet, GPID: IPv4
>>   Revert timer: 1
>>   Primary   strict-path  State: Dn
>> Priorities: 7 0
>> OptimizeTimer: 1
>> SmartOptimizeTimer: 2
>>199 Aug 10 12:04:44.607 Deselected as active
>>198 Aug 10 12:04:44.607 172.22.205.1: Non-RSVP capable router detected
>>197 Aug 10 12:04:44.607 Link-protection Down
>>196 Aug 10 12:04:44.606 Session preempted
>>195 Aug 10 12:04:44.504 172.22.210.1: Tunnel local repaired
>>194 Aug 10 12:04:44.504 172.22.210.1: Down
>>
>> "198 Aug 10 12:04:44.607 172.22.205.1: Non-RSVP capable router detected"
>> seems to be very clear,but it is not, because all routers are rsvp enabled
>>
>> mumulox@mx5t> show rsvp neighbor logical-system P2
>> RSVP neighbor: 3 learned
>>

Re: [j-nsp] OSPF next hop

[Wayne Tucker]

On Tue, Jul 24, 2012 at 12:36 PM, Aaron Dewell  wrote:
> Yes, Type Transit (2).  However, the Network LSA only includes 3 attached 
> routers (should be 6 currently).  There are two Network LSAs in R7.  One has 
> the interface IP of R1 (non-DR/BDR) with 3 attached routers (R1, R5, R6).  
> The other has the interface IP of R2 and shows 3 attached routers (R2, R7, 
> and R8).  The interfaces on R3 and R4 are currently shut down.
>
> Further looking into it, there is disagreement all across this network about 
> who is the DR and BDR.  Half the routers show one set, and half show the 
> other.  I think that might produce some issues!

Wow, that is weird.  If L2 communication is good across the segment
then MTU or authentication mismatch would be my next guess.

It might be worth turning on OSPF tracing, if you haven't done so already:

set protocols ospf traceoptions file ospf-trace.log size 2m files 2
world-readable
set protocols ospf traceoptions flag error detail

There are other flags available, but I've found that "error detail"
almost always provides me the information I need.  At the same time,
it's pretty quiet under normal conditions (so I leave it enabled on
most of my OSPF routers).

:w

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

Re: [j-nsp] Analyser output interfaces - drops, CoS, loss-priority etc.

[Wayne Tucker]

On Tue, Jul 24, 2012 at 1:05 AM, Dale Shaw  wrote:
> - Is there a 'best practice' for CoS config (scheduler-map, mainly)
> for analyser output interfaces? I don't really want any fancy queueing
> on these ports.

I'd say it depends on what else you're doing with CoS on that switch,
though I think I remember reading somewhere that all analyzer frames
were handled as best effort.


> - In the context of an analyser session, is loss-priority low (the
> default) the best bet? Or high? I can't find any good references on
> this - any KB articles either talk about VLANs as outputs (not
> physical interfaces) or loss-priority is set to high in the example
> without any explanation.

If your objective is to keep the mirrored frames from being dropped
then low would be better - though if it's going out a physical
interface then I don't know that it would matter.  On a shared
interface (like what would be used when mirroring to a VLAN), frames
with loss priority set to high should be dropped first (so that
they're less likely to interfere with critical traffic).


> More generally, has anyone gone to the trouble of tuning NICs in
> probes/analyser targets? I would be grateful for any advice there,
> too. Flow control seems to be an obvious one to disable in the 'send'
> direction (from the probe's perspective).

If you're doing any TCP analysis then you'll probably want to disable
most of the offload features on the NIC.  The way they reassemble the
segments plays hell with most tools - you end up seeing large
segments, weird ACKs, etc.  On Linux boxes with Intel 82576 NICs I
use: ethtool -K $IFACE rx off tx off sg off tso off gso off gro off.

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

Re: [j-nsp] OSPF next hop

[Wayne Tucker]

On Mon, Jul 23, 2012 at 11:02 PM, Aaron Dewell  wrote:
> I ran into an odd behavior here tonight, I'm hoping someone has some ideas.  
> We have 8 routers on a broadcast OSPF segment.  All are advertising their 
> loopback addresses (amongst other things).  I'll call this R1 to R8 for now.  
> Their IP addresses on this shared segment are 192.168.0.16X/28 (X 
> corresponding to RX).
>
> R2 is the current DR and R6 is the BDR.  All the priorities are the same, not 
> that it matters.
>
> From R7, all routes to the other routers' loopback address cross R2!  I'm not 
> sure if it's because it happens to be the DR or what.
>
> acd@R7> show route 
>
> inet.0:  destinations,  routes ( active, 0 holddown, 4 hidden)
> + = Active Route, - = Last Active, * = Both
>
> /32  *[OSPF/10] 23:57:02, metric 40045
> > to 192.168.0.162 via ge-0/0/3.200
>
> The metric indicates that the path is: R7->R2->R1->R6, which is proven by the 
> traceroute.  The metric for this broadcast segment is 2 on all routers.  
> The 45 is a 10G interface directly connecting R2 and R1.  The metric of the 
> correct path is exactly 20k (directly connected over this shared segment).
>
> The example is typical, all of the other router's loopback's look the same 
> (except R8 which is it's buddy and directly connected).
>
> Any ideas on what else to look at?  The OSPF database looks reasonable.  Our 
> other shared segments act normal.  All routers are on 11.4R2.

That is odd.  Do all of the routers have a full adjacency with the DR and BDR?

Does each router LSA show a transit link to the ID if the type 2 LSA
for that network (it should show that address in the "data" field)?

:w

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

Re: [j-nsp] DSCP-marked traffic mysteriously being dropped by MX960

[Wayne Tucker]

On Mon, Jul 23, 2012 at 8:02 AM, John Neiberger  wrote:
>
> Well, we have applied the scheduler map to the interface but we're
> still seeing 100% drops in queue 1, which is where CS2 is hitting. It
> is literally dropping every packet in queue 1, but I don't understand
> enough about what I'm seeing to understand why.
>
>  Queue counters:   Queued packets  Transmitted packets  Dropped 
> packets
> 0 HSD, BASIC-D4775 4775   
>  0
> 1 MNGMT, VOIP-49130 
> 4913
> 2 UET, CDN, VO   00   
>  0
> 3 VOIP-BEARER,  81   81   
>  0

It looks like you're mapping multiple classes to the same queue.  I
try to avoid doing that - from what I recall it comes with an added
requirement that all forwarding classes in that queue use the same
scheduler.

I noticed in your previous output that you're setting the
loss-priority for the management traffic to high - are you sure you
want to do that?  It's a little counter-intuitive, but loss-priority
high is the traffic you want to drop before low (or medium, etc.).
Depending on the drop profile used it's pretty much guaranteed to not
get any resources in cases like this where there is no applicable
scheduler (the aggressive settings keep the packets from even getting
into a queue).  In fact, it's probably why you're seeing these drops
in the first place - the drop profile for loss-priority low is usually
liberal enough that the packets still get queued and forwarded.

> classifiers {
> dscp DSCPV4-CLASSIFIER;

Can you paste the config for DSCPV4-CLASSIFIER?

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

Re: [j-nsp] DSCP-marked traffic mysteriously being dropped by MX960

[Wayne Tucker]

Does show interfaces  extensive on the interface between Router A and
Device A show any drops?  IIRC, the default scheduler map does not define
schedulers for anything other than be and nc - so if you're classifying the
packets on input then it could be that they're going to a class that has no
resources on the egress interface.

:w


On Fri, Jul 20, 2012 at 2:15 PM, John Neiberger wrote:

> We have packet captures going at the endpoints, but not in between,
> unfortunately. It would be nice if we had a sniffer at that location
> so we could mirror the ports and get some data there.
>
> The inbound filter on Router C looks like this:
>
> term netmgmt {
> then {
> count fec-cs2;
> loss-priority high;
> forwarding-class MNGMT;
>
> Elsewhere, MNGMT is defined as cs2.
>
> The outbound filter on Router A toward the end device is very long,
> but the first two terms should allow ICMP and traceroute from the
> address space that Device B is in. Further down in the filter is
> another term that specifically permits CS2, among other things. We
> know that that filter is working because when we remove the ingress
> marking filter everything starts working, which indicates that the
> outbound filter on Router A is correctly matching the source IP
> address of Device B. I'd like to post more of the config, but I'm
> trying to keep it sanitized and anonymous.  :)  I don't want to
> irritate any bosses by posting our configs publicly.
>
> Thanks,
> John
>
> On Fri, Jul 20, 2012 at 3:04 PM, OBrien, Will 
> wrote:
> > Have you captured traffic before and after to validate the marking?
> > Relavent config bits would help.
> >
> > On Jul 20, 2012, at 3:56 PM, John Neiberger wrote:
> >
> >> We've been troubleshooting a strange problem for a few days. JTAC is
> >> on the case, too, but we have not found any resolution. I thought
> >> maybe picking some minds here would be helpful. Here is a simplified
> >> diagram:
> >>
> >> [Device A] ---   [Router A] ---  [Router B] --- [Router C]
> >> - [Device B]
> >>
> >> The problem is that packets from Device B to Device A are being
> >> dropped at Router A. Routers A and C are MX960s. Router B is a CRS.
> >> Router C has an ingress firewall filter that does nothing but mark
> >> traffic as cs2. Router A has an egress firewall filter toward Device
> >> A, but it specifically allows the source IP address of Device B as
> >> well as any traffic marked as cs2.
> >>
> >> Here is where it really gets weird. If we remove the filter on Router
> >> C that marks the traffic, everything starts working. Put the filter
> >> back in place and the traffic stops. We've been looking at this for a
> >> couple of days and JTAC has spent a few hours looking at it and we're
> >> still no closer to figuring out why cs2 traffic is being dropped. With
> >> the filter in place, traceroutes from Device B to A stop at Router A.
> >> Remove the marking filter and traceroutes complete and pings start
> >> succeeding.
> >>
> >> Can any of you think of a potential culprit that we're not seeing? I
> >> would hope that if this were something obvious, JTAC would have caught
> >> it by now. We're all stumped.
> >>
> >> Thanks!
> >> John
> >> ___
> >> juniper-nsp mailing list juniper-nsp@puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] root-login via ssh and 11.x

[Wayne Tucker]

On Tue, Jun 26, 2012 at 8:32 AM, Nick Kritsky wrote:

> To all:
> sorry for misinformation. It looks like change in root authentication
> behavior was caused not by JunOS upgrade, but by change from
> "system authentication-order [ tacplus password ]"
> to
> "system authentication-order tacplus"
>
> I have to be more careful.
> Still, I can't understand the logic behind this.
> "system authentication-order [ tacplus password ]" == root can login
> "system authentication-order tacplus" == root cannot login
> "system authentication-order tacplus" + "system services ssh
> root-login allow" == root can login
>

That is interesting.  The root-login option causes the PermitRootLogin in
the OpenSSH sshd config (/var/etc/sshd_config) to be changed (not set = not
set; allow = yes, deny-password = without-password, deny = no).

The authentication-order command causes /etc/pam.conf to be changed.
 Here's what it looks like with [ tacplus password ] on a 10.4 box in my
lab:

su auth sufficient pam_rootok.so no_warn
su auth sufficient pam_self.so   no_warn
su auth requisite  pam_group.so  no_warn group=wheel fail_safe root_only
su auth required   pam_unix.so   try_first_pass
login   authsufficient  pam_tacplus.so
conf=/var/etc/pam_tacplus.conf template_user=remote  try_first_pass
no_warn
login   authrequiredpam_unix.so try_first_pass no_warn
login   session requiredpam_permit.so
login   account requiredpam_unix.so

With the password option removed, the third line changes to:

login   authrequiredpam_unix.so local_fallback no_warn

With authentication-order not set the tacplus lines go away and the login
line instead reads:

login   authrequiredpam_unix.so

I can't find anything in the PAM documentation about local_fallback so I'm
guessing that's a Juniper extension.

The best hypothesis I've been able to come up with so far is that the
PermitRootLogin yes option allows sshd to authenticate root through some
other mechanism, though even that doesn't seem to fit all of the facts.

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

Re: [j-nsp] root-login via ssh and 11.x

[Wayne Tucker]

On Tue, Jun 26, 2012 at 5:09 AM, Nick Kritsky wrote:

> FYI: It looks like in version 11 Juniper has changed default settings
> for "system services ssh root-login".
> Now if you want to login as root via ssh, you have to explicitly allow
> it. in 10.X it was allowed by default.
> Tested on EX-4200, SRX-100.


I can't reproduce this on any of these:

EX4200 running 11.4R2
EX4200 running 11.3R6
SRX240 running 11.2R6
SRX240 running 11.2S6
MX80 running 11.4R3

Are you using a RADIUS server?  What setting are you using for
system/authentication-order, if any?

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

Re: [j-nsp] Firewall best practices

[Wayne Tucker]

On Mon, Jun 11, 2012 at 5:04 PM, Ben Dale  wrote:

> What would really help though is if Junos allowed multiple address-books
> to be bound to a single zone - that way, SRXs buried deeper in your network
> would have access to all address-book entries on a single upstream zone
> with very little configuration management.  I'm sure this concept would
> make tools like Space and NSM easier to use as well - Juniper SRX PLMs are
> you listening out there?  SAVE US!
>
>
It takes some getting used to, but this can be accomplished through
configuration groups:

Here's a vanilla address book on a Junos 10.4 box:

# show security zones security-zone trust address-book
address ironman 192.168.0.16/32;
address knife 192.168.0.8/32;

Create a couple of groups and apply them:

# set groups group1 security zones security-zone trust address-book address
address1 192.168.0.1/32
# set groups group2 security zones security-zone trust address-book address
address2 192.168.0.1/32
# set apply-groups [ group1 group2 ]

And now the address book contains the additional entries:

# show security zones security-zone trust address-book | display
inheritance
address ironman 192.168.0.16/32;
address knife 192.168.0.8/32;
address inet6:sandman 2001:470:ea7c:0:221:6aff:fe66:bdcc/128;
##
## 'address1' was inherited from group 'group1'
## '192.168.0.1/32' was inherited from group 'group1'
##
address address1 192.168.0.1/32;
##
## 'address2' was inherited from group 'group2'
## '192.168.0.1/32' was inherited from group 'group2'
##
address address2 192.168.0.1/32;

An added bonus of having the address book (or almost other configuration)
in a group is that you can use "load replace" (or the equivalent in the XML
API) to keep it consistent when you distribute it around.  Add a few more
layers and you could have a fully fledged system for managing any
configuration bits on a device.

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

Re: [j-nsp] Cisco IGP fast convergence

[Wayne Tucker]

On Tue, May 29, 2012 at 3:19 AM, Wan Tajuddin Wan Hussin  wrote:

> We are planning to deploy MX in our all Cisco network. However, my tech
> team are not comfortable with mismatch LSA timer which MX unable to
> configure certain parameter.
>
> At the moment we are using the following setting on Cisco.
>
>
>  timers throttle spf 50 50 5000
>  timers throttle lsa 0 20 5000
>
> Has anyone deploy this type of setting and successfully integrate with
> Juniper without any issue.
>

These timers throttle SPF runs and LSA flooding.  I don't recall anything
for controlling the latter in Junos, but there are some knobs under
protocols/ospf/spf-options that accomplish results similar to the former.

That being said, you may not need to tweak anything on Junos.  The IOS
defaults tend to be conservative because they are designed for older/slower
hardware, whereas Junos was designed with the assumption that the control
plane would be separate and would have reasonable processing power
available.

If you're concerned about transient loops then loop free alternates are
better use of your resources.  They don't prevent transient loops (nothing
can), but they allow the forwarding plane to compensate for certain link
failures.

You should also look into BFD (as Doug mentioned), though that's a solution
for a different problem.

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

Re: [j-nsp] Document Update - EX Features

[Wayne Tucker]

On Thu, May 3, 2012 at 9:18 PM, Skeeve Stevens <
skeeve+juniper...@eintellego.net> wrote:

> Does anyone know who we hassle to get a document updated?
>
> Specifically:
>
> http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html


Use the "Rate and give feedback" widget at the top of the page - it has
worked for me in the past.

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

Re: [j-nsp] Testing a license

[Wayne Tucker]

On Tue, May 1, 2012 at 7:14 AM, Skeeve Stevens <
skeeve+juniper...@eintellego.net> wrote:

> I am suggesting a "One year security subscription for Enterprise - includes
> Sophos AV, Enhanced WF, Sophos AS , and IDP on SRX 240" for the SRX240.
>
> But, I want to test the configuration locally here in Australia.
>
> Can I put the licensing on my SRX240 in my lab, configure everything up,
> then remove it for installation in the remote country by our local guys?
>

No (as others have already mentioned), but if memory serves you can get a
trial license that will last 30 days - you might even be able to do that
once/year per device.

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

Re: [j-nsp] Juniper SFP's

[Wayne Tucker]

On Tue, Apr 24, 2012 at 6:02 PM, Skeeve Stevens <
skeeve+juniper...@eintellego.net> wrote:

> There is likely to be no difference, but will JTAC tell me to get lost if I
> use an EX one in an SRX or MX or vice versa?
>

At one point I was using LX optics from one platform in another (I think it
was MX in SRX, but that could be backwards).  They worked fine, but DOM was
showing really odd values (33 volts, module temperature of several hundred
degrees, etc.).  The counters looked normal once I switched them out for
the "right" optics.

They were third party optics but they were programmed for those platforms.
 I don't have any Juniper optics in that variety so I don't know whether
they'd behave the same.



> Does anyone have experience with the compatibility of the generics?
> Agilestair or so on?  I really am happy to sell genuine Juniper SFP's, but
> why the hell are there different codes for each one?  Why am I waiting for
> stock for 3 weeks for an SRX one when they have 163 EX ones.
>

I've had good luck with Approved Optics.  I try to stick with Juniper on
devices that have a lot of optics (since it would be a pain to change them
all out if JTAC tried to blame the optics for a problem), but I might
change that strategy if I had enough devices to warrant sparing Juniper
optics (for JTAC-compatible changeouts) in appropriate quantities.

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

Re: [j-nsp] redistribute iBGP learned routes

[Wayne Tucker]

On Sun, Apr 22, 2012 at 9:56 AM, Matthias Brumm  wrote:
> customer --- eBGP --- access router --- iBGP --- core router --- iBGP
> --- edge router --- eBGP --- transit
>
> How would you establish this? I do not want an iBGP connection from
> access to edge. The only way I see at the moment, is to configure
> edge-routers as route-reflector-client, but that seems to be a rather
> unclean setup.

Your choices for IBGP are 1.) full mesh or 2.) set up route reflection
(in the core or another device depending on what you've got to work
with).

Is there any particular reason you don't want IBGP between access and edge?


> Should I redistriute the customers prefixes in OSPF
> between access and core and advertise them from core to edge via iBGP?

I wouldn't - especially if the customer isn't using a private ASN.


> Maybe there is a policy-statement to achieve this?

I'm not aware of any way to make a non-reflector router advertise
prefixes to an IBGP peer that it learned from another IBGP peer.  Even
if I did, I would neither use it nor recommend its use.

> What would be the best practice here?

small scale: full mesh
medium scale (no firm definition - just a matter of when maintaining
(n**2-n)/2 sessions gets to be troublesome for your environment):
route reflectors
large scale: lots of ways.. may involve route reflectors,
confederations, MPLS and BGP-free core, etc.

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

Re: [j-nsp] Stacking cable sizes

[Wayne Tucker]

On Thu, Mar 15, 2012 at 10:37 AM, Keegan Holley
 wrote:
> The juniper website doesn't seem to have exact lengths or part numbers for
> the "small", "medium" and "large" stacking cables described in the hardware
> guides.  Just wondering if anyone on the list knew the length of each
> cable.  I was also curious if the cable that comes with the switch is small
> or medium.

Others have provided the lengths and part numbers so I'll leave that out.

With each increase in length the cables get substantially thicker and
(at least in the case of >50cm - haven't ever priced that one) double
in price.

I don't know if the current docs cover this, but looping the included
cable between vcp-0 and vcp-1 on a standalone EX4200 gives you a
second path between PFEs (which can save you a hop across a PFE in
some cases).  That, plus it's a great place to store it in case you
might need it later.

:w

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