Re: [j-nsp] Copy files to RE
On Wed, 18 May 2011 09:29:25 -0400 Chris Evans wrote: > How about automatic script sync too now now, don't be greedy :-) but yes, that is sorely missing too. -- Pierfrancesco Caci ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS major releases - differences between revisions
Hello there, There are _no_ single release notes doc for 10.4 Link to 10.4R3 release notes http://www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/release-notes/10.4/junos-release-notes-10.4r3.pdf Link to 10.4R4 release notes http://www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/release-notes/10.4/junos-release-notes-10.4.pdf And you can find all previous and current 10.4 release notes docs (note plural) - 10.4R1, 10.4R2, 10.4R3 and 10.4R4 - on this page http://www.juniper.net/techpubs/en_US/junos10.4/information-products/pathway-pages/product/10.4/index.html HTH Rgds Alex - Original Message - From: "Dale Shaw" To: "juniper-nsp" Sent: Thursday, May 19, 2011 1:49 AM Subject: [j-nsp] JUNOS major releases - differences between revisions Hi all, I feel like a bit of a newbie asking this (and, relatively speaking, I am!) because it feels like something that should be fairly straight-forward. And maybe it is. Q: Is there a way to determine what has changed between two revisions of a major JUNOS release? For argument's sake, how do I find out precisely what changed between 10.4R3 and 10.4R4? The release notes for 10.4 don't spell it out very clearly. I suppose I could look just at the outstanding and resolved issues sections of the release notes but I'm not even sure how I can go back and look at the 10.4 release notes at the time the previous revision was released. A 'single' 10.4 release note exists and is simply revised when a new revision to the major release goes out. I know (in theory) there shouldn't be any new features between revisions -- just bug fixes. I'm more familiar navigating cisco IOS release notes where, even between maintenance releases, it's made fairly clear what has changed. Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] JUNOS major releases - differences between revisions
Hi all, I feel like a bit of a newbie asking this (and, relatively speaking, I am!) because it feels like something that should be fairly straight-forward. And maybe it is. Q: Is there a way to determine what has changed between two revisions of a major JUNOS release? For argument's sake, how do I find out precisely what changed between 10.4R3 and 10.4R4? The release notes for 10.4 don't spell it out very clearly. I suppose I could look just at the outstanding and resolved issues sections of the release notes but I'm not even sure how I can go back and look at the 10.4 release notes at the time the previous revision was released. A 'single' 10.4 release note exists and is simply revised when a new revision to the major release goes out. I know (in theory) there shouldn't be any new features between revisions -- just bug fixes. I'm more familiar navigating cisco IOS release notes where, even between maintenance releases, it's made fairly clear what has changed. Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX switches and TCAM utilisation
On Wed, May 18, 2011 at 12:42:22PM -0500, Richard A Steenbergen wrote: > On Wed, May 18, 2011 at 05:10:54PM +0100, William J Hulley wrote: > > Hi, > > > > I'm using some EX3200s running 10.0S6.1 and developing a configuration > > using filter based forwarding to policy route traffic between routing > > instances. > > > > It's all working fine in the lab but I'm concerned about the potential > > growth of the firewall policy and utilisation of the TCAM in > > production and would obviously like to model the usage and monitor it. > > > > Are there any known supported/un-supported ways of getting useful > > stats out of the box beyond just relying on syslog messages saying > > there isn't enough cam? > > Drop into the fpc shell from root, like so: > > RE:0% vty fpc0 Wow Richard, that is amazing info. What version of JunOS was that from? on 10.0S I sadly only get these columns: Number of rules as Egress PCL: 59335 59335 Egress PCL rules Page_id Entry_id Instance fw_id RuleRule-Index -- 32 0 23735928559 ospf-neighbours.8.ext.0 64 32 2 23735928559 ospf-neighbours.8.ext.1 65 33 0 23735928559 ospf-neighbours.8.ext.2 66 ... 16872 23735928559 puppet_dashboard.44.ext.8 3375 16910 23735928559 deny-all.44.ext.0 3382 So it's hard to tell when the tcam is full. C. -- +442077294797 http://mediaserviceprovider.com/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Avoid route loop for joining IS-IS/OSPF areas with redundancy?
I am trying to solve some problems and I need a little sanity check. I have some routers that only support OSPF and I am trying to integrate this OSPF area/autonomous-system into a level2 IS-IS area/autonomous-system. Simplified, it looks like this: IS-IS OSPF-OSPF RTR B RTR D / | \ / | \ /|\ IS-IS | OSPF RTR A | RTR F --static-route 0.0.0.0/0->my ISP \ |/ \| / \ | / IS-IS / OSPF---OSPF RTR C RTR E A couple other things to note: a. there is no Level 1 IS-IS here, just Level 2. b. OSPF is area 0.0.0.0. c. IS-IS wide metrics only, so no real distinction between internal and external routes with IS-IS. d. the static route 0.0.0.0/0 pointing to my ISP needs to be propagated into the IS-IS autonomous system, and I want to rely on OSPF costing on the interfaces to traffic engineer the path for the default route, while still allowing for redundancy. e. to avoid looping in general, I tag routes redistributed from IS-IS into OSPF and then reject routes from OSPF to be redistributed into IS-IS matching that tag. The same logic applies for routes from OSPF to IS-IS. Here is the first problem: If I stay with the default Junos route preferences and let's say that one of the ASBRs (Router B or C) goes down and comes back up, I'll get a routing loop for the default route. Since wide-metrics forces IS-IS to forget about the internal/external distinction, the default route gets lost between Routers B and C. Following the advice of Herrero and Van Der Ven in _Network Mergers and Migrations_, it should be sufficient to prefer OSPF internal AND external routes above IS-IS. For example, I could drop the IS-IS level 2 internal preference from 18 down to something below the default OSPF external route preference of 150 to something like 155. I would need to do this on both routers B and C. This would force the OSPF external route for 0.0.0.0/0 to win over IS-IS at the border routers, B and C. But here is a second problem: If I do not have OSPF configured directly between Routers B and C, I could get a suboptimal routing situation. For example, let's say I have a loopback address on router A and the path from A to C is "shorter" than the path from A to B. Router B would then see router A's loopback as best advertised through OSPF via Router D. Ugh. So perhaps I just need to configure OSPF between B and C. This still isn't the most optimal method, because now that loopback address for A is best reachable from router B through router C, even though A is right next door. I could just extend OSPF all the way over to router A and clean that up, even though I really am trying to move off OSPF as soon as possible to simplify life, but I guess I can live with it temporarily. I just need to remember to apply the same route preference settings and redistribution routing logic with tags on router A as I have done on routers B and C. In the future, when I want to replace the OSPF-only routers with routers that support OSPF and IS-IS, I can simply go from router to router and reverse the route preferences for IS-IS and OSPF, making IS-IS better, and then I can remove OSPF altogether. Anyway, am I on the right track here, or am I forgetting something really important? Clarke Morledge College of William and Mary Information Technology - Network Engineering Jones Hall (Room 18) Williamsburg VA 23187 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX policy logging
>>> On 5/18/2011 at 12:20 PM, "Scott T. Cameron" wrote: > Does anyone have a trick for logging all policies? I'm not particularly > fond of going and tagging each policy with "log". > > Worse, is there a way to flag the default-policy with a log statement? I > have deny-all and no options that follow, would be nice to catch them all > with a log as well. > > Scott > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp # set group log-all-policies security policies from-zone <*> to-zone <*> policy <*> then log session-init # set security policies apply-group log-all-policies -- Crist Clark Network Security Specialist, Information Systems Globalstar 408 933 4387 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX policy logging
> -Original Message- > From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- > boun...@puck.nether.net] On Behalf Of Scott T. Cameron > Sent: Wednesday, May 18, 2011 3:20 PM > To: juniper-nsp@puck.nether.net > Subject: [j-nsp] SRX policy logging > > Does anyone have a trick for logging all policies? I'm not > particularly > fond of going and tagging each policy with "log". You can do it with apply-groups: set groups global-logging security policies from-zone <*> to-zone <*> policy <*> then log session-init set security policies apply-groups global-logging > Worse, is there a way to flag the default-policy with a log statement? > I > have deny-all and no options that follow, would be nice to catch them > all > with a log as well. Again, you can do this with an apply-group: set groups default-log security policies from-zone <*> to-zone <*> policy log-all-else match source-address any set groups default-log security policies from-zone <*> to-zone <*> policy log-all-else match destination-address any set groups default-log security policies from-zone <*> to-zone <*> policy log-all-else match application any set groups default-log security policies from-zone <*> to-zone <*> policy log-all-else then deny set groups default-log security policies from-zone <*> to-zone <*> policy log-all-else then log session-init set security policies apply-groups default-log HTHs. Stefan Fouant, CISSP, JNCIEx2 www.shortestpathfirst.net GPG Key ID: 0xB4C956EC ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX policy logging
Does anyone have a trick for logging all policies? I'm not particularly fond of going and tagging each policy with "log". Worse, is there a way to flag the default-policy with a log statement? I have deny-all and no options that follow, would be nice to catch them all with a log as well. Scott ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX switches and TCAM utilisation
Wonderful, thanks! On 18 May 2011, at 18:42, Richard A Steenbergen wrote: > On Wed, May 18, 2011 at 05:10:54PM +0100, William J Hulley wrote: >> Hi, >> >> I'm using some EX3200s running 10.0S6.1 and developing a configuration >> using filter based forwarding to policy route traffic between routing >> instances. >> >> It's all working fine in the lab but I'm concerned about the potential >> growth of the firewall policy and utilisation of the TCAM in >> production and would obviously like to model the usage and monitor it. >> >> Are there any known supported/un-supported ways of getting useful >> stats out of the box beyond just relying on syslog messages saying >> there isn't enough cam? > > Drop into the fpc shell from root, like so: > > RE:0% vty fpc0 > > BSD platform (MPC 8544 processor, 48MB memory, 0KB flash) > > PFEM0(vty)# > > > Next you need to find the vendor ID for the platform, like so: > > PFEM0(vty)# show tcam vendor > Vendor = internal_ch3_tcam Vendor_id = 1 > > For EX8200 it's vendor id 6, for EX3200 it seems to be vendor id 1. > > Then you need to find the instance ID for the hardware you're looking > for. On EX8200 I know instance 2 is used for GE cards, instance 4 is > used for XE cards. On EX3200 there only seems to be instance 2 (as > you'd expect): > > PFEM0(vty)# show tcam vendor 1 instances > > Vendor InstancePage Size > > internal_ch3_tcam 2 4 > > > So then to view the usage info for this vendor/instance: > > PFEM0(vty)# show tcam vendor 1 instance 2 rules > Number of rules as Ingress PACL: 0 > Number of rules as Ingress VACL: 0 > Number of rules as Ingress RACL: 528 > Number of rules as Egress PCL: 135 > > 528 Ingress RACL rules > > HW-indexPage_idEntry_idrule_size fw_idRule > >6296 1574 0227 > AUTOFW-INVALID-PROTOCOLS.ext.0 >6298 1574 2227 > AUTOFW-INVALID-PROTOCOLS.ext.1 >6496 1624 0227 > AUTOFW-BORDER-FILTERED-PROTOCOLS.ext.0 >6498 1624 2227 > AUTOFW-BORDER-FILTERED-PROTOCOLS.ext.1 >6708 1677 0227 > AUTOFW-BORDER-LIMIT-IP-OPTIONS.ext.0 >6710 1677 2227 > AUTOFW-BORDER-LIMIT-IP-OPTIONS.ext.1 >6960 1740 0227 > AUTOFW-LIMIT-ICMP-ECHO.ext.0 > ... > > TCAM utilization: 1326(used), 12938(free), 14264(total) > > And there is your total tcam utilization above. Depending on code and > platform it may show you a slightly different view, for example here is > the utilization on an EX8200 running older 10.1 code: > > PFEM15(vty)# show tcam vendor 6 instance 4 rules > Instance 4 > DB 0 Ingr PACL:0/ 996 (current/max) rules. Util. 0.000% > DB 1 Ingr VACL:0/ 12288 (current/max) rules. Util. 0.000% > DB 2 Ingr RACL: 410/ 32768 (current/max) rules. Util. 1.251% > DB 3 Egr PACL:0/1024 (current/max) rules. Util. 0.000% > DB 4 Egr PCL1: 103/8188 (current/max) rules. Util. 1.258% > > But you get the gist. :) > > -- > 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
Re: [j-nsp] EX switches and TCAM utilisation
On Wed, May 18, 2011 at 05:10:54PM +0100, William J Hulley wrote: > Hi, > > I'm using some EX3200s running 10.0S6.1 and developing a configuration > using filter based forwarding to policy route traffic between routing > instances. > > It's all working fine in the lab but I'm concerned about the potential > growth of the firewall policy and utilisation of the TCAM in > production and would obviously like to model the usage and monitor it. > > Are there any known supported/un-supported ways of getting useful > stats out of the box beyond just relying on syslog messages saying > there isn't enough cam? Drop into the fpc shell from root, like so: RE:0% vty fpc0 BSD platform (MPC 8544 processor, 48MB memory, 0KB flash) PFEM0(vty)# Next you need to find the vendor ID for the platform, like so: PFEM0(vty)# show tcam vendor Vendor = internal_ch3_tcam Vendor_id = 1 For EX8200 it's vendor id 6, for EX3200 it seems to be vendor id 1. Then you need to find the instance ID for the hardware you're looking for. On EX8200 I know instance 2 is used for GE cards, instance 4 is used for XE cards. On EX3200 there only seems to be instance 2 (as you'd expect): PFEM0(vty)# show tcam vendor 1 instances Vendor InstancePage Size internal_ch3_tcam 2 4 So then to view the usage info for this vendor/instance: PFEM0(vty)# show tcam vendor 1 instance 2 rules Number of rules as Ingress PACL: 0 Number of rules as Ingress VACL: 0 Number of rules as Ingress RACL: 528 Number of rules as Egress PCL: 135 528 Ingress RACL rules HW-indexPage_idEntry_idrule_size fw_idRule 6296 1574 0227 AUTOFW-INVALID-PROTOCOLS.ext.0 6298 1574 2227 AUTOFW-INVALID-PROTOCOLS.ext.1 6496 1624 0227 AUTOFW-BORDER-FILTERED-PROTOCOLS.ext.0 6498 1624 2227 AUTOFW-BORDER-FILTERED-PROTOCOLS.ext.1 6708 1677 0227 AUTOFW-BORDER-LIMIT-IP-OPTIONS.ext.0 6710 1677 2227 AUTOFW-BORDER-LIMIT-IP-OPTIONS.ext.1 6960 1740 0227 AUTOFW-LIMIT-ICMP-ECHO.ext.0 ... TCAM utilization: 1326(used), 12938(free), 14264(total) And there is your total tcam utilization above. Depending on code and platform it may show you a slightly different view, for example here is the utilization on an EX8200 running older 10.1 code: PFEM15(vty)# show tcam vendor 6 instance 4 rules Instance 4 DB 0 Ingr PACL:0/ 996 (current/max) rules. Util. 0.000% DB 1 Ingr VACL:0/ 12288 (current/max) rules. Util. 0.000% DB 2 Ingr RACL: 410/ 32768 (current/max) rules. Util. 1.251% DB 3 Egr PACL:0/1024 (current/max) rules. Util. 0.000% DB 4 Egr PCL1: 103/8188 (current/max) rules. Util. 1.258% But you get the gist. :) -- 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
[j-nsp] EX switches and TCAM utilisation
Hi, I'm using some EX3200s running 10.0S6.1 and developing a configuration using filter based forwarding to policy route traffic between routing instances. It's all working fine in the lab but I'm concerned about the potential growth of the firewall policy and utilisation of the TCAM in production and would obviously like to model the usage and monitor it. Are there any known supported/un-supported ways of getting useful stats out of the box beyond just relying on syslog messages saying there isn't enough cam? Regards, Bill. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Copy files to RE
I personally hate having to do any kind of script that should be built into the os... On May 18, 2011 12:03 PM, "Yann Berthier" wrote: > > On 2011-05-18, at 9:29 AM, Chris Evans wrote: > >> How about automatic script sync too >> > > once you can file copy other-routing-engine: > > you just have to push that across when doing a script refresh, so problem solved > > but yeah, one way or another the point is to be able to sync scripts > > - y > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Copy files to RE
On 2011-05-18, at 9:29 AM, Chris Evans wrote: > How about automatic script sync too > once you can file copy other-routing-engine: you just have to push that across when doing a script refresh, so problem solved but yeah, one way or another the point is to be able to sync scripts - y ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX, Nat + BGP
The sad bit is that I've done Nat on SRX just like that as well. Thanks for the sanity check. I pulled the lo0 address and poof it works. Now I'm trying to stack my bandwidth policer with the nat config and hitting a similar issue. I think the only way to do both is to put the nat process into a routing instance... Any thoughts on that one? As soon as I enable my policer filter, traffic breaks again. I presume that it never returns to the interface filter to hit the service filter. On May 17, 2011, at 11:45 PM, Julien Goodwin wrote: > On 18/05/11 10:34, OBrien, Will wrote: >> I've been working through a nat configuration on my lab MX960 with a MS-DPC >> blade that I've borrowed. >> To start, I'm trying to create a simple nat'd subnet. However, the NAT guide >> that I've been provided doesn't really fit my current design. >> >> The example I'm looking at uses a nat pool that's defined like so: >> 150.150.150.0/24 >> >> with an outside interface that has say, 150.150.150.1/24 on it, >> >> Ok. >> >> Well, in my world, I use MX's for BGP announcements. So I'm trying to put >> the NAT source interface on a lo0 instead of a normal interface. >> >> Is anyone else doing it this way or is there some other sneaky trick I'm >> missing? So far applying the service filter only seems to break traffic. > > I've not done NAT on MX only SRX, but with an SRX just announce the NAT > pool as a route (static and readvertise, for whatever reason just adding > a pool isn't enough to make it eligible for redist), don't need to > assign it to an interface at all. > > -- > Julien Goodwin > Studio442 > "Blue Sky Solutioneering" > Will O'Brien University of Missouri, DoIT DNPS Network Systems Analyst - Redacted obri...@missouri.edu ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Copy files to RE
How about automatic script sync too On May 18, 2011 9:27 AM, "Yann Berthier" wrote: > > On 2011-05-18, at 3:19 AM, Pierfrancesco Caci wrote: > >> implement "other-routing-engine" for file operation as well, like it >> is for request login. It would make updating stuff (namely the >> scripts) a breeze. > > that would be most welcome indeed > > - y > > ___ > 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] Copy files to RE
On 2011-05-18, at 3:19 AM, Pierfrancesco Caci wrote: > implement "other-routing-engine" for file operation as well, like it > is for request login. It would make updating stuff (namely the > scripts) a breeze. that would be most welcome indeed - y ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] some bugs to avoid
Yes, but the system mountes them from root so if we have corrupted root, the system will not boot. On 18.05.2011 1:09, Stacy W. Smith wrote: That's probably not worth the hassle. The operating system is already mounted as a set of read-only memory-disk file systems from ISO images embedded within the install package. In addition, the verified-exec functionality will only allow Juniper-signed binaries to be executed. --Stacy lab@mxC-1> show system storage Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 885M 141M 673M 17% / devfs 1.0K 1.0K 0B 100% /dev /dev/md0 43M43M 0B 100% /packages/mnt/jbase /dev/md1231M 231M 0B 100% /packages/mnt/jkernel-ppc-10.3R1.9 /dev/md2 15M15M 0B 100% /packages/mnt/jpfe-MX80-10.3R1.9 /dev/md36.4M 6.4M 0B 100% /packages/mnt/jdocs-10.3R1.9 /dev/md4 72M72M 0B 100% /packages/mnt/jroute-ppc-10.3R1.9 /dev/md5 18M18M 0B 100% /packages/mnt/jcrypto-ppc-10.3R1.9 /dev/md62.8G 8.0K 2.6G0% /tmp /dev/md72.8G 4.3M 2.6G0% /mfs /dev/da0s1e 98M14K90M0% /config procfs 4.0K 4.0K 0B 100% /proc /dev/da1s1f 2.8G 279M 2.3G 11% /var lab@mxC-1> start shell % mount /dev/da0s1a on / (ufs, local, noatime) devfs on /dev (devfs, local) /dev/md0 on /packages/mnt/jbase (cd9660, local, noatime, read-only, verified) /dev/md1 on /packages/mnt/jkernel-ppc-10.3R1.9 (cd9660, local, noatime, read-only, verified) /dev/md2 on /packages/mnt/jpfe-MX80-10.3R1.9 (cd9660, local, noatime, read-only) /dev/md3 on /packages/mnt/jdocs-10.3R1.9 (cd9660, local, noatime, read-only, verified) /dev/md4 on /packages/mnt/jroute-ppc-10.3R1.9 (cd9660, local, noatime, read-only, verified) /dev/md5 on /packages/mnt/jcrypto-ppc-10.3R1.9 (cd9660, local, noatime, read-only, verified) /dev/md6 on /tmp (ufs, local, noatime, soft-updates) /dev/md7 on /mfs (ufs, local, noatime, soft-updates) /dev/da0s1e on /config (ufs, local, noatime) procfs on /proc (procfs, local, noatime) /dev/da1s1f on /var (ufs, local, noatime) On May 17, 2011, at 1:43 PM, Tima Maryin wrote: Did anyone try to hack /etc/fstab in order to mount / as read-only? Can it help ? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Copy files to RE
On Tue, 17 May 2011 14:51:32 -0400 Phil Shafer wrote: > "Cyn D." writes: > >I tried to copy(ftp) jinstall file to backup RE but for some reason > >the Mgmt port on bac kup RE is not responsive. Then tried to copy > >the file from master RE to backup RE but it > > takes for ever - more than half hour still not complete. Just > > wondering what is the bes > >t way to copy the big file in this situation? > > You can copy files between REs using "re0:xxx" and "re1:xxx" as > src/dst: > please, please, please... implement "other-routing-engine" for file operation as well, like it is for request login. It would make updating stuff (namely the scripts) a breeze. Thanks -- Pierfrancesco Caci ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
