Re: [j-nsp] Recommended Releases now posted for MX, M, T, QFX
On Tuesday, January 31, 2012 12:32:26 AM James Jones wrote: I am just curious what issues you guys are having with the junos releases? Run through the archives to get a feel for what issues folk are facing. And these are just the issues that folk have decided to share. There are others that aren't shared, or folk that aren't sharing entirely. I am currently not having issues with any of my Juniper kit. It's really dependent on how kinky you're running your boxes. If you look at my route reflectors (M120's), 10.4R4.5 is solid, no issues. If you look at my PE Aggregation routers (MX480's, M320's, T320's), you don't want to know. If you look at the MX480 we're trying to make a BRAS, all bets are off :-). It would be interesting to understand the use cases in which you are seeing issues. The problem is that since Junos 9.4, we've all been thinking and hoping that the R4 release of that train (and all the ones following it) would be the ideal one. The solid one. The one on which we can hang our boots on and kick back. But alas, that was never to be the case, and given we're now literally peeking at Junos 13 (or 14, or 15, whatever they decide to do after 12), it's amazing that we're all still chasing that ever elusive dream of a stable Junos. Which, by the way, is not to discount all the good work that Juniper have done, particularly since the debacle that was Junos 10.2, but given that operators need to choose between: o Stable code. o Code that features you actually want. o Code that will be under Juniper EEOL program. o Code that will run new hardware. o Code that will fix all issues past without bringing issues present. ... you can see where all the frustration is coming from. What's worse, Junos 8 was a dream, so we all know what it's like to have good code :-). Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Recommended Releases now posted for MX, M, T, QFX
One incredible frustration we're going through lately on the MX boxes is the BRAS function as Mark mentioned briefly . we're up to bleeding edge code now (11.4R1.14) just to get what we consider typical features of a BRAS box. Combine that with the first BRAS box I've seen that is picky about Radius VSA's and it makes it really difficult to deploy. We are not sure if the word stable enters the equation yet as a BRAS neither - time will tell as we're pushing out several of these boxes shortly despite concerns around code. Paul -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mark Tinka Sent: Tuesday, January 31, 2012 3:05 AM To: James Jones Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Recommended Releases now posted for MX, M, T, QFX On Tuesday, January 31, 2012 12:32:26 AM James Jones wrote: I am just curious what issues you guys are having with the junos releases? Run through the archives to get a feel for what issues folk are facing. And these are just the issues that folk have decided to share. There are others that aren't shared, or folk that aren't sharing entirely. I am currently not having issues with any of my Juniper kit. It's really dependent on how kinky you're running your boxes. If you look at my route reflectors (M120's), 10.4R4.5 is solid, no issues. If you look at my PE Aggregation routers (MX480's, M320's, T320's), you don't want to know. If you look at the MX480 we're trying to make a BRAS, all bets are off :-). It would be interesting to understand the use cases in which you are seeing issues. The problem is that since Junos 9.4, we've all been thinking and hoping that the R4 release of that train (and all the ones following it) would be the ideal one. The solid one. The one on which we can hang our boots on and kick back. But alas, that was never to be the case, and given we're now literally peeking at Junos 13 (or 14, or 15, whatever they decide to do after 12), it's amazing that we're all still chasing that ever elusive dream of a stable Junos. Which, by the way, is not to discount all the good work that Juniper have done, particularly since the debacle that was Junos 10.2, but given that operators need to choose between: o Stable code. o Code that features you actually want. o Code that will be under Juniper EEOL program. o Code that will run new hardware. o Code that will fix all issues past without bringing issues present. ... you can see where all the frustration is coming from. What's worse, Junos 8 was a dream, so we all know what it's like to have good code :-). Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] GRE packet fragmentation on j-series
Pls refer the below appnote
http://www.juniper.net/us/en/local/pdf/app-notes/3500192-en.pdf
see the section
From: Ben Dale bd...@comlinx.com.au
To: Lukasz Martyniak lmartyn...@man.szczecin.pl
Cc: Juniper-Nsp (juniper-nsp@puck.nether.net) juniper-nsp@puck.nether.net
Sent: Tuesday, January 31, 2012 5:28 AM
Subject: Re: [j-nsp] GRE packet fragmentation on j-series
Hi Lukasz,
J-Series only needs a license to download signature updates for IDP - in order
to stop fragmentation, all you need to do is create a security policy that
matches on GRE traffic match application junos-gre and then references the
idp engine in the action then permit application-services idp.
This will force the IDP engine to re-assemble the GRE fragments for inspection
(but not actually inspect them).
Juniper had a really good document explaining this with examples for MPLSoGRE,
but my google and KB-fu is failing.
Cheers,
Ben
On 26/01/2012, at 7:17 PM, Lukasz Martyniak wrote:
Thanks for quick response, i had a hoped that this could be done in other
whey. I think jseries need extra license for IDP.
On Jan 24, 2012, at 11:35 PM, Alex Arseniev wrote:
My understanding is that GRE fragmentation should occur if egress interface
MTU is GRE pkt size.
For GRE reassembly, you need IDP policy, this means high memory SRX model.
IDP license is not needed.
Rgds
Alex
- Original Message - From: Lukasz Martyniak
lmartyn...@man.szczecin.pl
To: juniper-nsp@puck.nether.net
Sent: Tuesday, January 24, 2012 2:04 PM
Subject: [j-nsp] GRE packet fragmentation on j-series
Hi all
I have some problem with gre tunnels. I need to fragment packages in
tunnel. I run gre between two jseries (junos 10.4R6) and lunch MPLS on it.
The problem looks like that packages with MTU above 1476 are not
fragmented/reassembled and are dropped.
interfaces gr-0/0/0
unit 10 {
clear-dont-fragment-bit;
description Tulne to r1-lab;
tunnel {
source 10.200.0.1;
destination 10.200.0.2;
allow-fragmentation;
path-mtu-discovery;
}
family inet {
mtu 1500;
address 100.100.100.1/30;
}
family mpls {
}
}
Have someone have similar problem ? is there a simple way to fix this ?
Best Lukasz
___
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
MPLSoGRE with GRE Fragmentation and Reassembly
--Thanks
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Recommended Releases now posted for MX, M, T, QFX
On Tuesday, January 31, 2012 06:12:02 PM Paul Stewart wrote: One incredible frustration we're going through lately on the MX boxes is the BRAS function as Mark mentioned briefly . we're up to bleeding edge code now (11.4R1.14) just to get what we consider typical features of a BRAS box. Combine that with the first BRAS box I've seen that is picky about Radius VSA's and it makes it really difficult to deploy. We are not sure if the word stable enters the equation yet as a BRAS neither - time will tell as we're pushing out several of these boxes shortly despite concerns around code. Ditto. The MX is nowhere near ready to run as BRAS. But like you, we decided to migrate to it, so we have no choice but to run bleeding edge Junos 11.4R1 as well, just to get basic things the outgoing Redback is able to do, as well as some IPv6. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Recommended Releases now posted for MX, M, T, QFX - Update!
On Tuesday, January 31, 2012 06:26:44 PM Mark Tinka wrote: The MX is nowhere near ready to run as BRAS. But like you, we decided to migrate to it, so we have no choice but to run bleeding edge Junos 11.4R1 as well, just to get basic things the outgoing Redback is able to do, as well as some IPv6. In hindsight, we probably should have gone with Cisco's ASR1006. Oh well... Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Recommended Releases now posted for MX, M, T, QFX - Update!
Yup.. our hindsight would have been to continue deploying E/ERX ;) Paul -Original Message- From: Mark Tinka [mailto:mti...@globaltransit.net] Sent: Tuesday, January 31, 2012 5:28 AM To: Paul Stewart Cc: 'James Jones'; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Recommended Releases now posted for MX, M, T, QFX - Update! On Tuesday, January 31, 2012 06:26:44 PM Mark Tinka wrote: The MX is nowhere near ready to run as BRAS. But like you, we decided to migrate to it, so we have no choice but to run bleeding edge Junos 11.4R1 as well, just to get basic things the outgoing Redback is able to do, as well as some IPv6. In hindsight, we probably should have gone with Cisco's ASR1006. Oh well... Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Filter-based forwarding outside of inet.0?
I am still trying to wrap my head around FBF, and I am stuck on how to
achieve a Cisco-like PBR forcing a packet that matches a set of conditions
to go to a different next-hop inside a VRF. The problem I have is when
the new next-hop can only be resolved within the VRF, NOT the default
routing instance (inet.0).
Let's say I am trying to create this forwarding instance to change the
default route:
[edit routing-instances fbf-test]
HonkinBigMx# show
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 192.168.255.1;
}
}
I need to create a rib group where 192.168.255.1 can be resolved
(correct?). It can be resolved in a virtual routing instance (a VRF)
called test.inet.0 where I need to insert via a filter the changed default
route next-hop for PBR forwarding purposes. THe 192.168.255.1 can not
resolve in inet.0 because it does not live there.
If I try to create a rib group:
interface-routes {
rib-group inet fbf-rib-test;
}
rib-groups {
fbf-rib-test {
import-rib [ fbf-test.inet.0 test.inet.0 ];
}
}
The Junos compiler complains:
[edit routing-options interface-routes]
'rib-group'
fbf-rib-test: primary rib for instance master was not found in
ribgroup configuration.
error: configuration check-out failed
I try to define the interface-routes at in the test.inet.0 routing
instance stanza (which is where I think it should be defined anyway), and
I get a similar complaint.
In reading the docs, they insist that I must import inet.0 into the rib
group, even though the next-hop can not be found to resolve there.
Furthermore, I can only define a rib-group in the default routing
instance part of the config and not in the routing-instance part of the
config.
What am I missing here and/or how can I workaround this limitation?
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
Re: [j-nsp] packet based on jseries
On Tue, Jan 24, 2012 at 2:09 AM, Pierre-Yves Maunier j-...@maunier.org wrote: 2012/1/23 pkc mls pkc_...@yahoo.fr You can activate packet based routing on recent Junos SRX/J-Series devices : http://juniper.cluepon.net/Enabling_packet_based_forwarding but some functions will stop working, such as cflow or IPsec tunnels. -- Michel~ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
