Re: [j-nsp] Junos 11.2R4.3 on MX
Yes, doing a lab eval on it and it has a nasty mibd leak bug. Running a daily 11.2 build at the moment that fixes it (precursor to R5 coming out in January). So, I would wait for R5 if you plan on doing any SNMP work at all on the box. -Jeff On Dec 21, 2011, at 12:20 PM, Brendan Mannella wrote: Just wondering if anyone has been brave enough to run Junos 11.2R4.3 yet on a MX960? We are currently on the latest 10.4, but would really like to upgrade to get “trunk style” config on Trio line cards. I also noticed during a previous ISSU that the Trio based line cards aren’t compatible yet with ISSU and had to be rebooted during a software upgrade. This feature is also available in 11.2. Our configuration is pretty basic, Layer2, BGP, OSPF, nothing fancy. Any info would be appreciated. Thanks, Brendan ___ 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 Experiences - Was: JUNOS 10.4S6 for EX8200 - PR/676826
Weird, I have a number of SRX210s running 10.4Rx and have had no notable issues at all. Now 9.x code was a totally different story. I work out of my home office, so my main 210 has to be working all the time, which it does just fine. Currently Running: ADSL2+ PIM for uplink, 10Mb V4 + V6 (both flow) AX411 WLAN Few GRE tunnels COS using MFC filters NAT: Source and Destination A handful of V4/V6 BGP sessions I have a second SRX210 sitting next to it as a cold spare if I need it, but have never needed it. I use MRTG to graph my resource utilization on it (including flows), just to keep an eye on things and have been satisfied with the performance. Regards, -Jeff On Sep 1, 2011, at 11:00 AM, Paul Stewart wrote: We have yet to see that even with PIM modules installed - do you remember what version of JunOS you were running by chance? Paul From: Nathan Sipes [mailto:nathan.si...@gmail.com] Sent: September-01-11 12:05 PM To: Paul Stewart Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] JUNOS 10.4S6 for EX8200 - PR/676826 I have had similar experiences to Richard's with the Free SRX210H I even managed to get a DSL PIM in there as well. Had it up and working for about 2 months when the pim quit forwarding traffic randomly. Rebooting the SRX seems to fix it well enough though... I will say that the free hardware has cost a lot of my time and some annoyed phone calls from my wife when netflix doesn't work. On Thu, Sep 1, 2011 at 9:48 AM, Paul Stewart p...@paulstewart.org wrote: Actually I'm curious as well - RAS is not typically wrong though about this kind of stuff ;) We have numerous SRX deployed for firewall and router functionality - some are running Dynamic VPN (which yes, we've had issues with - definitely it's not perfect). We've been bitten by some surprises as well ... so I'm not disagreeing, just saying that we're pretty used to these issues we've encountered and don't deploy if we know they will come up. Typically, we use them as site to site VPN boxes along with firewalling. I have an SRX210 at my home as well - run the full UTM suite on it and had no real issues (granted it's a home environment to be fair). RAS, can you share a few highlights of broken? Appreciate it, Paul -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers Sent: September-01-11 11:35 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] JUNOS 10.4S6 for EX8200 - PR/676826 On 01/09/11 10:09, Richard A Steenbergen wrote: I have an SRX210 in my basement doing my home routing, and it is the only free device I've ever been given that I would seriously consider returning and asking for my money back. Broken doesn't even begin to describe it, my condolences to anyone who actually needs to run these things in production. Is this for routing functionality, or firewall functionality? We're using one as an MPLS PE, and it seems to be working ok, but given what you've said... gulp! Is there a good summary of the problems anywhere, or do I need to trawl the archives? ___ 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] DPC or MPC with MX480
My personal opinion is that it depends on the situation. If you want any of the higher density cards or any of the newer interfaces you are going to have to go MPC. We have a large number of MXs of varying size and I made the decision to remain DPC based as opposed to mix-chassis (as I couldn't justify ditching the large number of DPCs we have now). However, we are evaluating the MX for a different role that requires MPCs so we'll look at that, but only as an MPC-only unit. Unless something drastically changes, I can't ever see us moving to a mixed DPC/MPC MX just because it is asking for pain based on interop issues thus far (and widely discussed here previously). Regards, -Jeff On Aug 25, 2011, at 9:23 AM, Vladislav A. VASILEV wrote: Hi everyone, I am in process of procuring new hardware and I've got a question. If you were to go for MX480 would you order it with MPCs or DPCs. Also if your network were to have MX80s as well which are Trio based would that influence the decision on choosing either MPCs or DPCs for the MX480s? Regards, Vladislav A. VASILEV ___ 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] RE : ECMP vs LAG and OAM vs BFD
Good to know. Since I replied to a number of people privately about LFM in JUNOS, I should also mention that we ran into a major issue with LFM last Friday. Just spent the last 5 days working with ATAC and Engineering on this. Short story is, do not deploy LFM if you have the following combination in your network: 1. VRF using vrf-table-label 2. M320 PE with a 1-port 10GE XENPAK PIC used as an upstream interface 3. I-Chip FPC for the above mentioned 10GE PIC If you have this combo, either remove vrf-table-label, or don't deploy LFM. This is broke in all JUNOS versions. :) Regards, -Jeff On Aug 16, 2011, at 10:06 AM, david@orange-ftgroup.com david@orange-ftgroup.com wrote: De : juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] de la part de Rafael Rodriguez [packetjoc...@gmail.com] Date d'envoi : vendredi 29 juillet 2011 22:08 À : Daniel Verlouw Cc : Juniper Puck Objet : Re: [j-nsp] ECMP vs LAG and OAM vs BFD FYI list, OAM LFM (802.3ah) appears to be supported in Junos 11.1 for Trio/MPC (I've yet to test this). http://www.juniper.net/techpubs/en_US/junos11.1/information-products/topic-collections/release-notes/11.1/index.html?topic-53312.html#jd0e1736 On Sat, Jul 23, 2011 at 7:22 AM, Daniel Verlouw dan...@shunoshu.net wrote: On Fri, Jul 22, 2011 at 22:14, Stefan Fouant sfou...@shortestpathfirst.net wrote: Regarding BFD's capabilities to determine member state of individual member links, this is not currently supported by BFD. Take a look at IETF Draft 'Bidirectional Forwarding Detection (BFD) for Interface' which was just released a few weeks ago. It is designed to meet these requirements - http://tools.ietf.org/html/draft-chen-bfd-interface-00 IOS XR (at least on the ASR9k) supports BFD over individual member links. Saw it in the lab, seemed to work fine. Not sure if it's implementation is based on this draft though, or if it's a proprietary one. --Daniel. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ___ 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] Independent domain
Biwa, it is most commonly used in L3VPN scenarios where you want to perform
IBGP between the PE and CE instead of the more common EBGP.
It would look similar to this:
someone@R1 show configuration routing-options | match autonomous
autonomous-system 65412;
So, my internal backbone ASN is 65412, but in this case the customer wants to
do IBGP with me and their ASN is 65600.
someone@R1 show configuration routing-instances VPNC
instance-type vrf;
interface ge-0/0/1.411;
vrf-target target:65412:600;
routing-options {
autonomous-system 65600 independent-domain;
}
protocols {
bgp {
group IBGP {
type internal;
neighbor 192.168.30.1;
}
}
}
someone@R1 show route table VPNC
VPNC.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.5.0.0/16*[BGP/170] 00:05:26, localpref 100
AS path: I
to 192.168.30.1 via ge-0/0/1.411
10.6.0.0/16*[BGP/170] 00:04:12, localpref 100, from 10.200.16.3
AS path: I
to 10.200.2.2 via ge-0/0/0.110, label-switched-path R1-R9
192.168.30.0/24*[Direct/0] 00:05:28
via ge-0/0/1.411
192.168.30.2/32*[Local/0] 00:05:31
Local via ge-0/0/1.411
192.168.31.0/24*[BGP/170] 00:04:12, localpref 100, from 10.200.16.3
AS path: I
to 10.200.2.2 via ge-0/0/0.110, label-switched-path R1-R9
Hope this helps.
-Jeff
On Jul 27, 2011, at 12:05 AM, biwa net wrote:
Dear All
I am having a hard time understanding the concept of independent-domain ,
Although I read the doc about it , the explanation, is not very clearly
explained and not very clear in practical terms
Anyone can explain in leman terms what is the role of it , and especially
can anyone give me some real life example where and how this would be
applied ?
Thanks
Biwa
___
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
Guys, FWIW, I tested and cleared LFM over LAG for our core and it has worked very well. Ran in to some interesting things along the way, but in the end it behaves as advertised and is a huge step in the right direction, especially for detecting carrier outages where there is no Fault Propagation end-to-end. Ping me offline if you want to see what it looks like. Regards, -Jeff On Jul 22, 2011, at 1:27 PM, Rafael Rodriguez wrote: On Fri, Jul 22, 2011 at 4:14 PM, Stefan Fouant sfou...@shortestpathfirst.net wrote: 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-00http://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. No sub-second failure detection, its 1-3 sec range. Are individual links in the LAG able to detect failures with OAM? Should be able to but I would of course test it first... :) 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 Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.**net 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] Third Edition of Minei Lucek MPLS-Enabled Applications
I got mine almost a month ago from Amazon (Jan 20th), so it was definitely released early. :) Cheers, -Jeff On Feb 18, 2011, at 2:52 PM, David wrote: Couldn't care less how it's delivered, as long as I get my hands on a copy. Just ordered from Amazon along with Network Mergers and Migrations: Junos Design and Implementation by Gonzalo Herrero, et.al. Thanks to folks at Juniper for publishing more books! Need more substantive books on network technologies like Juniper/Wiley is putting out rather than the fluff that's been coming out lately from CriscoPress. David. On Fri, Feb 18, 2011 at 2:18 AM, Alex alex.arsen...@gmail.com wrote: Is this book delivered by time machine? Product Details a.. Paperback: 628 pages b.. Publisher: Wiley; 3 edition (March 8, 2011) == - Original Message - From: Clarke Morledge chm...@wm.edu To: juniper-nsp@puck.nether.net Sent: Thursday, February 17, 2011 10:01 PM Subject: [j-nsp] Third Edition of Minei Lucek MPLS-Enabled Applications I see that there is now a new edition of Ina Minei's and Julian Lucek's _MPLS-Enabled Applications: Emerging Developments and New Technologies_ out now. http://www.amazon.com/MPLS-Enabled-Applications-Developments-Technologies-Communications/dp/0470665459 I have read much of the second edition and it is probably the best one-stop text on MPLS protocols and theory that I have come across. I only wish there were JUNOS configuration and debugging cross-references to go along with it to make it more practical. Anyway, I was wondering if anyone on the list has read the new third edition yet. I'd be curious to know if it would worth getting over and above the second edition. Thanks. 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 ___ 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] Juniper QoS (LLQ)
Be aware though that COS is very router and interface specific, so while a generic example like this will work in most cases, it won't work in all. For example, with some PICs you cannot have more than one med-high+ priority: [edit class-of-service interfaces] 'ge-5/1/0' More than one scheduler is configured as strict-high or high or medium-high in SCHED-MAP for ge-5/1/0. Ifd ge-5/1/0 supports only one scheduler with strict-high or high or medium-high. error: configuration check-out failed This is for an 8-port GE-IQ PIC in an M320, btw. -Jeff On Feb 4, 2011, at 9:22 AM, Matthew Tighe wrote: Depending on your hardware you can have up to 16 forwarding classes. I wrote a very basic 3 class example here (Network Control, Expedited Forwarding, and BE) to get you started. Network Control is your control plane protocols. There are a lot more options than what is here. I would recommend checking out the CoS documentation ( http://www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/nce/qos-cos-overview/index.html) but the basic steps are: 1. Create your forwarding classes [edit class-of-service] set forwarding-class queue 0 BE set forwarding-class queue 2 EF set forwarding-class queue 3 NC 2. Create the schedulers for each class [edit class-of-service schedulers] set sched-BE transmit-rate percent XX set sched-BE buffer-size percent XX set sched-BE priority low set sched-EF transmit-rate percent XX set sched-EF buffer-size percent XX set sched-EF priority high set sched-NC transmit-rate percent 5 set sched-NC buffer-size percent 5 set sched-NC priority strict-high (5 percent is the default for network control on JunOS 10) 3. Map the schedulers to each forwarding class: [edit class-of-service scheduler-maps] set sched-map-llq forwarding-class BE scheduler sched-BE set sched-map-llq forwarding-class EF scheduler sched-EF set sched-map-llq forwarding-class NC scheduler sched-NC 4. Apply scheduler map to the interface: [edit class-of-service interfaces] set interface scheduler-map sched-map-llq --- In your case you would create additional forwarding classes for each of your BE queues. HTH, Matt On Mon, Jan 31, 2011 at 12:51 AM, Vlad Ion vlad.th...@gmail.com wrote: Hi, Can anyone lend a hand with a sample configuration of QoS on Juniper? I am trying to have something really close to an existing Cisco deployment of LLQ with 1 PQ for VoIP and routing protocols (OSPF/IS-IS, BGP, LDP, RSVP), 3 CBWFQ classes (OAM, Services, IPSec VPNs) and a default class with everything that was not included in the previous classes. Thanks in advance, Vlad ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Matthew Tighe matthew.e.ti...@gmail.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX480 JunOS version.
On Jan 28, 2011, at 3:19 PM, Joel Jaeggli wrote: On 1/28/11 2:35 PM, Keith wrote: On 1/28/2011 2:16 PM, Richard A Steenbergen wrote: On Fri, Jan 28, 2011 at 02:03:54PM -0800, Keith wrote: Currently the box is running 10.2R1.8. It has a MIC-3D 20 port card, MPC1, and RE-S-2000. Juniper just put out a tech bulletin this morning admitting the obvious, that 10.2R1/R2/R3 and 10.3R1 for Trio (MPC) cards are massively broken and shouldn't be used. Try 10.3R2, it's been mostly ok for us (not counting the bug we hit the other day where all the MPCs crashed in an endless loop after updating a prefix-list referenced in a firewall filter on them, but at least so far this seems rare :P). Alas 10.3R3 seems to be delayed, but you'll be far better off with 10.3R2 than you will with 10.2R1 in the config above. Thanks Richard. I see that 10.4R1.9 is out. Have you had a go at that version yet? I've got an outstanding bug on mx480 where rpd/vrrpd barf on native interfaces but not irb's in 10.4r1.9 Regards, Keith We are going to start an eval with 10.4R2, but all of our MX's (about 40 MX960 and MX480s) are running 9.5R4.3 as that was the last real stable release we found. However, it is missing a number of features as well (and had a few annoying bugs), so I am hoping 10.4R2 ends up being decent. All DPC based here. 10.4R1 I have not been impressed with, so I just held off on it. -Jeff ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Offline config verification
That won't always work though. If there are pieces of the config that are hardware dependent, such as COS, etc., you won't get an alert without identical hardware to evaluate it on. For basic config items it would be fine of course. Jeff On Jan 14, 2011, at 1:58 PM, Tim Eberhard xmi...@gmail.com wrote: Olives are great for these types of scripts. An olive vmware machine can be hosted on anything and just be used for config verification. Hope this helps, -Tim Eberhard On Jan 14, 2011, at 3:40 PM, Nvvk Brnn saveda...@gmail.com wrote: Hi: I have some perl scripts that generate Juniper configs. I need to verify that these configs are Juniper compatible (as there could be bugs in my scripts) I have 2 options. 1) Copy the generated config to a juniper router, load merge config and then commit to see if there are errors. (We will actually see errors while doing a load merge) 2) This is the option that I want to pursue (in the interest of time as I have lots of verification to do) An offline config parser that will tell me if I have a valid Juniper config. Do we know which daemon in juniper does this config parsing? I could start a shell on the juniper and copy the binaries to a remote machine and start playing with them, but wanted to see if someone has any similar experience. Thanks, N ___ 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] Filtering the export of VRF routes with iBGP export filters....
I would be interested if you find a solution. We have had 2 JTAC cases open on this exact same thing, and both ended in JTAC giving up and not being able to present a workable solution. My scenario is slightly different, but still would require the exact functionality you are looking for Regards, -Jeff On Aug 30, 2010, at 1:25 PM, David Ball wrote: Ts/MXs running 10.0.R3.10 I don't have access to my actual configs, but think I can verbalize anyways. Does anyone know if it's possible to filter a given VRF route prior to export to an iBGP peer? Naturally, the route itself includes an RD and RT, and I can't get my 'match' clauses to work. I've been trying matching on things like community (ie. community SOMENAME members target:###:###), on RIB (ie. rib bgp.l3vpn.0), and also using a route-filter (which I don't believe supports VRF routes), but with no success. For interest's sake, I'm running in 'route-reflector-ready' mode, in that routes are being exported from bgp.l[2|3]vpn.0 rather than from the individual routing tables themselves, hence my trying to match on the bgp.l3vpn.0 RIB instead of an individual VRF's RIB. I was sure I saw a workaround listed here, but can't find it in the archives for the life of me. David ___ 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
