And I thought privacy concerns were bad enough with all these apps on my PC dialing "home", now I have to worry about my routers doing it too? ;)
On 7/28/08, Doug Marschke <[EMAIL PROTECTED]> wrote: > Although it won't solve all your problems, I think Juniper is trying to > solve some of these issues with their AIS product. > > http://www.juniper.net/techpubs/software/management/ais/ais10/ais-guide/ > frameset.htm > > > Basically a way to have some proactive and reactive cases automatically > opened via scripts that are running on the router. > > I have tested it, and it seems pretty cool, we'll see if it works! :) > > Doug Marschke > Principal Technologist > Strategic Networks Training > JNCIE-ER #3, JNCIE-M/T #41, JNCIS-FW, JNCI > www.ietraining.net > (415)902-5702 > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Richard A > Steenbergen > Sent: Wednesday, July 09, 2008 8:47 PM > To: David Ball > Cc: Eric Van Tol; juniper-nsp@puck.nether.net; matthew zeier > Subject: Re: [j-nsp] Juniper support vs. Cisco TAC - experiences? > > On Wed, Jul 09, 2008 at 06:25:07PM -0600, David Ball wrote: >> Another thing which I (and surely most of you) try to do is inundate >> them with data when opening a case right at the get-go, in hopes of >> avoiding the mundane questions Richard alluded to. Not just a 'req >> sup info', but attach any core files (/var/crash I think), many of the >> log files found in /var/log/ (not just 'messages'), the 'traceoptions' >> log for the problem/protocol/interface you're working on, a network >> diagram, and a rediculously detailed explanation of precisely what >> you're seeing, what else you've tried during troubleshooting, and what >> those results were. It will take much longer to open the ticket, but >> in my experience it shaves days off the resolution time. I've even >> had a JTAC person reply with 'wow, thanks for all the great >> information when opening the ticket...I'm escalating to ATAC now' when >> they realized the issue was clearly out of their comfort zone. > > I have an op script which helps with some of this monotony by uploading > log files to the FTP site (*), but there are a few nagging software > issues > which keep it from being a "good" solution. For example, there is no > scriptable command to MKDIR on an ftp site, nor is there a way to run a > CLI command and save the results to a temp file (in non-XML format) so > you > can upload it. Why do you need this? For example, "show config | display > > omit | display inheritence | display commit", since 99% of regular JTAC > is > completely incapable of understanding commit scripts, group inheritence, > > or apply-flags omit. At best you get to run a few commands manually, > save > them to temp files in known locations, and then use the script to > automate > a few upload commands. > > This particular issue is actually my primary example of why having such > wonderful op script functionality can sometimes be a bad thing. I've > been > trying to submit a feature request to get a built in method to securely > upload support information for literally years now, and with the > addition > of op scripts the universal cop-out is "we don't need to do this, you > can > do it yourself with op scripts". Sounds great in theory, except that you > > can't actually do most of the work required due to a few missing > commands. > Requiring an op script also puts the functionality beyond the reach of > the > vast majority of users, who don't happen to be reading this list or > browsing juniper.cluepon.net. But even more importantly, I wonder how > many > people actually stop to think about the security of the data they are > transmitting over the wire. Not only are you uploadig the entire > contents > of your router's configuration in plain-text, but often times you are > trasmitting the entire contents of your memory as part of core dumps. If > > someone wanted to do some industrial espionage its hard to think of a > better place to start than by intercepting some packets going to > ftp.juniper.net. A proper JUNOS implementation, in addition to being > able > to upload all kinds of things that you can't do with op scripts, would > distribute the public key cert file for Juniper's ftp server as part of > JUNOS, then sftp the data securely. > > Op scripts are great things, but sometimes they aren't a substitute for > the real thing, and this would be so simple to implement and beneficial > for users that it absolutely boggles the mind why it keeps getting > rejected. > > At any rate, here is the not-really-working-well version of the script > if > anyone wants to play with it. FYI the point of the temp file is so that > you can grab files off of any RE, including the "other RE" which might > not > have connectivity to anythig except the active RE via TNP. Another good > addition would be the uploading of an arbitrary file, or the uploading > of > the results of arbitrary pfe commands, incase you need to gather more > data > than the default log files. I thought I had uploaded this to > juniper.cluepon.net but I must have been waiting until I could get it > fixed. :) > > version 1.0; > ns junos = "http://xml.juniper.net/junos/*/junos"; > ns xnm = "http://xml.juniper.net/xnm/1.1/xnm"; > ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0"; > import "../import/junos.xsl"; > > template upload($file, $dest) { > var $filename = jcs:regex("[^\/]+$", $file)[1]; > var $destfile = $hostname _ "." _ $filename; > var $tmpfile = "/tmp/" _ $filename _ "XXXFIXMEWITHREALTMPNAME"; > > /* Copy specified file to a temporary local location */ > var $copy_temp = { > <file-copy> { > <source> $file; > <destination> $tmpfile; > } > } > > var $results_temp = jcs:invoke($copy_temp); > <output> $results_temp; > > > /* Upload file from temp location to the remote server */ > var $copy_upload = { > <file-copy> { > <source> $tmpfile; > <destination> $dest _ "/" _ $destfile; > } > } > > <output> "Uploading " _ $filename _ " to " _ $dest; > var $results_upload = jcs:invoke($copy_upload); > <output> $results_upload; > > > /* Clean up the mess left behind */ > var $delete = { > <file-delete> { > <path> $tmpfile; > } > } > > var $results_delete = jcs:invoke($delete); > } > > > /* Requires JUNOS 8.4+, and still doesn't work right */ > template save($data, $file) { > var $put = { > <file-put> { > <filename> $file; > <encoding> "ascii"; > <file-contents> $data; > } > } > > var $results_put = jcs:invoke($put); > <output> "Debug: " _ $results_put; > } > > var $arguments = { > <argument> { > <name> "destination"; > <description> "Destination Path"; > } > <argument> { > <name> "case"; > <description> "Juniper Support Case Number"; > } > <argument> { > <name> "routing-engine"; > <description> "Routing Engine"; > } > } > > param $case; > param $destination; > param $routing-engine; > > /* Set defaults for some arguments */ > var $dest = jcs:first-of($destination, > "ftp://ftp.juniper.net/pub/incoming/"); > /* XXX Fix this with "which RE am I" code */ > var $re = jcs:first-of($routing-engine, "re0"); > > match / { > <op-script-results> { > if ($case) { > <output> "Automated version currently unsupported, run these > first:"; > <output> "request support information | save /tmp/support"; > <output> "show config | display omit | display commit | save > /tmp/config"; > > /* > var $support = jcs:invoke('get-support-information'); > var $config = jcs:invoke('get-configuration'); > call save($support, "/tmp/support"); > call save($config, "/tmp/config"); > */ > > call upload($file = $re _ ":/tmp/support", $dest = $dest _ > $case); > call upload($file = $re _ ":/tmp/config", $dest = $dest _ > $case); > call upload($file = $re _ ":/var/log/messages", $dest = > $dest _ $case); > call upload($file = $re _ ":/var/log/chassisd", $dest = > $dest _ $case); > } else { > <xnm:error> { > <message> "Juniper Support Case Number argument > required."; > } > } > } > } > > > (*) If you can even get them to look at the FTP site. I still run into > JTAC people who don't know it exists, don't know how to check it, or > insist that you copy and paste everything into an email attachment or > webpage upload form anyways. Also beware of large file handlig, I know > for > certain that whatever method they use to access the FTP site contents > doesn't handle un-tgz'ing a kernel coredump from an RE with 4GB of ram > (well that and regular JTAC doesn't know what a .tgz is, but I'll stop > complaining about them for today :P). > > -- > Richard A Steenbergen <[EMAIL PROTECTED]> > http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 > 2CBC) > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Sent from Gmail for mobile | mobile.google.com Stefan Fouant Principal Network Engineer NeuStar, Inc. - http://www.neustar.biz GPG Key ID: 0xB5E3803D _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp