Re: [j-nsp] igmp snooping layer 2 querier breaks ospf in other devices
I thought this was asked, but don’t recall an answer, what’s the point of turning on a querier if the switch is already a PIM router? You don’t need an IGMP snooping querier if it’s a multicast router. On Fri, Feb 2, 2024 at 8:21 AM Aaron Gould via juniper-nsp < juniper-nsp@puck.nether.net> wrote: > I tried to recreate the scenario in my lab with no success > > 21.2R3-S4.8 - in lab - problem not seen > 20.2R3-S7.3 - in lab - problem not seen > 19.2R3-S6.1 - in lab - problem not seen > 18.3R3-S6.1 - in lab - problem not seen > 17.4R2-S11 - in lab - problem not seen > > 17.4R2-S11 - in field - problem seen > > > again, the problem is, when i enabled this command... > > set protocols igmp-snooping vlan vlan100 l2-querier source-address > 10.100.4.1 > > ...a customer riding an l2circuit on ge-0/0/2 report to me that their > multicast stops working... ospf goes down and stays in INIT... > > when i remove all pim and igmp, then there OSPF neighbors up and stabilizes > > i just don't know how running igmp inside vlan 100 with ports ge-0/0/4, > 5 and 6 would have anything to do with an l2circuit on ge-0/0/2 > > > -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
Re: [j-nsp] MX304 - Edge Router
I think the key here is that the OP had evaluation licenses. Those are timed and things stop working when they expire. Purchased license are permanent and do not expire. On Wed, Oct 25, 2023 at 6:18 AM Mark Tinka via juniper-nsp < juniper-nsp@puck.nether.net> wrote: > > > On 10/25/23 14:42, Saku Ytti via juniper-nsp wrote: > > > But we can reject licenses that expire in operation and cause an > > outage. That I think is a very reasonable ask. I know that IOS XE for > > example will do this, you run out of license and your box breaks. I > > swapped out from CRS1k to ASR1k because I knew the organisation would > > eventually fail to fix the license ahead of expiry. > > We had this happen to us in 2014 when we recovered a failed server > running CSR1000v. The "installation evaluation" license expired after 60 > days, and since everyone forgot about it, the box went down. > > So as part of our deployment/recovery procedure, we always procure > CSR1000v licenses for each installation. > > Of course, with things changing to Cat8000v, this could get juicy. > > > > I'm happy if the device calls homes via https proxy, and reports my > > license use, and the sales droid tells me I'm not compliant with > > terms. Making it a commercial problem is fine, making it an acute > > technical problem is not. > > > > > > In your specific case, the ports never worked, you had to procure a > > license, and the license never dies. So from my POV, this is fine. And > > being absolutist here will not help, as then you can't even achieve > > reasonable compromise. > > I tend to agree. > > Mark. > ___ > 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] Junos 21+ Killing Finger Muscle Memory...
I find it kind of telling that customers are just getting around to
complaining about it two years after it was released. Not at all
surprising, but illustrates how slow network operators update cycles can be
compared to the pace of development.
To the Junos developers, this is ancient news, long forgotten in the dozens
of sprints and multiple releases since.
On Wed, Jul 12, 2023 at 2:13 PM Andrey Kostin via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> Hi Mark,
> 100% agree if it could help.
> Very annoying. If UX designer touched it, he or she probably never
> actually worked with Junos.
>
> Kind regards,
> Andrey
>
> Mark Tinka via juniper-nsp писал(а) 2023-07-12 04:49:
> > So, this is going to be a very priviledged post, and I have been
> > spending the last several months mulling over even complaining about
> > it either on here, or with my SE.
> >
> > But a community friend sent me the exact same annoyance he is having
> > with Junos 21 or later, which has given me a final reason to just go
> > ahead and moan about it:
> >
> > tinka@router> show rout
> > ^
> > 'rout' is ambiguous.
> > Possible completions:
> > routeShow routing table information
> > routing Show routing information
> > {master}
> > tinka@router>
> >
> > I'm going to send this to my Juniper SE and AM. Not sure what they'll
> > make of it, as it is a rather priviledged complaint - but in truth, it
> > does make working with Junos on a fairly historically commonly used
> > command rather cumbersome, and annoying.
> >
> > The smile that comes to my face when I touch a box running Junos 20 or
> > earlier and run this specific command, is unconscionably satisfying
> > :-).
> >
> > Mark.
> ___
> 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] Advertising inactive routes to iBGP neighbors
I don't quite understand. Why don't you just export the static into your routing protocol? How is the static route a "fallback" if it is really the active route? On Sun, Apr 17, 2022 at 8:57 AM James via juniper-nsp < juniper-nsp@puck.nether.net> wrote: > > > > -- Forwarded message -- > From: James > To: juniper-nsp@puck.nether.net > Cc: > Bcc: > Date: Sun, 17 Apr 2022 10:49:44 -0500 > Subject: Advertising inactive routes to iBGP neighbors > Hi all, > > I have two routes in inet.0, neither of which come from BGP: > > 10.200.7.2/32 *[Static/5] 00:14:40 > > to 10.200.7.2 via irb.102 > [EVPN/7] 00:08:25 > > via irb.102 > > I want to advertise the 'EVPN/7' route, either alongside or completely in > place > of the 'Static/5' route. The particular use case here is EVPN-VXLAN virtual > machine traffic optimization, where I want to advertise the EVPN route > with a > higher localpref to steer traffic towards one or more particular leaf > switches > while still advertising the static route as a fallback in case the EVPN > route > is not there. Normally this works because the attached prefixes are longer > than > a /32, but I just can't seem to figure out how to make this work with /32 > statically routed prefixes. > > I've already tried several methods including rib-groups to bring the route > into > another table (no support for rib-groups with EVPN routes), bgp add-path > (doesn't advertise the second path), and playing with route preferences > (static route needs to be the active route for forwarding purposes), but > none > of those have been successful. > > Any other suggestions on how I could achieve this? > > Thanks, > James > > > > -- Forwarded message -- > From: James via juniper-nsp > To: juniper-nsp@puck.nether.net > Cc: > Bcc: > Date: Sun, 17 Apr 2022 10:49:44 -0500 > Subject: [j-nsp] Advertising inactive routes to iBGP neighbors > ___ > 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] Configuring of MACsec for three EX4300 Switches
MACsec (802.1AE) is NOT limited to point-to-point connections.
However, many vendors have partial implementations which do have such
limitations. Juniper devices' support varies greatly by hardware platform
and software versions.
On Thu, Nov 5, 2020 at 8:06 AM Richard McGovern via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
>
>
>
> -- Forwarded message --
> From: Richard McGovern
> To: "switch...@tutanota.com"
> Cc: "juniper-nsp@puck.nether.net"
> Bcc:
> Date: Thu, 5 Nov 2020 16:05:20 +
> Subject: Re: Configuring of MACsec for three EX4300 Switches
> MACSEC is pt-to-pt so is your plan to run MACSEC from Point A to EX4300
> and then connect same EX4300 to Point B - two different and independent
> MACSEC connections?
>
> If you want pass-through of one session you will need to create some sort
> of tunnel between EX port A to port B -(internal maybe GRE 'might' work.
> This is not like say IPSec connections.
>
> Good luck. Please reply if you find a solution.
>
> Rich
>
> Richard McGovern
> Sr Sales Engineer, Juniper Networks
> 978-618-3342
>
> I’d rather be lucky than good, as I know I am not good
> I don’t make the news, I just report it
>
>
> On 11/5/20, 6:09 AM, "switch...@tutanota.com"
> wrote:
>
> Hi,
>
> following only the required configuration of
>
> https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/macsec-configuring-mx-series.html
> for
> # Configuring MACsec Using Static Connectivity Association Key (CAK)
> Mode
>
> works fine for two switches, but with a third EX4300 in the middle not.
>
> Thus, could anyone please help what is required to ensure connectivity
> through
> three EX4300?
>
> Even the configuration (A; with several tries) on the outer sides
> switches such as
> e.g. given for (one port) per switch
> jack@cs2# set security macsec connectivity-association ca1 mka
> eapol-address provider-bridge
> jack@cs2# set security macsec connectivity-association ca1 mka
> eapol-address lldp-multicast
> jack@cs2# set protocols layer2-control mac-rewrite interface
> ge-0/0/13 protocol ieee8021
> worked not for the three EX4300.
>
> Tunneling through a EX4200, in the middle (via vlan, snippet see
> below) worked fine, even without the
> configuration (A) at the outer sides switches, only with the most
> important commands
> given in
> https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/macsec-configuring-mx-series.html
> .
>
> Any idea why tunneling through the middle EX4300 failed? (Used
> version: 17.3R3-S9.3!)
>
> Regards,
> Jack
>
>
> # PS: What is the equivalent code for EX4300 from the EX4200 code
>vlan-id 55;
>dot1q-tunneling {
>layer2-protocol-tunneling {
>all;
>}
>
>
>
> Juniper Business Use Only
>
>
>
> -- Forwarded message --
> From: Richard McGovern via juniper-nsp
> To: "switch...@tutanota.com"
> Cc:
> Bcc:
> Date: Thu, 5 Nov 2020 16:05:20 +
> Subject: Re: [j-nsp] Configuring of MACsec for three EX4300 Switches
> ___
> 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] SRX300 Sudden Reboot
If it's a model with an external power brick, replace the power supply. For random reboots, one of the first things I check is the power supply. On Sun, Oct 25, 2020 at 1:45 PM Mohammad Khalil wrote: > Thanks all for the kind replies. > Adding to that , the FW got hanged and I cannot access it remotely unless > it is rebooted manually. > It keeps working for couple of days and then it is back again to hang > status. > Current SW version is 15.1X49 > > Any recommendations ? Should I do an upgrade? > > BR, > Mohammad > > On Fri, 23 Oct 2020 at 01:31, wrote: > > > I'd check for any firmware bugs that may have been triggered and caused a > > reboot. > > > > On Oct 22, 2020 15:22, Emille Blanc > wrote: > > > > What was the reported reboot reason? > > You will find that in 'show chassis routing-engine' > > > > -Original Message- > > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf > > Of Mohammad Khalil > > Sent: Thursday, October 22, 2020 3:13 PM > > To: Juniper List > > Subject: [j-nsp] SRX300 Sudden Reboot > > > > Greetings > > I have SRX300 which is running normally for long time except for the last > > two weeks where I have suffered from sudden reboot. > > Model: srx300 > > Junos: 15.1X49-D70.3 > > JUNOS Software Release [15.1X49-D70.3] > > > > Nothing has been changed or added and nothing in the log messages is > > related to this. > > As well , no active alrams and temperature levels are fine: > > tbzadmin@FW-PB-NEW# run show chassis environment > > Class Item Status Measurement > > Temp Routing Engine OK 45 degrees C / 113 > degrees > > F > > Routing Engine CPU OK 58 degrees C / 136 > degrees > > F > > Power Power Supply 0 OK > > > > What could be the issue? > > > > Much appreciated. > > ___ > > 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
Re: [j-nsp] Mirroring IPv6 neighbor advertisements
Maybe you should be looking at DHCPv6 if you want those kinds of logs. On Fri, Mar 22, 2019 at 2:19 PM Jason Healy wrote: > > We're starting to play around more with IPv6, and one thing we're missing is > a log of who has which address. In IPv4 we have DHCP and can check the logs, > but we're using SLAAC for v6 so that's not an option. > > I set up a quick trunk interface with all our VLANs as members and started > sniffing. While I'm seeing plenty of neighbor discoveries, I'm not seeing > any(?) neighbor advertisements. I'm guessing that because the sniffing box > doesn't have an address on each VLAN, it's not participating in ND and > registering for multicast, so we're getting pruned. IGMP snooping is on by > default on all VLANs. > > I'd prefer not to have to add an interface on each VLAN just to grab all this > traffic (more to keep in sync, security concerns, etc). Is there a way to > tell the switch to force IPv6 multicast traffic for ff02::1 to go to a > specific port? Our core is a QFX5100; the other switches in the network are > a mix of EX3200/4200/3400. > > For the moment I've got it to work by setting up firewall filters on each > VLAN in our core and port-mirroring just the ICMPv6 (type 136) traffic to a > monitoring port. That works, but it's also a lot of configuration overhead. > If there's a better way, I'd love suggestions! > > Thanks, > > Jason > ___ > 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] OSPF Confusion
On Thu, Feb 27, 2014 at 02:23:17PM -0600, Eduardo Barrios wrote: Hi Christ, This from Juniper about exporting into ospf and metrics: http://www.juniper.net/techpubs/en_US/junos13.1/topics/concept/ospf-routing-external-metrics-overview.html So if you exported your static routes into OSPF they will be a Type 2 external metric (you can check with show ospf database external detail), use only external cost and not take into account the link-state metric in your diagram. I'm pretty sure that's not how it works. Think about the case where you have the same external route imported in multiple places. How would OSPF decide which route to take? That explanation of type-1 versus type-2 is misleading. For a type-2 route, the path to the best (lowest metric) type-2 LBA is the best path to that LBA's ASBR. So in my case, the best path from R3 to R2 (the ASBR for the external routes) is through R1 (at least that's how it looks to me). I have tried changing all of the external routes to be imported as type-1, and I get the exact same result. But being able to see all of the metrics did show some interesting things. I was playing with costs, trying to make them reflect the inverse-bandwidth model better, when I noticed that this, 11 R1 - R2 \ /20 \10 / \ / \ / \ / 10\ /50 R3 Set of metrics got me the behavior I wanted. From R3, the next hop for external routes off of R2 was R1. I was running with type-1 externals, so the path metric shows up. The metric for one of those externals is 32. So that is elucidating in one way. Now I see why, when the cost for R2-R3 equals the the cost for R3-R2, that the R3-R2 link is the best next hop. The metric is 10+1+(cost on that link) versus just (cost on that link). But in another way, I'm still confused. Why does the cost for R2-R3 come into the calculation of the cost for R3-R2 at all. I think I'm missing some basic understanding of OSPF. I'll also add that when I purposely break the R1-R3 link, the protocol does not seem to deal with it at all. So, yeah, I really seem to be lost on traffic engineering in OSPF. * You might have to write an export policy: from protocol static + any route-filter that you need, then accept and also add metric xx Thanks, Eduardo Eduardo Barrios, EIT, JNCIP-SP Telecommunications Specialist Lower Colorado River Authority | 3505 Montopolis Dr. | Austin, TX 78744 512.730.6332 ph -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Crist Clark Sent: Tuesday, February 25, 2014 5:12 PM To: juniper-nsp@puck.nether.net Puck Subject: [External] [j-nsp] OSPF Confusion . The problem is that R3 sees R2 as the best next hop for all of the statics on R2. I don't understand why. The cost of the path from R3 to R2 is lowest via R1, 11 vs. 20, right? . ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] OSPF Confusion
This may be something simple, but I've been staring at it a while and am confused now. I have a rather simple network, 11 R1 - R2 \ /20 \10 / \ / \ / \ / 10\ /20 R3 The numbers are the OSPF metrics for each interface. The R1-R2 link is 10 Gbps. The interface metric is manually set to 1 on R1 and R2. The other two links are both 1 Gbps media, but the R1-R3 is limited to 500 Mbps and the R2-R3 to 100 Mbps by their respective carriers. (Well, not really. This is a lab set up meant to simulate the real network.) I've used the 10 and 20 metrics on the interfaces as shown to tell OSPF something about that. What I want to happen is all traffic from R3 to go to both R1 and R2 via the R1-R3 link unless that link is down. With the costs configured as they are, I would think it would do that, but it's not working for R3. This is all a NSSA. R3 is distributing a default route into the area. Both R1 and R2 are importing static routes into the area. The routing on R1 and R2 works how I want. R2 sees R1 as the best next hop for the default and all of R1's statics. R1 sees R3 as the default next hop and sees R2 as best for all of R2's statics. The problem is that R3 sees R2 as the best next hop for all of the statics on R2. I don't understand why. The cost of the path from R3 to R2 is lowest via R1, 11 vs. 20, right? R3 is a EX4500/4200 chassis running 11.1R3.5. In trying to troubleshoot this, I'm also a bit baffled by the router LSA that R3 is sending out to the area. Here's the IP info for the links, R1-R2: 160.33.151.85-160.33.151.86/30 R1-R3: 10.56.1.14-10.56.1.1/28 R2-R3: 10.56.1.22-10.56.1.17/29 But when I look at the LSA for itself in R3's database, OSPF database, Area 0.0.0.1 Type ID Adv Rtr Seq Age Opt Cksum Len Router *10.56.1.110.56.1.10x8030 2005 0x20 0x9786 48 bits 0x2, link count 2 id 10.56.1.1, data 10.56.1.1, Type Transit (2) Topology count: 0, Default metric: 10 id 10.56.1.17, data 10.56.1.17, Type Transit (2) Topology count: 0, Default metric: 20 Topology default (ID 0) Type: Transit, Node ID: 10.56.1.17 Metric: 20, Bidirectional Type: Transit, Node ID: 10.56.1.1 Metric: 10, Bidirectional Gen timer 00:09:48 Aging timer 00:26:35 Installed 00:33:25 ago, expires in 00:26:35, sent 00:33:23 ago Last changed 00:36:20 ago, Change count: 22, Ours It looks like its listing itself in as its neighbors? Wha'? The other devices' router LSAs look like I expect. BTW, the other two routers are Palo Alto Networks firewalls. Like I said, I'm probably missing something easy. Haven't done much OSPF in JUNOS or tried much traffic shaping before. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Resetting SFP+ Remotely
I have a problem with some SFP+ modules that are going down. It looks like they just stop transmitting after hours or days up. I think it's just a case of a batch bad hardware. All of the modules are from the same OEM and have very close serial numbers. Other modules in the same EX-4500 chassis work fine. We're replacing them as we come across problems. However, the troubled switch and modules are at a remote site, and it takes time to replace them. We found that removing and reseating the module in the chassis will bring it back up again for a few hours or days. It buys us some time to get to parts to the remote DC to do the work. We'd like a bandaid procedure to mimic that from the CLI. We've tried setting the interface to disabled in the configuration, commit, remove disabled, and commit, but that doesn't bring it back. Similarly, we've tried doing a ifconfig down from the shell, but that doesn't work either. Is anyone aware of some JUNOS CLI or shell-foo on an EX-4500 chassis to reset SFP+ modules just as if you actually removed the module from the chassis and slid it back in? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Interface group based on description
If you want to start down the commit script rabbit hole to do this, here is a good start: http://www.juniper.net/us/en/community/junos/script-automation/library/configuration/backbone-mtu/ On Wed, Oct 30, 2013 at 2:50 PM, Brad Fleming bdfle...@gmail.com wrote: Does anyone know any tricks for creating a grouping of interfaces based on the description attached? For example: Any logical interface with the label “BACKBONE to far-node” goes into a group that could then be referenced in OSPF, LDP, RSVP, etc. An interface-range is close but doesn’t allow you to reference a tagged link; it expands it’s members only to ge-0/0/0.0 even if other units are configured within the range. Interface-sets are not allowed to be referenced in protocol configuration as near as I can tell. I’d really love a way to provision an interface, label it with “BACKBONE” or “CPE”, and have that label automatically configure the interface for the proper protocols. It’d really eliminate mistakes when turning up new tail circuit locations. Any suggestions or pointers would be greatly appreciated! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Spanning Tree Inconsistent State
I am a little confused about the spanning tree state on an EX4200 VC,
running 11.4R5.5.
{master:0}
cjc@dmz4200 show spanning-tree bridge
STP bridge parameters
Context ID : 0
Enabled protocol: RSTP
Root ID : 32768.88:e0:f3:77:53:81
Hello time: 2 seconds
Maximum age : 20 seconds
Forward delay : 15 seconds
Message age : 0
Number of topology changes: 20
Time since last topology change : 3661899 seconds
Topology change initiator : xe-0/1/0.0
Topology change last recvd. from : 88:e0:f3:74:51:6a
Local parameters
Bridge ID : 32768.88:e0:f3:77:53:81
Extended system ID : 0
Internal instance ID: 0
{master:0}
cjc@dmz4200 show spanning-tree interface
Spanning tree interface parameters for instance 0
InterfacePort IDDesignated Designated PortState Role
port IDbridge ID Cost
ge-0/0/0.0 128:513 128:513 32768.88e0f3775381 2 FWDDESG
ge-0/0/47.0128:560 128:560 32768.88e0f3775381 2 FWDDESG
xe-0/1/0.0 128:609 128:609 32768.88e0f3775381 2000 FWDROOT
xe-0/1/2.0 128:611 128:611 32768.88e0f3775381 2000 FWDDESG
ge-1/0/0.0 128:625 128:625 32768.88e0f3775381 2 FWDDESG
ge-1/0/47.0128:672 128:672 32768.88e0f3775381 2 FWDDESG
xe-1/1/0.0 128:721 128:776 32768.50c58dac4c81 2000 BLKALT
xe-1/1/2.0 128:723 128:723 32768.88e0f3775381 2000 FWDDESG
So what I'm confused about is that the show spanning-tree bridge output
says that this switch is the root bridge, yet the per-interface output
indicates that there are ROOT and ALT ports. Also, the bridge ID for the
ROOT port is the switch itself? Whereas the ALT port is what I would
expect, except that it again seems to contradict the idea that this switch
is the root bridge.
I think my RSTP on this switch is in some messed up state? When I turn on
traceoptions for rstp, I see sucpicious stuff like,
Oct 2 11:26:59.532378 PISM: Port xe-1/1/0.0: IMPOSSIBLE EVENT/STATE
Combination Occured
Oct 2 11:26:59.532396 PISM: Event routine returned FAILURE
Oct 2 11:26:59.532414 MSG: RstPortInfoMachine function returned FAILURE!
Oct 2 11:26:59.532441 RECV: PortReceiveStateMachine Action returned
FAILURE!
Oct 2 11:26:59.532467 MSG: RstPortReceiveMachine function returned FAILURE!
Oct 2 11:26:59.532493 MSG: RstHandleInBpdu function FAILED!
Is there a low risk way to reset RSTP on a production switch?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] LACP to NetApp
We have a mixed virtual chassis of two EX4500s and two EX4200s. They
are connected to
two NetApp filers. Each filer has a LACP aggregate to the VC
consisting of two 10-Gig links
to each of the 4500s (so four xe interfaces in each one). Once things
are up and running,
it works fine, but things do not always come up cleanly after one of
the filers does a
hand back or reboots.
The problem happens most times, but not every time. It happens with
both controllers. It
does not happen to the same physical link in a bundle each time, and
it does not happen
only with links associated with one of the 4500 chassis. That seems to
imply a software
problem, not physical.
The trouble is one of the links in a bundle will end up stuck in the
Defaulted state as
seen from show lacp interfaces output. The symptom seen to the
network users is that
connectivity to specific machines on a network are lost, something
like the host with
192.168.2.100 is reachable, but 192.168.2.99 is not. I think this has
to do with the hashing
to chose a link in the LACP. The combinations that get sent to the
Defaulted link are
being lost, while others work.
From the Juniper EX side, the problem looks like the system is not
receiving any LACPDUs
on the affected link. The show lacp statistics interfaces counters
are not incrementing for
Rx PDUs. However, we have not been able to determine whether the
problem is that the
NetApp is not sending PDUs, or the Juniper is not processing them.
Recovery from the condition is easy. On the switch side, the interface
in the Defaulted
state is manually downed and upped,
# ifconfig xe-0/0/6 down
# ifconfig xe-0/0/6 up
And the LACP happily completes proper negotiations.
We have been trying to work with JTAC and NetApp support. The problem
has been finding
downtime to reboot the filers.
Both Juniper and NetApp have said they have seen issues like this, but
they were resolved by
specifying the following settings for the aggregate interface on the
switch-side,
aggregated-ether-options {
lacp {
active;
periodic slow;
}
}
To make the EX switch match the NetApp's defaults (defaults that
cannot be changed on their
side). But this did not solve the problem for us.
Has anyone here seen LACP problems with NetApp or other vendors? The
plan, if we ever get
the chance to do some troubleshooting, is to do analyzer captures to
see what's happening
with the LACPDUs. In the mean time, we were trying to also think of a
reliable way to automate
the reset of interfaces in the bundles if they fall into the Defaulted state.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX policy logging
On 5/18/2011 at 12:20 PM, Scott T. Cameron routeh...@gmail.com wrote: Does anyone have a trick for logging all policies? I'm not particularly fond of going and tagging each policy with log. Worse, is there a way to flag the default-policy with a log statement? I have deny-all and no options that follow, would be nice to catch them all with a log as well. Scott ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp # set group log-all-policies security policies from-zone * to-zone * policy * then log session-init # set security policies apply-group log-all-policies -- Crist Clark Network Security Specialist, Information Systems Globalstar 408 933 4387 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX policy action to inject a route in a table??
On 3/17/2011 at 3:04 PM, Clarke Morledge chm...@wm.edu wrote: The SRX policy actions (count, deny, log, permit, reject) are helpful, but a little limited. I am wondering if there might be a way to enforce a special action such as take the ip address of the source packet and inject it into a routing table of some sort. What I have in mind is some way to use the SRX to grab the IPs of misbehaving hosts and put the address in a RIB. Then I can use routing policy to put the route into a BGP feed to a border router that would null route traffic to and from that IP address using tricks with Unicast Reverse Path Forwarding. This would be like using the SRX has a simple honeypot to then enforce a host address block at the network perimeter. Of course, there are all sorts of dangers and challenges involved, such as making sure you don't end up DOS'ing the SRX yourself, etc. But I still wish there was a clean way to proactively do this. My other option is to just log the packet to somewhere else, parse the log, then grab the IP of the offender and populate my BGP feed that way. But this could get complicated, too. It could be a handy feature to do all of this task on the SRX. Anybody have any ideas on this? Event script. SLAX scripts are a bit hard to wrap your head around at first, but this Day One document is a pretty good primer, http://www.juniper.net/us/en/community/junos/training-certification/day-one/automation-series/applying-junos-automation/ You may want to hit up, http://code.google.com/p/junoscriptorium/ And see if something even close already exists there. BTW, anyone else know of good sources of JUNOS script examples? -- Crist Clark Network Security Specialist, Information Systems Globalstar 408 933 4387 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Monitoring Connectivity Out Multiple Links
A number of people emailed me asking to let them know if I found a solution or made any progress on this. I've had some time to work on it and think I have the RPM stuff figured out. Now I just need to actually use what RPM tracks in some event-options to actually have the system respond autonomously. For more details and configuration code, see the my thread at the J-Net Forums, http://forums.juniper.net/t5/SRX-Services-Gateway/Dual-ISP-Failover-via-RPM/m-p/72700/highlight/false#M8459 On 1/24/2011 at 8:54 PM, Crist Clark crist.cl...@globalstar.com wrote: I've got a site with multiple Internet links. I want to continuously monitor Internet connectivity across all links although I only plan to use one at a time for production traffic. This is fail over only, not load balancing. Just routing by link up or down is not sufficient. All of the links terminate as Ethernet on the device, an SRX 240H, with switches between it and the CPE. I found the Real Time Monitoring (RPM) features in JUNOS, and it seemed perfect. I could set up a few ICMP pings and HTTP GETs to some reliable locations and then only fail over when the preferred ISP has more failures than the backup(s). But I'm having problems getting this to work. I thought I could set up a routing instance with the default route out each ISP then set up a RPM test associated with each routing instance, after all, the knobs seem to be in place to do this, but it does not work. From the research I've done, it seems that a forwarding routing instance won't actually affect the packets originating on the host itself? So what is the right way to do this? Am I on the right track? BTW, this is running 10.0, but upgrading is definitely an option. -- Crist Clark Network Security Specialist, Information Systems Globalstar 408 933 4387 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Monitoring Connectivity Out Multiple Links
I've got a site with multiple Internet links. I want to continuously monitor Internet connectivity across all links although I only plan to use one at a time for production traffic. This is fail over only, not load balancing. Just routing by link up or down is not sufficient. All of the links terminate as Ethernet on the device, an SRX 240H, with switches between it and the CPE. I found the Real Time Monitoring (RPM) features in JUNOS, and it seemed perfect. I could set up a few ICMP pings and HTTP GETs to some reliable locations and then only fail over when the preferred ISP has more failures than the backup(s). But I'm having problems getting this to work. I thought I could set up a routing instance with the default route out each ISP then set up a RPM test associated with each routing instance, after all, the knobs seem to be in place to do this, but it does not work. From the research I've done, it seems that a forwarding routing instance won't actually affect the packets originating on the host itself? So what is the right way to do this? Am I on the right track? BTW, this is running 10.0, but upgrading is definitely an option. -- Crist Clark Network Security Specialist, Information Systems Globalstar 408 933 4387 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Free Certification Exams
A co-worker and I have both gotten calls offering deals to get vouchers for free Juniper certification exams by the end of the year. I was wary at first, but it seems to check out. I wish I had more than two weeks with to study, schedule, and take a certification exam. Especially when those two weeks include major holidays. But I was just curious the angle behind this. Anyone know the reason they're doing it? And why I couldn't have gotten a call like this, oh, a month ago when it would have been reasonable to actually get a cert or two done? -- Crist Clark Network Security Specialist, Information Systems Globalstar 408 933 4387 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Static Routing - SRX
Does an SRX get confused when you have asymetric routing like
that on a single zone? Does it confuse the stream processing?
The SRX will only ever see the one way traffic from the host
on your local network to the remote network. The return traffic
(I assume) will go straight from the VPN gateway back to the
host on the same LAN.
Have you turned on some trace options to see what's going on?
security {
flow {
traceoptions {
file vpn_problem;
flag basic-datapath;
packet-filter vpn_traffic {
destination-prefix 172.30.200.0/24;
}
}
}
On 11/3/2010 at 11:02 AM, Paul Stewart p...@paulstewart.org wrote:
Thanks... yeah, pretty much.
We installed the static route and were unable to reach anything on the
172.30.200.0/24 network from a machine in the 192.168.20.0/24 subnet. On
that actual machine (Windows 7) we installed a route in Windows and were
able to communicate no problem (bypassing the route statement on the SRX).
This seems to imply that by using a default route you can't take traffic
into an interface and route it back out the SAME interface - an issue we
used to face on the Cisco PIX boxes at one time.
Looking for a workaround to this - our solution at this point is to bring
the 192.168.20.121 device (which is a VPN appliance that connects us to our
billing platforms) in via a subnet on a directly connected interface. The
downside to this is that it involves some routing changes on the VPN portion
which we're trying to avoid as it involves a third party.
Literally on the Cisco 2800 in place it's ip route 172.30.200.0
255.255.255.0 192.168.20.121. On the SRX we have set routing-options
static route 172.30.200.0/24 next-hop 192.168.20.121.
Thanks,
Paul
-Original Message-
From: Michael Damkot [mailto:mdamkot...@gmail.com]
Sent: Wednesday, November 03, 2010 1:55 PM
To: Paul Stewart
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Static Routing - SRX
Paul-
Just to make sure I'm tracking correctly, you've tried installing a static
route and it didn't work?
On Nov 3, 2010, at 11:48 , Paul Stewart wrote:
Hi there.
Can anyone give any suggestion/guidance on the following.
I'm trying to do a static route *out* the same interface that the traffic
came *in* on. This is on an SRX-240
Here are the details:
Private: 192.168.20.0/24
Public: 216.168.x.x/32
Static route: 172.30.200.0/24 to gateway - 192.168.20.224 to
192.168.20.121
192.168.20.121 is the IP on a VPN appliance.
Traffic from a client computer never gets routed to the VPN appliance.
This
works on a Cisco 2800 without a problem, but I can't get it working on the
SRX.
So, to walk this through a bit more - a computer sitting on the
192.168.20.0
subnet has a default gateway of 192.168.20.224. We want a route on the
SRX
that routes any traffic coming into 192.168.20.224 that is destined to
172.30.200.0/24 to be sent to 192.168.20.121. In Cisco 2800 it's just a
static route.
Ran across this challenge in the Cisco PIX world as well..
Thanks for any input..
Paul
___
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
--
Crist Clark
Network Security Specialist, Information Systems
Globalstar
408 933 4387
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX650 Clustering - IPv6
I just happened to be looking at the 10.2 release notes after seeing your email. IPv6 Support [snip] * Chassis cluster—In JUNOS Release 10.2, we support chassis cluster in an active-passive (failover) deployment. [Junos OS Security Configuration Guide] You may want to have a closer look at the 10.2 documentation (the current recommended release for SRXs). I am not using this feature so I have no personal experience whether it actually works. On 11/2/2010 at 10:43 AM, Paul Stewart p...@paulstewart.org wrote: Hi there. We are looking to bring on an additional SRX650 at a site by clustering. One of the requirements though is IPv6 traffic and it appears it's not supported? From http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-c ollections/release-notes/10/topic-39007.html : Chassis Cluster On SRX Series and J Series devices, the following features are not supported when chassis clustering is enabled on the device: * All packet-based protocols, such as MPLS, Connectionless Network Service (CLNS), and IP version 6 (IPv6) Do any of the SRX boxes support clustering with IPv6? Is there any timeline on this being fixed that anyone knows of? Our goal is redundant routing engines should something happen - makes more $$$ sense to add an additional SRX650 when there is one existing.. Thanks in advance, Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Crist Clark Network Security Specialist, Information Systems Globalstar 408 933 4387 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Screening logs on SRX
Which will show up in the NSM logs as a semi-useless Self log like PFE_FW_SYSLOG_IP messages or actually be parsed? On 9/7/2010 at 4:45 PM, Ben Dale bd...@comlinx.com.au wrote: You aren't the only ones! Fortunately the screen logs feature is being introduced in JUNOS 10.4 which will log when a screen threshold is reached: Sep 8 09:43:31 rtlogd: receives log RT_SCREEN_TCP from RT_IDS at severity 3, miscellaneous string=Port scan! source: 172.16.10.23:54326, destination: 172.16.10.254:712, zone name: LAN, interface name: vlan.10, action: drop, attribute-list=attack-name 10 Port scan! source-address 12 172.16.10.23 source-port 5 54326 destination-address 13 172.16.10.254 destination-port 3 712 source-zone-name 3 LAN interface-name 7 vlan.10 action 4 drop On 08/09/2010, at 5:41 AM, Jérôme Fleury wrote: Hi Fahad, that's a good question. I've been searching for a long time, and could not find neither... I'm not even able to see them on my STRM, which defeats completely the purpose of this appliance. On Tue, Sep 7, 2010 at 12:02, Fahad Khan fahad.k...@gmail.com wrote: Hi Folks, Can some body tell me that how can I see the logs of the attack packets generated by some source for let say port scan, IP spoof etc Thanks in adv, regards, Muhammad Fahad Khan JNCIP - M/T # 834 IT Specialist Global Technology Services, IBM fa...@pk.ibm.com +92-301-8247638 Skype: fahad-ibm http://pk.linkedin.com/in/muhammadfahadkhan ___ 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
Re: [j-nsp] Enumerate All Possible VPN Tunnels? Really?
If the SRX box was at the same site as I am, it would be at risk
of physical assault. This just seems so wrong and broken. If I look
at the IPsec logs (kmd), the Phase 2 negotiations with the peer look
totally correct,
Jul 19 06:21:05 Phase-2 [responder] done for
p1_local=ipv4(udp:0,[0..3]=local_IP)
p1_remote=fqdn(any:0,[0..26]=remote_name)
p2_local=ipv4_subnet(any:0,[0..7]=172.18.3.0/30)
p2_remote=ipv4_subnet(any:0,[0..7]=remote_net.0/24)
But after using those remote and local subnets in Phase 2, when I
look at the security association on the SRX says,
ccl...@covfw# run show security ipsec security-associations detail
Virtual-system: Root
Local Gateway: local_IP, Remote Gateway: remote_IP
Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Now is it just me, or is that completely broken? The system knows which
addresses it is negotiating about in Phase 2, but then puts wide open
identities in the local database?
On 7/16/2010 at 2:57 PM, Crist Clark crist.cl...@globalstar.com wrote:
I've got what I think should be a fairly vanilla hub-and-spoke
VPN configuration. The hub is a Cisco ASA (really, it eventually
should be dual hub, but wait until I get one working before I
worry about that) and one of the spokes is a SRX (10.1).
I can get a single tunnel up between the SRX and the ASA without
much problem. However, we have a situation where there are
multiple non-contiguous networks at each site. At the hub and
other spokes, we just enumerate all of the networks at the remote
site and the networks at the local side, and the device builds
individual tunnels between the various networks as needed with
a single configuration entry.
Doesn't seem to work that way on the SRX (JUNOS). I started with
a route-based VPN. That's how I got my one quick tunnel up, but
the SRX side would always say the tunnels were associated
locally with 0.0.0.0/0 and remotely with the same. This lead to
the problem that the SRX would try to cram traffic from local_netX
and remote_netY down a VPN that had been negotiated in IKE Phase 2
as between local_netA and remote_netB.
I talked to JTAC about this, and their solution was going to be
to enumerate every possible combination of tunnels,
security {
ipsec {
vpn vpn_1-cfg {
ike {
proxy-identity {
local local_netA;
remote remote_netB;
}
}
}
}
}
Which does not scale. The tech said maybe policy-based would be
better. So I went to the site-to-site VPN tool on the Juniper
support page to see what it would say. I put two networks in
either side of the tunnel and it spit out a configuration with
EIGHT security policies, one in each direction for the four ways
you can pair the two networks at each site. And that's still not
really working right.
Neither of these is solutions is scalable. There's got to be a
better way to do this, right?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Enumerate All Possible VPN Tunnels? Really?
I've got what I think should be a fairly vanilla hub-and-spoke
VPN configuration. The hub is a Cisco ASA (really, it eventually
should be dual hub, but wait until I get one working before I
worry about that) and one of the spokes is a SRX (10.1).
I can get a single tunnel up between the SRX and the ASA without
much problem. However, we have a situation where there are
multiple non-contiguous networks at each site. At the hub and
other spokes, we just enumerate all of the networks at the remote
site and the networks at the local side, and the device builds
individual tunnels between the various networks as needed with
a single configuration entry.
Doesn't seem to work that way on the SRX (JUNOS). I started with
a route-based VPN. That's how I got my one quick tunnel up, but
the SRX side would always say the tunnels were associated
locally with 0.0.0.0/0 and remotely with the same. This lead to
the problem that the SRX would try to cram traffic from local_netX
and remote_netY down a VPN that had been negotiated in IKE Phase 2
as between local_netA and remote_netB.
I talked to JTAC about this, and their solution was going to be
to enumerate every possible combination of tunnels,
security {
ipsec {
vpn vpn_1-cfg {
ike {
proxy-identity {
local local_netA;
remote remote_netB;
}
}
}
}
}
Which does not scale. The tech said maybe policy-based would be
better. So I went to the site-to-site VPN tool on the Juniper
support page to see what it would say. I put two networks in
either side of the tunnel and it spit out a configuration with
EIGHT security policies, one in each direction for the four ways
you can pair the two networks at each site. And that's still not
really working right.
Neither of these is solutions is scalable. There's got to be a
better way to do this, right?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] NSM, IDP200 and SRX240
I was told by a reseller that I would not be able to manage our existing IDP200 and a new SRX240 using the same NSM. I know I can't do it using the NSM version we are running, 2008.1r1, but from the 2010.2 documentation, it looks like it can manage both devices. Are there some limitations to managing an IDP200 and SRX240 from one NSM 2010.2 installation? Or might he have been referring to some gotcha in the NSM upgrade path from 2008.1r1 to 2010.2 that would stop us from wanting to move the IDP200 off of the existing NSM installation? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
