Re: [j-nsp] Trouble with just one IPSec tunnel among many
Perhaps you are running into a resource issue or at the upper limit of number of supported tunnels? Definitely strange, and not one I have seen before. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI http://www.shortestpathfirst.net > On Nov 18, 2015, at 12:20 PM, Jonathan Call wrote: > > A google of this error message directed me to a blog: > (http://thomaspollet.blogspot.com/) that discusses how SA can exist in the > management plane but not in the data plane. When I ran request pfe execute > command "show usp ipsec sa" target fwdd my st0.142 interface is not listed. > > I've already tried deleting and committing the IPSec settings so I may be > forced to do a commit full or a reboot. Clearing the ike and ipsec > security-associations gets rid of the settings but the VPN never recovers > until remove and commit the SRX B VPN settings again. > > Jonathan > > > From: juniper-nsp on behalf of Jonathan > Call > Sent: Wednesday, November 18, 2015 9:19 AM > To: Stefan Fouant > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] Trouble with just one IPSec tunnel among many > > I found this in the traceoptions I collected from SRX A: > http://pastebin.com/Kk0gSzaD > > So the tunnel is there, but its not there. That explains the lack of ESP > packets on that side. > > Jonathan > > From: Stefan Fouant > Sent: Tuesday, November 17, 2015 8:08 PM > To: Jonathan Call > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] Trouble with just one IPSec tunnel among many > > > Have you tried debugging under [edit security flow traceoptions] yet? There > is a wealth of information in there using the flag 'basic-datapath' that may > help you. > > Stefan Fouant > JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI > m (703) 625-6243 > > On Nov 17, 2015, at 9:42 PM, Jonathan Call wrote: > > > I have an SRX250 (SRX A) and an SRX240h2 (SRX B) connected via a PSK IPSec > tunnel. They both have multiple IPSec tunnels configured to other SRX devices > on our network. Recently the tunnel between the two stopped passing traffic. > Both IKE and IPSec security association were UP on both sides. (show > security ike security-association and show security ipsec > security-association) If I pinged from SRX A to something on SRX B I would > see the echo request come into SRX B and the echo reply go out. On SRX A I > would only see the outbound packet flow with no response. When I would ping > from SRX B to SRX A, SRX A acted as if nothing was happening at all. I ran a > traceoptions to capture the ICMP traffic from SRX A to SRX B. SRX A looked > like it was sending the traffic out the tunnel interface but had no reply > content. The tracefile on SRX B was completely empty. > > After confirming there was nothing abnormal in the routing tables on both of > them I tried clearing the IKE and IPSec sessions to rebuild the VPN. Both > Phase 1 IKE and Phase 2 IKE came back up but now ping fails in both > directions. When I look at the 'show security ipsec statistics index' > information on each side SRX B shows some ESP packets being encrypted and > decrypted but not very many. The SRX A ESP statistics are all zeros. > > Restarting ipsec key management seems a bit extreme since it will take out > all of the other IPSec sessions. Is there some other troubleshooting I can > try before I resort to that? > > Thank you, > > Jonathan > > > > ___ > 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] Trouble with just one IPSec tunnel among many
Have you tried debugging under [edit security flow traceoptions] yet? There is a wealth of information in there using the flag 'basic-datapath' that may help you. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI m (703) 625-6243 > On Nov 17, 2015, at 9:42 PM, Jonathan Call wrote: > > I have an SRX250 (SRX A) and an SRX240h2 (SRX B) connected via a PSK IPSec > tunnel. They both have multiple IPSec tunnels configured to other SRX devices > on our network. Recently the tunnel between the two stopped passing traffic. > Both IKE and IPSec security association were UP on both sides. (show security > ike security-association and show security ipsec security-association) If I > pinged from SRX A to something on SRX B I would see the echo request come > into SRX B and the echo reply go out. On SRX A I would only see the outbound > packet flow with no response. When I would ping from SRX B to SRX A, SRX A > acted as if nothing was happening at all. I ran a traceoptions to capture the > ICMP traffic from SRX A to SRX B. SRX A looked like it was sending the > traffic out the tunnel interface but had no reply content. The tracefile on > SRX B was completely empty. > > After confirming there was nothing abnormal in the routing tables on both of > them I tried clearing the IKE and IPSec sessions to rebuild the VPN. Both > Phase 1 IKE and Phase 2 IKE came back up but now ping fails in both > directions. When I look at the 'show security ipsec statistics index' > information on each side SRX B shows some ESP packets being encrypted and > decrypted but not very many. The SRX A ESP statistics are all zeros. > > Restarting ipsec key management seems a bit extreme since it will take out > all of the other IPSec sessions. Is there some other troubleshooting I can > try before I resort to that? > > Thank you, > > Jonathan > > > > ___ > 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] How reliable is EX multichassis? 3300 and 8200 switches
On Oct 31, 2012, at 10:01 AM, Luca Salvatore wrote: > Yep my mistake. > However I do have 'set chassis redundancy graceful-switchover' configured as > well as 'set protocols nonestop-routing' > > On 31/10/2012, at 11:24 PM, "Stefan Fouant" > mailto:sfou...@shortestpathfirst.net>> wrote: > > I think you are confusing GRES w/ GR. NSR and GRES are NOT mutually > exclusive and in fact NSR requires it to function. 'set chassis redundancy graceful-switchover' is GRES, not GR. > What I actually see when the master switch robots is that the AE interfaces > between my devices flaps. I think this causes my OSPF neighbours to go down. > > I see this in the logs: "rpd[2241]: RPD_OSPF_NBRDOWN: OSPF neighbor > 10.255.255.9 (realm ospf-v2 vlan.83 area 0.0.0.1) state changed from Full to > Down due to KillNbr (event reason: interface went down" Which device is the ae interface tied to? Is it a VC-LAG with members tied to multiple physical devices, or is it comprised of only links belonging to a single device? Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Systems Engineer, Juniper Networks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
I think you are confusing GRES w/ GR. NSR and GRES are NOT mutually exclusive and in fact NSR requires it to function. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Systems Engineer, Juniper Networks On Oct 31, 2012, at 2:07 AM, Luca Salvatore wrote: > It's an EX4500-VC running Junos 11.4r2.14 > You can't configure GRES + NSR - they are mutually exclusive right? > Config is attached. > > > Luca > > > -Original Message- > From: Doug Hanks [mailto:dha...@juniper.net] > Sent: Wednesday, 31 October 2012 4:27 PM > To: Luca Salvatore; Morgan McLean; EXT - bd...@comlinx.com.au > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches > > Make sure the platform + software + configuration supports GRES + NSR + NSB > and you're good to go. > > > On 10/30/12 8:58 PM, "Luca Salvatore" wrote: > >> Yep I'm aware, but why are my OSPF neighbours going down when one >> switch reboots? >> >> Luca >> >> >> -Original Message- >> From: Doug Hanks [mailto:dha...@juniper.net] >> Sent: Wednesday, 31 October 2012 2:42 PM >> To: Luca Salvatore; Morgan McLean; EXT - bd...@comlinx.com.au >> Cc: juniper-nsp@puck.nether.net >> Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 >> switches >> >> GR is mutually exclusive with NSR. >> >> >> You want NSR. >> >> On 10/30/12 5:44 PM, "Luca Salvatore" wrote: >> >>> I'm just playing around with this now since I have a few new EX >>> switches not in production just yet Have a pretty simple setup with >>> two >>> EX4500 in VC connected to another two >>> EX4500 in VC mode. I'm running OSPF between them. >>> >>> I rebooted the master member while running a ping an it took around 40 >>> seconds to come back up. I noticed that my OSPF adjacency went down >>> and the delay was waiting for the OSPF neighbours to come back up. >>> >>> I have: >>> nonstop-routing configured under routing options graceful-switchover >>> configured under chassis redundancy nonstop-bridging configured under >>> ethernet-switching-options >>> >>> Would graceful-restart be a better config than non-stop routing? >>> >>> Luca >>> >>> >>> -Original Message- >>> From: juniper-nsp-boun...@puck.nether.net >>> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Morgan >>> McLean >>> Sent: Wednesday, 31 October 2012 11:00 AM >>> To: Ben Dale >>> Cc: juniper-nsp@puck.nether.net >>> Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 >>> switches >>> >>> Neither of these two options show up as a configurable flag: >>> >>> set routing-options nonstop-routing >>> set ethernet-switching-options nonstop-bridging >>> >>> I'm running 11.4R2.14 on the ex3300-48t switches. >>> >>> Granted, right now the VC is broken so maybe it doesn't allow me to >>> configure it? I can head to the datacenter and upgrade these two >>> devices to recommended release and report back tomorrow as well. >>> >>> Morgan >>> >>> On Tue, Oct 30, 2012 at 4:30 PM, Ben Dale wrote: >>> >>>> Hi Morgan, >>>> >>>> On 31/10/2012, at 9:06 AM, Morgan McLean wrote: >>>> >>>>> Can anybody give me an idea regarding typical failover times if >>>>> the >>>> master >>>>> in a two switch pair were to die? The quickest I've seen in my >>>>> testing >>>> with >>>>> EX3300's is 45 seconds, just for L2 forwarding to continue >>>>> working, no routing. All the ports drop link as well on the >>>>> secondary switch while things switch over. I can have my laptop >>>>> connected to the secondary >>>> switch, >>>>> passing traffic up an uplink on the secondary, and if the master >>>>> dies it creates a 45 second interruption. >>>>> >>>>> Normal? >>>>> >>>> >>>> Yes, but add the following to your configuration: >>>> >>>> set virtual-chassis no-split-detection(you may already have this) >>>> set routing-options nonstop-routing >>>> set ethernet-switching-options nonstop-bridging >>>
Re: [j-nsp] WAN input prioritization on MX
On Oct 15, 2012, at 9:40 AM, Gustavo Santos wrote: > Hi, After reading your comments, I will try to explain better what I'm > trying to achieve. I'm trying to do classification and queueing on an > ingress interface. > > When the wan interface gets rate limit threshold (500mbits), all the > traffic that is destinated to the high priority destination subnet gets > precedence and no packet loss or lower packet loss, than the low priority. > > The egress traffic to these subnets goes to two different physical > interfaces ( ge-1/0/5 and ge-1/0/5) So , from what I read from you, the > ingress interface should "see" the rate limit of 500mbits gets congestion > and then discard packets from wan that have destination (address) subnet > that differs from the high priority subnet. > > For instance: If the current wan ingress traffic total is 450mbits and high > priority traffic is 100mbits, and low priority is 350mbits = no packet > discard, but if traffic towards high priority subnet is 300mbits and low > priority is 300mbits, then the queuing / scheduler will drop the low > priority traffic until the sources traffic gets shaped to 200mbits for the > low priority and the high priority gets 300mbits. > > On Linux it's quite simple to achieve. Everything you are describing above is quite simple to achieve in Junos as well, I just think you need to spend some time reading the docs a bit more as it appears there are a few gaps in your understanding. But believe me, what you are trying to achieve is quite possible and has been supported in Junos since the very earliest implementations. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] delay-buffer in Juniper
On Oct 13, 2012, at 1:52 PM, Huan Pham wrote: > [HP] I think you can transmit at rate higher than the configured value if > theres no congestion (e.g. if there's no traffic waiting to be transmitted in > other queues). > > Here's the quote from Doc: > > [Juniper Doc] > rate-limit—(Optional) Limit the transmission rate to the rate-controlled > amount during congestion. In contrast to the exact option, when there is no > congestion, the scheduler with the rate-limit option shares unused bandwidth > above the rate-controlled amount. > > http://www.juniper.net/techpubs/en_US/junos9.5/topics/reference/configuration-statement/transmit-rate-edit-dynamic-profiles.html > > > [HP] Not mentioned in the Doc but I think in case of congestion, traffic is > is rate limited by being buffered, as opposed to being policed. I think it is > only dropped if its queue is full (or subject to RED). In other words, they > CAN BE queued if there is congestion and contention from different queues for > the bandwidth! > > Do you mean the queue buffer is always 0 when we use "rate limit" option? Hi Huan, Honestly, that's 9.5 documentation. Perhaps something changed at some point, but in current versions of code this is not how it works. I have taught this class for a few years now and have also worked w/ QoS on Junos for some time and the rate-limit option is used to limit the transmission rate to the specified amount. Take a look at the latest docs and you will see. I would say that your analogy of the queue buffer being 0 when using a transmit-rate w/ the rate-limit option is spot on. There is no buffering taking place. In other words, if you configured a transmit-rate of 0% with the rate-limit knob, all packets belonging to that queue would be dropped. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Strangeness with CoS and scheduler rate-limiting
On Oct 13, 2012, at 2:59 PM, Per Westerlund wrote: > > Note that the scheduler "tmp-be" is not used. My belief is that everything > that is not explicitly mentioned in the scheduler-map is handled by the > default configuration (in practice the rest of the flows hit the default > best-effort forwarding-class). This is not correct. When you explicitly define a scheduler-map and apply it to an interface, there is no default configuration anymore applied to that interface. What this means is there is no guarantee to Best Effort or Network Control at all, and your experience may vary depending on network conditions. You are correct, however that the rest of the traffic will hit your BE forwarding-class, but there are no guarantees to this class. If you have BE traffic, or NC, and you want to accommodate it, then you need to make sure you configure the appropriate schedulers and apply them to your scheduler-map. Can you do that and then when you have it configured properly see what your results look like. We can take it from there if you are still experiencing issues. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] delay-buffer in Juniper
It depends on the options you've got configured with your transmit-rate. If you configure a transmit-rate with a keyword of rate-limit it will never buffer, it will simply drop any packets which are in excess of the configured transmit-rate. If you configure a transmit-rate with a keyword of exact, it will buffer the traffic in excess of the configured transmit-rate, regardless of whether there is excess capacity available. It will buffer this traffic until it falls below the configured transmit-rate and then it will send this buffered traffic. If you configure a transmit-rate without either of the two options above, it will allow the queue to use excess capacity if it is available (whereby it will not be buffered), or if excess capacity is not available, then the traffic in excess of the configured transmit-rate will be buffered. HTHs, Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate On Oct 13, 2012, at 12:39 PM, tim tiriche wrote: > Hi, > > I have a BRONZE queue configured with 20% TX rate/low priority on a > 10G interface. > When does juniper start buffering traffic. If it exceeds the 20% TX > rate or if the 10G interface is oversubscribed? > > -Tim > ___ > 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] Ethernet switching/bridging on SRX High-End
Hi, Actually, you can absolutely do transparent mode on High End SRX Platforms by way of bridge-domains... And if I recall correctly in 11.1 and higher this is also the same way you configure transparent mode on the branch devices as well (i.e. no ethernet-switching family). Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Sep 12, 2012, at 12:39 PM, Bao Nguyen wrote: > Unfortunately, as far as I know, there's no "ethernet-switching" or > "bridging" capability on the high-end SRX that I know of, even though > the branch can do "ethernet-switching." > > -bn > 0216331C > > > On Wed, Sep 12, 2012 at 1:14 AM, Dale Shaw wrote: >> Hi all, >> >> I'm trying to find a way to use an srx3400 as an intermediate box to >> provide L2 connectivity between a couple of EX switches and a J2320. >> This is just a short-term arrangement to get me out of a bind. If I >> can't do it, it's not a big deal, I'll dig up a 3rd switch. >> >> Essentially I want to use the srx3400 as a basic switch, so that the >> two EX switches' uplinks and the J's LAN-facing port are in the same >> broadcast domain. I want to use three ge- interfaces to accomplish the >> task. >> >>[SRX]--[J2320] >>/ \ >> / \ >> | | >> [EX1] [EX2] >> >> >> The obvious feature seems to be bridge-domains (as >> "ethernet-switching" isn't supported on SRX-HE) but it doesn't look >> like I can run it if the SRX is in 'route mode'. >> >> I'm running JUNOS 10.0R4 on the SRX. >> >> Clues? >> >> cheers, >> Dale >> ___ >> 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] SRX - tap mode?
You can always create your own 'tap mode' by simply configuring Filter Based Forwarding and shunting your selective traffic through your IDP. I did this all the time in my previous life when dealing with security devices that couldn't scale enough to place in-line. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Sep 12, 2012, at 11:43 AM, William McLendon wrote: > hi Tim, > > thanks for the response - but reading the description that sounds like the > firewall itself still has to be inline, which i'm trying to avoid here. > > I guess what does the rest of the config have to look like for it to function > correctly off a span port? ie there wouldn't be any routing or IP interfaces > involved. > > Thanks, > > Will > > On Sep 12, 2012, at 11:35 AM, Tim Eberhard wrote: > >> High end SRX's support tap mode. Branch as far as I know do not. >> >> http://www.juniper.net/techpubs/software/junos-security/junos-security10.2/junos-security-swconfig-security/topic-45272.html >> >> Hope this helps, >> -Tim Eberhard >> >> On Wed, Sep 12, 2012 at 10:33 AM, William McLendon >> wrote: >>> hi everyone, >>> >>> do SRX firewalls support a "tap mode" installation? Really just looking at >>> it for purposes of evaluation of IDP functionality where tap mode would be >>> the least intrusive method to see data vs having to put it inline (and then >>> deal with the inevitable "you put a device inline and now XYZ doesn't >>> work!") >>> >>> I seem to recall that they do not, and they have to be installed in L3 mode >>> or in Transparent mode, but was hoping I may have missed the feature in a >>> release note somewhere. >>> >>> Thanks, >>> >>> Will >>> ___ >>> 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] Ethernet switching/bridging on SRX High-End
Hi Dale, I have never tried to do tranarent mode bridging on an SRX while converting it to packet mode, so I am unsure if it can even be done. However, if you don't mind the additional stateful processing why not just configure bridging and then configure an any-any-any policy to allow everything through. Should be relatively straightforward... Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Sep 12, 2012, at 4:14 AM, Dale Shaw wrote: > Hi all, > > I'm trying to find a way to use an srx3400 as an intermediate box to > provide L2 connectivity between a couple of EX switches and a J2320. > This is just a short-term arrangement to get me out of a bind. If I > can't do it, it's not a big deal, I'll dig up a 3rd switch. > > Essentially I want to use the srx3400 as a basic switch, so that the > two EX switches' uplinks and the J's LAN-facing port are in the same > broadcast domain. I want to use three ge- interfaces to accomplish the > task. > >[SRX]--[J2320] >/ \ > / \ > | | > [EX1] [EX2] > > > The obvious feature seems to be bridge-domains (as > "ethernet-switching" isn't supported on SRX-HE) but it doesn't look > like I can run it if the SRX is in 'route mode'. > > I'm running JUNOS 10.0R4 on the SRX. > > Clues? > > cheers, > Dale > ___ > 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] Config help with an SRX110 & ADSL
Oops, I meant to say that you should replace fe-0/0/0.0 with the at-1/0/0.0 interface under the propagate settings, since at-1/0/0.0 is the one receiving the DHCP parameters from upstream. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Aug 28, 2012, at 9:12 AM, Stefan Fouant wrote: > Also, your DHCP propagate setting is referencing fe-0/0/0.0 whereas is should > be referencing vlan.0, vlan.1 and vlan.2. Per the docs, the propagate option > applies to the logical interface which will receive TCP/IP settings from the > external network for propagation to the DHCP pool running on the device. > Currently, fe-0/0/0.0 isn't a routing interface and it isn't part of any > assigned zone. > > HTHs. > > Stefan Fouant > JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI > Technical Trainer, Juniper Networks > > Follow us on Twitter @JuniperEducate > > Sent from my iPad > > On Aug 28, 2012, at 7:41 AM, Dale Shaw wrote: > >> [Apologies for top post] >> >> There are a few problems with the config (once you get basic comms up >> you'll need to look at your IPsec settings) but I suspect the main problem >> is that interface at-1/0/0.0 isn't assigned to a security zone (untrust). >> >> Cheers, >> Dale >> >> On Aug 28, 2012 8:10 PM, "Josh Farrelly" wrote: >> ___ >> 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] Config help with an SRX110 & ADSL
Also, your DHCP propagate setting is referencing fe-0/0/0.0 whereas is should be referencing vlan.0, vlan.1 and vlan.2. Per the docs, the propagate option applies to the logical interface which will receive TCP/IP settings from the external network for propagation to the DHCP pool running on the device. Currently, fe-0/0/0.0 isn't a routing interface and it isn't part of any assigned zone. HTHs. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Aug 28, 2012, at 7:41 AM, Dale Shaw wrote: > [Apologies for top post] > > There are a few problems with the config (once you get basic comms up > you'll need to look at your IPsec settings) but I suspect the main problem > is that interface at-1/0/0.0 isn't assigned to a security zone (untrust). > > Cheers, > Dale > > On Aug 28, 2012 8:10 PM, "Josh Farrelly" wrote: > ___ > 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] LACP Load Balance
Also, you need to send a sizable number of flows to effect a proper distribution. A handful of flows is just not going to cut it, based on the below mentioned hash. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Aug 28, 2012, at 3:32 AM, Julien Goodwin wrote: > On 28/08/12 17:20, Mohammad Khalil wrote: >> I am trying to make load balancing on the links as I checked the traffic >> and its not balanced >> Any ideas will be highly appreciated > > Depending on what traffic you're sending it may not be evenly hashable > across the links. > > Depending on which side is uneven you might find help in: > > EX: > http://kb.juniper.net/InfoCenter/index?page=content&id=KB22943&smlogin=true > > MX: > http://www.juniper.net/techpubs/en_US/junos10.3/topics/concept/layer-2-services-load-balancing-and-link-aggregation.html > > -- > Julien Goodwin > Studio442 > "Blue Sky Solutioneering" > > ___ > 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] test
No... :-b Sent from my HTC on the Now Network from Sprint! - Reply message - From: "Mohammad Khalil" Date: Thu, Aug 16, 2012 4:23 am Subject: [j-nsp] test To: anyone getting my messages? On Thu, Aug 16, 2012 at 1:02 AM, Mohammad Khalil wrote: > Test > ___ 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] what is differnet between bridge and ethernet-switching ?
There is no difference between the two. Sent from my HTC on the Now Network from Sprint! - Reply message - From: "bruno.juniper" Date: Mon, Aug 13, 2012 4:01 am Subject: [j-nsp] what is differnet between bridge and ethernet-switching ? To: "juniper-nsp" what is differnet between bridge and ethernet-switching ? i am always confused . as i know ,when i configure mx ,we use bridge . when i configure ex ,we use ethernet-switching. root@test# set interfaces fe-0/0/0 unit 0 family ? Possible completions: + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups > bridge Layer-2 bridging parameters > ccc Circuit cross-connect parameters > ethernet-switching Ethernet switching parameters > inet IPv4 parameters > inet6IPv6 protocol parameters > iso OSI ISO protocol parameters > mlfr-end-to-end Multilink Frame Relay end-to-end protocol parameters > mlfr-uni-nni Multilink Frame Relay UNI NNI protoc -- Best Regards, Bruno ___ 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] BAJUG2
On 8/10/2012 2:00 PM, Doug Hanks wrote: It's time for the Bay Area Juniper Users Group again. October 16th 5.30pm. Sign up for free at http://bajug.eventbrite.com Kudos Doug, really good stuff... maybe I'll have to schedule some training related travel to Sunnyvale so I can attend. Thanks for setting this up. -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Static Route Names
Annotate. It is your friend. Sent from my HTC on the Now Network from Sprint! - Reply message - From: "GIULIANO (WZTECH)" Date: Fri, Aug 10, 2012 11:44 am Subject: [j-nsp] Static Route Names To: 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] Sending vpls broadcast packets over static LSP
Stupid question, but you do have DUT13 configured for the static LSP as well
correct?
Sent from my HTC on the Now Network from Sprint!
- Reply message -
From: "Bala Subrahmanyam Venkata"
Date: Thu, Aug 9, 2012 5:31 am
Subject: [j-nsp] Sending vpls broadcast packets over static LSP
To:
Hello-
I'm trying to configure this (Static Point-to-Multipoint Flooding LSP
for vpls):
http://www.juniper.net/techpubs/software/junos/junos95/swconfig-vpns/id-11510467.html#id-11512557
I have the static LSP up but the broadcast packets don't seem to go
over it. Any specific reason ? I've pasted what I think as
configs/show output needed. One thing I've done is that the static LSP
is just a plain static LSP (i.e. there is no multiple endpoints for
it...) Let me know if more is required...Thanks in advance.
Topology:
MX240-DUT13DUT11
(where MX240 & DUT11 have the VPLS endpoints)
bala@MX240# show routing-instances slsp-vpls
instance-type vpls;
interface ge-1/1/9.0;
provider-tunnel {
rsvp-te {
static-lsp slsp3;
}
}
protocols {
vpls {
no-tunnel-services;
vpls-id 2047;
neighbor 11.11.11.11;
connectivity-type ce;
}
}
[edit]
bala@MX240#
bala@MX240# show protocols mpls static-label-switched-path slsp3
ingress {
next-hop 9.1.7.13;
to 31.31.31.11;
push 2046;
}
bala@MX240# run show vpls connections instance slsp-vpls
.
Instance: slsp-vpls
VPLS-id: 2047
Neighbor Type St Time last up # Up trans
11.11.11.11(vpls-id 2047) rmt OL
bala@MX240# run show mpls static-lsp name slsp3 extensive
Ingress LSPs:
LSPname: slsp3, To: 31.31.31.11
State: Up
Nexthop: 9.1.7.13 Via ge-1/0/6.0
LabelOperation: Push, Outgoing-label: 2046
Created: Thu Aug 2 09:48:01 2012
Bandwidth: 0 bps
Statistics: Packets 0, Bytes 0
Total 2, displayed 1, Up 1, Down 0
Transit LSPs:
Total 1, displayed 0, Up 0, Down 0
Bypass LSPs:
Total 0, displayed 0, Up 0, Down 0
[edit]
bala@MX240#
bala@MX240# run show vpls statistics instance slsp-vpls
VPLS statistics:
Instance: slsp-vpls
Local interface: ge-1/1/9.0, Index: 87
Broadcast packets:769916
Broadcast bytes : 197098496
Multicast packets: 0
Multicast bytes : 0
Flooded packets : 0
Flooded bytes: 0
Unicast packets : 0
Unicast bytes: 0
Current MAC count: 0 (Limit 1024)
[edit]
bala@MX240#
[edit]
bala@MX240#
___
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] Sending vpls broadcast packets over static LSP
Yes, RSVP-TE provider-tunnels is for an inclusive PMSI, dynamically signalled.
Sent from my HTC on the Now Network from Sprint!
- Reply message -
From: "Bala Subrahmanyam Venkata"
Date: Thu, Aug 9, 2012 7:27 am
Subject: [j-nsp] Sending vpls broadcast packets over static LSP
To:
Or perhaps the "static" is really a "static RSVP LSP" (and not a true
static LSP which is "static-label-switched-path" in juniper speak)...?
That could explain why it is configured under "rsvp-te" in the
routing-instance...can someone from juniper confirm ?
TIA
On Thu, Aug 9, 2012 at 3:01 PM, Bala Subrahmanyam Venkata
wrote:
> Hello-
>
> I'm trying to configure this (Static Point-to-Multipoint Flooding LSP
> for vpls):
> http://www.juniper.net/techpubs/software/junos/junos95/swconfig-vpns/id-11510467.html#id-11512557
>
> I have the static LSP up but the broadcast packets don't seem to go
> over it. Any specific reason ? I've pasted what I think as
> configs/show output needed. One thing I've done is that the static LSP
> is just a plain static LSP (i.e. there is no multiple endpoints for
> it...) Let me know if more is required...Thanks in advance.
>
>
>
> Topology:
>
> MX240-DUT13DUT11
>
> (where MX240 & DUT11 have the VPLS endpoints)
>
>
>
> bala@MX240# show routing-instances slsp-vpls
> instance-type vpls;
> interface ge-1/1/9.0;
> provider-tunnel {
> rsvp-te {
> static-lsp slsp3;
> }
> }
> protocols {
> vpls {
> no-tunnel-services;
> vpls-id 2047;
> neighbor 11.11.11.11;
> connectivity-type ce;
> }
> }
>
> [edit]
> bala@MX240#
>
> bala@MX240# show protocols mpls static-label-switched-path slsp3
> ingress {
> next-hop 9.1.7.13;
> to 31.31.31.11;
> push 2046;
> }
>
>
> bala@MX240# run show vpls connections instance slsp-vpls
> .
> Instance: slsp-vpls
> VPLS-id: 2047
> Neighbor Type St Time last up # Up trans
> 11.11.11.11(vpls-id 2047) rmt OL
>
>
>
> bala@MX240# run show mpls static-lsp name slsp3 extensive
> Ingress LSPs:
> LSPname: slsp3, To: 31.31.31.11
> State: Up
> Nexthop: 9.1.7.13 Via ge-1/0/6.0
> LabelOperation: Push, Outgoing-label: 2046
> Created: Thu Aug 2 09:48:01 2012
> Bandwidth: 0 bps
> Statistics: Packets 0, Bytes 0
> Total 2, displayed 1, Up 1, Down 0
>
> Transit LSPs:
> Total 1, displayed 0, Up 0, Down 0
>
> Bypass LSPs:
> Total 0, displayed 0, Up 0, Down 0
>
> [edit]
> bala@MX240#
>
> bala@MX240# run show vpls statistics instance slsp-vpls
> VPLS statistics:
>
> Instance: slsp-vpls
>Local interface: ge-1/1/9.0, Index: 87
> Broadcast packets:769916
> Broadcast bytes : 197098496
> Multicast packets: 0
> Multicast bytes : 0
> Flooded packets : 0
> Flooded bytes: 0
> Unicast packets : 0
> Unicast bytes: 0
> Current MAC count: 0 (Limit 1024)
>
> [edit]
> bala@MX240#
>
>
> [edit]
> bala@MX240#
___
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 Forwarding Address
In this case, router 1 is originating external the LSA through redistribution of the static, hence the other routers will see R1 as the next hop. Although i have never done this myself, I think you should be able to manipulate your OSPF export policy to include a 'then next-hop 10.10.200.1' to manipulate the forwarding-address. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Aug 2, 2012, at 7:59 AM, Benny Amorsen wrote: > I have a weird problem where I can get IOS to set the Forwarding Address > for an external type 2 route (LSA type 5) in OSPF, but I cannot get > Junos to do the same. > > The test network has 3 devices. Two of them are VRF's in an MX80 > (router1 10.10.200.10 and router2 10.10.200.11), the last one is a > firewall (fw 10.10.200.1). All connected to the same switch, and > the network is a /27. > > The MX80-VRF's are talking OSPF, again completely plainly configured > simply by putting the interface in area 0.0.0.0. > > router1 has a static route to 192.168.200.0/24 via fw 10.10.200.1. It > redistributes this route into OSPF, again a completely plain policy just > saying "from static" "then accept". > > router2 receives the route through OSPF but Forwarding Address is not > set. Therefore it sends traffic destined for 192.168.200.0/24 to > router1 -- which is sort-of correct, but it would be much better if > the traffic was passed directly to the firewall. > > If I replace router1 with a VRF on a Cisco 7600, Forwarding Address > is set to 10.10.200.1 and everything works as I expected. This is > obviously not my preferred solution :) > > > /Benny > > > > ___ > 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] Information about source nat
It all really depends on a number of factors. Does this host require bidirectional communication, I.e. should it be able to initiate sessions outbound in addition to receiving sessions initiated inbound? If that's the case, static NAT is the way to go. Sent from my HTC on the Now Network from Sprint! - Reply message - From: "bizza" Date: Tue, Jul 3, 2012 8:03 am Subject: [j-nsp] Information about source nat To: Hi all, I have an srx cluster with many ip addresses on external interface. I need to assign an external ip to a specific host/subnet/port. For example, a server in DMZ must send email using a specific IP. Which is the best way to do this? Persistent nat? Nat pool? Any hints? Regards Marco ___ 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] Whats the best way to announce an IP range in BGP? Doesn't physically exist anywhere.
Sorry for the top post... Seems phone vendors haven't figured out how to create a decent email editor on a phone yet. When I worked at Arbor, we always recommended that customers would front end anything maintaining state (i.e. a SFW) with something that didn't (i.e. a Router) and to use Stateless ACLs to allow through only that which was absolutely required in order to allow stateful devices further downstream to perform their duties more efficiently. Then customers buy something like a Juniper SRX in an attempt to collapse their network (routing & firewalling) and believe that they are now back to front ending everything with a stateful device. The beauty of the SRX device is that while it is a stateful device, traffic arriving on interfaces can still be processed by stateless FFs which get processed before handing it off to the the stateful FW module and consuming precious recources on the SPCs. So by all means, collapse your network if you need to, use a single box for routing and firewall if your design warrants it, but make sure you still use common sense and deploy it in a manner that is consistent with best current practices and will safeguard your network without itself becoming a bottleneck. Stefan Fouant GPG Key ID: 0xB4C956EC Sent from my HTC EVO. - Reply message - From: "joel jaeggli" Date: Sat, Jun 23, 2012 12:39 am Subject: [j-nsp] Whats the best way to announce an IP range in BGP? Doesn't physically exist anywhere. To: "Morgan Mclean" Cc: "juniper-nsp@puck.nether.net" On 6/22/12 9:49 AM, Morgan Mclean wrote: > This is exactly what happened. The session table filled up. One of our > security guys took down our edge 650 cluster from a single unix box out on > the net. This is what happens when you use a stateful box for an internet router. a router with a covering aggreate and some knowledge of the more specifc on the interior would inexpensively discard traffic bound for unreachable destinations. > > Sent from my iPhone > > On Jun 22, 2012, at 4:39 AM, "Scott T. Cameron" wrote: > >> On Wed, Jun 20, 2012 at 10:14 PM, Morgan McLean wrote: >> >>> I have a /24 I want to announce, but I don't actually have it anywhere on >>> the network. I NAT some of its IP's on the SRX that has the BGP session >>> with our providers. >>> >>> I've been using static routes with the discard flag, but I don't really >>> like the way the SRX handles traffic. It still creates sessions for traffic >>> destined to IP's not used anywhere (hitting the static route) and can be >>> easily dos'd because of this. >>> >>> Is there a better way to just tell our providers hey, we have this range? >>> >>> >> It sounds like you're using the SRX as an edge router with a BGP session >> upstream? >> >> I don't have this architecture here, but I had the same problem. I had my >> edge router announce the /24 to the BGP upstreams, and my SRX announce the >> /24 via OSPF to the MX. >> >> Unfortunately, one of my IPs was hammered, and filled up the session table >> with invalid sessions. That's the real issue, at least in my case, was >> that even invalid sessions were taking a session, and prohibiting >> legitimate traffic from flowing. >> >> The solution was only to announce from SRX to MX (edge router) the /32s >> that were actually in use. >> >> I suppose that a firewall filter may help on your ingress ports to only >> permit the traffic to the /32s that are actually in use, but I can't say >> from experience if this will happen before a session is created, even in >> invalid state. >> >> Scott >> ___ >> 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] Best practice MTU?
On 4/26/2012 5:32 PM, OBrien, Will wrote: Anyone have suggestions for a best practice MTU? (That is over 9000?!) You know before you go about changing MTUs to something over 9000, you might want to take a look at this youtube video. These two guys talk about the pros and cons of setting it to over 9000 and after watching it I kinda get the idea that it might not be such a good thing: http://www.youtube.com/watch?v=SiMHTK15Pik -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] looking for jncie-sp study follow
On 4/24/2012 8:42 PM, Juniper Maillist wrote: Thanks, Do you recommend taking the bootcamp just before entering the exam (1 week before) for well prepared candidates? If no, when do you recommend to take it? No, this is a big mistake. I recently taught the bootcamp and had two candidates attempt to sit the exam the very next week and both failed despite being fairly well prepared. No matter how well prepared you are, during the bootcamp you are going to identify areas that need improvement. I think a few weeks are warranted to go through and master those areas prior to sitting the exam. If you can, I'd schedule the actual exam about a month after taking the bootcamp. HTHs. -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] looking for jncie-sp study follow
On 4/24/2012 7:32 PM, Ron Johnson wrote: In other news today... http://www.proteus.net/about/press-room/torrey-point-acquires-proteus-networks Big congrats to Joe Soricelli and Doug Marschke who both founded Proteus and are frequent visitors/posters on this list. All the best to you in your new venture and teaming up w/ TorreyPoint. -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] looking for jncie-sp study follow
On 4/24/2012 7:31 PM, Juniper Maillist wrote: Hi Stephan, How can we order the JNCIE-SP bootcamp material from the OnFullifillment website? I could not find it in the courses lists. I was mistaken, it appears we do not offer the bootcamp materials on our onfulfillment website at this time, although this may be subject to change sometime in the future. -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Interconnect two VRFs via L2 security box with redundant path
Comments in-line... On 4/24/2012 1:48 PM, Clarke Morledge wrote: Stefan, I was just hunting through your blog for ideas when I saw your post :-) Thanks for jumping in. A few responses in-line below. On Tue, 24 Apr 2012, Stefan Fouant wrote: If that adjacency goes down, a simple floating static (static route w/ higher preference than the dynamic BGP/IS-IS route) can be used pointing to next-table will do the trick. No need to used Logical-Tunnels or use auto-export. If my two routers were directly connected all of the time, this would be fine. But I'm also thinking of the case of when there might be another L3 hop between the two routers. I guess I could insert another floating static on the third router, but that just seemed to add a little more complexity to me. I was hoping for a way to just let the dynamic routing protocols do the work for me instead of fooling with a bunch of statics with filter-based forwarding. Don't get me wrong, I like FBF. I was just hoping to leverage dynamic routing more. I guess what I was referring to is that you don't really need to have the MX West device be used at all in the event that the L2 Packet scrubber dies, as per the restrictions in your initial email: "I also need to have a redundant path, preferably passing through the other core router (MX West). In the event that the Layer2 box dies, or if the MX East core router dies, unfortunately traffic will not get inspected but I will still have connectivity between the North and South VRFs via the MX West core router. " What I'm saying is that if the Packet Scrubber dies, the protocol adjacency through the VR North and the VR South on the MX East device will fail, and you could simply route directly from VR North to VR South on the same device by using simple floating static route pointing to next-table. In other words, if traffic arrives in VR North on MX East and packet scrubber device dies, then the floating static in vr_north.inet.0 will point to vr_south.inet.0, and vice-versa for traffic in the reverse direction. So you have no need for a redundant path through MX West and that would only be used in the event that the entire MX East device goes down. Of course, in your case you've got not just two VRFs but also an East and West path which further complicates things - why not just connect the MX West device into your L2 Packet Scrubber as well and keep things the same on both the East and West device so that you can take full advantage of two planes. This will keep configurations uniform regardless of whether traffic comes in on the East or West devices. I should have given the reason why I do not put the L2 scrubber between the two routers: conservation of fiber. I already have fiber connecting the routers in different wiring centers for traffic that does not need to be scrubbed. Chewing up another set of strands is much more expensive than simply connecting both sides of the L2 scrubber to just one router in the same rack. Makes sense... -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] looking for jncie-sp study follow
On 4/24/2012 2:02 PM, Devin Kennedy wrote: Hi Stefan: Do you also have a recommendation for study materials for the JNCIP-SP (taking to renew JNCIE-M) and also for study towards the JNCIE-SEC exams? Hi Devin, The same materials that you would use to prepare for JNCIE are also the ones you would use to prepare for the JNCIP written exam, so JCOS, JMV, JMR, and AJSPR. I would say the majority of the exam is based on routing so your main focus should be on the AJSPR materials - lot of BGP, IS-IS and OSPF questions. If you're already JNCIE-M, I would say a light review would be sufficient - the passing score is pretty low so I don't think you'll have any problems. For the SEC exam, I would recommend JSEC, AJSEC, JIPS, and JUTM, as well as a cover-to-cover read of the 'Junos Security' book by Rob Cameron, Tim Eberhard, et. al. Get your hands on some SRX devices and spend as much time as possible mocking up different scenarios. Since you're already JNCIE-M, I think you could do SEC preparation in as little as 3 months if you're focused. Also you can check out my blog for more info on the SEC exam: http://www.shortestpathfirst.net/2011/09/12/preparation-tips-for-the-jncie-sec-exam/ Good luck! -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] looking for jncie-sp study follow
On 4/24/2012 2:02 PM, Devin Kennedy wrote: Hi Stefan: Do you also have a recommendation for study materials for the JNCIP-SP (taking to renew JNCIE-M) and also for study towards the JNCIE-SEC exams? Hi Devin, The same materials that you would use to prepare for JNCIE are also the ones you would use to prepare for the JNCIP written exam, so JCOS, JMV, JMR, and AJSPR. I would say the majority of the exam is based on routing so your main focus should be on the AJSPR materials - lot of BGP, IS-IS and OSPF questions. If you're already JNCIE-M, I would say a light review would be sufficient - the passing score is pretty low so I don't think you'll have any problems. For the SEC exam, I would recommend JSEC, AJSEC, JIPS, and JUTM, as well as a cover-to-cover read of the 'Junos Security' book by Rob Cameron, Tim Eberhard, et. al. Get your hands on some SRX devices and spend as much time as possible mocking up different scenarios. Since you're already JNCIE-M, I think you could do SEC preparation in as little as 3 months if you're focused. Also you can check out my blog for more info on the SEC exam: http://www.shortestpathfirst.net/2011/09/12/preparation-tips-for-the-jncie-sec-exam/ Good luck! -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] looking for jncie-sp study follow
On 4/24/2012 11:17 AM, bruno.juniper wrote: ths stefan, i have do most of lab in cjnr /ajnr/ advance vpn/ jncip lab guide /jncie lab guide and Proteus Networks workbook. didn't take jncie-sp bootcamp. it's too expensive for me. Bruno, The CJNR/AJNR/Advanced VPN are all really old and have been updated with a lot of additional material that you are likely to see on the exam. The material you have will leave a lot of gaps so I don't recommend using that material as your sole means of preparation. I would honestly take a look at our Onfulfillment website and get some of the updated materials and study those before sitting the exam: http://www.onfulfillment.com/JuniperTrainingPublic/WelcomePublic.aspx?sid=323 Honestly, I would suggest maybe postponing your lab attempt while you take a look at the updated materials. It's a really tough exam and you will have a lot of gaps if you don't have the latest materials. Cheers, -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX650 Cluster throughput
On 4/24/2012 11:36 AM, Jeff Rooney wrote: So I'm doing some testing with an SRX 650 cluster(11.2R6.3) and am starting to see some odd throughput issues, being that this is my first SRX cluster, I'm most likely overlooking something minor. Physical setup is pretty basic, each srx has multiple links connected into its own switch, as well as two cross connects between the pair of SRX for control and fabric. The switches are connected with a 4 port portchannel. All interfaces are gig and negotiated to 1000m. Switches are catalyst 4948's, if that matters. SRX-node0 sw0 | | | | | SRX-node1 sw1 I have two servers connected into sw0, when on the same vlan iperf udp tests show 900Mbits/sec and tcp tests show 940+Mbits/secso far so good. Moving one box to another vlan and a seperate reth, so traffic now traverses srx-node0...traffic plummets. Iperf udp shows 500Mbits/sec and tcp 317Mbits/sec. Prior to setting up the cluster I tested via a single SRX and saw 900Mbits/sec+ for both tcp and udp. Both hosts are on the same switch and traversing node0 which is also on the same switch. Each vlan terminates on its own reth. Any suggestions as to where to look next? What are you using to generate traffic? Is it a single flow by any chance? -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] looking for jncie-sp study follow
On 4/24/2012 11:17 AM, bruno.juniper wrote: ths stefan, i have do most of lab in cjnr /ajnr/ advance vpn/ jncip lab guide /jncie lab guide and Proteus Networks workbook. didn't take jncie-sp bootcamp. it's too expensive for me. Bruno, The CJNR/AJNR/Advanced VPN are all really old and have been updated with a lot of additional material that you are likely to see on the exam. The material you have will leave a lot of gaps so I don't recommend using that material as your sole means of preparation. I would honestly take a look at our Onfulfillment website and get some of the updated materials and study those before sitting the exam: http://www.onfulfillment.com/JuniperTrainingPublic/WelcomePublic.aspx?sid=323 Honestly, I would suggest maybe postponing your lab attempt while you take a look at the updated materials. It's a really tough exam and you will have a lot of gaps if you don't have the latest materials. Cheers, -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] looking for jncie-sp study follow
On 4/24/2012 11:17 AM, bruno.juniper wrote: ths stefan, i have do most of lab in cjnr /ajnr/ advance vpn/ jncip lab guide /jncie lab guide and Proteus Networks workbook. didn't take jncie-sp bootcamp. it's too expensive for me. Bruno, The CJNR/AJNR/Advanced VPN are all really old and have been updated with a lot of additional material that you are likely to see on the exam. The material you have will leave a lot of gaps so I don't recommend using that material as your sole means of preparation. I would honestly take a look at our Onfulfillment website and get some of the updated materials and study those before sitting the exam: http://www.onfulfillment.com/JuniperTrainingPublic/WelcomePublic.aspx?sid=323 Honestly, I would suggest maybe postponing your lab attempt while you take a look at the updated materials. It's a really tough exam and you will have a lot of gaps if you don't have the latest materials. Cheers, -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX650 Cluster throughput
On 4/24/2012 1:01 PM, Jeff Rooney wrote: Single flow using iperf for all of my tests, only variation is that I'm using both udp and tcp tests, and via the cluster udp seems to handle better, but still only seeing 500Mbit Just for giggles why don't you increase your test to utilize multiple flows and lets see if you get different performance (this is going to be the more likely scenario anyways since it's unlikely you'll have a single host sending 900+ Mbits of traffic). Based on your results we can probably start to narrow down performance limitations. -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Interconnect two VRFs via L2 security box with redundant path
On 4/24/2012 12:44 PM, Clarke Morledge wrote: I have a design question to propose to the list. Suppose I have two VRFs in my MX routing core. Servers connect to one VRF (South) and the clients connect to the other VRF (North). I have a Layer2 security packet scrubbing box for inspecting traffic between my servers and clients. I have a sample network diagram: http://i.imgur.com/ZuOoC.png Here are my restrictions: a. I need to interconnect the North and South VRFs with the Layer2 security box physically at one of my two core routers (MX East). b. I also need to have a redundant path, preferably passing through the other core router (MX West). In the event that the Layer2 box dies, or if the MX East core router dies, unfortunately traffic will not get inspected but I will still have connectivity between the North and South VRFs via the MX West core router. c. Traffic is forced through the Layer2 box using dynamic routing protocols (I'd like to stay away from statics if I can). I would like to stick with IS-IS, but I could use BGP if needed for filtering purposes. I need to be careful not to introduce a routing loop between the two VRFs. The redundant link on MX West needs to be properly weighted such that it is completely passive except in the event that there is a failure at MX East and/or the Layer2 box. d. I have an MPLS infrastructure available in the core, so I could build a VPLS, L2 VPN, or L3 VPN if it would help. But I do want to keep things as simple as I can. How would you put together such a design? How would you implement the routing protocols between the VRFs? Would you use a logical tunnel at MX West to form the backup connection between the two VRFs? If you use vrf-import and vrf-export of routes (with auto-export) between the VRFs instead of a logical tunnel, how would you properly weight the routing information? Clarke, I've done designs like this before and it was always a combination of some dynamic routing protocol such as IS-IS or BGP between the two VRs across the L2 connection through the packet scrubber. This path will always be used so long as the adjacency remains operational. If that adjacency goes down, a simple floating static (static route w/ higher preference than the dynamic BGP/IS-IS route) can be used pointing to next-table will do the trick. No need to used Logical-Tunnels or use auto-export. Of course, in your case you've got not just two VRFs but also an East and West path which further complicates things - why not just connect the MX West device into your L2 Packet Scrubber as well and keep things the same on both the East and West device so that you can take full advantage of two planes. This will keep configurations uniform regardless of whether traffic comes in on the East or West devices. -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] looking for jncie-sp study follow
On 4/23/2012 11:26 PM, bruno.juniper wrote: Looking for study folks; My exam is in 2 moths.skype: brunojuniper Your best bet is to go through all the labs in JIR, AJSPR, JMV, JMR, and JCOS. Mock these up and go through as many different scenarios as possible. Also, the labs in Harry Reynolds' JNCIP and JNCIE Study Guides are still good to go through as they are somewhat representative of the type of stuff you will seen on the exam. In addition, have you taken our JNCIE-SP bootcamp? You can order these materials from our OnFullfillment website. -- Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Hurry Juniper vouchers 100 % off Valid for 100 days !!!!!!!!!!!!!!!!!!!!!
I think he's offering the vouchers for any of the written exams, so that someone could take the respective P level exam to recent their IE. The folks at cert are not going to like this... I think there is a clause on the voucher that says they are not to be for resale... Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Mar 26, 2012, at 11:40 AM, Doug Hanks wrote: > Those exams are retired anyway. > > Thank you, > > -- > Doug Hanks - JNCIE-ENT #213, JNCIE-SP #875 > Sr. Systems Engineer > Juniper Networks > > > On 3/25/12 7:21 AM, "Jose Madrid" wrote: > >> To be clear, he is selling these and not just giving them away. >> >> On Sun, Mar 25, 2012 at 10:05 AM, CCIE 2008 wrote: >> >>> *Hi all* >>> * >>> * >>> *If anyone interested in recertify your JNCIP-M, JNCIE-M or JNCIE-ER >>> credential, offering you a voucher for 100% off Junos-based >>> Professional-level (JNCIP) exam price - a $300 value! If you wish to >>> remain >>> Juniper Networks-certified .* >>> * >>> * >>> >>> >>> *Unicast me fast if you need any .* >>> * >>> * >>> * >>> * >>> *Best regards* >>> ___ >>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> >> >> >> >> -- >> It has to start somewhere, it has to start sometime. What better place >> than here? What better time than now? >> ___ >> 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] Hidden IPv4 iBGP routes
Yes this is correct and is indeed the default Junos behavior. If you wanted to receive a looped BGP update, you can define the amount of loops allowed (.i.e. number of times your own AS appears in the AS Path attribute) by configuring the 'set routing-options autonomous system loops ' command. HTHs. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Mar 13, 2012, at 4:10 PM, "Mohammad" wrote: > Hi john; > > > > As far as I know when an eBGP router receives a route contains its own AS > in the AS path it consider it as a loop, so for your case the juniper router > is seeing its own AS () in the route's ASPATH received from its eBGP > neighbor (X Y I), so the solution I would suggest is to remove AS > on the other router before sending it to the juniper router, if is > a private AS you can use remove private on the other router; or you can use > AS override. > > Hope it is helpful; > Mohammad Salbad > ___ > 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] How to calculate "burst-size-limit" in JUNOS Firewall Policer
It should be 5ms of the interface speed, not 5ms of the CIR
Stefan Fouant
GPG Key ID: 0xB4C956EC
Sent from my HTC EVO.
- Reply message -
From: "Arun Kumar"
Date: Thu, Mar 8, 2012 6:24 am
Subject: [j-nsp] How to calculate "burst-size-limit" in JUNOS Firewall Policer
To:
Hi All,
I am facing some issues in calculating the right burst size limit for
Firewall policer in Junos. As per the document, the burst size limit is
calculated like below:
1. The minimum value allowed is 1500 bytes.
2. The minimum value should be 10 times of interface MTU.
3. Burst size limit is calculated for 5ms for data burst. Burst size limit
= (bandwdith limit *0.005)/8
That is for CIR=2048000 (bandwidth limit 2048000 bps), burst size limit is
2048000 * 0.005 / 8 = 1480 bytes. Since this violates point no 2, I set
burst-size-limit to 15180 bytes (interface Gigabit MTU is 1518 bytes). When
I set this, I am not able to pass traffic more than 200kbps. Only I
increase the burst-size-limit to higher random value policer works as
expected.
user@host# show firewall policer TEST
if-exceeding {
bandwidth-limit 2048000;
burst-size-limit 15180;
}
then discard;
How to calculate the correct burst-size-limit for Junos Firewall Policer?
thanks
Arun
___
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] Dual Stack Aggregate Policing via Firewall Filter
Hi Devin,
Have you tried using a Physical Interface Policer? A Physical Interface
Policer will allow you to apply your policers across different terms across
different firewall filters, that are applied to different protocol families
on a single physical interface, and then it will merge all the filters which
call that policer on the same physical interface. The cool thing is you can
use this across different logical interfaces that might even be in different
routing instances!
Try something along the following:
[edit firewall]
policer cos1_drop_8000K_out_medium {
physical-interface-policer; < This is required
if-exceeding {
bandwidth-limit 8m;
burst-size-limit 1m;
}
then discard;
}
family inet {
filter filter-ipv4 {
physical-interface-filter; < This is required
term 1 {
from {
protocol tcp;
port 80;
}
then {
policer cos1_drop_8000K_out_medium;
accept;
}
}
}
}
family inet6 {
filter filter-ipv6 {
physical-interface-filter; < This is required
term 1 {
from {
protocol tcp;
port 80;
}
then {
policer cos1_drop_8000K_out_medium;
accept;
}
}
}
}
HTHs.
Stefan Fouant
JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI
Technical Trainer, Juniper Networks
> -Original Message-
> From: Devin Kennedy [mailto:devinkennedy...@hotmail.com]
> Sent: Thursday, March 01, 2012 9:08 AM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] Dual Stack Aggregate Policing via Firewall Filter
>
> Hello:
>
>
>
> We are currently testing dual stack CoS on the Juniper platform and
> we're not seeing any way to aggregate the policing applied to IPv4 and
> IPv6. We want to allocate a customer a specific amount of bandwidth,
> say 10m (including both IPv4 and IPv6 traffic in any proportional
> amount), and have the traffic policed to 10m regardless of the amount
> of IPv4 or IPv6 traffic.
>
>
>
>
> I see there is an option to use a logical-interface-policer at the unit
> level:
>
>
>
> firewall policer 10M-policing
>
> {
>
> logical-interface-policer;
>
> if-exceeding {
>
> bandwidth-limit 10m;
>
> burst-size-limit 100k;
>
> }
>
> then discard;
>
> }
>
>
>
>
>
> interfaces {
>
> fe-2/0/3 {
>
> vlan-tagging;
>
>unit 200 {
>
>vlan-id 200;
>
> policer {
>
> input 10M-policing;
>
> output 10M-policing;
>
> }
>
>
>
> However, we are policing differently for each CoS queue so we need to
> call policers via MF and BA filters. The problem is that there has to
> be a different filter for each family (inet and inet6), so the two are
> not able to use an aggregate amount. So if we apply the same 10m
> policer to each family it won't aggregate and instead applies an
> instance of the policer for each family (so a total of 20m).
>
>
>
> Does anyone know if it's possible to configure an aggregate policer
> across two different firewall filters? Below is an example of what we
> are currently doing:
>
>
>
> ge-0/0/1 {
>
> per-unit-scheduler;
>
> vlan-tagging;
>
> speed 100m;
>
> link-mode full-duplex;
>
> gigether-options {
>
> no-auto-negotiation;
>
> }
>
> unit 2001 {
>
> vlan-id 2001;
>
> family inet {
>
> filter {
>
> output cos_filter;
>
> }
>
> address x.x.x.x/30;
>
> }
>
> family inet6 {
>
> filter {
>
> output cos_filter-v6;
>
> }
>
> address x::x/64;
>
> }
>
> }
>
> }
>
>
>
> The cos_filter then calls BA and MF filters such as:
>
>
>
> [edit]
>
> juniper@SRX210-2-IPV6# show firewall family inet filter cos1_MF
>
> term 1 {
>
> from {
>
> protocol [ udp tcp ];
>
> port 2081;
>
> }
>
> then {
>
> policer cos1_drop_8000K_out_medium;
>
> count COS1_MF_counter;
>
> forwarding-class cos1;
>
> accept;
>
> }
>
> }
>
>
>
> [edit]
>
> juniper@SRX210-2-IPV6# show firewall family inet filter cos1_ba
>
> term 1 {
>
> from {
>
> dscp [ 46 40 ];
>
> }
>
> then {
>
> policer
Re: [j-nsp] MX960 Redundant RE problem
I was referring more to a bug in hardware... Bad memory, etc. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Feb 15, 2012, at 1:56 PM, Daniel Roesen wrote: > On Wed, Feb 15, 2012 at 12:24:50PM -0500, Stefan Fouant wrote: >> The cool thing is the Backup RE is actually listening to all the >> control plane messages coming on fxp1 destined for the Master RE >> and formulating it's own decisions, running its own Dijkstra, >> BGP Path Selection, etc. This is a preferred approach as opposed >> to simply mirroring routing state from the Primary to the Backup >> is because it eliminates fate sharing where there may be a bug >> on the Primary RE, we don't want to create a carbon copy of that >> on the Backup. > > I don't really buy that argument. Running the same code with the same > algorithm against the same data usually leads to the same results. > You'll get full bug redundancy - I'd expect RE crashing simultaneously. > Did NSR protect from any of the recent BGP bugs? > > The advantage I see are less impacting failovers in case of a) hardware > failures of active RE, or b) data structure corruption happening on both > REs [same code => same bugs], but eventually leading to a crash of the > active RE sooner than on the backup RE, or c) race conditions being > triggered sufficiently differently timing-wise so only active RE > crashes. > > Am I missing something? > > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX960 Redundant RE problem
Morgan,
You are correct if you are running GRES only, however if you enable NSR
basically the Backup RE also actively runs rpd and maintains state adjacencies,
etc, so in the event of a Primary RE failure you will not need to reestablish
adjacencies, etc.
The cool thing is the Backup RE is actually listening to all the control plane
messages coming on fxp1 destined for the Master RE and formulating it's own
decisions, running its own Dijkstra, BGP Path Selection, etc. This is a
preferred approach as opposed to simply mirroring routing state from the
Primary to the Backup is because it eliminates fate sharing where there may be
a bug on the Primary RE, we don't want to create a carbon copy of that on the
Backup.
Stefan Fouant
JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI
Technical Trainer, Juniper Networks
Follow us on Twitter @JuniperEducate
Sent from my iPad
On Feb 15, 2012, at 2:56 AM, Morgan McLean wrote:
> Correct me if I'm wrong, but backup routing engines never have adjacencies
> or peering relationships etc because they are not active, correct? When
> they become master they have to reestablish those sessions. Thats how it
> seems to be for our SRX routing engines, at least, but routes are shared
> between the two so that during the time it takes for those things to
> reestablish, the routes are still moving traffic.
>
> I might be wrong, but that was my impression.
>
> Morgan
>
> 2012/2/14 Mohammad
>
>> Hi everyone
>>
>>
>>
>> We have an MX960 with two routing engines, Re0: Backup, Re1: Master
>>
>> When we try to switchover to the backup RE we see the following message:
>>
>> XXX# run request chassis routing-engine master switch
>>
>> error: Standby Routing Engine is not ready for graceful switchover
>> (replication_err soft_mask_err)
>>
>> Toggle mastership between routing engines ? [yes,no] (no)
>>
>> Noting that we used to switchover between the two Res a day a before with
>> no
>> issues
>>
>>
>>
>> Also, when we login to the re0 (backup) and check the isis, rsvp, etc… we
>> see the following:
>>
>> XXX> request routing-engine login other-routing-engine
>>
>> €
>>
>> --- JUNOS 10.2R3.10 built 2010-10-16 19:24:06 UTC
>>
>> {backup}
>>
>> XXX> show isis adjacency
>>
>>
>>
>> {backup}
>>
>> XXX> show rsvp session
>>
>> Ingress RSVP: 0 sessions
>>
>> Total 0 displayed, Up 0, Down 0
>>
>>
>>
>> Egress RSVP: 0 sessions
>>
>> Total 0 displayed, Up 0, Down 0
>>
>>
>>
>> Transit RSVP: 0 sessions
>>
>> Total 0 displayed, Up 0, Down 0
>>
>>
>>
>> {backup}
>>
>> XXX>
>>
>> While we can see the bgp routes and L3VPN routes,,,
>>
>> We have tried to replace the backup with another one, but with the same
>> results
>>
>> Any ideas, this issue is really confusing us, and it is a very critical
>> router in our network.
>>
>>
>>
>> Thank you in advance
>>
>> Mohammad Salbad
>>
>> ___
>> 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] how to prepare JNCIE-SP lab
Bruno, You might want to listen to the certification webinar we put together a few weeks ago: http://www.juniper.net/us/en/community/junos/live/111005/#overview Bottom line, if you can get yourself a single MX you can use logical-systems and logical- tunnel interfaces to emulate a large topology, or in lieu of that you can get your hands on some branch SRX devices and convert them to packet mode. The following blog article I wrote for the M series exam a while back covers the configuration required if you choose to use MX with Logical Systems. http://www.shortestpathfirst.net/2010/01/13/preparation-tips-for-the-jncip-mt-and-jncie-mt-exams/ Study material from Junos Class of Service, Junos Multicast Routing, Junos MPLS & VPNs, and the Advanced Junos Service Provider Routing curriculum, and do all the associated labs as they are highly indicative of the type of things you will see on the exam. Harry Reynold's now out-of-print JNCIP and JNCIE Study Guides are still useful for preparation as well... You can find them in PDF format by searching for them on Google. Study hard and practice, practice, practice... Learns those tricks like 'load merge terminal relative', 'load patch', copy and paste techniques in conjunction with 'show | display set'. Another little trick that will save you time when determining aggregates for summarization: http://www.shortestpathfirst.net/2011/06/21/jncie-tips-from-the-field-summarization-made-easy/ Good luck and may the force be with you! Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Oct 26, 2011, at 10:50 PM, "bruno" wrote: > hello guys, > > I have pass jncip-m last year. coz i don't have time to prepare jncie-m ,so i > give up. now i am avaible for jncie .juniper said the MX > series was added in the lab . how to prepare for it .should i buy mx device? > any suggestion? also need JNCIE peer . > -- > Best Regards, > Bruno > ___ > 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] Summarize Global Table
You can use aggregate /generated routes which require more specific contributing routes to become active, and then only advertise the protocol aggregate routes to your downstream nodes that have smaller tables, however you still need to create the aggregates which is a manual process. You can get pretty creative however, in your definition of aggregates, so that they can encompass a large number of specifics - for example, if your downstream node only supported a FIB of a few routes, you could create 2 aggregates on the upstream node, perhaps 0/1 and 128/1. This is an extreme example, but you get the idea. As far as I know, there are no ways to automatically summarize along the lines of what you are getting at because routers aren't intelligent enough to determine what prefix masks to use for summarization without user input. What you would need to accomplish what you are describing is some way to tell the device that you want to summarize all the routing information into x number of prefixes, and then have the router automatically compute the best summaries where routing information overlaps and can be consolidated into a single prefix/mask combination. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Oct 25, 2011, at 12:21 PM, Brad Fleming wrote: > Are there any tricks to auto-summarize the contents of a RIB where the > tributary routes are not originated locally? > > Example: > Input routes: > prefix: 1.0.0.0/16, next-hop: 5.5.5.5 > prefix: 1.0.1.0/16, next-hop: 5.5.5.5 > prefix: 1.0.2.0/16, next-hop: 4.4.4.4 > prefix: 1.0.3.0/16, next-hop: 5.5.5.5 > > Consolidated, Installed routes: > prefix: 1.0.0.0/14, next-hop: 5.5.5.5 > prefix: 1.0.2.0/16, next-hop: 4.4.4.4 > > Basically a way to consolidate total number of prefixes entering the FIB. > > If such a thing existed we could feed non-Juniper, TCAM-based routers a > smaller table but still maintain the advantages of best path, hot potato > routing. > ___ > 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] Logical interface policer question
Logical-interface policer will group all protocol families on a given logical
interface (i.e. unit) into the same policer construct. Normally, if you have
an interface, say ge-0/0/0.0 and you have two protocol families, say family
inet and family inet6, both referencing the same input policer, Junos actually
invokes two separate policer instances - one for each protocol family. So if
the policer was a 100 Mbps policer, each protocol family would get 100 megs...
By enabling the logical-interface policer command, you can think of it
aggregating all protocol families on that interface, so now instead of each
getting 100 meg, they actually share a single policer instance, effectively
sharing 100 meg between the two.
Hope that helps and sorry for any typos, I am on my mobile...
Stefan Fouant
GPG Key ID: 0xB4C956EC
Sent from my HTC EVO.
- Reply message -
From: "tim tiriche"
Date: Tue, Oct 11, 2011 8:29 pm
Subject: [j-nsp] Logical interface policer question
To:
Hi,
I am preparing for JNCIP-SP exam and would like to understand what
logical interface policer statement does?
The documentation says it is an aggregate policer but it is not very
clear to me.
policer example:
[edit firewall]
+ policer policer-test {
+ logical-interface-policer;
+ if-exceeding {
+ bandwidth-limit 10m;
+ burst-size-limit 100k;
+ }
+ then discard;
+ }
[edit interfaces ge-2/0/0 unit 0]
+ family inet {
+ policer {
+ input policer-test;
+ }
+ address 1.1.1.1/30;
+ }
+ family inet6 {
+ policer {
+ input policer-test;
+ }
+ address abcd::1/64;
+ }
[edit interfaces ge-2/0/0 unit 1]
+ family inet {
+ policer {
+ input policer-test;
+ }
+ address 2.2.2.2/30;
+ }
[edit interfaces]
+ ge-2/0/1 {
+ unit 0 {
+ family inet {
+ policer {
+ input policer-test;
+ }
+ address 121.1.1.1/30;
+ }
+ }
+ }
does this mean that a total of 10M will be shared among all the
interfaces and protocol families on a first come first serve basis?
or does each unit get 10M (i.e ge-2/0/0 (inet+inet6) = 10M, ge-2/0/0.1
= 10M, ge-2/0/1=10M?
or does each physical interface get 10M? (i.e ge-2/0/0 = 10M + ge-2/0/1 = 10M)
is there any way to check this on a jseries router on a m/t series, i
believe there was a PFE command on the FPC to see the value.
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] config help
Haha looks like Robert already responded to you... At least it's nice to know I'm not crazy and someone else would give you similar advice... :-b Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Oct 10, 2011, at 9:19 AM, Stefan Fouant wrote: > If you are using EX Series, take a look at PVLANs - > http://www.juniper.net/techpubs/en_US/junos10.0/topics/concept/private-vlans-ex-series.html > > This allows you to split broadcast domains into separate isolated broadcast > subdomains to constrain connectivity while at the same time keeping devices > in the same subnet and thereby reducing your overall IP address utilization. > > HTHs. > > Stefan Fouant > JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI > Technical Trainer, Juniper Networks > > Follow us on Twitter @JuniperEducate > > Sent from my iPad > > On Oct 10, 2011, at 4:59 AM, Richard Zheng wrote: > >> Hi, >> >> Here is our setup. Customer A comes in on vlan 2001, customer B on vlan 2002 >> and etc. We may uses separate subnets for each vlan. However it wastes lots >> of IPs. Is there a way to use the same subnet, e.g. vlan 2001 uses IP >> 10.0.0.10, and vlan 2002 uses IP 10.0.0.11 and 10.0.0.12. How about use >> 10.0.0.1/24 as loopback, enable proxy-arp on each vlan, then put a filter on >> each interface to only allow assigned IP to go through? >> >> Would this work on M7i/M10i? >> >> Thanks, >> Richard >> ___ >> 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] config help
If you are using EX Series, take a look at PVLANs - http://www.juniper.net/techpubs/en_US/junos10.0/topics/concept/private-vlans-ex-series.html This allows you to split broadcast domains into separate isolated broadcast subdomains to constrain connectivity while at the same time keeping devices in the same subnet and thereby reducing your overall IP address utilization. HTHs. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Oct 10, 2011, at 4:59 AM, Richard Zheng wrote: > Hi, > > Here is our setup. Customer A comes in on vlan 2001, customer B on vlan 2002 > and etc. We may uses separate subnets for each vlan. However it wastes lots > of IPs. Is there a way to use the same subnet, e.g. vlan 2001 uses IP > 10.0.0.10, and vlan 2002 uses IP 10.0.0.11 and 10.0.0.12. How about use > 10.0.0.1/24 as loopback, enable proxy-arp on each vlan, then put a filter on > each interface to only allow assigned IP to go through? > > Would this work on M7i/M10i? > > Thanks, > Richard > ___ > 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] Request for help from the community
Thank you to all of you who have provided me comments offline. Very much appreciated. Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate On 9/21/2011 10:13 AM, Stefan Fouant wrote: Hi all, I am in the process of writing some literature regarding VPLS and would like to ask you, the Junos user community, to provide some insight into what you would like to see in embodied in such a work. What are some of the areas with which you feel need more clarification, either from a theoretical standpoint or in practical implementations, additionally, what areas do you feel the VPLS documentation is lacking and warrants better examples. Is there interest in: - VPLS Multihoming scenarios? - Enabling Spanning Tree on the PE towards the CE per VPLS instance? - Enabling the use of P2MP LSPs for BUM traffic? As many suggestions as you can provide folks, feel free to respond privately if you so wish. Thanks in advance, ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Request for help from the community
Hi all, I am in the process of writing some literature regarding VPLS and would like to ask you, the Junos user community, to provide some insight into what you would like to see in embodied in such a work. What are some of the areas with which you feel need more clarification, either from a theoretical standpoint or in practical implementations, additionally, what areas do you feel the VPLS documentation is lacking and warrants better examples. Is there interest in: - VPLS Multihoming scenarios? - Enabling Spanning Tree on the PE towards the CE per VPLS instance? - Enabling the use of P2MP LSPs for BUM traffic? As many suggestions as you can provide folks, feel free to respond privately if you so wish. Thanks in advance, -- Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Policy-options: Logical AND for community values
On 9/20/2011 10:18 AM, Rafael Rodriguez wrote: Hello list, I've run into a snag and need some advice. *Goal:* Within a policy, reject prefixes that meet two conditions. All other prefixes are accepted. *Conditions (logical AND):* 1) Prefix must contain a community tag of "65000:999" 2) Prefix must NOT contain a community tag of "65000:.11.." (regex) In condition 2) it is much easier for me to describe what I don't want than it is to describe what I do want (invert-match community). Hi Rafael, I don't have the time to give a detailed answer at the moment, but have you thought about looking into Junos Policy subroutines? This seems like it'd be a perfect fit for your requirements. Definitely one of the lesser understood features of Junos but it's very powerful when you need it. http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-policy/policy-routing-policies-subroutine-evaluation-method.html Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Next Gen MVPN flooding assistance
On 9/20/2011 12:17 PM, Mark Tinka wrote: On another note, it sounds like you are working on some real interesting stuff Mark... It sure is, I do have to say :-). Just out of curiousity, since I am always eager to learn how people are deploying this in the real-world - do you have multiple ingress nodes streaming the same content and use diverse P2MP LSPs to your head-ends a-la "live-live" or some other approach for ensuring redundant data? Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Next Gen MVPN flooding assistance
On 9/20/2011 6:51 AM, Mark Tinka wrote: Cisco will need to move fast and implement NG-MVPN too, supporting both RSVP-TE and mLDP. I thought Cisco supported NG-VPN approach now... are they still only supporting PIM/GRE only? On another note, it sounds like you are working on some real interesting stuff Mark... Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netscreen Firewalls and TCP States/Bypass
On 9/20/2011 7:25 AM, Phil Mayers wrote: On 20/09/11 11:07, Stephan Tesch wrote: On Tue, 20 Sep 2011 08:31:33 +0100, Phil Mayers wrote: 'unset flow tcp-syn-check' is what you want but unfortunately it is a global setting, so all or nothing... Are you sure? I don't think that's what he wants; as suggested by the name, this relaxes the requirement for the 1st packet to be a syn/syn+ack pair, but the firewall will still expect to see both sides of the flow IIRC; in a previous iteration of our network, we were prone to asymmetric routing causing our firewalls problems, and we've run with "unset flow tcp-syn-" from day one. We had this (unset flow typ-syn-check) running on a large cluster the other day and once we turned the flow feature on, some dual-homed hosts stopped working due to incorrect routing tables. Up to that point our cluster only saw one side of the connection, without any problems. That has been ScreenOS 5.4 (back in the days). Don't know if this has changed in the 6.x line, we haven't turned it off since :) Sounds like I'm wrong and Stefan (and Stephan) are right! Don't feel bad... the behavior has changed somewhat over the years... it's hard to keep track of it all :) Doubly so in this case as we all push the ScreenOS stuff out of our minds to make room for SRX. Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netscreen Firewalls and TCP States/Bypass
'unset flow tcp-syn-check' is what you want but unfortunately it is a global setting, so all or nothing... You can issue a 'get flow' after the configuration change to verify the behavior. Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Sep 19, 2011, at 10:03 PM, "Josh Farrelly" wrote: > Hi all > > > > Does anyone know whether the Juniper Netscreen SSG20, running: > > > > Hardware Version: 710(0) > > Firmware Version: 6.1.0r2.0 (Firewall+VPN) > > > > Has any ability to bypass the checking of TCP states for certain > interfaces/hosts? > > > > I have a situation where we have one configured in a topology using > asymmetric routing. This will cause initial connections to go to the > SSG20 then be hairpinned and routed to a second gateway on the LAN. > > > > Doing this will obviously leave the device confused about the TCP state > considering the second default gateway is going to deliver direct to the > host. The SSG20 will see lots of out-of-order packets and SYNs/ACKs > where it shouldn't. > > > > On the Cisco ASA I can configure TCP state bypass, which essentially > lets the device treat TCP in a similar way it does UDP. Does anyone know > of any similar feature on the Juniper SSG20 that can allow it to work in > this situation? > > > > I know this isn't the best situation nor the best thing to be doing, but > it's only a stop-gap measure during our migration to new infrastructure. > > > > Regards, > > > > Josh Farrelly. > > ___ > 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] Next Gen MVPN flooding assistance
I think it often helps to use the old PIM-SM vs. PIM-DM example, where one might be more beneficial than the other depending on how sparse or densely distributed your receivers are. I-PMSIs certainly make a lot more sense for cable providers and other similar networks where content must be distributed to a bunch of head-end devices before being sent to set-top boxes, similar to your network Mark. On the other hand, S-PMSIs definitely make sense where receivers are more sparsely distributed and bandwidth considerations are paramount so relieving unnecessary replication state is desired. Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Sep 19, 2011, at 9:45 PM, Mark Tinka wrote: > On Friday, September 16, 2011 09:46:41 PM Krasimir Avramski > wrote: > >> Hi, >> >> It is normal behavior with inclusive P-tunnels (in your >> case P2MP lsps).It is default without explicit selective >> configuration. > > Indeed. > > We initially started out with I-PMSI's and then wanted to > shift to S-PMSI's, but then since we needed to deploy MPEG > probes at every Receiver PE router to record video signal > quality (and because any router configured with the NG-MVPN > routing instance has at least one IPTv customer), keeping I- > PMSI's makes sense. > > If you don't expect a Receiver PE router to ever have > Multicast receivers, you likely won't be setting P-tunnels > towards it in the first place :-). > > Now the annoying bit is when you use 'vrf-table-label' and a > P router generates two copies of every Multicast packet > toward a bud node. Quite annoying. > > Cheers, > > 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] "ping: sendto: Operation not permitted" in LAN
Hi Saku, I think we are simply getting the wires crossed. Your original email stated "Trio appears to change this, in inet6 simply doing 'match port X' without 'match next-header tcp|udp' correctly finds port X, regardless of its position in the frame (you can move the UDP/TCP port position via extension headers)." We were originally talking about TCP options, and somehow the topic got switched to the behavior with ports. I was responding that for port, current incarnations do the same thing (vs. Trio). I see your point however with regards to other behavior in Trio and agree it's better. Thanks, Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 19, 2011, at 4:29 AM, Saku Ytti wrote: > On (2011-08-18 21:23 -0400), Stefan Fouant wrote: > >> Trio has nothing to do with this - the behavior when matching on a >> port is completely different than using the bit-field match >> operators. Even without Trio, if you specify a match on a port >> without protocol, it will look in the appropriate locations >> depending on whether the traffic is TCP or UDP. That is not the >> case with bit-field match operators. >> >> See >> http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-policy/policy-firewall-filter-how-to-specify-match-conditions.html#jd0e29000 > > Thanks for clearing that up. However if 'port' assumes implied udp/tcp > (instead > of just finding port values in predefined offset, regardless of protocol) why > doesn't 'tcp-established' assume implied tcp? Is there any useful application > behind this inconsistency? > > Also do you have access internally to information which you are able to share, > when would JunOS CLI get 'match protocol udp|tcp|icmp' for ipv6? So users > could, in existance of extension headers still match for L4 protocol? > > Thanks again, > -- > ++ytti > ___ > 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] "ping: sendto: Operation not permitted" in LAN
This is the nature of stateless firewall-filters guys... It has been this way since the beginning and everybody else seems to understand this behavior. I don't see anybody else screaming that this is a gaping security hole. You do realize that this is no different than ACLs on Cisco right? If you need something that will handle traffic statefully, use a firewall instead. Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 19, 2011, at 6:33 PM, Nick Kritsky wrote: > "inconsistency"? > I would say "gaping security hole". I wonder how many routers out there are > setup to pass any IP packet with ACK bit turned on. > > Nick > > On Fri, Aug 19, 2011 at 5:50 PM, Stefan Fouant > wrote: > Hi Saku, > > 'tcp-established' or any of the other TCP bit-field match conditions do > assume an implied TCP, but they aren't actually checking to see if the > protocol is actually TCP. Therefore, they are simply looking for a bit to be > on or off at a specific offset where those fields would be if the packet was > actually TCP. > > What this means is that if the packet is anything other than TCP, and a > protocol match type of TCP is not specified, other packets may match if the > bit is set at that particular offset. > > This isn't really an "inconsistency" as you say and there are no real useful > applications here... This is why the Juniper documentation and other > literature is explicit to point out that you should always use a 'protocol > tcp' match when using these bit-field conditions... > > HTHs. > > Stefan Fouant > JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI > Technical Trainer, Juniper Networks > http://www.shortestpathfirst.net > http://www.twitter.com/sfouant > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] "ping: sendto: Operation not permitted" in LAN
Hi Saku, 'tcp-established' or any of the other TCP bit-field match conditions do assume an implied TCP, but they aren't actually checking to see if the protocol is actually TCP. Therefore, they are simply looking for a bit to be on or off at a specific offset where those fields would be if the packet was actually TCP. What this means is that if the packet is anything other than TCP, and a protocol match type of TCP is not specified, other packets may match if the bit is set at that particular offset. This isn't really an "inconsistency" as you say and there are no real useful applications here... This is why the Juniper documentation and other literature is explicit to point out that you should always use a 'protocol tcp' match when using these bit-field conditions... HTHs. Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 19, 2011, at 4:29 AM, Saku Ytti wrote: > On (2011-08-18 21:23 -0400), Stefan Fouant wrote: > >> Trio has nothing to do with this - the behavior when matching on a >> port is completely different than using the bit-field match >> operators. Even without Trio, if you specify a match on a port >> without protocol, it will look in the appropriate locations >> depending on whether the traffic is TCP or UDP. That is not the >> case with bit-field match operators. >> >> See >> http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-policy/policy-firewall-filter-how-to-specify-match-conditions.html#jd0e29000 > > Thanks for clearing that up. However if 'port' assumes implied udp/tcp > (instead > of just finding port values in predefined offset, regardless of protocol) why > doesn't 'tcp-established' assume implied tcp? Is there any useful application > behind this inconsistency? > > Also do you have access internally to information which you are able to share, > when would JunOS CLI get 'match protocol udp|tcp|icmp' for ipv6? So users > could, in existance of extension headers still match for L4 protocol? > > Thanks again, > -- > ++ytti > ___ > 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] "ping: sendto: Operation not permitted" in LAN
On 8/18/2011 3:18 PM, Saku Ytti wrote: On (2011-08-18 10:28 -0400), Stefan Fouant wrote: established. This can cause strange behavior since it's only looking for it a simple bit match against the TCP ACK or RST fields. However because you are not tying it specifically to TCP traffic, any packets which have a 1 value at that offset will match. Trio appears to change this, in inet6 simply doing 'match port X' without 'match next-header tcp|udp' correctly finds port X, regardless of its position in the frame (you can move the UDP/TCP port position via extension headers). Hi Saku, Trio has nothing to do with this - the behavior when matching on a port is completely different than using the bit-field match operators. Even without Trio, if you specify a match on a port without protocol, it will look in the appropriate locations depending on whether the traffic is TCP or UDP. That is not the case with bit-field match operators. See http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-policy/policy-firewall-filter-how-to-specify-match-conditions.html#jd0e29000 for more information. HTHs. Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] "ping: sendto: Operation not permitted" in LAN
On 8/18/2011 8:21 AM, Martin T wrote:
As you can see, there is a firewall applied to ge-0/0/0.10.
Configuration of the "fw-out" is following:
term established {
from {
tcp-established;
}
then {
count established;
accept;
}
}
You don't have a match for protocol TCP here in your term established.
This can cause strange behavior since it's only looking for it a simple
bit match against the TCP ACK or RST fields. However because you are
not tying it specifically to TCP traffic, any packets which have a 1
value at that offset will match.
The same applies to every host in 192.168.1.0/28 network. If I ping
the M20(192.168.1.14) from servers there is same amount of packet
loss. Any ideas, what might cause this "ping: sendto: Operation not
permitted"? If additional information is needed, please ask :)
Honestly, I am unsure how any of your ping packets are getting out due
to the fact that you don't have any terms allowing ICMP echo-requests
outbound. My only thought here is that it may be matching on the term
established for the reasons I just mentioned.
I would suggest modifying the term established to include 'from protocol
tcp', and then adding another term to allow ICMP echo requests outbound.
Make sure to insert this term before the final drop term.
HTHs.
Stefan Fouant
JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] load balancing in Route reflector scenario
Have you tried the advertise-inactive knob on the RR? I can't guarantee that this will work but it just might also advertise the route towards PE3 as well. Of course, if this works, then you would need to enable multipathing on PE1 accordingly. Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 10, 2011, at 2:44 PM, biwa net wrote: > Dear All > > I have a setup where I need to load balancing routes received from 2 RR in > IPV4 environment (not VPN-IPV4) > > I have my PE (let's called PE1) connected to 2 RR (cluster), my destination > subnet eg: 10.1.1.1/24 is behind 2 PE (PE-2 and PE3) which are also client > of the same 2RR > > PE-2 and PE3 are sending the same route 10.1.1.1/24 to the RR , which as > per normal behavior is selecting the best route to PE1 , > > My issue is that RR is always advertising the route 10.1.1.1/24 through PE2 > (due to lower router id) as best path and I would like to load balanced it > through PE2 and PE3 > > Anyone can recommend a way to load balance ? > > Unfortunately I dont have a lab to test any solution and there are live > traffic on this ,so all I can do is guessing is whether the below 2 option > would work or not. > > 2 option I have > > 1.So here I am trying to thinking about testing the multipath command under > the RR configuration to see if I am receiving routes from both PE or not , > > 2. try to put all devices them in routing instance VRF , with the BGP > configuration under it (both RR and client) , and RD configured in the VRF > (but not putting any vpn family under bgp) so that it stays IPV4 routes , > maybe I could cheat the RR to believe these are 2 differentes routes due to > the RD, but dont know if this works or not . > > anyone has had similar issue and found a workaround ? > > does the 2 option above actually work or not ? > > thanks for any 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
Re: [j-nsp] In Search of the Optimal RE Protect Filter - A Journey
Hi Clarke, Lot's of good insight here. You've put together some pretty good stuff. Have you thought about putting it on a blog somewhere? Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant On 8/9/2011 4:25 PM, Clarke Morledge wrote: I have posed a number of questions to the mailing list over the past couple of months about configuring RE protect filters for the MX platform. I'd like to summarize my experiences so that others do not have to go through the headaches I've had. An Introduction: In our campus environment we have been moving towards an MX core/distribution infrastructure with EX switches at the access level. We have had to slowly do this while keeping our layer2 connectivity with a legacy vendor switch infrastructure intact. Unfortunately, part of the reason we have been wanting to rid our campus of the legacy layer2 infrastructure is that it has been prone to experience topology failures, even with spanning tree enabled --- with limited troubleshooting tools. Various layer2 "micro loops", as well as other broadcast storm events, have sometimes resulted in minor, brief outages in our old infrastructure, but when these events get propagated into the MX world, it could be disaster. So while security and intentional DoS attacks are sufficent reasons for implementing RE filters, if you are concerned about braodcast storms in general you might consider what we have learned: 1. In addtion to the security approach, RE filters are important from a resource perspective. The big bottleneck we've found with respect to resources isn't with the RE itself. During an "attack" on the RE, the CPU and memory looks pretty healthy. The issue has more to do with the buffering of packets as they enter a PFE destined for the RE. A burst of traffic to the RE could trigger tail drops in the queuing before doing other forms of harm. 2. Juniper's decision to allow all broadcast/multicast traffic on layer3 interfaces to go to the RE by default makes the MX platform particularly vulnerable to Denial of Service attacks involving broadcast storms, particularly for otherwise targeted ip broadcasts; i.e. destined to an ip subnet. If you have a Cisco background, you should be aware of this since the 6500/7600 systems do NOT handle directed ip broadcasts in the Supervisor by default. In Cisco, you have to flip a flag to force the Sup to handle various forms of broadcasts (caveat: ARP is always handled by the Sup, from what I have observed). 3. The "targeted broadcast" feature new in 10.2 will help to relieve the RE of the burden forwarding directed broadcast without necessarily involving the RE: http://www.juniper.net/techpubs/en_US/junos10.2/information-products/topic-collections/config-guide-network-interfac$ Though I should confess that I haven't done much testing with this recent feature. So I am not sure if this helps with traffic for the local subnet; i.e. ip broadcasts that are not intended to cross a subnet boundary. 4. If your Juniper gear isn't running highly time-sensitive applications, the broadcast issue may not bother you. But if you are trying to run something like BFD with the recommended setting of 300 ms interval with 3 misses, you might be in trouble. 5. I'll put in another plug for Doug Hanks timely book for Securing the Routing Engine. It really helped me this summer to provide an effective set of templates for building scalable filters: http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/securing-routing-engine/ 6. Doug's book is best geared towards protecting the router from malicious, security related activity. Unfortnately, it does not really address the broadcast storm issue directly. For example, while you can build effective RE filters to protect against excessive ip broadcast with either discard actions in your filters or rate limiting policers, this will not help with ARP broadcasts. The best tool to deal with ARP storms is using an ARP policer. Applied to a layer3 interface via "family inet", it affords you the protection that you need. There is a __default_arp_policer__ (look at "show policer" for the output), but the settings appear to be rather relaxed. Just be careful not to be overly aggressive and starve the RE of the ARP packets it really needs to process. Unfortunately, you can not set the ARP policer on the loopback interfaces themselves. It must be applied to either regular interfaces on a PFE and/or an IRBs. 7. If you have multiple routing instances, you will need to be aware of how they function with respect to your loopback interfaces. Assuming that each routing instance (VRFs, virtual routers) has its own loopback address that you have configured, you should know that the loopback interface serves as the entr
Re: [j-nsp] BGP "Holdtime", " Active Holdtime" and "Preference" values
On 8/9/2011 7:55 AM, Martin T wrote: Hi, in case one has following settings active with it's BGP peer: Holdtime: 90 Preference: 170 Active Holdtime: 90 Keepalive Interval: 30 ..then what do they mean? As I understand, "Holdtime" is the maximum number of seconds allowed to elapse between the time that a BGP system receives successive keepalive or update messages from a peer. So if the holdtime is configured to 90s, the "Holdtime" value under "show bgp neighbor I.I.P.P" doesn't change, does it? How is "Active Holdtime" different from "Holdtime"? And what does this "Preference" mean? Holdtime is the configured holdtime on the local device, whereas Active Holdtime is the negotiated holdtime between the two peers, which should be the minimum of the two peers holdtime configuration. Preference is the value we assign to BGP routes learned from this neighbor, which in this case is 170, the default. Preference is the equivalent of Administrative Distance in Cisco, and allows the router to determine which route to prefer should the identical route be learned from multiple sources (ex: RIP[100] vs. BGP[170]). Last but not least- in case of the configuration above, is it possible that the connection between peers is down for example 80 seconds and then comes back up, but as holdtime is set to 90s, the session stays up? Yes. Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] good filter to protect RE
On 8/8/2011 10:01 PM, Kurt Bales wrote: Dont forget the Juniper Day One book on Securing the RE also has some good examples. http://forums.juniper.net/t5/Day-One-Books/Day-One-Book-Securing-the-Routing-Engine-on-M-MX-and-T-Series/ba-p/92276 I second the Day One Guide. Cymru is a good starting point, but it hasn't been updated in ages... Doug's book is basically a modernized, more verbose equivalent of the Cymru re-protect filter. By the way, for what it's worth, although the title of the book would lead you to believe it's only applicable towards the M, MX, and T-Series routers, quite the contrary, it's equally applicable towards SRX, EX, and J-Series as well. Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] hardware DS1s
Ask and you shall receive... "Security Products Comparison"... enjoy! http://www.juniper.net/us/en/local/pdf/datasheets/1000265-en.pdf Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 6, 2011, at 12:21 AM, "Ryan Finnesey" wrote: > Ok so I am back to look at the SRX Series because I want to keep everything > within the same unit. Does anyone know of any documents that compare the > Branch SRX Series to the J Series? > > Cheers > Ryan > > > -Original Message- > From: Stefan Fouant [mailto:sfou...@shortestpathfirst.net] > Sent: Saturday, August 06, 2011 12:09 AM > To: Ryan Finnesey > Cc: > Subject: Re: [j-nsp] hardware DS1s > > The SRX 210 is the only device that I am aware of that has an internal > ExpressCard slot for the CX111 3G modem. All the other platforms use an > external bridge, so unfortunately you are out of luck here... > > The J-Series do support internal ISDN BRI PIMs, however these must be > purchased separately. > > HTHs. > > Stefan Fouant > JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI > Technical Trainer, Juniper Networks > http://www.shortestpathfirst.net > http://www.twitter.com/sfouant > > Sent from my iPad > > On Aug 5, 2011, at 11:15 PM, "Ryan Finnesey" wrote: > >> Is there an internal option for the J-Series for both the ISDN BRI and >> 3G/4G wireless? >> >> Cheers >> Ryan >> >> >> -Original Message- >> From: Stefan Fouant [mailto:sfou...@shortestpathfirst.net] >> Sent: Friday, August 05, 2011 11:14 PM >> To: Ryan Finnesey >> Cc: >> Subject: Re: [j-nsp] hardware DS1s >> >> J-Series or branch SRX would fit the bill here as you can easily meet >> your requirement with either platform. You can get the CX111 cellular >> bridge for 3G backup for these platforms. Since you don't need >> firewalling, SRX might be overkill however... >> >> Stefan Fouant >> JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI >> Technical Trainer, Juniper Networks >> http://www.shortestpathfirst.net >> http://www.twitter.com/sfouant >> >> Sent from my iPad >> >> On Aug 5, 2011, at 10:28 PM, "Ryan Finnesey" wrote: >> >>> What would the group recommend in terms of Juniper hardware that we >>> can use at remote locations where we would install one or two DS1s? >>> This would be a TDM network witch we will run MPLS so no need for >>> firewall. If possible we would like to have the same box to be able >>> to support ISDN BRI and or 3G/4G wireless as a backup option. >>> >>> >>> >>> Cheers >>> >>> Ryan >>> >>> >>> >>> ___ >>> 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] hardware DS1s
Yes, it is an OEM of of the CBA750. Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 6, 2011, at 12:19 AM, "Ryan Finnesey" wrote: > The CX111 looks very similar the a CradlePoint device. Does Juniper OEM > them? > > -Original Message- > From: Stefan Fouant [mailto:sfou...@shortestpathfirst.net] > Sent: Friday, August 05, 2011 11:14 PM > To: Ryan Finnesey > Cc: > Subject: Re: [j-nsp] hardware DS1s > > J-Series or branch SRX would fit the bill here as you can easily meet your > requirement with either platform. You can get the CX111 cellular bridge for > 3G backup for these platforms. Since you don't need firewalling, SRX might > be overkill however... > > Stefan Fouant > JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI > Technical Trainer, Juniper Networks > http://www.shortestpathfirst.net > http://www.twitter.com/sfouant > > Sent from my iPad > > On Aug 5, 2011, at 10:28 PM, "Ryan Finnesey" wrote: > >> What would the group recommend in terms of Juniper hardware that we >> can use at remote locations where we would install one or two DS1s? >> This would be a TDM network witch we will run MPLS so no need for >> firewall. If possible we would like to have the same box to be able >> to support ISDN BRI and or 3G/4G wireless as a backup option. >> >> >> >> Cheers >> >> Ryan >> >> >> >> ___ >> 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] hardware DS1s
The SRX 210 is the only device that I am aware of that has an internal ExpressCard slot for the CX111 3G modem. All the other platforms use an external bridge, so unfortunately you are out of luck here... The J-Series do support internal ISDN BRI PIMs, however these must be purchased separately. HTHs. Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 5, 2011, at 11:15 PM, "Ryan Finnesey" wrote: > Is there an internal option for the J-Series for both the ISDN BRI and 3G/4G > wireless? > > Cheers > Ryan > > > -Original Message- > From: Stefan Fouant [mailto:sfou...@shortestpathfirst.net] > Sent: Friday, August 05, 2011 11:14 PM > To: Ryan Finnesey > Cc: > Subject: Re: [j-nsp] hardware DS1s > > J-Series or branch SRX would fit the bill here as you can easily meet your > requirement with either platform. You can get the CX111 cellular bridge for > 3G backup for these platforms. Since you don't need firewalling, SRX might > be overkill however... > > Stefan Fouant > JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI > Technical Trainer, Juniper Networks > http://www.shortestpathfirst.net > http://www.twitter.com/sfouant > > Sent from my iPad > > On Aug 5, 2011, at 10:28 PM, "Ryan Finnesey" wrote: > >> What would the group recommend in terms of Juniper hardware that we >> can use at remote locations where we would install one or two DS1s? >> This would be a TDM network witch we will run MPLS so no need for >> firewall. If possible we would like to have the same box to be able >> to support ISDN BRI and or 3G/4G wireless as a backup option. >> >> >> >> Cheers >> >> Ryan >> >> >> >> ___ >> 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] hardware DS1s
J-Series or branch SRX would fit the bill here as you can easily meet your requirement with either platform. You can get the CX111 cellular bridge for 3G backup for these platforms. Since you don't need firewalling, SRX might be overkill however... Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 5, 2011, at 10:28 PM, "Ryan Finnesey" wrote: > What would the group recommend in terms of Juniper hardware that we can use > at remote locations where we would install one or two DS1s? This would be a > TDM network witch we will run MPLS so no need for firewall. If possible we > would like to have the same box to be able to support ISDN BRI and or 3G/4G > wireless as a backup option. > > > > Cheers > > Ryan > > > > ___ > 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] srx with ethernet switching and chassis clustering
On 8/1/2011 4:41 PM, Jonathan Lassoff wrote: On Mon, Aug 1, 2011 at 12:04 AM, Richard Zheng wrote: Thanks jof. I see, in production we can make other switches handle the access and only use srx for firewall. So after setting up reth interface, we should be able to add vlan-tagging to it, right? I believe so, but honestly I do this with multiple independent SRXes rather than reth interfaces. I would presume vlan-tagging will work with reth interfaces, but I'm not 100% sure. Yup, reth interfaces can easily handle VLAN-tagging, and in fact can be configured as either family inet interfaces with tagging (in which case they will be terminating the Layer 3 for each respective VLAN), or they can be configured as family bridge with trunking enabled in which case the device will be operating in transparent mode (a-la bump-in-the-wire for pure Layer 2 firewalling of the respective VLANs). HTHs. Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RSVP to LDP migration
On 7/27/2011 9:41 AM, Phil Bedard wrote: It's fairly simple. Just turn up LDP everywhere, make sure the LDP paths exist in inet.3 and then turn off RSVP or set the preference on RSVP higher. You can tunnel LDP over RSVP so if you are just adding gear to the edge of the existing network it may be easier to turn on LDPoRSVP and just run LDP on interfaces at the edge. Just an FYI, the book 'Network Mergers and Migrations' by Gonzalo Gómez Herrero and Jan Antón Bernal van der Ven provides excellent coverage of the subject matter and has a whole chapter dedicated to migration of label distribution protocols. http://www.amazon.com/gp/product/0470742372/ref=as_li_ss_tl?ie=UTF8&tag=short0e-20&linkCode=as2&camp=217145&creative=399369&creativeASIN=0470742372 Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS Scaling
On 7/23/2011 8:47 PM, tim tiriche wrote: Does Juniper support VPLS with 802.1ah? Has anyone deployed this? Hi Tim, On the MX Series devices, there is extensive support for (MAC) tunneling and bridging of Ethernet frames across Provider Backbone-Bridges which include the use and integration with VPLS as a transport mechanism. You'll find extensive per-port VLAN tag manipulation and normalization features which include support for 802.1ad (Q-in-Q) and 802.1ah (MAC-in-MAC). Take a look at the MX Solutions Guide which covers a lot of this in great detail - http://www.juniper.net/techpubs/en_US/junos11.1/information-products/topic-collections/solutions-guide-mx-series/mx-solutions-guide.pdf HTHs. Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Question on SCU/DSU
Hi there,
SCU/DCU is not for policy-based routing but rather for accounting of traffic
that matches certain source prefixes or destination prefixes.
If what you are trying to accomplish is policy-based routing, what you want to
look into is Filter-Based Forwarding (FBF) on Junos platforms. With FBF, you
can implement a firewall filter and match on any of the normal parameters you
would normally use (IP Source, Dest, Proto, Port, etc.) and then direct traffic
into a routing instance of your choosing by using the 'then routing-instance'
action.
HTHs.
Stefan Fouant
JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant
Sent from my iPad
On Jul 23, 2011, at 5:20 PM, cc loo wrote:
> Hey folks,
>
> I have some problems understanding SCU/DSU so some clarification would help
> here !
>
> I'm trying to do some policy-based-routing base on source prefixes.
>
> So when a packet enters my router, it would like to tag it with a class
> (local,transit-customers,upstream). Then i would like to send it to another
> routing-instance (default route it to a proxy actually), base on the class
> tagged
>
>
> I have some configs here
>
> ### this is to tag packets to see what kind of customers
> policy-statement identify-prefixes {
>term 1 {
>from {
>protocol [ ospf static direct local ]; ### my access customers
>}
>then {
>destination-class dcu-ospf;
>source-class scu-ospf;
>accept;
>}
>}
>term 2 {
>from {
>protocol bgp;
>community [ 12345:1304 12345:1305 12345:1307 12345:1308
> 12345:1400 ]; ### my transit customers
>}
>then {
>destination-class dcu-bgp;
>source-class scu-bgp;
>accept;
>}
>}
>term 3 {
>from protocol bgp;
>then {
>destination-class dcu-all-others; ### anything else
>source-class scu-all-others;
>accept;
>}
>}
> }
>
>
> Now i read the official docs that i have to enable a input and a output
> interface. (access interface and upstream interface)
> But i don't quite understand the direction of the interface.
>
> What i'm trying to find out is what class a packet belongs to when it enters
> the route. Base on that i'll inspect the packet's class to decide if i want
> to forward it to the proxy or not.
> Hope someone can shed some light on this, its giving me heaps of headache.
> The more i read the more confusing it gets
> ___
> 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] ECMP vs LAG and OAM vs BFD
On 7/22/2011 1:27 PM, Rafael Rodriguez wrote: In the meantime, why not just run LACP across your LAG interface? This can accomplish the goal quite easily. No sub-second failure detection, its 1-3 sec range. Gotchya... Testing this now. Found: http://www.juniper.net/techpubs/en_US/junos11.1/topics/example/layer-2-802-1ah-ethernet-oam-lfm-example-for-aggregated-ethernet-mx-solutions.html Cool deal, thanks for sharing! Let us know how it works out. Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ECMP vs LAG and OAM vs BFD
On 7/22/2011 11:24 AM, Rafael Rodriguez wrote: Interesting, did not know that control packets were always sent on the lowest numbered interface in a LAG. Are you aware of any Juniper documentation mentioning this? I found KB10926 but this is specific to EX and not MX. So LAG + BFD will do nothing in determining if individual links in the LAG are actually 'up'. Thanks. I am not sure of any documentation but we do cover this in some of our training materials. I will see what I can dig up. Regarding BFD's capabilities to determine member state of individual member links, this is not currently supported by BFD. Take a look at IETF Draft 'Bidirectional Forwarding Detection (BFD) for Interface' which was just released a few weeks ago. It is designed to meet these requirements - http://tools.ietf.org/html/draft-chen-bfd-interface-00 In the meantime, why not just run LACP across your LAG interface? This can accomplish the goal quite easily. Are individual links in the LAG able to detect failures with OAM? Should be able to but I would of course test it first... :) Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] srx advice
On 7/22/2011 1:51 AM, Kurt Bales wrote: Hello Richard, I would hazard a guess that because not every virtual router needs to be running in flow-based mode (ie run some in packet-mode ala http://datainter.cz/doc/3500192-en.pdf ), that it may be possible to not require 2x Zones per VR. In a similar vein, it's not uncommon to see Filter-Based Forwarding (FBF) scenarios for those that require next-hop resolution in a different table than inet.0. In these cases you'll use a forwarding instance-type, but it won't be bound to any zones or require any security parameters. Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ECMP vs LAG and OAM vs BFD
On 7/22/2011 7:18 AM, Rafael Rodriguez wrote: Hello list, I'm looking at options on how to do all of the following: 1) Increase bandwidth capacity by adding multiple links with 'flow' based hashing 2) Sub-second detection mechanism of a indirect link failure that is distributed to hardware (i.e. PFE handles) 3) Above two must work with NSR and GRES + GR (NSR and GRES + GR and mutually exclusive, will only use one of the two) If you run NSR/GRES you *CANNOT* run GR. There are no platforms or combinations which will allow you to run these simultaneously. GRES/NSR is a natural replacement for GRES and so it is not needed. So far here are the possible combinations I've come across (not sure if these are NSR and GRES + GR friendly): 1) LAG + BFD (this doesn't sound like a good idea b/c you have no grantee that hashing on each side will use the same link for BFD packets) If you were to run BFD, since these are control packets they will always take the lowest numbered interface in the LAG; in other words the normal hashing doesn't come into play for any control packets running across a LAG. Regardless, BFD runs between Layer 3 peers using the PPMD (Periodic Packet Management Daemon), so it doesn't matter which link is used for BFD packets as it won't be used to verify reachability of individual member links. 2) LAG + OAM (presume OAM will be for each physical interface and not entire the LAG) This is a better approach if you want to verify your end to end connectivity across Layer 2... look into Link Fault Management for segment isolation/verification and Connectivity Fault Management for end-to-end isolation/verification. 3) ECMP + BFD 4) ECMP + OAM Why run ECMP? If all you want to do is connect a few hosts via multiple paths LAGs should do the trick. Why would you want to waste address space unnecessarily, not to mention have to deal with forwarding-table load-balance policies? Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] equivalent to cisco's oer
On 7/21/2011 6:29 AM, Eric Hileman wrote: Does junos have an equivalent to cisco's oer? For those that don't know oer is cisco's bgp route optimization ability to take into consideration congestion, delays, etc.. I imagine you could do something along these lines with RPM (or even periodic automated traceroutes) coupled with an Op Script to change the attributes on one BGP path to make them less preferable. Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] best way to shut down BGP session
I would say first modify import and export policy to influence the routing such that upstream and downstream nodes view the BGP speaker as less preferred. Give it some time for BGP tables to settle down and nodes to converge on new more preferable paths, then simply deactivated BGP. Of course all of this hinges on having multiple routers as exit points in your network. Sorry for the top post. Stefan Fouant GPG Key ID: 0xB4C956EC Sent from my HTC EVO. - Reply message - From: "Matthias Brumm" Date: Tue, Jul 19, 2011 6:29 am Subject: [j-nsp] best way to shut down BGP session To: "Juniper-NSP" Hi! What are you using to shut down a BGP session in the most smoothly way for maintenance purposes? At this time I have used an import/export statement with a reject action in it. But perhaps you have a better way, so that the routes on the connected routers are reroutes very smoothly, so that the customers are nearly unaffected? Regards, Matthias ___ 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] MX Firewall Capabilities
Brendan, It really depends on what you are trying to accomplish. The SRX is going to scale to much greater levels when it comes to Stateful Firewalling capability - it basically operates on a flow forwarding paradigm where it's designed from the ground up to handles sessions statefully. On the other hand, the MX with the DPC will give you some of this capability, but remember the underlying paradigm is quite a bit different. These are packet forwarding devices, so any traffic that you want to handle statefully will have to be routed through the DPC. As such, there are finite limitations to what you can put through a single DPC and therefore wouldn't be appropriate if you want all your traffic to be handled statefully. Plus, on the MX with the DPC it is basically configured using interface-style and next-hop style service-sets which is quite a bit different from the configuration syntax used on the SRX. The SRX is a lot more straightforward and simpler to configure when it comes to this type of functionality. Of course, I am not trying to dissuade you from using the MX in this scenario, it's perfectly valid if you only want to handle a subset of the traffic statefully. Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant On 7/12/2011 1:19 PM, Brendan Mannella wrote: Nice, and if I decided I want stateful firewalling and IPS, I see I can use the DPC card... Are there any pros/cons to this vs just buying a separate SRX? -Original Message- From: OBrien, Will [mailto:obri...@missouri.edu] Sent: Tuesday, July 12, 2011 1:04 PM To: sth...@nethelp.no Cc: Brendan Mannella; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MX Firewall Capabilities Yup. That is correct. Border filters are no problem without the ms-dpc. Sent from my iPad On Jul 12, 2011, at 12:56 PM, "sth...@nethelp.no" wrote: Just wondering what the firewalling capabilities are with the MX series vs the SRX. We just would like to have basic firewall (block all incoming ports, allow specifcs). Would we need the MS-DPC to achieve this? The new router will be are trio cards. As long as you don't need *state* tracking but simply basic filtering on ports, IP addresses etc your standard MX cards work just fine - no need for MS-DPC. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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] snmp count for arp policer?
On 7/12/2011 11:06 AM, Clarke Morledge wrote:
On an IP interface (on a router like the MX), you can configure filters
to count different types of IP packets. But there does not appear to be
a way to count ARP packets, since they do not have an IP header.
I would like to be able to have some type of ARP packet counter per
interface that I can query with SNMP, just like you would with the IP
counters via filters that can be programmed into the router hardware.
The closest thing I can find that might do it is using an ARP policer.
Unfortunately, this will only catch packets that hit some limit on your
policer. This is better than nothing, but not great. From the CLI, you
can look at the number of hits on the __default_arp_policer__, which I
assume will get superceded by any interface specific ARP policer. In
this context, the "show policer" output via the CLI is helpful:
show policer
Policers:
Name Bytes Packets
__default_arp_policer__ 22143436345 330586727
But I do not know how to collect this information via SNMP.
Does anyone have any clues on how to do this, aside from scripting it
out via junoscript and the utility mib?
Hi Clarke,
If you are using an MX platform, instead of using family-inet on your
interfaces, configure them in a bridge-group using family bridge (simply
use an IRB interface for the routing functions). Then you can create
firewall filters for those respective interfaces under [firewall filter
family bridge] as in the following:
root@lab-mx1# show firewall
family bridge {
filter test {
term arp {
from {
ether-type arp;
}
then {
count arp;
accept;
}
}
}
}
Once you have a counter assigned, you can now poll this via SNMP as well.
HTHs.
Stefan Fouant
JNCIE-ER #70, JNCIE-M #513, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX destination-nat & ping
On 7/11/2011 6:31 PM, Scott T. Cameron wrote: With SRX static-nat, all traffic (all protocols) is forwarded to a specific IP. With SRX destination-nat, a specific protocol (tcp/udp, presumably) is forwarded to a specific IP [and optionally port] There does not appear to be an option in destination-nat to send ICMP to an IP, so that it responds to, for example, ping. Unless you are doing port translation, simply matching on destination-address in your match statement and then specifying the translated address in your then statement should do the trick. You may need to enable proxy-arp in your environment if the ingress IP (pre-translated) is a different address than the interface IP, but other than that you shouldn't need to do anything fancy to enable ping traffic to flow through... Sorry I don't have access to a device at the moment to give you a working config... can we see your configs in the meantime? Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX destination-nat & ping
On 7/11/2011 1:16 PM, Scott T. Cameron wrote: Thought I would bump this back up. Anyone have any success in getting a destination-nat on SRX respond to ICMP? Any tricks to loopback to 127.0.0.1 or anything else? Don't really care how, just would like it as an option. Scott Hey Scott, Can you describe the setup in more detail? Usually NAT is designed to translate traffic for hosts that are behind the firewall, so the host should usually be the one to respond to ICMP. Are you talking about doing destination-NAT to an address located on the SRX itself? Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] Firewalls "as-a-service" in an MPLS infrastructure...
On 7/8/2011 9:15 AM, Keegan Holley wrote: I never said it's not possible, just that I've rarely seen it done correctly. Not everyone has your level of skill. Just for arguments sake how did you handle shared bandwidth? In other words how did you keep a DDOS attack on one customers's segment from using up all available bandwidth in some shared segment upstream from the firewall. Oh no worries Keegan, I was just pointing out that it can in fact be done... In my case, the way we designed it was that individual customers were assigned to unique VLANs on the ingress interface on the Firewall. Each VLAN was mapped to a unique customer VSYS. Upstream routers had specific routes for each customer pointing to those unique VLANs. Rate-limiters were applied on said upstream router for each customer VLAN to restrict starvation of the entire pipe. Make sense? Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] Firewalls "as-a-service" in an MPLS infrastructure...
On 7/8/2011 12:28 AM, Keegan Holley wrote: Could be interesting. I've rarely seen firewall as a service done right though. It's hard to keep, cpu, memory usage, DDOS attacks, misconfiguration, etc. of one customers from affecting the other customers that share hardware. That being said there are better platforms to run the firewall instances on that are available now, checkpoint VSX comes to mind. Years ago when I had to develop a Network Based Firewall solution for a particular ISP in order to comply with the Federal Government's NetworX bid, we chose Juniper's NS-5400 for precisely this reason. In ScreenOS you have the concept of resource profiles with which you can limit the amount of CPU, Sessions, Policies, MIPs and DIPs (used for NAT), and other user defined objects such as address book entries, etc. that each VSYS can avail. These are essential elements of any multi-tenant firewall solution and evaluated platforms should likewise have similar offerings to contain resource usage for individual customers. Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Bypass LSP functionality question
On 7/7/2011 12:26 PM, Harry Reynolds wrote: Do you have a per-packet lb policy applied to the forwarding table at the point of local repair? AFAIK, any fast reroute/bypass needs this for optimal switchover as it allows the detour/bypass to be preinstalled in the pfe waiting for its day in the sun. As I recollect, the ingress will continue to use the bypass until it can signal a new path (MBB). You may want to set the ingress lsp to adaptive to better chances of the new path being established so the lsp can get of the bypass. Harry is right. This is covered in the 'Junos MPLS and VPNs' course. Only the Active LSP's next-hop is installed in the PFE by default. During the time that it takes for the RE to install the detour or bypass next-hop in the forwarding table, it is not unusual to see a small amount of dropped traffic. Harry, I've always wondered about this however, since the recommended solution is to apply a forwarding-table load-balance policy, does this mean that traffic will *always* use both the Primary path as well as any Detours or Bypasses under normal working conditions? Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ATM2 pic connected to another M7i cannot get ISIS adjatency ; (
You have both sides doing clocking internal?
Also, what is the config under [protocols isis]?
Stefan Fouant
GPG Key ID: 0xB4C956EC
Sent from my HTC EVO.
- Reply message -
From: "Xavier Beaudouin"
Date: Thu, Jul 7, 2011 10:51 am
Subject: [j-nsp] ATM2 pic connected to another M7i cannot get ISIS adjatency
; (
To:
Hi there,
I have 2 M7i with pic :
PIC 3 REV 08 750-005724 CN54302x OC-3 ATM-II IQ, MM
Since I don't use ATM, I wanted to use this as interrouter connection using :
jun-m7i-1 at-0/3/0 <-> jun-m7i-2 at-0/3/0
jun-m7i-1 at-0/3/1 <-> jun-m7i-2 at-0/3/1
I finaly found a way to make the communication (ipv4) between the routers, but
it doesn't seems to work with ISIS.
Here is jun-m7i-1 base configuration :
interfaces {
at-0/3/0 {
description "To jun-m7i-2_at-0/3/0";
mtu 9192;
clocking internal;
encapsulation atm-pvc;
atm-options {
pic-type atm2;
vpi 1;
}
unit 0 {
encapsulation atm-snap;
vci 1.100;
oam-period 3;
oam-liveness {
up-count 3;
down-count 3;
}
family inet {
address xx.xx.xx.125/30;
}
family iso;
}
}
at-0/3/1 {
description "To jun-m7i-2_at-0/3/1";
mtu 9192;
clocking internal;
encapsulation atm-pvc;
atm-options {
pic-type atm2;
vpi 1;
}
unit 0 {
vci 1.100;
family inet {
address xx.xx.xx.121/30;
}
family iso;
}
}
lo0 {
description Loopback;
unit 0 {
family inet {
no-redirects;
primary;
address xx.xx.xx.1/32 {
primary;
preferred;
}
}
family iso {
address 49.0001.0xxx..xxx1.00;
}
}
}
}
On jun-m7i-2 :
interfaces {
at-0/3/0 {
description "To jun-m7i-1_at-0/3/0";
mtu 9192;
clocking internal;
encapsulation atm-pvc;
atm-options {
pic-type atm2;
vpi 1;
}
unit 0 {
encapsulation atm-snap;
vci 1.100;
oam-period 3;
oam-liveness {
up-count 3;
down-count 3;
}
family inet {
address xx.xx.xx.126/30;
}
family iso;
}
}
at-0/3/1 {
description "To jun-m7i-1_at-0/3/1";
mtu 9192;
clocking internal;
encapsulation atm-pvc;
atm-options {
pic-type atm2;
vpi 1;
}
unit 0 {
encapsulation atm-snap;
vci 1.100;
family inet {
address xx.xx.xx.122/30;
}
family iso;
}
}
lo0 {
description Loopback;
unit 0 {
family inet {
no-redirects;
primary;
address xx.xx.xx.xx/32 {
primary;
preferred;
}
}
family iso {
address 49.0001.0xxx..xxx2.00;
}
}
}
}
show isis interface
IS-IS interface database:
Interface L CirID Level 1 DRLevel 2 DRL1/L2 Metric
at-0/3/0.03 0x1 Point to PointPoint to Point 10/10
at-0/3/1.03 0x1 Point to PointPoint to Point 10/10
lo0.0 0 0x1 Passive Passive 0/0
Any clues, ideas ?
Kind regards,
Xavier
___
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] Bypass LSP functionality question
Correction, I said Path Tear in my previous message, rather I meant Path Err... Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant On 7/7/2011 12:15 AM, Stefan Fouant wrote: On 7/6/2011 11:50 AM, David Ball wrote: Just looking for confirmation of a suspicion here. If I have an LSP configured with link-protection on every interface along the way (creating many-to-one Bypass LSPs, as opposed to 1:1 detours), no secondary standby path defined, and a protected interface fails, the ingress node will have no ability to perform a make-before-break, right? Because the Path Tear messages will be sent both upstream and downstream from the failed interface? The bypass will only help me up until the upstream nodes process the Path Tears and a new LSP is signalled from the ingress nodeor am I missing something? Hi David, The bypass is only used temporarily to save the traffic that is already traversing the LSP. At the same time that the bypass LSP is being used, the node which established the Bypass around the failure will will send the Path Tear message upstream towards the Ingress LSR. Once the Ingress LSR receives the Path Tear it may signal an alternate path assuming some Secondary paths have been configured. You could have the Secondary LSP set up as a Standby in which case it is pre-signaled but will require double the amount of reservation state in the network. This is inherently make-before-break because the Secondary Standby is already established by the time your Primary has failed. Another option is to configure the Adaptive option which will force the Ingress LSR to continue using the Primary LSP (traversing a Bypass) until it has signaled the Secondary path and only once the secondary has been established will it cease using the Primary. This has the benefit of also reducing the amount of reservation state in the network due to the fact that Adaptive option signals LSPs using the Shared Explicit style. HTHs, Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ 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] Bypass LSP functionality question
On 7/6/2011 11:50 AM, David Ball wrote: Just looking for confirmation of a suspicion here. If I have an LSP configured with link-protection on every interface along the way (creating many-to-one Bypass LSPs, as opposed to 1:1 detours), no secondary standby path defined, and a protected interface fails, the ingress node will have no ability to perform a make-before-break, right? Because the Path Tear messages will be sent both upstream and downstream from the failed interface? The bypass will only help me up until the upstream nodes process the Path Tears and a new LSP is signalled from the ingress nodeor am I missing something? Hi David, The bypass is only used temporarily to save the traffic that is already traversing the LSP. At the same time that the bypass LSP is being used, the node which established the Bypass around the failure will will send the Path Tear message upstream towards the Ingress LSR. Once the Ingress LSR receives the Path Tear it may signal an alternate path assuming some Secondary paths have been configured. You could have the Secondary LSP set up as a Standby in which case it is pre-signaled but will require double the amount of reservation state in the network. This is inherently make-before-break because the Secondary Standby is already established by the time your Primary has failed. Another option is to configure the Adaptive option which will force the Ingress LSR to continue using the Primary LSP (traversing a Bypass) until it has signaled the Secondary path and only once the secondary has been established will it cease using the Primary. This has the benefit of also reducing the amount of reservation state in the network due to the fact that Adaptive option signals LSPs using the Shared Explicit style. HTHs, Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] strange packet loss without impact
Honestly, I don't suspect that it is an issue with fwdd, but you should be able to get more detailed information about individual threads by enabling task accounting. Once enabled you can do a 'show task accounting' for more detailed info. Regards, Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI Technical Trainer, Juniper Networks Sent from my iPad On Jul 4, 2011, at 9:33 AM, Matthias Brumm wrote: > Hello! > > At the moment I am monitoring it with top on UNIX shell, do you have another > suggestion? In top this process is idleing. > > Regards, > > Matthias > > 2011/7/4 Christian > >> Hi, >> Try to monitor the fwdd process - when running high it causes packet to >> drop on these pc's. >> >> Christian >> >> >> Le 04/07/2011 13:11, Adam Leff a écrit : >> >> I realize this will sound silly, but have you checked for half-duplex >>> on your interfaces? >>> >>> Those onboard J6350 interfaces are actually 10/100/1000, so if you >>> don't have the speed and link-mode hardcoded, do a show interfaces >>> extensive ge-0/0/# and check the link partner section to ensure you're >>> running full-duplex. >>> >>> Adam >>> >>> On Jul 4, 2011, at 7:01, Matthias Brumm wrote: >>> >>> Hello! >>>> >>>> Since some weeks now, we have a strange packet loss on one of our edge >>>> locations. >>>> >>>> A few days ago an IX informed us about packet loss on our router. The >>>> router >>>> in place is a J6350. We have a 1 Gig line to us and two 1 Gig lines to >>>> some >>>> uplinks. Every communication goes through a 1 Gig copper link to a >>>> ProCurve >>>> 2810-24G. So the external links are connected to the switch and the >>>> switch >>>> via one cable with the router. >>>> >>>> The packet loss is strange, because: >>>> >>>> 1. In smokeping during the busy hours of the day, there are losses of >>>> about >>>> 5% >>>> 2. From my workstation I get packet loss of about 10 up to 50% >>>> 3. There are no errors on the switch or router interface (except i.e. >>>> VLAN >>>> errors) >>>> 4. no customers have reported any problems. But there are many customers >>>> relying on real time communication (VoIP/RDP) >>>> 5. The switch port with the router is showing maximum 200 Mbit >>>> 6. The router is showing 20% real-time threads >>>> >>>> According to the datasheet the J-Series should be able to deliver this >>>> performance easily. Or are the onboard Gig-Interfaces the problem? Of >>>> course >>>> I know, that this physical configuration is a bad idea, and I will change >>>> is >>>> very soon to ease the load on this particular port. >>>> >>>> Any other ideas? >>>> >>>> Regards, >>>> >>>> Matthias >>>> __**_ >>>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>>> https://puck.nether.net/**mailman/listinfo/juniper-nsp<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<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<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] SQL*Net and firewalls..
Thanks for sharing Derick... Good stuff! Stefan Fouant Technical Trainer, Juniper Networks JNCIE-ER #70, JNCIE-M #513, JNCI http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Jun 30, 2011, at 8:36 PM, Derick Winkworth wrote: > New blog post I hope others find helpful... > > > http://blinking-network.blogspot.com/2011/06/sqlnet-aka-oracle-tns-and-firewalls.html > ___ > 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] OAM on logical router
On 6/30/2011 1:25 AM, MSusiva wrote: Hi Experts, Does logical router on MX support CFM? As far as I know these are simply interface specific settings, so it shouldn't make a difference if they are running within a logical system, virtual router construct, or simply within the default instance. -- Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI http://www.shortestpathfirst.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Static AnyCast PIM + MSDP not working
On 6/28/2011 6:59 PM, Doug Hanks wrote:
Stacy,
I disabled PIM on the multicast source. I also disabled PIM on all of the
devices management interfaces (172.16.1.0/24). You were correct as the DR was
being elected on the broadcast network.
Disabling PIM on the management interfaces is a critical step. We
stress this point a lot in the 'Junos Multicast Routing' class with
configurations that look like the following:
pim {
rp {
local {
family inet {
address 10.0.6.254;
}
}
}
interface all {
mode sparse;
interface fxp0.0 disable;
}
}
This is probably doubly important in lab settings where you may not be
using the OOB fxp interface for mgmt but rather some other revenue port
for mgmt purposes. Likely you'll want to disable those as well.
Nonetheless it sounds like Stacy got you covered! Good luck in your
studies mate!
--
Stefan Fouant
JNCIE-ER #70, JNCIE-M #513, JNCI
http://www.shortestpathfirst.net
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Output for "show bgp summary" is showing different on twoREs
Yeah, I would suggest restarting the backup RE and see if it comes into the proper state as well... Stefan Fouant JNCIE-M #513, JNCIE-ER #70, JNCI http://www.shortestpathfirst.net GPG Key ID: 0xB4C956EC > -Original Message- > From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- > boun...@puck.nether.net] On Behalf Of saurabh sood > Sent: Saturday, June 25, 2011 12:28 PM > To: Alex > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] Output for "show bgp summary" is showing different > on twoREs > > It will help me to narrowdown this issue. > > Thanks > > On Sat, Jun 25, 2011 at 9:23 PM, Alex wrote: > > > If the BGP peer in the master Routing Engine has negotiated address- > family > > capabilities that are not supported for nonstop active routing, then > the > > corresponding BGP neighbor state on the backup Routing Engine shows > as idle. > > On switchover, the BGP session is reestablished from the new master > Routing > > Engine. > > http://www.juniper.net/**techpubs/en_US/junos11.1/** > > topics/reference/requirements/**nsr-system-requirements.html#**nsr- > bgp<http://www.juniper.net/techpubs/en_US/junos11.1/topics/reference/re > quirements/nsr-system-requirements.html#nsr-bgp> > > Note, for instance, inet-vpn multicast AFI is not supported for NSR. > > HTH > > Rgds > > Alex > > > > > > - Original Message - From: "saurabh sood" > > > To: > > Sent: Saturday, June 25, 2011 2:40 PM > > Subject: [j-nsp] Output for "show bgp summary" is showing different > on > > twoREs > > > > > > Hello, > >> > >> I have observed a different scenario, i don't know wthr it is by > expected > >> or > >> not. > >> > >> Router has two REs and GRES, NSR is enabled also commit synchronize > is > >> there. > >> But while checking the output for "show bgp summary" then on Master > RE > >> everything is showing ok. > >> > >> On the other hand backup RE is showing all bgp states IDLE. > >> > >> Is it an expected behavior? > >> > >> Regards, > >> > >> Sunny > >> __**_ > >> juniper-nsp mailing list juniper-nsp@puck.nether.net > >> https://puck.nether.net/**mailman/listinfo/juniper- > nsp<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] Output for "show bgp summary" is showing different on two REs
> -Original Message-
> From: saurabh sood [mailto:saurabh...@gmail.com]
> Sent: Saturday, June 25, 2011 10:18 AM
> To: Stefan Fouant
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Output for "show bgp summary" is showing different
> on two REs
>
> Thanks for this good answer.
>
> Even I was thinking the same but unfortunately when I tried the same on
> one of my other router then i saw the following:
>
> Master RE:
>
> {master}
> lab> show bgp summary
> Groups: 2 Peers: 2 Down peers: 0
> Table Tot Paths Act Paths SuppressedHistory Damp State
> Pending
> inet.0 0 0 0 0 0
> 0
> Peer AS InPkt OutPktOutQ Flaps Last
> Up/Dwn State|#Active/Received/Accepted/Damped...
> 1.1.1.1 100 11 12 0 0
> 4:25 0/0/0/0 0/0/0/0
> 21.1.1.2300 12 13 0 0
> 4:43 0/0/0/0 0/0/0/0
>
> Backup RE:
>
> {backup}
> lab> show bgp summary
> Groups: 2 Peers: 2 Down peers: 0
> Table Tot Paths Act Paths SuppressedHistory Damp State
> Pending
> inet.0 0 0 0 0 0
> 0
> Peer AS InPkt OutPktOutQ Flaps Last
> Up/Dwn State|#Active/Received/Accepted/Damped...
> 1.1.1.1 100 5 5 0 0
> 2:00 0/0/0/0 0/0/0/0
> 21.1.1.2300 5 5 0 0
> 2:00 0/0/0/0 0/0/0/0
>
> Please let me know your thoughts about this as it seems to be different
> what we think.
Yeah this is very interesting indeed. I am not an expert when it comes to
matters of redundant routing engine operations - let me ask you a question,
when the Primary RE fails, does everything resume properly on the backup? Do
you see adjacencies reforming, or is it seamless? Hopefully this is
non-production so you can play with it a bit...
Stefan Fouant
JNCIE-M #513, JNCIE-ER #70, JNCI
http://www.shortestpathfirst.net
GPG Key ID: 0xB4C956EC
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Output for "show bgp summary" is showing different on two REs
> -Original Message- > From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- > boun...@puck.nether.net] On Behalf Of saurabh sood > Sent: Saturday, June 25, 2011 9:41 AM > To: juniper-nsp@puck.nether.net > Subject: [j-nsp] Output for "show bgp summary" is showing different on > two REs > > Hello, > > I have observed a different scenario, i don't know wthr it is by > expected or > not. > > Router has two REs and GRES, NSR is enabled also commit synchronize is > there. > But while checking the output for "show bgp summary" then on Master RE > everything is showing ok. > > On the other hand backup RE is showing all bgp states IDLE. > > Is it an expected behavior? IIRC, this is normal behavior. You don't actually want RPD on each respective RE attempting to form BGP adjacencies with remote peers at the same time. On the other hand, all the kernel state is replicated - as BGP packets come in they are replicated to both REs so that they both have local copies of the RIB and based on this should compute identical copies of the FIB tables, etc. (The reason we don't simply synchronize the state of the Backup RE to the Primary is because of Fate Sharing - if there is a problem on the Primary you don't want the Backup to be synched and therefore have similar problems). I believe as soon as you perform GRES (or should the Primary fail for some reason), the BGP finite state machine should immediately toggle from the Idle state to the Established state (or whatever a particular peering state happened to be on the Primary RE). Sorry I don't have more specifics, this is covered in more detail in 'Junos High Availability' by James Sonderegger, Orin Blomberg, Kieran Milne, and Senad Palislamovic. This is an excellent book if you want more details regarding operations such as the above. HTHs. Stefan Fouant JNCIE-M #513, JNCIE-ER #70, JNCI http://www.shortestpathfirst.net GPG Key ID: 0xB4C956EC ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] New J-net publications: Secure the routing engine and Useful tips/tricks
> -Original Message- > From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- > boun...@puck.nether.net] On Behalf Of Harry Reynolds > Sent: Tuesday, June 21, 2011 8:01 PM > To: 'juniper-nsp List' > Subject: [j-nsp] New J-net publications: Secure the routing engine and > Useful tips/tricks > > While there I suggest you also snag the new "tips techniques, and > templates" book. > > http://www.juniper.net/us/en/community/junos/training- > certification/day-one/fundamentals-series/junos-tips-techniques/ Thanks for sharing this Harry. I also helped contribute to this guide and I can tell you that along with my meager contribution, this thing is chock full of lots of useful stuff. I likewise have picked up a few new tricks since looking at this as well. Cheers! Stefan Fouant JNCIE-M #513, JNCIE-ER #70, JNCI http://www.shortestpathfirst.net GPG Key ID: 0xB4C956EC ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX loopback filter and monitor traffic
Hi Clarke, One thing you forgot to mention is if your re-protect filter is actually discarding the traffic or not. However, assuming that you are discarding, the reason you are not seeing the traffic via the monitor command is because the traffic destined to the RE is not actually being filtered on the RE itself but is actually being filtered at the PFE. When you commit the config, the compiled filter is pushed down to microkernel on PFE so anything destined to the RE can be filtered via forwarding plane hardware. You can see counters because those are actually gathered at PFE and then the statistics are sent to the RE. Hope this makes sense. Sorry for the top post, I am on my Android. Stefan Fouant GPG Key ID: 0xB4C956EC Sent from my HTC EVO. - Reply message - From: "Clarke Morledge" Date: Thu, Jun 16, 2011 10:53 am Subject: [j-nsp] MX loopback filter and monitor traffic To: I have a question about how the "monitor traffic" capability works on the loopback interface, particularly with respect to a filter. If write a filter, such as under a "firewall family inet filter re-protect" stanza, and apply it to the loopback address, unit 0: set interfaces lo0 unit 0 family inet filter input re-protect I can see traffic hitting the filter, if I have any counters configured in the filter. I can see that the traffic coming into the filter is getting to the RE via any IRBs or other layer 3 interfaces that are terminated on the MX. I can do a "monitor traffic" on any of these layer 3 interfaces on the input side and see the relevant traffic (to and/or from the RE). However, if I do a "monitor traffic" on the loopback interface itself, I see nothing: MX> monitor traffic interface lo0.0 no-resolve no-domain-names verbose output suppressed, use or for full protocol decode Address resolution is OFF. Listening on lo0.0, capture size 96 bytes ^C 0 packets received by filter 0 packets dropped by kernel If all of the traffic that comes into the router to the RE via these exposed Layer3 interfaces eventually makes it way to the RE via the loopback address, at unit 0, why is that the "monitor traffic" command does not show me anything?Why is the loopback interface so "special"? Clarke Morledge College of William and Mary Information Technology - Network Engineering Jones Hall (Room 18) Williamsburg VA 23187 ___ 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] IKE Key Life-times on J-series vs. SRX
> -Original Message- > From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- > boun...@puck.nether.net] On Behalf Of Devin Kennedy > Sent: Thursday, June 02, 2011 3:59 PM > To: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] IKE Key Life-times on J-series vs. SRX > > Does anyone know if the lifetime value used for the IKE session is > determined by the initiator? It appears from the behavior I've > observed > that the lifetime value is always determined by whichever peer is in > the > initiator role. That shouldn't be the case, but will need to do some digging. It should always be that the peers use the lesser of the two lifetime settings as their negotiated IKE SA lifetime. Stefan Fouant JNCIE-M #513, JNCIE-ER #70, JNCI GPG Key ID: 0xB4C956EC ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX policy logging
> -Original Message- > From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- > boun...@puck.nether.net] On Behalf Of Scott T. Cameron > Sent: Wednesday, May 18, 2011 3:20 PM > To: juniper-nsp@puck.nether.net > Subject: [j-nsp] SRX policy logging > > Does anyone have a trick for logging all policies? I'm not > particularly > fond of going and tagging each policy with "log". You can do it with apply-groups: set groups global-logging security policies from-zone <*> to-zone <*> policy <*> then log session-init set security policies apply-groups global-logging > 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. Again, you can do this with an apply-group: set groups default-log security policies from-zone <*> to-zone <*> policy log-all-else match source-address any set groups default-log security policies from-zone <*> to-zone <*> policy log-all-else match destination-address any set groups default-log security policies from-zone <*> to-zone <*> policy log-all-else match application any set groups default-log security policies from-zone <*> to-zone <*> policy log-all-else then deny set groups default-log security policies from-zone <*> to-zone <*> policy log-all-else then log session-init set security policies apply-groups default-log HTHs. Stefan Fouant, CISSP, JNCIEx2 www.shortestpathfirst.net GPG Key ID: 0xB4C956EC ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
