[j-nsp] Word of warning about 9.6R4
It looks like they imported one of the isis bugs I was seeing in 10.0R3 into 9.6R4, which wasn't there in 9.6S5. It seems if you have any isis prefix-export-limit configured it triggers an isis overload, regardless of whether you've actually hit the configured value or not. Hopefully this saves somebody else the grief that it caused me, before you assume 9.6S5 to 9.6R4 is a safe upgrade. :) -- 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] Vlan Rewrite - Non IQ PICs (MX)
HI Tarique what type of TCC are you talking about ? VLAN -TCC ? I guess it depends on how JKING wants to do his VLAN mapping, from what I remember VLAN-CCC only supports one type of TPID, whereas vlan-rewrite can support all 3 types of the TPID. now don't ask what the 3 TPID 0x8... are as I don't remember :-p I personnaly wasn't aware you could do vlan rewrite directly on the TCC config, I always believed you still needed to configure the input-vlan-map additionally to the TCC config. If true, then I guess we never stop learning, if not then it is added config for nothing, Can anyone confirm this ? thanks Furthermore, if the choice is between the two, I would use VLAN rewrite as it is a bit more flexibility, such as the option to have CE-PE on one end sending native packet and tagging only on when the packet reaches the PE interface (via native-vlan-id options) and the other end can have the vlan being forwarded to the CE. On 2 June 2010 17:36, Tarique A. Nalkhande - BMC t.nalkhande@mobily.com.sa wrote: TCC is the way to go.. TCC is supported in CCC, draft-Kompella, and draft-Martini based VPNs to allow for interworking between dissimilar access technologies (or differing VLAN IDs, which are normally required to be the same at both ends of a L2 VPN). Feel free to unicast, if you need anything more specific. Goodwill, Tarique A.N -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto: juniper-nsp-boun...@puck.nether.net] On Behalf Of Bj?rn Tore Paulen Sent: Tuesday, June 01, 2010 9:53 PM To: Jking T Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Vlan Rewrite - Non IQ PICs (MX) Jking T skrev: So there we are, no vlan rewrite for point-to-point L2VPN, kompella without IQ. Kompella without IQ.. Not sure if Kireeti would approve... ;-) /BT ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp --Disclaimer- This email and any files transmitted with are classified as confidential unless otherwise specified. This e-mail is intended solely for the use of the individual or entity to whom this e-mail is addressed. If you have received this email by mistake, please notify the sender and delete this e-mail immediately and permanently. Although measures were taken to free this e-mail and its attachments from any malicious code infection, it is the responsibility of the recipient to check this email and any attachments for the presence of such infection. The use of EEC(Mobily) e-mail service is limited for EEC(Mobily) business use only. ___ 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] GRE Bridging, is it possible with a Juniper box ?
On Thu, 3 Jun 2010, Patrik Olsson wrote: Have you tried looking for L2TP with PPP over BCP intestead PPP over IPCP? If you want to encapsulate the whole ethernetframe and send over a GRE tunnel so you get a bridged enviroment, is it called Ethernet over IP (EOIP). Dont remeber the rfc, but is not supported by Juniper. Only supported by a small Latvian vendor I think... I wonder if you refer to rfc3378. I recall support for it was recently added in Linux as well. But I don't see why encapsulaitng whole ethernet frames in GRE could not work if vendors just chose to support it. Then as 'ether type' in GRE header you could put 0x6558 or 0x8100 (IEEE 802.1q VLAN-tagged frames *). The former is also supported in Linux [http://lwn.net/Articles/303062/] *) http://www.iana.org/assignments/ethernet-numbers -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] NTT IPv6-aware people contact
Hi. Could someone from NTT Communications Japan contact me off-ist regarding NTT's IPv6 Transition Consultancy ? -- Best regards, Egor Zimin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NSR with SRX
I have tested it and it wroks. On Tue, Jun 1, 2010 at 4:44 PM, Fahad Khan fahad.k...@gmail.com wrote: Has any one tested NSR (for Dialup VPN) with SRX 3600 ?? regards, Muhammad Fahad Khan JNCIP - M/T # 834 IT Specialist Global Technology Services, IBM fa...@pk.ibm.com +92-321-2370510 +92-301-8247638 Skype: fahad-ibm http://www.linkedin.com/in/muhammadfahadkhan On Sat, May 29, 2010 at 10:16 AM, Chen Jiang iloveb...@gmail.comwrote: NSR works but will not be officially supported by JNPR any more. On Wed, May 26, 2010 at 8:52 PM, Fahad Khan fahad.k...@gmail.comwrote: Dear Folks, Has any one used Netscreen Remote Client for dialup VPN with SRX device?? I have seen in release notes of 10.1 that SRX does not support NSR. But in security guide, NSR is a dedicated chapter please respond quickly regards, Muhammad Fahad Khan JNCIP - M/T # 834 IT Specialist Global Technology Services, IBM fa...@pk.ibm.com +92-321-2370510 +92-301-8247638 Skype: fahad-ibm http://www.linkedin.com/in/muhammadfahadkhan http://fahad-internetworker.blogspot.com http://www.visualcv.com/g46ptnd ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- BR! James Chen -- BR! James Chen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SSG Admin User Help
If you are using a non-root account, you are not allowed to create or remove user accounts. Only the root administrator account (named netscreen unless it was changed) is allowed to create or remove admin user accounts. If you're logged on with the root administrator account you should be able to remove it with the unset command. Hope that helps. Dave David W. Ford, CISSP JNCI, JNCIS-SEC, JNCIS-FWV Security Engineer d...@proteus.net -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Brad Fleming Sent: Thursday, June 03, 2010 10:57 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] SSG Admin User Help Hello all, We've gone through some sudden staff changes and I need to remove some config from an SSG-550M running ScreenOS 6.2. I know we shouldn't have a device with no backup; all things that will be fixed going forward. I just want to be sure we aren't sitting wide open for remote access on the box right now. Any help is appreciated. Specifically, I need to remove the following: set admin user user password hashed pass privilege all set admin mail mail-addr1 email I'm having trouble removing the configurations from both the CLI and web interface. I believe my account is allowed full read-write capabilities... device- get ssh SSH V2 is active SSH is enabled SSH is ready for connections Maximum sessions: 6 Active sessions: 1 Admin Ip Addr Vsys Auth Method Service -- --- -- my usr my ip Root password console ___ 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] Word of warning about 9.6R4
Ehlo, Can you provide PR# ? Also, are there any other conditions to be present for this bug to be triggered ? I have here in lab 10.0R3.10 , with prefix-export-limit set and some routes redistributed from static and can't see overload set on LSP ( of course, number of routes are not hitting limit ) thanks in advance Piotr Marecki 2010/6/3 Richard A Steenbergen r...@e-gerbil.net: It looks like they imported one of the isis bugs I was seeing in 10.0R3 into 9.6R4, which wasn't there in 9.6S5. It seems if you have any isis prefix-export-limit configured it triggers an isis overload, regardless of whether you've actually hit the configured value or not. Hopefully this saves somebody else the grief that it caused me, before you assume 9.6S5 to 9.6R4 is a safe upgrade. :) -- 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] SSG Admin User Help
It does help, thank you. That's pretty much what I figured was happening. Looks like I'll be doing a root admin recovery during maintenance tonight too! :D On Jun 3, 2010, at 1:05 PM, David W. Ford wrote: If you are using a non-root account, you are not allowed to create or remove user accounts. Only the root administrator account (named netscreen unless it was changed) is allowed to create or remove admin user accounts. If you're logged on with the root administrator account you should be able to remove it with the unset command. Hope that helps. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Word of warning about 9.6R4
On Thu, Jun 03, 2010 at 11:13:52AM -0700, Piotr Marecki wrote: Ehlo, Can you provide PR# ? Also, are there any other conditions to be present for this bug to be triggered ? I have here in lab 10.0R3.10 , with prefix-export-limit set and some routes redistributed from static and can't see overload set on LSP ( of course, number of routes are not hitting limit ) No PR# yet, they're still trying to replicate it. It's possible that something else is required to cause it, but our standard config seems to do it every time. We've definitely seen this blow up on multiple routers on 10.0R3 and 9.6R4 and be fixed by removing the prefix-export-limit, even though that limit was in no danger of being hit.. -- 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
[j-nsp] Traffic shaping on J and SRX
Hi all, I need to shape on egress from CE to PE to match the service provider's 'PVC' speed. The physical interface is gigabit Ethernet. We have a variety of J and SRX boxes running JUNOS 10.0R3. We have the following access/service speed combos (all on J/SRX ge-x/x/x or SRX xe-x/x/x): 100m/10m, 1g/50m, 1g/100m, 1g/150m, 1g/200m, 10g/1g. I have a JTAC case running on this but I haven't been making good progress. The carrier's EoSDH access network throws away traffic when bursts fill up the relatively small buffers (~130K) in their Alcatel equipment. I need to tune the shaper to control/buffer bursts. Through the JTAC case (which I have just asked to be escalated), I have NOT been able to determine: 1. how the burst size is calculated when (for example) 'shaping-rate 150m' is used without any other configuration on a logical unit. 2. how, if at all, the burst size can be tuned. I need to ensure I drive the burst size (in bytes) down to =130K for all of the access/speed combinations above How is everyone doing this in the real world? Lastly, through my investigations with Juniper folks outside the JTAC, I have become aware of two things: - The default burst size on J-series cannot be configured and (whatever it is,) is too high - PR/511498. The shaper burst-size was calculated based on interface-bandwidth instead of the shaping-rate. Fixed in 10.0-20100326.0 daily SR or later, apparently. No more info. I hate to draw the comparison but detailed information about how the shaper works and can be tuned is readily available in vendor C land :-/ Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Traffic shaping on J and SRX
Hi,
Try this config. I am not sure if it could resolve your problem, but you can
give it a try.
==
interfaces {
ge-0/0/1 {
description ## 100m ##;
unit 0 {
bandwidth 100m;
family inet {
address xx.xx.xx.xx/30;
}
}
}
}
class-of-service {
interfaces {
ge-0/0/1 {
unit 0 {
shaping-rate 100m;
}
}
}
}
=
--
Michel~
On Thu, Jun 3, 2010 at 3:09 PM, Dale Shaw
dale.shaw+j-...@gmail.comdale.shaw%2bj-...@gmail.com
wrote:
Hi all,
I need to shape on egress from CE to PE to match the service
provider's 'PVC' speed. The physical interface is gigabit Ethernet. We
have a variety of J and SRX boxes running JUNOS 10.0R3.
We have the following access/service speed combos (all on J/SRX
ge-x/x/x or SRX xe-x/x/x): 100m/10m, 1g/50m, 1g/100m, 1g/150m,
1g/200m, 10g/1g.
I have a JTAC case running on this but I haven't been making good progress.
The carrier's EoSDH access network throws away traffic when bursts
fill up the relatively small buffers (~130K) in their Alcatel
equipment. I need to tune the shaper to control/buffer bursts.
Through the JTAC case (which I have just asked to be escalated), I
have NOT been able to determine:
1. how the burst size is calculated when (for example) 'shaping-rate
150m' is used without any other configuration on a logical unit.
2. how, if at all, the burst size can be tuned. I need to ensure I
drive the burst size (in bytes) down to =130K for all of the
access/speed combinations above
How is everyone doing this in the real world?
Lastly, through my investigations with Juniper folks outside the JTAC,
I have become aware of two things:
- The default burst size on J-series cannot be configured and
(whatever it is,) is too high
- PR/511498. The shaper burst-size was calculated based on
interface-bandwidth instead of the shaping-rate. Fixed in
10.0-20100326.0 daily SR or later, apparently. No more info.
I hate to draw the comparison but detailed information about how the
shaper works and can be tuned is readily available in vendor C land
:-/
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] GRE Bridging, is it possible with a Juniper box ?
This sounds like what Cisco is doing with OTV. They are using ethernet over GRE w/multicast to transport ethernet... It is being marketed as a better alternative to VPLS. From: Pekka Savola pek...@netcore.fi To: Patrik Olsson d...@webkom.se Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Thu, June 3, 2010 4:59:26 AM Subject: Re: [j-nsp] GRE Bridging, is it possible with a Juniper box ? On Thu, 3 Jun 2010, Patrik Olsson wrote: Have you tried looking for L2TP with PPP over BCP intestead PPP over IPCP? If you want to encapsulate the whole ethernetframe and send over a GRE tunnel so you get a bridged enviroment, is it called Ethernet over IP (EOIP). Dont remeber the rfc, but is not supported by Juniper. Only supported by a small Latvian vendor I think... I wonder if you refer to rfc3378. I recall support for it was recently added in Linux as well. But I don't see why encapsulaitng whole ethernet frames in GRE could not work if vendors just chose to support it. Then as 'ether type' in GRE header you could put 0x6558 or 0x8100 (IEEE 802.1q VLAN-tagged frames *). The former is also supported in Linux [http://lwn.net/Articles/303062/] *) http://www.iana.org/assignments/ethernet-numbers -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] (no subject)
7 Sent from my iPhone ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] (no subject)
8 On Jun 3, 2010 11:45 PM, Tommy Perniciaro tpernici...@accuvant.com wrote: 7 Sent from my iPhone ___ 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] (no subject)
It's the answer to the universe! *faints* On 04/06/2010, at 11:08 AM, Tommy Perniciaro wrote: 7 Sent from my iPhone ___ 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] GRE Bridging, is it possible with a Juniper box ?
Hi Group, Well I have a slight confession to make. When I initially asked the question, it was based on the assumption that Cisco provided this. But they don't. I had played with bridging over frame relay way back, and somehow this became GRE in my mind. Sorry about the mistake. So now im looking into L2TP as an alternative. But the One-Access 1221 1424 are supporting ethernet over GRE. Kind Regards, Peter Krupl -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Derick Winkworth Sent: Friday, June 04, 2010 4:58 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] GRE Bridging, is it possible with a Juniper box ? This sounds like what Cisco is doing with OTV. They are using ethernet over GRE w/multicast to transport ethernet... It is being marketed as a better alternative to VPLS. From: Pekka Savola pek...@netcore.fi To: Patrik Olsson d...@webkom.se Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Thu, June 3, 2010 4:59:26 AM Subject: Re: [j-nsp] GRE Bridging, is it possible with a Juniper box ? On Thu, 3 Jun 2010, Patrik Olsson wrote: Have you tried looking for L2TP with PPP over BCP intestead PPP over IPCP? If you want to encapsulate the whole ethernetframe and send over a GRE tunnel so you get a bridged enviroment, is it called Ethernet over IP (EOIP). Dont remeber the rfc, but is not supported by Juniper. Only supported by a small Latvian vendor I think... I wonder if you refer to rfc3378. I recall support for it was recently added in Linux as well. But I don't see why encapsulaitng whole ethernet frames in GRE could not work if vendors just chose to support it. Then as 'ether type' in GRE header you could put 0x6558 or 0x8100 (IEEE 802.1q VLAN-tagged frames *). The former is also supported in Linux [http://lwn.net/Articles/303062/] *) http://www.iana.org/assignments/ethernet-numbers -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ 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
