Re: [j-nsp] LDP on ex4200/3200 series..and 1RU LSR?
I had a couple over here, they seemed pretty good. I had L3VPN working and l2circuit but didn't try VPLS and I was not aware of the limitation. Now, I am a little surprised about this lack of feature parity. It is supposed to be a Trio box, so shouldn't everything work? All in all though the ACXs we tried were really good and we will be using them. It's better than all the SRX boxes I have out at the moment! (though they have worked really very well) -- Leigh > > Only l2circuit for now, rumors are that vpls is in the roadmap. > > With vpls it could get really interesting... > > > -Original Message- > From: juniper-nsp-boun...@puck.nether.net > [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Caillin > Bathern > Sent: Thursday, December 20, 2012 2:39 PM > To: Ben Dale; juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] LDP on ex4200/3200 series..and 1RU LSR? > > No multicast today either... just a head ups :( L3VPNs also missing > until the end of the month.. > > -Original Message- > From: juniper-nsp-boun...@puck.nether.net > [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Ben Dale > Sent: Thursday, 20 December 2012 11:25 PM > To: juniper-nsp@puck.nether.net List > Subject: Re: [j-nsp] LDP on ex4200/3200 seriesand 1RU LSR? > > > > On 20/12/2012, at 4:58 PM, Michel de Nostredame > wrote: > > > Possibly Juniper is positioning ACX for that? > > But ACX has far lower port density and those 1U ACX has only DC > > power-supplier. > > This was my feeling too, but there is *currently* no VPLS support on > ACX. I'm hoping that will change in the future. > > The passive cooling is a big win and although the data sheet doesn't > mention it, there is an AC version of the ACX 1100 on the pricelist: > > ACX1100 Universal Access Router, AC Version, Dual power supply, 1RU, > ETSI 300, SyncE/1588v2, Temperature hardened, Passively cooled,8xGE > RJ45, 4xGE RJ45/SFP Combo (Optics Sold Separately) > > I've got a pair of these coming into the lab in the new year (lead > times are currently measured in *months*) and will be interested to see > what the limitations are. They're priced right in the middle of the > J4350 and J6350 too which is also interesting. > > > On Wed, Dec 19, 2012 at 10:32 PM, Mark Tees > wrote: > >> Can't help but wonder what they were thinking with that design. > >> > >> How many people out there want this functionality in a 1RU box? > >> > >> On 20/12/2012, at 1:00 PM, Tim Jackson wrote: > >> > >>> It can't even pass packets with > 1 label. > >>> > >>> -- > >>> Tim > >>> > >>> > >>> On Wed, Dec 19, 2012 at 7:44 PM, Mark Tees > wrote: > >>> Would it be feasible still for only outer label operations? > >>> > >>> To use as P router would you only ever need to work with outer > label? > >>> > >>> Sent from some sort of iDevice. > >>> > >>> On 20/12/2012, at 9:52 AM, Craig Askings > wrote: > >>> > On 19 December 2012 20:18, Mark Tees wrote: > > > Hi list. > > > > Has anyone heard about if there is ever going to be support for > > LDP on the > > ex4200/3200 series? > > From what I understand the chipset on ex4200/3200 does not support > more than one mpls label, so LDP etc is not possible on that > hardware. > > -- > > Regards, > > Craig Askings > > io Networks Pty Ltd. > > > > mobile: 0404 019365 > > phone: 1300 1 2 4 8 16 > > ___ > > 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 > -- > Message protected by MailGuard: e-mail anti-virus, anti-spam and > content filtering.http://www.mailguard.com.au/mg > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > __ > This email has been scanned by the Symantec Email Security.cloud > service. > For more information please visit http://www.symanteccloud.com > __ __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SCBE-MX XE XFP socket
Hey All, Does anybody know what the XE XFP socket on the SCBE-MX for? I cannot find any documentation about it anywhere. It's on the end of the card next to the clock interface. -- Leigh __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] L3VPN PE-CE multihoming with OSPF
Hey Folks, I have a somewhat typical duel PE and duel CE scenario. However, the two PE and two CE routers are all in the same subnet and the two PE routers routing instances can see eachother over OSPF. I'm not sure if this is wise. Should routing instances belonging to the same MPLS VPN be able to exchange routes over OSPF when OSPF is the PE-CE routing protocol and those OSPF routes will be part of the VPN's routing table and exported with BGP? Could there then be an issue where a route is learned by PE-A from PE-B with OSPF, then from PE-B to PE-A with BGP and then around and around creating a route that never gets anywhere because it's self sustained? -- Leigh Porter __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 MPLS L3VPN Fragment drops
Here is the port config:
le...@agg1.pgt> show configuration interfaces ge-1/1/4
description "UGW9811 2/1/1 for MTU testing";
unit 0 {
family inet {
mtu 1500;
address 10.2.0.241/28;
}
}
le...@agg1.pgt>
le...@agg1.pgt> show configuration routing-instances s1u
instance-type vrf;
interface ge-1/0/2.1100;
interface ge-1/1/4.0;
interface ae0.510;
interface lo0.300;
route-distinguisher 29009:103;
vrf-import s1u-import;
vrf-export s1u-export;
vrf-target target:29009:103;
vrf-table-label;
protocols {
ospf {
export VPN-OSPF-export;
area 0.0.0.0 {
interface ae0.510;
interface ge-1/0/2.1100 {
passive;
}
interface ge-1/1/4.0 {
metric 1;
}
}
}
}
le...@agg1.pgt>
From: Tima Maryin [timamar...@mail.ru]
Sent: 06 November 2012 18:54
To: Leigh Porter
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MX80 MPLS L3VPN Fragment drops
On 06.11.2012 18:57, Leigh Porter wrote:
>> * Leigh Porter [2012-11-06 00:46]:
>>> A packet dump reveals that the TCP sender (FTP server) will send a
>>> segment, the LTE core will encap this segment and fragment the tunnel
>>> packet, these fragments enter into an MX80 and into a L3VPN instance
>>> but then only the first half of the fragmented datagram ever exits
>> the
>>> MX80 as an MPLS packet.
>>
>> Hi Leigh,
>>
>> you might be hitting PR736749:
>
> In L3VPN scenario, transit packets which require fragmentation, traversing
> over the
> mpls core, might get dropped at the egress PE, if the egress PE?s, CE facing
> interface
> is on trio chipset cards. [PR736749: This issue has been resolved.]
>
> It looks like that, but the packet was already fragmented and it was on
> ingress of a PE ;-)
That description is not very precise. It affects also transiting
fragments. I'm sure you're hitting this bug.
>> Which JunOS Version are you using?
>
> 10.4R1.5
__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 MPLS L3VPN Fragment drops
> * Leigh Porter [2012-11-06 00:46]: > > A packet dump reveals that the TCP sender (FTP server) will send a > > segment, the LTE core will encap this segment and fragment the tunnel > > packet, these fragments enter into an MX80 and into a L3VPN instance > > but then only the first half of the fragmented datagram ever exits > the > > MX80 as an MPLS packet. > > Hi Leigh, > > you might be hitting PR736749: In L3VPN scenario, transit packets which require fragmentation, traversing over the mpls core, might get dropped at the egress PE, if the egress PE?s, CE facing interface is on trio chipset cards. [PR736749: This issue has been resolved.] It looks like that, but the packet was already fragmented and it was on ingress of a PE ;-) > "Fragmented packets or small packets with padding might get dropped on > Trio based platforms" > > Which JunOS Version are you using? 10.4R1.5 I have now captured the naughty datagram and when I replay that into the MX80, it gets dropped. So at least I have a fully re-creatable issue now. -- Leigh __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX80 MPLS L3VPN Fragment drops
Hey All, I have a very weird MX80 issue... I have an LTE network and traffic is encaped into GTP tunnels. To keep the end-user MTU at 1500 the full-sized datagrams are stuffed into the GTP UDP tunnels and the tunnel datagrams are then fragmented, typically into a 1500 byte datagram and a subsequent 56 or so byte datagram. The base station re-assembles these and the whole process is transparent to an LTE user. However.. We have a problem where almost always a TCP stream (i.e. an FTP or HTTP session) will stall and never recover. A packet dump reveals that the TCP sender (FTP server) will send a segment, the LTE core will encap this segment and fragment the tunnel packet, these fragments enter into an MX80 and into a L3VPN instance but then only the first half of the fragmented datagram ever exits the MX80 as an MPLS packet. This happens at various times during the transfer. Sometimes at say 30MB transferred, sometimes at 200MB transferred. But always the same issue, a fragmented packet is sent but only the first fragment makes it out of the MX80. Now, TCP will re-send the segment and it does but then of EVERY SINGLE re-transmission the very same half of the datagram is dropped inside the MX80 never to be seen again. Which is odd because the transfer just happily sent upto hundreds of MB in exactly the same way. Meanwhile the same base station and client is passing lots of other traffic without any issues. There is no packet loss, the interfaces are clean. There are no odd flags on the datagrams in question, they look as though they are correctly formatted and wireshark correctly identifies the input to the MX80 as fragmented datagrams and reassembles them correctly. I have a case open for this, but has anybody ever heard of anything like this? -- Leigh Porter __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 port-mirror on MPLS interface
> > Ethernet, IP, CCC, VPLS etc all seems supported, but when I specify > family in any filter of forwarding-options for port-mirroring there is > no family mpls available. > > I think we need ERSPAN IETF draft, so you can export the original l2, > regardless what headers you have afterwards. > Why you cannot do this today, is because GRE wants ethertype, and there > isn't ethertype for 'the original L2 frame'. Cisco has reserved 0x88be > and 0x22eb for this. This is just too useful feature to be proprietary. > There probably should be two version of this standard, one with shim > header (like ERSPAN) and one without shim header (if that will allow it > to be implemented by more currently shipping hardware) It would be lovely if I could just do a simple Layer 2 port mirror to another port.. Oh well! I'll have to switch it through another box I suppose. -- Leigh __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX80 port-mirror on MPLS interface
Hey All, Does anybody know if the MX80 supports mirroring of MPLS family traffic? Ethernet, IP, CCC, VPLS etc all seems supported, but when I specify family in any filter of forwarding-options for port-mirroring there is no family mpls available. None of the documents seem to talk about mirroring MPLS traffic either.. Is this just not the done thing? Thanks! -- Leigh Porter __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Destination NAT on SRX cluster
Yup it is a bug, it works fine in 11.4R1.6. -- Leigh > -Original Message- > From: Ben Dale [mailto:bd...@comlinx.com.au] > Sent: 20 March 2012 13:09 > To: Leigh Porter > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] Destination NAT on SRX cluster > > Hi Leigh, > > On 20/03/2012, at 10:53 PM, Leigh Porter wrote: > > > > > error: The number of destination NAT pools exceeds limit of 0 [edit > > security nat destination rule-set incoming-connections rule > > port-forward then destination-nat] 'pool' > > failed to get pool (wilderness) > > error: configuration check-out failed > > It looks like a bug, but try changing the "from interface reth0.352" to > "from zone " and see if the issue goes > away. Failing that, upgrade to 11.1R6 and see if that fixes it. > > Ben > > __ > This email has been scanned by the Symantec Email Security.cloud > service. > For more information please visit http://www.symanteccloud.com > __ __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Destination NAT on SRX cluster
> From: Ben Dale [mailto:bd...@comlinx.com.au] > > Hi Leigh, > > On 20/03/2012, at 10:53 PM, Leigh Porter wrote: > > > > > error: The number of destination NAT pools exceeds limit of 0 [edit > > security nat destination rule-set incoming-connections rule > > port-forward then destination-nat] 'pool' > > failed to get pool (wilderness) > > error: configuration check-out failed > > It looks like a bug, but try changing the "from interface reth0.352" to > "from zone " and see if the issue goes > away. Failing that, upgrade to 11.1R6 and see if that fixes it. Yeah I thought bug too. I tried the "from zone .." but it didn't fix it. I'm just about to try 11.blah Thanks, Leigh __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] DSCP classifier on CCC interface
"Therefore, you do not have to depend on the underlying Layer 2 QoS support."
So it sounds as though is the layer 2 QoS field is there you can use that.
--
Leigh
> -Original Message-
> From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
> boun...@puck.nether.net] On Behalf Of Addy Mathur
> Sent: 20 March 2012 14:58
> To: Serge Vautour
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] DSCP classifier on CCC interface
>
> Serge:
>
> What platform/line-card are you trying this on? This is possible in
> JUNOS
> 11.4 when using Trio/MPC line-cards on the MX. See 11.4 release notes:
>
> http://www.juniper.net/techpubs/en_US/junos11.4/information-
> products/topic-collections/release-notes/11.4/index.html?topic-
> 62949.html#jd0e3519
>
> --Addy.
>
> On Mon, Mar 19, 2012 at 2:27 PM, Serge Vautour
> wrote:
>
> > Hello,
> >
> > Would anyone know if it's possible to apply a DSCP classifier on a
> CCC
> > interface? Here's what I have:
> >
> >
> > Interface:
> >
> > ge-1/2/1 {
> > encapsulation ethernet-ccc;
> > unit 0;
> > }
> >
> > Routing-Instance:
> >
> > instance-type l2vpn;
> > interface ge-1/2/1.0;
> > vrf-target target:123:41;
> > protocols {
> > l2vpn {
> > encapsulation-type ethernet;
> > no-control-word;
> > site Site1 {
> > site-identifier 1;
> > interface ge-1/2/1.0;
> > }
> > }
> > }
> >
> > Class-of-Service interface:
> >
> > ge-1/2/1 {
> > unit 0 {
> > classifiers {
> > dscp dscp-classifier;
> > }
> > }
> > }
> >
> >
> > Class-of-service classifier:
> >
> > dscp dscp-classifier {
> > import default;
> > forwarding-class expedited-forwarding {
> > loss-priority low code-points [ 101000 101001 101010 101011
> > 101100
> > 101101 101110 10 ];
> > }
> > }
> >
> >
> > Note that the L2VPN is port based. Any valid ethernet frame will go
> > through.
> >
> >
> > To test this I generate a ping and set the ToS field to 101. The
> > classifier above should drive this to the EF class but it isn't.
> >
> >
> > I'm wondering if maybe you can't use a DSCP classifier on a non-IP
> > interface? Anybody tried this before? I thought I'd try this mailing
> > list before opening a case.
> >
> > Thanks,
> > Serge
> > ___
> > 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
>
> __
> This email has been scanned by the Symantec Email Security.cloud
> service.
> For more information please visit http://www.symanteccloud.com
> __
__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] DSCP classifier on CCC interface
Did you try setting the 802.1p field and classifying based on that?
I'm about to do this also, but since this is a layer 2 service then you are
right, I don't think the IP header will be looked at. But I expect that it will
look at 802.1p and use that for QoS classification.
--
Leigh
> -Original Message-
> From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
> boun...@puck.nether.net] On Behalf Of Serge Vautour
> Sent: 19 March 2012 18:32
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] DSCP classifier on CCC interface
>
> Hello,
>
> Would anyone know if it's possible to apply a DSCP classifier on a CCC
> interface? Here's what I have:
>
>
> Interface:
>
> ge-1/2/1 {
> encapsulation ethernet-ccc;
> unit 0;
> }
>
> Routing-Instance:
>
> instance-type l2vpn;
> interface ge-1/2/1.0;
> vrf-target target:123:41;
> protocols {
> l2vpn {
> encapsulation-type ethernet;
> no-control-word;
> site Site1 {
> site-identifier 1;
> interface ge-1/2/1.0;
> }
> }
> }
>
> Class-of-Service interface:
>
> ge-1/2/1 {
> unit 0 {
> classifiers {
> dscp dscp-classifier;
> }
> } }
>
>
> Class-of-service classifier:
>
> dscp dscp-classifier {
> import default;
> forwarding-class expedited-forwarding {
> loss-priority low code-points [ 101000 101001 101010 101011
> 101100 101101 101110 10 ];
> }
> }
>
>
> Note that the L2VPN is port based. Any valid ethernet frame will go
> through.
>
>
> To test this I generate a ping and set the ToS field to 101. The
> classifier above should drive this to the EF class but it isn't.
>
>
> I'm wondering if maybe you can't use a DSCP classifier on a non-IP
> interface? Anybody tried this before? I thought I'd try this mailing
> list before opening a case.
>
> Thanks,
> Serge
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> __
> This email has been scanned by the Symantec Email Security.cloud
> service.
> For more information please visit http://www.symanteccloud.com
> __
__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Destination NAT on SRX cluster
Hello Folks,
I am configuring a cluster of SRX240s running 11.1R3.5 for destination NAT.
Simply, a device in the DMZ zone on a private IP address listening on port 22
needs to be reachable from the untrust zone on port 22.
destination {
pool wilderness {
address 172.16.253.10/32 port 22;
}
rule-set incoming-connections {
from interface reth0.352;
rule port-forward {
match {
destination-address 88.94.205.5/32;
destination-port 22;
}
then {
destination-nat pool wilderness;
}
}
}
}
proxy-arp {
interface reth0.352 {
address {
88.94.205.5/32;
}
}
}
I think this looks OK, but when I commit I get this error:
error: The number of destination NAT pools exceeds limit of 0
[edit security nat destination rule-set incoming-connections rule port-forward
then destination-nat]
'pool'
failed to get pool (wilderness)
error: configuration check-out failed
Does anybody know whats happening here?
Thanks,
Leigh Porter
UK Broadband
__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX100/2x0 as small MPLS CPE?
> > > > In the recent thread "MPLS in the Access", someone insightfully > pointed > > that the low-end SRX devices run JunOS with full MPLS support, and > are > > way, way cheaper than the various MPLS-CPE switch-type devices that > are > > starting to appear. > > We have more than 30 of Juniper SRX210 in our network doing MPLS and so > far they > are rock solid once they are configured. I have seen the occasional > once > in a blue moon panic when committing a change. The SRX210, not > officially > supported, work with the RAD DS3 to Ethernet SFP so they are > particularly > attractive for us where our fiber won't reach and we need a DS3 > transport. > > > > > This interests me: we have several sites on 100Mbit LES/WEES > circuits, > > and I have a vision of planting on at site with: > > > > 1. port 1 - MPLS /31 > > 2. port 2 - EoMPLS xconnect > > We use the SRX210 for l2circuits, VPLS and VRF without issues. However > the limitations mentioned in the thread "MPLS in the Access" need to be > taken on consideration, especially for the VPLS services. > > > > > ...bringing the whole site back to us at layer2 without relying on > the > > intermediate circuits having a MAC table of sufficient size, and > hiding > > ethertypes and so forth. This works for us because there's no inter- > > VLAN > > traffic at these sites, due to them being in separate VRFs. > > > > Can anyone comment on these devices in this or similar roles? In > > particular, how do they fare in areas such as buffer sizes (to deal > > with > > microbursts) and QoS support? We have been using SRX240s at the edge and in metro rings for some time, after teething troubles they have all been solid. I also have some SRX220 using MPLS over GRE over IP connected to the core using xDSL and this also works very well. We use them for LTE/WiMAX/WiFi backhaul. The only real issue I have is that I would love a SRX240 but with about 4Gb/s of throughput. That would be a nice little product. Does anybody have any real test results of MPLS throughput on the SRX series? -- Leigh Porter UK Broadband __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MTU on pseudowire over GRE
Hello Rafal, Its been a while since you posted this! Did you ever manage the 1500B MTU with this? I have some SRX boxes that correctly fragment the outgoing GRE packets but the other Juniper does not reassamble them. Thanks, Leigh -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Rafal Grzeskowiak Sent: 09 June 2010 13:19 To: juniper-nsp@puck.nether.net Subject: [j-nsp] MTU on pseudowire over GRE Hi! Is that possible to have MTU=1500B on any kind of pseudowire configured over GRE tunnel between 2 J-series routers? The tunnel is established over the internet, with access links' MTU=1500B on both sides. I tried with CCC, l2circuit, l2vpn and various settings of fragmentation, but I can't reach 1500B. Rafal -- regards, Rafal Grzeskowiak ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Interface routes in MPLS L3VPN
Hello all, Does anybody know how to persuade interfaces routes into the L3VPN routing table to be redistributed across the network? At the moment, I can build a policy to allow static routes, OSPF routes and interface routes to be propagated into the routing table but only the loopback routes actually make it in by default. Interface routes for external interfaces only seem to propagate into the table if there is a next-hop for a static of OSPF route in the same subnet. They are available locally, but they never make it into the VPN table. -- Leigh Porter ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
I am afraid they have already lost business because of the J-series. I will certainly not buy any more. -- Leigh -Original Message- From: juniper-nsp-boun...@puck.nether.net on behalf of Richard A Steenbergen Sent: Fri 7/23/2010 9:05 AM To: Pavel Lunin Cc: juniper-...@punk.nether.net Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases. On Fri, Jul 23, 2010 at 11:03:18AM +0400, Pavel Lunin wrote: > But excuse me. The way we discuss it here reminds me those teenager-style > web-forums where they have been talking 'windows-must-die' for last 15 > years. Everyone just thinks it's his duty to claim 'junos is so buggy, so > buggy! I am going to buy cisco! Do you hear? I am going to buy cisco!' I > think, almost everyone here picks the best (in his opinion) products of > different vendors, isn't it normal? Let's be honest, people in cisco-nsp > have not less reasons to turn the list into a holy-war platform, but they > manage to not. As I've said before, he reason it's so disappointing to see what has become of JUNOS is that it used to be so much better by comparison. I have nothing against Juniper, I love Juniper, and I'm very VERY sad that I've somehow found myself running IOS lite. I'm still buying Juniper products, and I'm still hopeful that things will get better, but the very real and objective facts are that a) Juniper left J-series in a broken and in many cases unusable state before they abandoned development, and b) they screwed a lot of customers in the process. Eventually they will run out of goodwill and start losing business because of it, and that kind of thing can be very hard to undo. -- Richard A Steenbergenhttp://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] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
I absolutely agree with the posts on the J-series boxes. I need lots of small(ish) boxes that will do a reasonable throughput of MPLS (PWEs, L3VPN etc) and I was really liking the J-series, but I need some QinQ stuff that they dont support, so I thought about the SRX would be ideal, but these recent JUNOS releases have been less than stable and after spending days trying to make stuff work that suddenly got fixed with a 10.1 release just reminds me a little too much of Cisco. Now, I would never use Cisco in anything but a switch any more, but this whole flow mode thing and recent JUNOS releases have made me get other vendors into my labs and I would rather use Juniper. I have J-series boxes that have to run code bloated by this crazy flow thing, SRXs that, well, dont seem to be all they could be (I was going to use SRX100s for a load of CPE till I watched one boot up) What happened? -- Leigh -Original Message- From: juniper-nsp-boun...@puck.nether.net on behalf of Chris Whyte Sent: Thu 7/22/2010 8:59 PM To: Amos Rosenboim Cc: juniper-...@punk.nether.net Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases. I understand. I was specifically addressing the high-level comment/concern that Juniper might do the same (ie implement flow mode) on M/MX/T series. SRX serves this purpose. That's all. My concern is that not everyone seems to understand the high-level decisions behind architecture, product and feature direction. I personally find it difficult that anyone can understand specific details without understanding these fundamental decisions first. Hence I was just trying to chime in with that type of information. By injecting some of this commentary it is also likely that the decision makers at certain BUs at Juniper will see some of your concerns first hand. My intention is a positive one. I promise you. :-) Another way to look at it: It's akin to understanding the why Juniper chose the one OS architectural approach vs Cisco choosing the N x OS architectural approach. Why choose a vendor until you fully understand the benefits of their architectural decisions? Thanks, Chris On 7/22/10 12:36 PM, "Amos Rosenboim" wrote: > Chris, > > The discussion is about J series routers, not SRXs. > The J series are marketed as routers not security devices and turning > them to security devices all of a sudden is a decision I still don't > understand. > > If you want to open a discussion about SRX we can do that. > I have no experience with the high end SRXs but a lot of experience > with the lower end SRX devices (210-650) and I can honestly say that I > consider them to be the worst piece of networking/security hardware I > ever worked with. > > The software quality for these devices is catastrophic, including many > stability related bugs which crashed devices time after time. > The logging of the devices is so inconvenient and also affect > performance significantly, to a level where logging advised by JTAC > killed a device. > I heard this not only from colleagues but also from advanced JTAC > engineers. > It came to a point where my company stopped selling SRX devices and > talking to the local distributer I understand that the overall Juniper > security sales (in our small country) declined significantly. > > It's important to mention that I'm a big Juniper fan (especially for > the Junos line of products), and I'm not looking to flame the product > for nothing. > > Regards > > Amos > > > On Jul 22, 2010, at 9:49 PM, Chris Whyte wrote: > >>> IMO Juniper has royally screwed up in the small router/CPE market. >>> One can hope that they won't perform similar stunts on the M/MX/T >>> series. >>> >> >> There's absolutely no reason why this would be considered. The fact >> that you >> would make that statement leads me to believe that people might not >> understand why the SRX product line was created in the first place. >> >> The entire SRX product line (branch and high-end) covers the >> performance >> spectrum across M and MX series but were created specifically as >> purpose-built security devices and therefore should be implemented >> as such. >> In addition, in order to do high-end processing of (stateful) flows >> you need >> dedicated and specific hw to achieve desired performance. That hw >> doesn't >> exist on MX and T series. It only exists on high-end SRX (ie SPUs). >> >> Thanks, Chris >> >> >> >> ___ >> 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] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
Oh... Would anybody mind telling me why this was a good idea? -- Leigh * Leigh Porter: > I thought that as soon as you turn MPLS on the flow mode was diabled > and you were back to good old packet mode? No, packets targeted at the device itself are still processed in flow mode. According to the documentation, there is no way around that. It means that all existing TCP sessions involving the device are severed when rerouting event occurs because their flow implementation is interface-sensitive. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
Has anybody had memory problems after upgrading to a flow based Junos release? (i.e. the router was perfectly speced before, load the new code and you suddenly need to uprade everything?) Perhaps this is just another bug to add to the Junos 10 list ;-) -- Leigh -Original Message- From: juniper-nsp-boun...@puck.nether.net on behalf of Christopher E. Brown Sent: Wed 7/21/2010 10:59 PM To: Heath Jones Cc: juniper-...@punk.nether.net Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases. On 7/21/2010 1:23 PM, Heath Jones wrote: > Chris - Sorry I didnt realise the process had changed names and we are > actually talking about the forwarding process itself. In that case, the > only other thing I can think of right now is: > When the forwarding process starts, it allocates the 400Mb+ for these > tables. The question is if the forwarding process is making a decision > based on the configuration *before* the point of memory allocation as to > if the allocation is required. > > This is what you need to know from Juniper engineers / dev team. It > probably wasn't written that way, and if not it makes searching for > configuration statements to achieve the goal pointless!! > (It's highly unlikely that they coded deallocation functions for those > structs. Much simpler to just restart a process..) > > Please let me know how you go with this - its an interesting problem! I have disabled and then re-started the process on a live router w/ packet mode config, no change in use. ___ 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] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
Just install Linux on the box ;-) -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Heath Jones Sent: 21 July 2010 11:05 To: Christopher E. Brown Cc: juniper-...@punk.nether.net Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases. Just a quick thought... what about renaming the flowd binary..? No I haven't tested it :) On 20 July 2010 23:14, Christopher E. Brown wrote: > > > I know alot of us here have been bitten by this, and the fact that > disabling flow mode and > reverting to packet does not free up any of the ~ 460MB or so being eaten > by fwdd/flowd is > insane. > > > I am currently having the "This is a design feature, the pre-alloc is > planned" argument > with a SE. > > > I have no issue with flow features being added, looks great for branch > office use. > > > What is killing be is that flow is not wanted, needed or usable in a > small-infra use with > multipath and MPLS services, but even disabled flowd is eating half the box > memory. > > > 52% memory usable at bootup (bare config) is not sane, and a 1GB 6350 used > to be able to > handle a few thousand igp routed plus a full table with easy and lots of > headroom, now it > is at 92% > > > > > I am pushing this w/ account team and support case, please do the same. If > enough people > complain about the insane resource consumption they might actually fix it. > > > ___ > 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] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
I am considering the SRX series and perhaps for J series for a quite large MPLS deployment and this flow stuff is a pet peeve of mine. From what I can see, all it means is that a box that used to do rather well is now limited by the number of flows it can handle and the ludicrous memory requirements of something that is not used. I'll be mentioning this in our requirements report for any equipment we order for this project. -- Leigh Porter -Original Message- From: Shane Short [mailto:sh...@short.id.au] Sent: 21 July 2010 08:32 To: Leigh Porter Cc: Jay Hanke; Christopher E. Brown; juniper-...@punk.nether.net Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases. I don't suppose this trick works on the SRX as well? *grin* -Shane On 21/07/2010, at 2:54 PM, Leigh Porter wrote: > > I thought that as soon as you turn MPLS on the flow mode was diabled and you were back to good old packet mode? > > -- > Leigh > > > -Original Message- > From: juniper-nsp-boun...@puck.nether.net on behalf of Jay Hanke > Sent: Tue 7/20/2010 11:26 PM > To: 'Christopher E. Brown'; juniper-...@punk.nether.net > Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases. > > Ditto, I was writing basically the same email when I saw your post come > through. I got a set of 2350's out of the box running 60% memory > utilization, I added a l3 vpn (with 3 routes) and the nice green bar in the > web interface changed colors on me. > > Thanks, > > Jay > > -Original Message- > From: juniper-nsp-boun...@puck.nether.net > [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Christopher E. > Brown > Sent: Tuesday, July 20, 2010 5:15 PM > To: juniper-...@punk.nether.net > Subject: [j-nsp] J series users bitten by the massive memory use increase > with flow mode add, please file jtac cases. > > > > I know alot of us here have been bitten by this, and the fact that disabling > flow mode and > reverting to packet does not free up any of the ~ 460MB or so being eaten by > fwdd/flowd is > insane. > > > I am currently having the "This is a design feature, the pre-alloc is > planned" argument > with a SE. > > > I have no issue with flow features being added, looks great for branch > office use. > > > What is killing be is that flow is not wanted, needed or usable in a > small-infra use with > multipath and MPLS services, but even disabled flowd is eating half the box > memory. > > > 52% memory usable at bootup (bare config) is not sane, and a 1GB 6350 used > to be able to > handle a few thousand igp routed plus a full table with easy and lots of > headroom, now it > is at 92% > > > > > I am pushing this w/ account team and support case, please do the same. If > enough people > complain about the insane resource consumption they might actually fix it. > > > ___ > 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] J series users bitten by the massive memory useincreas e with flow mode add, please file jtac cases.
I thought it did, additionaly the srx supports duel flow and packet mode. grrr --- original message --- From: "Shane Short" Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases. Date: 21st July 2010 Time: 8:32:06 am I don't suppose this trick works on the SRX as well? *grin* -Shane On 21/07/2010, at 2:54 PM, Leigh Porter wrote: > > I thought that as soon as you turn MPLS on the flow mode was diabled and you > were back to good old packet mode? > > -- > Leigh > > > -Original Message- > From: juniper-nsp-boun...@puck.nether.net on behalf of Jay Hanke > Sent: Tue 7/20/2010 11:26 PM > To: 'Christopher E. Brown'; juniper-...@punk.nether.net > Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease > with flow mode add, please file jtac cases. > > Ditto, I was writing basically the same email when I saw your post come > through. I got a set of 2350's out of the box running 60% memory > utilization, I added a l3 vpn (with 3 routes) and the nice green bar in the > web interface changed colors on me. > > Thanks, > > Jay > > -Original Message- > From: juniper-nsp-boun...@puck.nether.net > [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Christopher E. > Brown > Sent: Tuesday, July 20, 2010 5:15 PM > To: juniper-...@punk.nether.net > Subject: [j-nsp] J series users bitten by the massive memory use increase > with flow mode add, please file jtac cases. > > > > I know alot of us here have been bitten by this, and the fact that disabling > flow mode and > reverting to packet does not free up any of the ~ 460MB or so being eaten by > fwdd/flowd is > insane. > > > I am currently having the "This is a design feature, the pre-alloc is > planned" argument > with a SE. > > > I have no issue with flow features being added, looks great for branch > office use. > > > What is killing be is that flow is not wanted, needed or usable in a > small-infra use with > multipath and MPLS services, but even disabled flowd is eating half the box > memory. > > > 52% memory usable at bootup (bare config) is not sane, and a 1GB 6350 used > to be able to > handle a few thousand igp routed plus a full table with easy and lots of > headroom, now it > is at 92% > > > > > I am pushing this w/ account team and support case, please do the same. If > enough people > complain about the insane resource consumption they might actually fix it. > > > ___ > 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] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
I thought that as soon as you turn MPLS on the flow mode was diabled and you were back to good old packet mode? -- Leigh -Original Message- From: juniper-nsp-boun...@puck.nether.net on behalf of Jay Hanke Sent: Tue 7/20/2010 11:26 PM To: 'Christopher E. Brown'; juniper-...@punk.nether.net Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases. Ditto, I was writing basically the same email when I saw your post come through. I got a set of 2350's out of the box running 60% memory utilization, I added a l3 vpn (with 3 routes) and the nice green bar in the web interface changed colors on me. Thanks, Jay -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Christopher E. Brown Sent: Tuesday, July 20, 2010 5:15 PM To: juniper-...@punk.nether.net Subject: [j-nsp] J series users bitten by the massive memory use increase with flow mode add, please file jtac cases. I know alot of us here have been bitten by this, and the fact that disabling flow mode and reverting to packet does not free up any of the ~ 460MB or so being eaten by fwdd/flowd is insane. I am currently having the "This is a design feature, the pre-alloc is planned" argument with a SE. I have no issue with flow features being added, looks great for branch office use. What is killing be is that flow is not wanted, needed or usable in a small-infra use with multipath and MPLS services, but even disabled flowd is eating half the box memory. 52% memory usable at bootup (bare config) is not sane, and a 1GB 6350 used to be able to handle a few thousand igp routed plus a full table with easy and lots of headroom, now it is at 92% I am pushing this w/ account team and support case, please do the same. If enough people complain about the insane resource consumption they might actually fix it. ___ 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] J series users bitten by the massive memory use increase with flow mode add, please file jtac cases.
This flow mode thing has (IMO) to be one of the most annoying and quite useless features. Perhaps it is useful for firewall/enterprise apps, but please, what else? -- Leigh -Original Message- From: juniper-nsp-boun...@puck.nether.net on behalf of Christopher E. Brown Sent: Tue 7/20/2010 11:14 PM To: juniper-...@punk.nether.net Subject: [j-nsp] J series users bitten by the massive memory use increase with flow mode add, please file jtac cases. I know alot of us here have been bitten by this, and the fact that disabling flow mode and reverting to packet does not free up any of the ~ 460MB or so being eaten by fwdd/flowd is insane. I am currently having the "This is a design feature, the pre-alloc is planned" argument with a SE. I have no issue with flow features being added, looks great for branch office use. What is killing be is that flow is not wanted, needed or usable in a small-infra use with multipath and MPLS services, but even disabled flowd is eating half the box memory. 52% memory usable at bootup (bare config) is not sane, and a 1GB 6350 used to be able to handle a few thousand igp routed plus a full table with easy and lots of headroom, now it is at 92% I am pushing this w/ account team and support case, please do the same. If enough people complain about the insane resource consumption they might actually fix it. ___ 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] ADSL PIM on J2350 uses >85% memory
Yeah it seems OK with 1GB in the box. How do they manage to make use so much RAM? My Linux box with 8 DSL ports does very well on 512MB :) -- Leigh Manu Chao wrote: sorry to tell you need a memory upgrade (512 is the minimum no?) On Wed, Jul 15, 2009 at 12:38 PM, Leigh Porter wrote: Hey folks, I have a J2350 running various versions of 9.x, when I put a ADSL2+ PIM into the chassis, the memory utilisation jumps to 85% from 0% with no ADSL PIM. With a simple config this jumps to 95% or so. When up the config to the desired 4 ADSl PIMs, the Gig-E interfaces sometimes vanish and usually I only see 3 DSL PIMs, even though a 'sh chassis hardware' declares they are all there. All the memory seems to be eaten up by fwdd. The box has 512Mb of RAM, more then enough for 4 DSL ports and a few routes. What's happening here? Is 9.x broken? Thanks, Leigh Porter UK Broadband ___ 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] ADSL PIM on J2350 uses >85% memory
Hey folks, I have a J2350 running various versions of 9.x, when I put a ADSL2+ PIM into the chassis, the memory utilisation jumps to 85% from 0% with no ADSL PIM. With a simple config this jumps to 95% or so. When up the config to the desired 4 ADSl PIMs, the Gig-E interfaces sometimes vanish and usually I only see 3 DSL PIMs, even though a 'sh chassis hardware' declares they are all there. All the memory seems to be eaten up by fwdd. The box has 512Mb of RAM, more then enough for 4 DSL ports and a few routes. What's happening here? Is 9.x broken? Thanks, Leigh Porter UK Broadband ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 1000baseT SFP unsupported in 9.4
Hi, These seems to be a common issue here with SFPs working in one rel and suddenly not in the next rel. This really sucks quite a lot, why is this happening? Rather than ask if there is a supported SFP for this release/hardware, I'd like to know why SFPs that worked fine suddenly break with a point software upgrade! Any response from Juniper? -- Leigh On 14/02/2009 22:42, "Ruslan A. Magomedov" wrote: > Hello, > > I saw the same after upgrading from 9.2R2.15 to 9.3R2.8 and have not > tried later releases yet > > Switch stopped detecting two SFP-SX installed in 4x GE SFP module > I do not know what brand they were > >PIC 1 REV 03A 711-021270 AR0208112594 4x GE SFP > Xcvr 0NON-SFP XGS00206 UNKNOWN > Xcvr 1NON-SFP XGS00208 UNKNOWN > Xcvr 2 m> NON-JNPR H22L935 SFP-LX10 > Xcvr 3 rNON-JNPR H22L933 SFP-LX10 > > Best regards, > Ruslan > > Jeff S Wheeler wrote: >>> Is that an official SFP bought from juniper? >>> >>> Perhaps they have decided that any SFP NOT from them will no longer >>> be allowed to work due to it not having a magic number in its >>> memory stored on the SFP. >> That was my concern. I believe I will get a Juniper branded 1000baseT >> SFP and try the 9.4 upgrade again. I was surprised that a Cisco brand >> 10GBASE-LR XFP continued to work while all my generic SFP-Ts failed to >> establish any link. >> >> I had hoped one of the Juniper list readers might comment on this. >> > > ___ > 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 output
Duplicate packets received? SunnyDay wrote: hello anyone can explain this output has 200% success? bras01:(config)#run ping x.x.x.x Sending 5 ICMP echoes to x.x.x.x, timeout = 2 sec. !Success rate = 200% (10/5), round-trip min/avg/max = 0/1/9 ms bras01:(config)# Thank you ___ 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] Load balance with 2 adsl pics
I would also like to do this but does anybody know if the per-flow load
balancing will correctly distribute multiple GRE sessions between the
same pair of IP addresses fairly across the two paths?
AFAIK it will NOT do this and so per-flow load balancing will not always
... balance :)
Thanks,
Leigh Porter
UK Broadband
Masood Ahmad Shah wrote:
> I guess you have two static routes. If this is the case, as you know first
> of all the 2 routes should have the same prefix length (10.0.0.0/24,
> 0.0.0.0/0 etc) and Preference. You need to make these preferences equal
> either by configuring policy to set the preference/metric value same.
>
> To enable per-flow load balancing, you must set the load-balance per-packet
> action in routing policy configuration.
>
> policy-statement please-load-balance {
> then {
> load-balance per-packet;
> }
> }
>
>
> For further you can visit:
>
> http://www.juniper.net/techpubs/software/junos/junos70/swconfig70-policy/htm
> l/policy-actions-config11.html
>
> Regards,
> Masood Ahmad Shah
> BLOG: http://www.weblogs.com.pk/jahil
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mike
> Sent: Wednesday, July 23, 2008 2:10 PM
> To: Juniper-Nsp
> Subject: [j-nsp] Load balance with 2 adsl pics
>
> Hello
>
> I have a j router with 2 adsl pics is possible to load balance traffic
> between the 2 cards? And if so via Multilink? Or there is some other way to
> do so?
>
> ___
> 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 load a lot of prefixes
I'll give anybody a BGP feed for $40 a month :) -- Leigh Henry Hoang wrote: > What I have done in the past is to buy a BGP feed over T1 line wiring to > the lab. Here it the thing. If the ISP knows you are trying to get BGP > feed to the lab just for testing. They would not allow it. The trick is > you just mention that you want a kinda "read-only", a copy of BGP > internet table. The ISP will filter out any route update from your lab > site. > > As mentioned by others, You can use IXIA/Spirent to generate > routes..make sure the router can handle up to 1 million routes for BGP > internet routing table :-) hey...our planet is just fine, just we are > getting crowded..If you want to fun time, set up your linux PC as a BGP > router. Download the BGP internet table from the internet. Import it > into your linux router...BGP peer with your test device...Voila. > > Cheers, > > HH > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Leigh Porter > Sent: Wednesday, February 20, 2008 9:58 AM > To: [EMAIL PROTECTED] > Cc: juniper-nsp; [EMAIL PROTECTED] > Subject: Re: [j-nsp] How to load a lot of prefixes > > > Notepad can handle 25000 lines? > > ;-0 > > -- > Leigh > > > [EMAIL PROTECTED] wrote: > >> There are several products that can generate routes for testing >> > depending > >> on your budget. IXIA devices for example will do this and more. I >> > wanted > >> to the same thing a few months ago and I ended ip logging into a few >> > route > >> servers and outputting a sh route/sh ip route to a text file. Then I >> > just > >> used notepad to add the commands to configure the routes as static >> > routes > >> and pasted the result into the router. This is no way to get the full >> > > >> table, but I got about 25,000 routes (until I got bored). If you >> > really > >> want it to look like the real table you can add the routes to >> > different > >> routers and advertise them from actual ISP AS numbers and/or modify >> > the AS > >> path using with random policies. I did this with cisco boxes so YMMV. >> >> Keegan >> >> >> >> >> "wang dong bei" <[EMAIL PROTECTED]> >> Sent by: [EMAIL PROTECTED] >> 02/20/08 12:05 PM >> >> To >> juniper-nsp >> cc >> >> Subject >> [j-nsp] How to load a lot of prefixes >> >> >> >> >> >> >> Hi talented minds, >> >> I want to do some testing with BGP and I need to inject a lots of >> > routes, > >> preferably the entire Internet routing table, into some of the routers >> > of > >> an >> isolated lab. My initial approach is to capture the "show route bgp" >> output >> from one of my routers and massage the data into the "set >> > routing-options > >> static prefix." and load everything into my testing routers. >> > However, > >> the script is more difficult to write, the result is full of errors, >> > and > >> when I load the config, it somehow hang my terminal sessions. >> >> So are there anyways to quickly populate the routing table of my >> > testing > >> routers by administrative configuration means? >> >> thanks for your help. >> >> regards, >> >> dong bei >> ___ >> 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] How to load a lot of prefixes
Notepad can handle 25000 lines? ;-0 -- Leigh [EMAIL PROTECTED] wrote: > There are several products that can generate routes for testing depending > on your budget. IXIA devices for example will do this and more. I wanted > to the same thing a few months ago and I ended ip logging into a few route > servers and outputting a sh route/sh ip route to a text file. Then I just > used notepad to add the commands to configure the routes as static routes > and pasted the result into the router. This is no way to get the full > table, but I got about 25,000 routes (until I got bored). If you really > want it to look like the real table you can add the routes to different > routers and advertise them from actual ISP AS numbers and/or modify the AS > path using with random policies. I did this with cisco boxes so YMMV. > > Keegan > > > > > "wang dong bei" <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 02/20/08 12:05 PM > > To > juniper-nsp > cc > > Subject > [j-nsp] How to load a lot of prefixes > > > > > > > Hi talented minds, > > I want to do some testing with BGP and I need to inject a lots of routes, > preferably the entire Internet routing table, into some of the routers of > an > isolated lab. My initial approach is to capture the "show route bgp" > output > from one of my routers and massage the data into the "set routing-options > static prefix." and load everything into my testing routers. However, > the script is more difficult to write, the result is full of errors, and > when I load the config, it somehow hang my terminal sessions. > > So are there anyways to quickly populate the routing table of my testing > routers by administrative configuration means? > > thanks for your help. > > regards, > > dong bei > ___ > 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 load a lot of prefixes
Ask a friendly ISP to send you a complete routing table. I would be willing to do this. Else get a quagga on Linux to do it. -- Leigh wang dong bei wrote: > Hi talented minds, > > I want to do some testing with BGP and I need to inject a lots of routes, > preferably the entire Internet routing table, into some of the routers of an > isolated lab. My initial approach is to capture the "show route bgp" output > from one of my routers and massage the data into the "set routing-options > static prefix." and load everything into my testing routers. However, > the script is more difficult to write, the result is full of errors, and > when I load the config, it somehow hang my terminal sessions. > > So are there anyways to quickly populate the routing table of my testing > routers by administrative configuration means? > > thanks for your help. > > regards, > > dong bei > ___ > 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] Load balancing GRE tunnels
Hi Folks, I want to load balance multiple GRE tunnels over a number of circuits between a couple of routers. Since the routers will load balance per-flow and not per-packet, will the routers be able to distinguish between the tunnels ? The problem is that the tunnels will all be between the same IP addresses. AFAIK the layer3/4 info the router will use to load-balance is as follows: * Source IP address * Destination IP address * Protocol * Source port number * Destination port number * Incoming interface index Since all of these will be identical, what will happen? Thanks, Leigh Porter ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Junos 8.4 Address Translation
Hey Folks, Do you know if I can do simple IP address translation with 8.4 ? For example, if I see a datagram with a source address of 1.1.1.1 I want to change the destination address of the datagram to something of my choice (note, not the next-hop but the actual destination IP address of the datagram). Conversely, if I see a datagram to 1.1.1.1 I would like to change the destination IP address to say 7.7.7.7. Thanks! -- Leigh ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] AS-PAth Prepend and Loop Command
Hey, why not have them just prepend some random ASN to the prefixes? Then your loop filter won't care. -- Leigh Dan Farrell wrote: > Yeah, when the question is re-worded ... > > "My external peer is incorrectly announcing prefixes to me, how do I fix > this?" > > ... then the answer becomes clearer. > > > > danno > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Leigh Porter > Sent: Monday, January 07, 2008 11:29 AM > To: NAIDOO Kesva ROSI/I-BNF > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] AS-PAth Prepend and Loop Command > > > You should not tell us who they are to embarrass them :) > > -- > Leigh > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] AS-PAth Prepend and Loop Command
You should not tell us who they are to embarrass them :) -- Leigh NAIDOO Kesva ROSI/I-BNF wrote: > If this is a way of securing BGP updates then it is not a good solution. > If your neighbor, EBGP peer is prepending your AS in their updates then > they do not want you to know about their advertised networks. Why not do > this with a well know community, like no-export. > > I think that this EBGP peer is behaving abnormally and I agree with the > other posts. > > Kesva > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chris Morrow > Sent: Monday, January 07, 2008 9:31 AM > To: Leigh Porter > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] AS-PAth Prepend and Loop Command > > > > On Mon, 7 Jan 2008, Leigh Porter wrote: > > >> Here here.. Who's idea was that? >> >> > > perhaps someone doesn't want the other end talking to them? This I've > seen > used as a security measure at times: "AS1 is really bad, they have a > giant route list I can't filter that how about I just don't accept their > > routes? Oh, I could do that by prepending their AS on my announcements, > done!" > > >> Scott Morris wrote: >> >>>> From a technical standpoint, yes. BGP sees a loop whenever it sees >>>> > its own > >>> AS in the path. >>> >>> >>>> From a political/personal standpoint, you need to reach out and >>>> > smack the > >>> brainchild that is prepending YOUR AS into their BGP records. It >>> > would > > they might be doing it for a reason they feel is valid (see above) > > >>> serve them right to not be reached. >>> > > that might be their intent... > > >>> Just my thoughts. >>> >>> Scott >>> >>> >>> -Original Message- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Reza >>> > Sharifi > >>> Sent: Sunday, January 06, 2008 5:12 PM >>> To: juniper-nsp@puck.nether.net >>> Subject: [j-nsp] AS-PAth Prepend and Loop Command >>> >>> Hi All, >>> >>> If I have an external BGP connection to my neighbor, and if the >>> > neighbor is > >>> Prepending my own AS to the routes that is sending to me, do I need >>> > to > >>> implement the command " set routing-options autonomous-system loop to >>> > all of > >>> my internal routers inside my AS in order to get those routes? >>> So far, the only way I have been able to get the routes to all my >>> > internal > >>> routers is by applying the loop command, and do a clear BGP neighbor >>> soft-inbound I am running JUNOS 7.3R3.6, Is there any other way of >>> implementing this? >>> >>> Thanks, >>> Reza >>> _ >>> Share life as it happens with the new Windows Live. >>> >>> > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012 > 008 > >>> ___ >>> 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 > > * > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, changed > or falsified. > If you are not the intended addressee of this message, please cancel it > immediately and inform the sender. > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] AS-PAth Prepend and Loop Command
Here here.. Who's idea was that? Scott Morris wrote: > >From a technical standpoint, yes. BGP sees a loop whenever it sees its own > AS in the path. > > >From a political/personal standpoint, you need to reach out and smack the > brainchild that is prepending YOUR AS into their BGP records. It would > serve them right to not be reached. > > Just my thoughts. > > Scott > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Reza Sharifi > Sent: Sunday, January 06, 2008 5:12 PM > To: juniper-nsp@puck.nether.net > Subject: [j-nsp] AS-PAth Prepend and Loop Command > > Hi All, > > If I have an external BGP connection to my neighbor, and if the neighbor is > Prepending my own AS to the routes that is sending to me, do I need to > implement the command " set routing-options autonomous-system loop to all of > my internal routers inside my AS in order to get those routes? > So far, the only way I have been able to get the routes to all my internal > routers is by applying the loop command, and do a clear BGP neighbor > soft-inbound I am running JUNOS 7.3R3.6, Is there any other way of > implementing this? > > Thanks, > Reza > _ > Share life as it happens with the new Windows Live. > http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 > ___ > 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] load balancing between juniper routers for unequal cost path
Also with GRE tunnels you may run into MTU problems. At last with MPLS you won't have that pro Chuck Anderson wrote: > On Thu, Nov 08, 2007 at 08:39:23AM -0800, Hamid Ahmed wrote: > > >> 2) You are giving the explanation for equal cost paths. However in >> my case there are two unequal cost paths. So my question still how >> can u do that in using unequal cost paths ? >> > > >> 3) Please explain when u say the following: >> "What you will need to do is create 2 different RSVP Signaled LSPs >> towards the router which you want to "add more traffic", then you need to >> export these 2 LSPs in OSPF (not turn OSPF off!) so that the routing >> protocol can see and use these 2 new paths. In the end, you will have 2 >> equals paths going in 1 direction, and a >> single path in the other. If you need to move more traffic, then simply >> add a 3rd, 4th, etc LSP." >> > > >> 4) The above discussion is for when we are doing work within MPLS. >> Now in my case my intended traffic (Voice) does not use >> MPLS(however MPLS is enabled but for some other traffic like >> sigtran and O/M). OSPF is there as IGP and i need to load balance >> my intended traffic using the unequal cost path. I have an idea >> taht i create 2 x static GRE tunnels from one end to the other. My >> question can GRE tunnel override OSPF as that would be purely >> static routing and whatever goes with the tunnels would be just >> IP-payload. >> > > He is saying to expand your use of MPLS to provide the solution to > your un-equal multipath situation. You would be using MPLS "tunnels" > a.k.a. LSPs to provide the solution. I suppose GRE tunnels could work > too, but since you already have MPLS set up, you might as well expand > your use of it to cover this case as well. > ___ > 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] Out-of-band on J-series
Phil Mayers wrote: > So, > > On our M7i we use the 100meg management port to connect into our OOB > network. This network is a physically separate, flat addressed private > IP /16. > > On the J-series, one does not have an fxp0 with the associated > protection from accidentally switching packets. What do other people do? > Use a routing instance with a spare port as the member? What > disadvantages does that give you (can you syslog into a routing > instance? ntp? snmp trap?) No you can not, it is a pain. Everything managementish comes from the default router instance. We have a seperate management MPLS VPN and it would be great if traps and things could originate from this! -- Leigh ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Static ip bind with mac address
Perhaps 802.11x ? M.Mihailidis wrote: > so what do you suggest? > username and password authentication? > - Original Message - From: "Leigh Porter" > <[EMAIL PROTECTED]> > To: "M.Mihailidis" <[EMAIL PROTECTED]> > Cc: > Sent: Friday, October 05, 2007 11:58 AM > Subject: Re: [j-nsp] Static ip bind with mac address > > >> What happens if they change their MAC as well? >> >> M.Mihailidis wrote: >>> hello all >>> i have a netscreen 5gt and users in the company lan are configured >>> with static ip addresses. >>> Is there any way that i can bind their static addresses with their >>> mac-address so if they configure another ip they want get >>> access?.And i dont want to do it via dhcp. >>> >>> >>> BR >>> ___ >>> 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] Static ip bind with mac address
What happens if they change their MAC as well? M.Mihailidis wrote: > hello all > i have a netscreen 5gt and users in the company lan are configured with > static ip addresses. > Is there any way that i can bind their static addresses with their > mac-address so if they configure another ip they want get access?.And i dont > want to do it via dhcp. > > > BR > ___ > 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] JUNOS Firewalls and PPTp passthrough
Hi Folks, Does the JUNOS Starefull firewall (on J series and M series with AS-PIC) support PPTP passthrough? Thanks, Leigh Porter UK Broadband ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Per packet load balancing
On a similar note, does anybody know if Junipers will be any good at load balancing multiple GRE tunnels between two devices? -- Leigh David Ball wrote: > The following URL may help to explain: > > http://juniper.cluepon.net/index.php/Load_Balancing > > as would the official JUNOS doc on the matter: > > http://www.juniper.net/techpubs/software/junos/junos84/swconfig84-routing/id-10480125.html > >As for workarounds, sounds like getting the Internet Processor I > ASIC would be the only way (and I can't help but think that such a > move would be generally discouraged). > > NB: the first site is neither affiliated nor endorsed by Juniper > Networks..but contains good info. > > David > > > On 20/09/2007, Nick Kraal <[EMAIL PROTECTED]> wrote: > >> Dear all, >> >> As I understand it, Juniper routers do not support per packet load >> balancing on multiple interfaces similar to Cisco, and only in a per >> flow fashion. >> >> Is there is any workaround for this? >> >> Regards, >> >> -nick/ >> ___ >> 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] Third party compact flash on the J6350.
This is what I did, worked fine.. Stacy W. Smith wrote: > There are definitely issues with the "junos-jseries-cf" images > working on any CF that's not on the supported list. See: http:// > www.juniper.net/techpubs/software/jseries/junos84/rn-jseries-84/rn- > supported-IIIparty-hw.html#rn-supported-IIIparty-hw > > Not sure if your Kingston cf's match the ones on the list, but it > looks like the SanDisk ones do not. > > That being said, you MAY be able to use the snapshot command on an > existing J6350 router to prepare you current CFs. Use the supported > SanDisk—ImageMate USB 2.0 Reader/Writer for CompactFlash Type I and > II device to connect the CFs via USB. Then do "request system > snapshot media usb partition as-primary" You can also add the > "factory" keyword if you don't want to copy the configs with the > snapshot. > > HTH, > --Stacy > > On 11 Sep 2007, at 11:39 AM, [EMAIL PROTECTED] wrote: > > >> Hi all, >> >> I'm in the process of setting up our second J6350, and part of that >> includes making spare compact flash disks loaded with JunOS in case >> the >> flash in the chassis fails. I have tried multiple flash sizes and >> manufacturers, with two different JunOS versions. All fail to load >> on the >> new J6350 I am testing each on. >> >> Versions: >> >> junos-jseries-8.3R2.8-export-cf512.gz >> junos-jseries-8.3R2.8-export-cf1024.gz >> junos-jseries-8.4R1.13-export-cf1024.gz >> >> Media: >> >> SanDisk 256MB >> Kingston 512MB CF/512 3.3V/5V 9930294-011.A00LF >> Kingston 1GB CF/1GB-S 3.3V/5V 9904168-006.A00LF >> SanDisk Ultra II 2GB >> >> Thoughts? >> >> -- Stephen. >> >> ___ >> 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] 10 port GigE SFP PIC
An Ethernet port that does not do ARP? Lev Garantin wrote: > Hello, > > looking at the following page, I have a couple questions. > > http://www.juniper.net/techpubs/hardware/m320/m320-pic/gigabit-ethernet-sfp.html > > I'm not sure what to make of > "The 10-port Gigabit Ethernet PIC with SFP does not support MAC >accounting and policing, MAC learning, TPID, or flexible Ethernet >encapsulation." > > "no MAC learning" as in "no ARP"? > > And does this PIC have a full 1Gbit/s bandwidth available per port into > the router or is there some kind of oversubscription happening (given a > FPC3)? > > Thanks in advance and kind regards, Lev > > > > > Pinpoint customers who are looking for what you sell. > http://searchmarketing.yahoo.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] Image compatibility
Yeah well it's fudge marketing.. Cisco could do the same if they had 90Mb images too I am sure. Then you'd just have to tral through all the myriad of variations of feature-sets and releases... I agree though, I am sure I can work out what's an M10 and thats a M160 myself.. -- Leigh Richard A Steenbergen wrote: > On Thu, Aug 02, 2007 at 11:59:11AM -0500, Hyunseog Ryu wrote: > >> Of course, that is key feature of junos. >> > > Just remember that already more than 60% of the size of a JUNOS image is > all the different subimages for each platform, and it's only going to get > worse with new platforms and feature bloat creep in. > > -rw-r--r-- 1 ras ras 2936350 Aug 2 03:56 jpfe-M10-8.3R2.8.tgz > -rw-r--r-- 1 ras ras 13376060 Aug 2 03:58 jpfe-M120-8.3R2.8.tgz > -rw-r--r-- 1 ras ras 4788351 Aug 2 03:56 jpfe-M160-8.3R2.8.tgz > -rw-r--r-- 1 ras ras 8265202 Aug 2 03:57 jpfe-M320-8.3R2.8.tgz > -rw-r--r-- 1 ras ras 4700764 Aug 2 03:56 jpfe-M40-8.3R2.8.tgz > -rw-r--r-- 1 ras ras 4354887 Aug 2 03:57 jpfe-M7i-8.3R2.8.tgz > -rw-r--r-- 1 ras ras 7766830 Aug 2 03:57 jpfe-T-8.3R2.8.tgz > -rw-r--r-- 1 ras ras 3360007 Aug 2 03:58 jpfe-X960-8.3R2.8.tgz > -rw-r--r-- 1 ras ras 8852022 Aug 2 03:56 jpfe-common-8.3R2.8.tgz > > Personally I value the quicker install time of a reduce image size > (especially if you must use jinstall and reboot twice on older REs, ouch) > more than the "look ma one image" marketing. Being able to optionally > download a platform specific tarball would actually be nice. Then again so > would being able to fetch an image from Juniper via ftp or from the router > CLI instead of having to bust out lynx-ssl and scp. :) > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Upgrade M10i from 7.3R3.6
8.3 was withdrawn last time I looked due to 32bit ASN bugs.. Paolo Autore wrote: > 8.3 rev 1.7 is very stable > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL > PROTECTED] > Sent: Tuesday, July 24, 2007 18:21 > To: juniper-nsp@puck.nether.net > Cc: [EMAIL PROTECTED] > Subject: [j-nsp] Upgrade M10i from 7.3R3.6 > > Hello community .. > I need the community advice ... > I have some m10i and m7i routers and all of them are running the 7.3R3.6 > JunOS version. All the configuration are working OK, we are running ebgp > with ISPs and ibgp between our equiments. We are using the juniper router > to ipvpn services too, so we are running mpls, ldp, ospf. But now i need > to install in 2 or 3 routers GigaEthernet modules, so i need the 7.6 or > higher JunOS version. So my quesion is what version of JunOS can i > install, i have red some things about 8 version but i am not sure if > that is the better option. So i need your experience to decide which > could be the best option of JunOS to install in my routers, of course i > would not like to have strange problems with the bgp, ldp, etc. > thaks so much for your help community .. i apreciate it so much .. > > luis > > > Este correo electrónico puede contener información confidencial y > protegida legalmente bajo secreto profesional. La información está > dirigida solamente a la persona o entidad indicada como destinatario y su > acceso por cualquier otra persona no está autorizado. Si usted recibió > este mensaje electrónico por error, infórmeselo al remitente y bórrelo. > Aclaramos que los conceptos y opiniones comprendidos en este correo > electrónico, deben atribuirse exclusivamente a su autor y no deben > entenderse como necesariamente coincidentes con las de NAVEGA.COM, S.A. y > en consecuencia, absolutamente ajenos a la responsabilidad de sus > directores y ejecutivos, en tanto no hayan participado de su confesión y/o > emisión y quede esta participación expresamente consignada en el mensaje. > La divulgación pública de este correo electrónico, como así su copia, > reproducción total o parcial queda prohibida, dando lugar en caso de > inobservancia de esta todas las acciones legales que pudiesen > corresponder. Muchas Graci > ___ > 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] What do for a terminal server?
MrPaul wrote: > On 6/25/07, *Leigh Porter* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > Thats nice. Now what I would like next is for it to run `screen` > on each > RS232 port. The I can log in and see what happened and scroll back > a few > k lines. > > > Then telnet to a *nix server, run screen, then telnet to your terminal > server console port directly. > > Paul That's exactly what I do at the moment ;-) -- Leigh ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] What do for a terminal server?
Thats nice. Now what I would like next is for it to run `screen` on each RS232 port. The I can log in and see what happened and scroll back a few k lines. -- Leigh Joe Freeman wrote: > Actually, Cyclades (now Avocent) makes a dedicated console server as well... > Check out the ACS series... > http://www.avocent.com/web/en.nsf/Content/CycladesACS_Landing > > They come in variants from 1 to 48 ports, offer out-of-band management via > on board ethernet, or pcmcia slot (think modem, gsm/edge card, et al). They > run a Linux distro and are extremely versatile. > > One thing I like about them, especially in the use being discussed here, is > that they can log anything seen on a console port to a syslog file stored > locally ( or remotely) in onboard disk, or to a flash disk in one of the > PCMCIA slots. Helps a lot when you have a router misbehaving and errors > scroll by so fast you miss them. > > Joe > > > >>> I have used cyclades term servers with open source OS with lots of >>> success and flexibility. >>> >>> http://global.cyclades.com/products/2/ts_series >>> >>> >>> >>> >>> -Original Message- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Scott Morris >>> Sent: Monday, June 25, 2007 5:55 AM >>> To: 'Neal R'; juniper-nsp@puck.nether.net >>> Subject: Re: [j-nsp] What do for a terminal server? >>> >>> For all my Juniper lab stuff (and Cisco lab stuff), I just use a variety >>> of >>> Cisco equipment that can be found on the used market pretty cheap. >>> >>> Either a 2509/2511 for built in ports (end of sale I think, so used >>> equipment), or a 2600 or higher with an NM-16A or NM-32A module. >>> >>> You'll be able to access all your equipment just fine and it's really >>> simple >>> to find help/docs on configuration. >>> >>> There are other vendors as well, someone mentioned MRV (the old Xyplex >>> line >>> of terminal servers) which work very well. I have a couple old 1640's >>> (40 >>> port models) but they're a whole different beast to configure, so it all >>> depends on where your experience level is. >>> >>> HTH, >>> >>> Scott >>> >>> -Original Message- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Neal R >>> Sent: Monday, June 25, 2007 12:40 AM >>> To: juniper-nsp@puck.nether.net >>> Subject: [j-nsp] What do for a terminal server? >>> >>> >>> Ladies and gentlemen, >>> >>> I've recently developed a burning desire to expunge Cisco products >>> from >>> our network and every single customer network that we maintain. I'm >>> awaiting >>> the shipment of a Juniper 4350, I've already got an Extreme switch for >>> training purposes, and today I started the process of moving from Cisco >>> Call >>> Manager Express to a Trixbox solution. >>> >>>The one bit I'm having trouble with is the terminal server function. >>> We've got Cisco 2509/2511 all over the place and don't see a good >>> alternative to this in the market. I've asked the MikroTik forums if >>> they >>> might add a terminal server module to their appliance OS, I've asked the >>> Soekris mailing list if anyone is building terminal servers based on the >>> Net4801, and I'd like to hear from all of you on this point >>> - how do you do out of band management for clusters of Juniper routers? >>> >>> >>> >>> Neal >>> ___ >>> 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 >> >> > ___ > 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 do for a terminal server?
irix! Matt Yaklin wrote: > old computone ras server with a control card that does ssh. > > basically a 3-4U box that has an ethernet port and 48+ > ports for terminals. > > runs irix. > > On Mon, 25 Jun 2007, Doug Marschke wrote: > > >> I have used cyclades term servers with open source OS with lots of >> success and flexibility. >> >> http://global.cyclades.com/products/2/ts_series >> >> >> >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Scott Morris >> Sent: Monday, June 25, 2007 5:55 AM >> To: 'Neal R'; juniper-nsp@puck.nether.net >> Subject: Re: [j-nsp] What do for a terminal server? >> >> For all my Juniper lab stuff (and Cisco lab stuff), I just use a variety >> of >> Cisco equipment that can be found on the used market pretty cheap. >> >> Either a 2509/2511 for built in ports (end of sale I think, so used >> equipment), or a 2600 or higher with an NM-16A or NM-32A module. >> >> You'll be able to access all your equipment just fine and it's really >> simple >> to find help/docs on configuration. >> >> There are other vendors as well, someone mentioned MRV (the old Xyplex >> line >> of terminal servers) which work very well. I have a couple old 1640's >> (40 >> port models) but they're a whole different beast to configure, so it all >> depends on where your experience level is. >> >> HTH, >> >> Scott >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Neal R >> Sent: Monday, June 25, 2007 12:40 AM >> To: juniper-nsp@puck.nether.net >> Subject: [j-nsp] What do for a terminal server? >> >> >> Ladies and gentlemen, >> >> I've recently developed a burning desire to expunge Cisco products >> from >> our network and every single customer network that we maintain. I'm >> awaiting >> the shipment of a Juniper 4350, I've already got an Extreme switch for >> training purposes, and today I started the process of moving from Cisco >> Call >> Manager Express to a Trixbox solution. >> >>The one bit I'm having trouble with is the terminal server function. >> We've got Cisco 2509/2511 all over the place and don't see a good >> alternative to this in the market. I've asked the MikroTik forums if >> they >> might add a terminal server module to their appliance OS, I've asked the >> Soekris mailing list if anyone is building terminal servers based on the >> Net4801, and I'd like to hear from all of you on this point >> - how do you do out of band management for clusters of Juniper routers? >> >> >> >> Neal >> ___ >> 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 > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP VPLS support
So the vrf-table-label stick ALL routes in the vrf into the bgp.l3vpn table to be propagated to other PE routers? What happens if you want to originate a default route in say OSPF from a PE router to the CE router using OSPF and a static route with discard? The route will be propagated throughout the whole VPN wouldn't it? -- Leigh Erdem Sener wrote: > Here are the limitations: > > http://www.juniper.net/techpubs/software/junos/junos83/swconfig83-vpns/id-10993840.html > > Cheers, > Erdem > > On 6/19/07, Manu Chao <[EMAIL PROTECTED]> wrote: > >> AFAIK vrf-table label only work on a broadcast interface >> >> >> On 6/18/07, Amos Rosenboim <[EMAIL PROTECTED]> wrote: >> >>> Hello, >>> >>> Another workaround which we used (and got from this list as well) is >>> to configure "dummy" static routes >>> Something like route 172.16.80.1/32 next-hop 172.16.80.1 >>> >>> Also vrf-table label does not work on 100% of the pics, I don't have >>> a reference to the pic matrix, but I recall we had a problem with the >>> 10 X Channelized E1 pic. >>> >>> Regards >>> >>> Amos >>> >>> On Jun 18, 2007, at 6:21 PM, [EMAIL PROTECTED] wrote: >>> >>> > You need to use eighter vrf-table-label in the routing instance, or > configure a vt- interface with family inet and mpls (no addresses) > and > put it in the instance to have your 'direct' route(s) installed in > your mpls cloud. > family mpls is not needed on the vt-interface, family inet is enough. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ 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 > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP VPLS support
Hey folks, When using MPLS on JUNOS a directly connected interface route on a PE router is only assigned a label if there is a route on the PE router that uses this interface (static or OSPF or BGP). When a route is present that uses this interface then a label is assigned and the route makes it into bgp.l3vpn.0 Is there a way of changing this behavior? I would like to plug some servers directly into a PE router routing-instance and have then reachable, but the interface routes do not make it to the l3vpn table, even if I explicitly ask them to be with a policy. Thanks, folks, Leigh Porter ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BFD for MPLS LSP Stability
If an LSP were to fail shouldn't it be torn down anyway (unless it's all statically provisioned I guess) -- Leigh alaerte vidali wrote: > Have you used BFD for detecting failure on LSP? > If so, do you get false positives? > > tks, > Alaerte > > part of feature text in Juniper page: > === > You can configure Bidirectional Forwarding Detection (BFD) on MPLS > IPv4 LSPs as outlined in the Internet draft > draft-ietf-bfd-mpls-02.txt, BFD for MPLS LSPs. You can configure BFD > for LSPs using either LDP or RSVP as the signaling protocol. BFD is > used as a periodic Operation, Administration, and Maintenance (OAM) > feature for LSPs to detect LSP data plane faults. > == > ___ > 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] VPLS with 2 interfaces on the same router
This is a little off-topic but what's the best practice for this configuration? Do you usually leave some room for expansion (say 50% so a range of 10 will become 15).. Also a range of 50-60 or 60-80 will be a range of 11 ;-) -- Leigh Porter UK Broadband Monika M wrote: > There was a discussion on this forum with the above subject concluding the > below point. > > *The value of "site-identifier" must be equal or less then the value > of " site-range". With your current configuration if you configure this > VPLS service on another router the traffic won't be forwarded over the > MPLS cloud. > * > But as per Juniper document, the site range specifies the total number of > sites in the VPLS. If this is the total number of sites, why should it be > greatere than the site id? > > Assume we have 10 PEs in a instance. We will configure site range as 10 in > all the PEs. > The site id of individual PEs can be in any range. Could be 50-60, > 60-70. > I am not able to get the dependencies between these two configuration. Had > never come across in Juniper document also such a dependancy. Could you > please explain the reason behind this condition specified in your mail? > > TIA, > Monika > ** > ___ > 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] JNCIE studygroup - UK South How about JNCIP?
Hey All, The idea of JNCIE boot is great. If anybody would like to do the same for JNCIP then I and my company will be willing to arrange this. -- Leigh Porter UK Broadband Umar Ahmed wrote: > All, > > Many thanks for the great responses I've received, currently three > people have provisionally committed to the bootcamp, however there is > one more place left. The course looks like starting in mid August. If > anyone is interested please let me know. The bootcamp can only run with > a minimal of at leat 4 people. > > Lastly sorry to state the obvious, but to get the most out of the course > you should be JNCIP. > > Thanks, > > Umar. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Umar Ahmed > Sent: 05 June 2007 14:23 > To: juniper-nsp@puck.nether.net > Subject: [j-nsp] JNCIE studygroup - UK South > > All, > > I'm currently studying for the JNCIE (taking exam in late August) and > wanted to know if anyone from the London area or surrounding counties > was looking to setup a study group for this. I know of a few companies > that *may* be willing to provide a bootcamp if enough people are > interested. This will be based in the UK so cuts the costs down if more > people attend. Please email me if you are interested so that I can > provide further details. > > Thanks, > > Umar. > > > ** > Any opinions expressed in the email are those of the individual and not > necessarily the company. This email and any files transmitted with it > are confidential and solely for the use of the intended recipient. If > you are not the intended recipient or the person responsible for > delivering it to the intended recipient, be advised that you have > received this email in error and that any dissemination, distribution, > copying or use is strictly prohibited. > > If you have received this email in error, or if you are concerned with > the content of this email please e-mail to: > [EMAIL PROTECTED] > > The contents of an attachment to this e-mail may contain software > viruses which could damage your own computer system. While the sender > has taken every reasonable precaution to minimise this risk, we cannot > accept liability for any damage which you sustain as a result of > software viruses. You should carry out your own virus checks before > opening any attachments to this e-mail. > > Vanco UK Ltd Registered in England No: 2296733 Registered Office: John > Busch House, 277 London Road, Isleworth, Middlesex TW7 5AX > > Please consider the environment before printing this e-mail > ** > > ___ > 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] JunOS Litterature
Erwin D wrote: > There are some guy that I know passing JNCIE, by using the junos manual and > read from page 1 to finish while trying every command or feature there. > > > thanks, > > ~Erwin > It also helps if you have a nice network to practice on.. ;-) Does anybody else have a special script that filters SNMP traps going to the NOC when they want to get things done? -- Leigh ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper SSG 140/520
I have some 140s here and they work well. The older boxes (NS50) have been in production for about two years now and have never had any issues whatsoever. -- Leigh Peter E. Fry wrote: >> Looking for comments from anyone using the Juniper SSG >> line of security appliances, specifically model 140 or >> 520. We are considering trying one out as a replacement >> for an aging Cisco PIX 520. Most interested in the >> robustness, IPS functionality, etc. Also note that the >> new 520M can run JUNOS, any advantages there? >> > > When I was working with the Netscreen 5200 at work (back > in 2003-2004), I picked up a 5XT for a bit of > extracurricular work. If you're serious about trying before > you buy (and are dying to spend some cash), consider picking > up an SSG 5 for home use. > The SSG 520 would probably be closer to the PIX in form > (similar width; lower, longer, and probably louder), but > with a... tad more performance headroom. The old PIX specs > tended to be a bit... optimistic; I don't know about the new > ASA. In my experience you can take the Juniper performance > specs at face value. > The JUNOS angle is interesting -- the long-rumored union > of JUNOS and ScreenOS would yield a router with superior > security features and a firewall with superior routing > features. > > Peter E. Fry > > ___ > 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] Virtual Router
Guy Davies wrote: >> Hi, >> >> >>> As Chuck pointed out, though, the separation is far from complete. >>> For example, if user A logs into logical-router A and starts modifying >>> the config for logical-router A, then user B logs into logical-router >>> B and modifies the config for logical-router B then does a commit, he >>> will commit *all* changes to the config including those made by user >>> A. If those changes are syntactically incomplete, the commit may >>> fail. But worse, if they are syntactically correct but not correct in >>> terms of the intended behaviour, you'll get the incorrect behaviour. >>> >> Not that I disagree with your recommendation, but there is always the >> option of "edit exclusive". >> > > Hi Sabri, > > You're absolutely right. But you can bet that your customers will > 'forget' to use it and screw up the config for everyone ;-) I can see > really useful applications for logical-routers but (having actually > given this some serious thought for a customer of mine) I have come to > the conclusion that giving customers access to config level would be a > disaster waiting to happen. > I am sure it'd not be too complex for Juniper to add some functionality to JUNOS to only let certain classes or individual usernames edit specific logical routers and them limit the commit to that logical router. -- Leigh ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper Certification Study Guides
Do it without these resources. Write some excelent study guides. Sell them. Profit :) -- Leigh Porter Mark Tinka wrote: > Hello all. > > Would appreciate if anyone could recommend excellent > purpose-written study guides for the JNCIA, JNCIS and JNCIP > M/T-series certification tracks. > > I've found a couple that were published by Sybex, but they > seem rather dated. > > All help appreciated. > > 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] Re : IPv6 Routing Headers
This should address it :-) 7573:6561:6369:7363:6f69:6e73:7465:6164 -- Leigh Paul Goyette wrote: >> Or, if someone from Juniper could pipe in with a "We're >> working on it >> for the next release" sorta thing. :) >> > > Non-official statement: > > Juniper are aware of the issue and are investigating > how to properly address it. > > ___ > 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] Class of Service implementation over MLPPP link
FAHAD ALI KHAN wrote: > Dear All > > Thanks for you support i also want to start another thread which has ben > questioned alot of time but never answered. > > Carrying MPLS VPN [L2VPN (Kompella) and L2cct (Martini)] traffic over GRE > Tunnel. > > As it has been proposed in Juniper Documentation that MPLS over GRE is > supported, in practical it is but only for L3VPN. While pushing L2cct/L2vpn > traffic over GRE...it cause problem. VPNs stats shows UP and running but > their traffic didnt flows...even normal ping fails from CE to CE. > > Does anybody on this group has implemented this scenario? than please share > your sample configuration and comments. > > Regards > > Fahad > > Are there any MTU issues with this? -- Leigh Porter ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] JUNOS port forwarding
Hey all, I would like to configure NAT incoming port forwarding on a J series router. The outbound NAT works correctly but I can not find any documentation about incoming port forwarding. Can anybody give me some hints please? Thanks, Leigh Porter UK Broadband ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] J-series NAT
Hiya all, We have a J6350 doing outbound NAT just fine after upgrading to 8.2 to fix a bug. Does anybody know how to configure incoming port forwarding on a J-series? Thanks, Leigh Porter ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] fwdd crash with NAT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey, I am having a problem with fwdd crashing (segfault!) on JUNOS Software Release [8.0R2.8] (Export edition) When I use NAT. It works OK for about 5 mins, then dies... I already opened a support case, but has anybody else observed this? Cheers, Leigh Porter -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGCS23Z0chUame06wRAgdDAJ429BqIxi8jG85D/2eB2TRYgD/0ZgCgxyqG vFUMjIGnHRJlQzXhzUQX7TE= =SZvH -END PGP SIGNATURE- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RSVP-Signalled LSPs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The LSP should be re-built unless RSVP has signaled that the path be torn down. Of course, a native IPv4 lookup would break if you do not have the routes on all your routers so sending the traffic using native IPv4 lookups could be entirely pointless. - -- Leigh Dermot Williams wrote: > Hello all, > > > > I have a quick question about RSVP LSPs that one or more of you might be > able to answer for me. According to the JNCIS study guide "when an > established LSP experiences a failure and is torn down, the traffic that > was transiting the LSP begins to be forwarded using native IPv4 lookups > in the network." > > > > It's unclear from this sentence whether or not the LSP will be rebuilt > using an alternative path or if the router will forward packets using > the IGP indefinitely (requiring a manual clear in order to get it > rebuilt). Our experience is that the LSP will be rebuilt over an > alternative path fairly quickly but to date we have only used them to > carry Layer 2 VPNs so that may impact the behaviour. > > > > Could anyone clarify this for me? > > > > Dermot Williams > > > > Senior Network Engineer > > Irish Broadband Internet Services > > > > Mobile: +353 86 3887961 > > DDI: +353 1 4818481 > > > > > > > > > > > Note: > This message is for the named person's use only. It may contain > confidential, proprietary or legally privileged information. No > confidentiality or privilege is waived or lost by any mistransmission. If > you receive this message in error, please immediately delete it and all > copies of it from your system, destroy any hard copies of it and notify the > sender. You must not, directly or indirectly, use, disclose, distribute, > print, or copy any part of this message if you are not the intended > recipient. Irish Broadband and any of its subsidiaries each reserve the right > to monitor all e-mail communications through its networks. Any views > expressed in this message are those of the individual sender, except where > the message states otherwise and the sender is authorized to state them to be > the views of any such entity. > > Thank You. > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGCQUzZ0chUame06wRAuiqAKDE8er8vwVBbbanmcMAF2RUDN7+RQCggjpq lh7xjVA7l9QrwEMm3hXPyMA= =QFla -END PGP SIGNATURE- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Load Balancing via BGP outbound at Colo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'd say um summary that trying to load-balance multiple full BGP transit connections is a pain in the ass and really best avoided unless it's some simple prepend work either by prepending entire peers or using their BGP community toys to prepend individual peers. You'll rarely get anything like the load balancing you would like and then it only takes one upstream to start peering somewhere else or stop peering somewhere and it all goes to cock again. - -- Leigh Peter E. Fry wrote: > From: Jesper Skriver <[EMAIL PROTECTED]> > [...] >> So in short, using 'no-export' is HIGHLY dangerous, and >> should be used with great care - in fact I would strongly >> recommend not to use it. > > This is an excellent point. I've been seeing more and > more evidence lately (the latest bit being this thread: > https://puck.nether.net/pipermail/cisco-nsp/2007-March/038882.html) > that exotic manipulation of BGP is on the way out. > Seemingly straightforward routing and filtering policies can > interact in ways that can be tough to anticipate. Many of > the old tricks of the past such as announcing more specific > routes to individual peers or using upstream export controls > are a good idea only for folks who like chasing odd black > holes. > >> Instead prepend your advertisments to upsteams that you >> only want to use as backup, and/or inquire with those >> providers, if they have communities you can use to have >> them preprend when you re-advertise your prefixes. > > More common are communities that instruct your upstream to > assign a particular local pref -- similar, but they tend to > be more positive, and less applicable if I follow your > intent. Also, I tend to recommend against prepending > differently on multiple links to a single provider, as it > can unnecessarily propagate disruptions upstream. Those are > a bit aside, but hey. > > Peter E. Fry > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+lvrZ0chUame06wRAm34AJ9ughgezFAe+D62Vpq6APoFcmcpNgCgzn7h Xm/aeBflwS0ntmyejQuKObo= =eXzB -END PGP SIGNATURE- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JunOS 8.0 upgrade for SSG520/550M
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You can put JunOS on them? Doesn't it become a router then? - -- Leigh Affan Basalamah wrote: > Hi all, > > I just want to know what is the advantages for SSG520M and SSG550M to > be upgradeable to JunOS 8.0 rather than ScreenOS. What about all of > the functionality, is it has the same features from ScreenOS ? And > what about the price ? Is the price differ too much from non-M SSGs ? > > Many thanks, > > -affan > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF5YpOZ0chUame06wRAtUPAKC7be5aRjpABChWGlcOg8xsAwP3ggCfRVLp r4Mi9FAzPus8aEmT8Ma/INw= =2G0+ -END PGP SIGNATURE- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Transparent Proxy
I can do this maybe tomorrow if you can email me to remind me ;-) -Original Message- From: [EMAIL PROTECTED] on behalf of Ed Ronayne Sent: Tue 2/20/2007 4:21 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Transparent Proxy Hi all, Long time reader first time poster. over the last two months I have started changing a lot of our Cisco 7200's out with the new J6350. All things going well so far. I was wondering if anyone could share a quick config snipit for implementing a transparent proxy. I want to redirect all requests to port 80 seen coming in a vlan to a webcache box that is listening on port 80 out another interface. Regards Ed ___ 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] Optical integration - optical IMUX
Sorry folks, not sure where this hid for all that time! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leigh Porter Sent: 20 February 2007 14:17 To: Pekka Savola; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Optical integration - optical IMUX It is crazy pricing I am seeing even for 10G interfaces. I'm stuck with trunked 1G interfaces and it makes my racks look all messy. What happened to the super-cheap optics for 10G? -- Leigh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pekka Savola Sent: 01 February 2007 19:44 To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Optical integration - optical IMUX On Thu, 1 Feb 2007, Richard A Steenbergen wrote: > Aka everyone wants a cool new "40G interface", but nobody wants to > actually pay the price for true 40G serial optics when 10G is the biggest > thing available as a cheap commodity. Now if only someone could explain > this to the 100GE crowd. :P .. or to someone setting the price for 10G equipment.. Speaking as someone who's sometimes having issues justifying 30 times more expensive 10G equipment compared to "cheap commodity".. -- 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
Re: [j-nsp] Optical integration - optical IMUX
It is crazy pricing I am seeing even for 10G interfaces. I'm stuck with trunked 1G interfaces and it makes my racks look all messy. What happened to the super-cheap optics for 10G? -- Leigh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pekka Savola Sent: 01 February 2007 19:44 To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Optical integration - optical IMUX On Thu, 1 Feb 2007, Richard A Steenbergen wrote: > Aka everyone wants a cool new "40G interface", but nobody wants to > actually pay the price for true 40G serial optics when 10G is the biggest > thing available as a cheap commodity. Now if only someone could explain > this to the 100GE crowd. :P .. or to someone setting the price for 10G equipment.. Speaking as someone who's sometimes having issues justifying 30 times more expensive 10G equipment compared to "cheap commodity".. -- 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] Mobile IP on J series?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey all, Does anybody know if the J series (any) support mobile IP HA functionality? Or for that matter, the ERX as well? I just need to terminate 20 or so sessions for the lab at the moment, but later on I'll want to support live users with a few hundred thousand terminations.. Thanks, Leigh Porter -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF0Za0Z0chUame06wRAqPIAJ9wkA4GP47aOE/CKwwMD8qvU/55BgCfe+jd VrkjsuO5S4gQGGmNTZhd4sk= =8+Re -END PGP SIGNATURE- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Merchandise Question
Get a juniper sales person in and pretend you're going to spend $800,000 and then say how much your son loved the Juniper shirt and how sad he was that it got broken. You'll soon have another ;-) In fact, I'll ask our suppliers for one and post it over to you. What size would you like? -- Leigh -Original Message- From: [EMAIL PROTECTED] on behalf of Matt Yaklin Sent: Fri 1/12/2007 5:23 PM To: Wade Sheridan Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Merchandise Question On Fri, 12 Jan 2007, Wade Sheridan wrote: > Non-technical question here. > > My son ruined my only Juniper shirt and I wanted to know if anyone has an > idea where I can go to get another? I often see shirts from juniper on sale and on auction at www.ebay.com. matt > ___ > 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] Encrypted LSP
Hiya, Thanks Peder, I like this excerpt: Premium Security: Encrypted traffic within 2547 VPNs Some users have extremely high security requirements and require IPSec encryption of traffic within a Layer 3 2547 VPN. In this case, the ES PIC receives inbound traffic in the clear (or IPSec-encrypted), encrypts it, and then maps it into a 2547 VPN. -- Leigh -Original Message- From: Peder Christian Bach [mailto:[EMAIL PROTECTED] Sent: Fri 1/5/2007 9:37 PM To: Leigh Porter; juniper-nsp@puck.nether.net Subject: SV: [j-nsp] Encrypted LSP Hi. Take a look at this. http://www.juniper.net/products/modules/100089.pdf -Peder -Opprinnelig melding- Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av Leigh Porter Sendt: 5. januar 2007 12:52 Til: juniper-nsp@puck.nether.net Emne: [j-nsp] Encrypted LSP Hiya, Does anybody know if you can encrypt traffic on a LSP? i.e. have encrypted LSPs ? Thanks, Leigh Porter ___ 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] Encrypted LSP
Hiya, Does anybody know if you can encrypt traffic on a LSP? i.e. have encrypted LSPs ? Thanks, Leigh Porter ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
