[j-nsp] . Re: Controlling routes between OSPF areas
What if you put the policy and check on the other end ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Controlling routes between OSPF areas
On Thursday, May 10, 2012 04:06:26 AM Morgan McLean wrote: Also, just to add to this, if I try to deny a route by neighbor or next-hop, the entire route is denied regardless of where it comes from. If I try to deny the export of a route from protocol static on the announcing router, again it doesn't matter to which neighbor, it denies the entire route. Am I just SOL? BGP is so much easier to work with Link state routing protocols don't generally like to be filtered, as a consistent, holistic view of the global network topology is the only way to avoid loops in your link state IGP network. Yes, there is some kind of filtering available in routing implementations for link state routing protocols, and as you can see, it behaves rather strangely and might not do everything you want, the way you want or expect. For some implementations, I've seen filtering on inbound to be more successful, while in others, it's been the reverse. At the heart of it, while it is possible to filter prefixes being announced/received, the filters don't really filter the entire IGP message, as what is exchanged among neighbors is LSA's (OSPF) and LSP's (IS-IS), and not routes as in the case of BGP. I have been in your exact situation before where we've had to originate a default route to various Access switches in Metro-E rings, and IS-IS seemed like an obvious way to do it between the PE Aggregation routers and the Access switches directly. But while you could originate the default route to the Access network, it wasn't easy to prevent said route from being announced to other parts of the network where it wasn't needed (especially since we were a flat Level-2 IS- IS network). Unlike BGP, route exchanges among neighbors is not unicast in nature (yes, it can be in certain cases), so controlling which routes/LSA's/LSP's go where isn't easy. We ended up going with BGP, getting those default routes announced to all Access switches from the control-plane-only route reflectors in the network, and relying on MPLS to ensure proper forwarding of traffic (away from the route reflectors that were originating those default routes). Hope this helps. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Document Update - EX Features
On Friday, May 04, 2012 07:26:28 PM David Ball wrote: Some of the Juniper document maintainers peruse this list regularly. I once complained here about a VPLS document not quite being right, and I was emailed within days by someone who could facilitate such a change. They even solicited my feedback on how the wording should be structured. In 2008, I e-mailed the webmasters of www.juniper.net to add the M120 into the pictures of all their M-series routers at the time. The M120 was the only router missing, and lo and behold, the new image was uploaded to the web site within 24hrs. I was impressed :-). Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Update on 10.4R9 stability for MX?
On Thursday, May 10, 2012 01:59:55 AM Richard A Steenbergen There is a serious issue with MPLS RSVP auto-bandwidth in 10.4R9, which can cause the reservation calculations to be off by quite a bit. The least broken code we've found so far is 10.4S9, I'm surprised they haven't done an R10 yet. As far back as I can remember, Richard, you've pretty much had this particular issue with almost every major train Juniper have released :-). Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRLGs in Inter-Area LSPs
On Sunday, May 20, 2012 10:36:15 AM Łukasz Dudziński wrote: I didn't know that option before. It seems, it can be very useful in hierarchic networks. It's a pity that it is poor documented. Really? I thought it was reasonably documented way back as Junos 8.5. We use expanded loose hops back in Junos 9.x when we have a multi-level IS-IS backbone, between various Cisco and Juniper routers. It wasn't without its issues, but worked for the most part. What we did with our second network was simply use a flat Level-2 IS-IS domain, as p2mp RSVP-TE needed to run across different parts of the country, and sticking in multiple levels would have rendered that service problematic to deploy. But yes, BGP Label Unicast is the recommended scaling method for so-called Seamless MPLS deployments. I just think it's overly complicated. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Update on 10.4R9 stability for MX?
On Mon, May 21, 2012 at 03:43:33PM +0200, Mark Tinka wrote: On Thursday, May 10, 2012 01:59:55 AM Richard A Steenbergen There is a serious issue with MPLS RSVP auto-bandwidth in 10.4R9, which can cause the reservation calculations to be off by quite a bit. The least broken code we've found so far is 10.4S9, I'm surprised they haven't done an R10 yet. As far back as I can remember, Richard, you've pretty much had this particular issue with almost every major train Juniper have released :-). I wish it was a single issue, at least then I would have one definite thing to bitch about. It's more like a dozen different issues affecting the same subsystem, in a dozen different versions of code, over the last couple of years. You could say the same thing about SNMP, it's been broken about as many times over about as many different revisions (including recent ones :/). 10.4S9 does seem to have solved this latest issue, which was causing wildly inaccurate reservations. It's almost comical when RSVP tries to reserve a several petabit LSP (not much to do with recent JUNOS except laugh at this point, right? :P), but it's a lot less funny when nearly empty high-priority LSPs get mis-calculated to several gigabits and start causing incorrect preemptions... -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Update on 10.4R9 stability for MX?
The answer is pretty much the same with every code version. You can query the list for what others think are relevant bugs, but it's largely subjective. Depends on the size of your network, the services you use and where you're upgrading from. If you're already in the 10.4 train upgrading to a new release is (some list members may differ) supposed to provide bug fixes only and no new features or bugs. If you are coming from a much older code you may see new bugs that weren't there before as well as changes in features or syntax. Generally, speaking I haven't come across many bugs in 10.4 although we're running an older release. According to their software lifecycle policy there shouldn't be any bugs in 10.4R9 that aren't in earlier versions of 10.4. As I said earlier though YMMV considerably. 2012/5/9 Clarke Morledge chm...@wm.edu It has been a couple of months since the JTAC recommended Junos software versions has been updated for the MX. As of February, the recommendation was to use 10.4R8.5 for the MX, except that there is an issue related to BFD configurations on the DPC line cards. Supposedly, the fix is in 10.4R9. In looking at the release notes, there are some issues that have been resolved in the 11.x series but nothing noted yet for any future 10.4.x releases. Perhaps there are future 10.4.x versions planned to carry forward these fixes? I am curious to know about anyone's experience with 10.4R9 over the past few months. I have DPC only currently; i.e. no MPC hardware -- and no MultiServices. 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-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] JUNOS downloads
Has anybody else noticed that the old software download page isn't getting updated at the same time as the new one? For example, 11.4R3 came out 3 days ago, but it isn't listed on the old software page at all. The new and improved system also appears to require javascript to work properly, for example the proceed button at the bottom of the EULA acceptance is non-functional in lynx or elinks if you're trying to download your JUNOS images via a unix shell. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS downloads
Using a unix shell, to download software directly to a router, which itself uses a unix shell..? Sorry - That's too clever (and hence; not allowed). =) - CK. On 2012-05-22, at 9:29 AM, Richard A Steenbergen wrote: the proceed button at the bottom of the EULA acceptance is non-functional in lynx or elinks if you're trying to download your JUNOS images via a unix shell. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS downloads
#ciscoed On May 21, 2012, at 6:32 PM, Richard A Steenbergen r...@e-gerbil.net wrote: Has anybody else noticed that the old software download page isn't getting updated at the same time as the new one? For example, 11.4R3 came out 3 days ago, but it isn't listed on the old software page at all. The new and improved system also appears to require javascript to work properly, for example the proceed button at the bottom of the EULA acceptance is non-functional in lynx or elinks if you're trying to download your JUNOS images via a unix shell. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] mx240 vs asr 9006
Pro JUNOS: I would add that JUNOS I think has much better automation features. Also there are some interesting features on the MX that make deploying appliance-in-the-cloud setups easier to deploy (BGP capable appliance between MPLS LERs). I generally think VPLS is easier in JUNOS. Pro Cisco: MPLS/VRF aware foo. Like NAT, SSL, IPSec/GET, and just a load of other features. Although I'm not sure how much of this applies to the 9k.. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth/ From: Mark Tinka mark.ti...@seacom.mu To: juniper-nsp@puck.nether.net Sent: Sunday, May 20, 2012 2:51 PM Subject: Re: [j-nsp] mx240 vs asr 9006 On Wednesday, April 25, 2012 03:54:56 PM Phil Bedard wrote: Yes thanks for mentioning that. My opinion would be to use a MX480 like someone else said just due to the increased slot capacity, over the 9006 or 240. For me, the extra 2x slots on the MX480 wouldn't be a compelling-enough reason to choose it over the ASR9006. Like someone mentioned earlier, chassis pricing is so negligible that it makes more sense to go for an MX480 over an MX240 like it would to go for an ASR9010 over an ASR9006. In our case, it's mostly come down to how much we want to scale in the space that we (don't have), which is why an MX240 has never made any sense to us, just like the ASR1004. Moroever, both the MX and ASR9000 chassis' are shipping faster line cards that mean you can pack more bandwidth into a single slot by the time you think about scaling across the entire chassis. Having operated both platforms in the same network, while I'll always have both vendors in my network as principle, my reasons to choose one over the other would be: o I'd prefer an ASR9000 over the MX because of the more intuitive ingress packet marking on the Cisco. Juniper can now do it on the Trio line cards with firewall filters, but it doesn't support marking of EXP bits. If only Juniper - despite the numerous times I've asked - could implement the ToS Translation Tables feature that they do for the IQ2 and IQ2E PIC's for the M- series routers, on the MX line, it would bring them inline with Cisco on this platform (Juniper's classic egress marking/rewriting has always been awkward, IMHO). o I'd prefer the MX because it implements NG-MVPN, while Cisco are still mucking about, re-enacting the LDP vs. BGP fiasco of old. o I'd prefer the the Cisco if I had to mix the classic and newer line cards in the same chassis, as (at least for a long while), mixing DPC's and MPC's was problematic. Word is that this is no longer an issue - I'm due to test. o I'd prefer the Juniper because Cisco make you pay for ridiculous licenses just to deploy l3vpn's on the ASR9000. You get the point... but: o Either router would be fine for basic IPv4, IPv6 and MPLS services. o Either router would be fine for PE Aggregation scenarios in Metro-E networks. o Either router would be fine if I wanted to add non-Ethernet line cards to it (the MX is now sporting these, even though I'm wary it may not be mature yet). o Either router would be fine if I wanted to run 100Gbps Ethernet ports. Hope this helps. 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
