From owner-rancid-discuss@shrubbery.net Mon Sep 2 12:20:22 2002 Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ni.shrubbery.net (8.11.6/8.11.1) with ESMTP id g82CKMf14641 for ; Mon, 2 Sep 2002 12:20:22 GMT Received: (from majordom@localhost) by guelah.shrubbery.net (8.11.6/8.11.1) id g82CG7u27877 for rancid-discuss-outgoing; Mon, 2 Sep 2002 12:16:07 GMT Received: from mta04bw.bigpond.com (mta04bw.bigpond.com [139.134.6.87]) by guelah.shrubbery.net (8.11.6/8.11.1) with ESMTP id g82CFlN27873 for ; Mon, 2 Sep 2002 12:16:03 GMT Received: from milk.choqolat.org ([144.135.24.75]) by mta04bw.bigpond.com (Netscape Messaging Server 4.15 mta04bw May 23 2002 23:53:28) with SMTP id H1T8Q300.7BV for ; Mon, 2 Sep 2002 22:15:39 +1000 Received: from CPE-144-136-10-58.vic.bigpond.net.au ([144.136.10.58]) by bwmam03.mailsvc.email.bigpond.com(MailRouter V3.0n 26/2374342); 02 Sep 2002 22:15:39 Content-Type: text/plain; charset="us-ascii" From: Andrew Fort To: rancid-discuss@shrubbery.net Subject: Ignoring regular differential updates Date: Mon, 2 Sep 2002 22:16:20 +1000 User-Agent: KMail/1.4.1 MIME-Version: 1.0 Message-Id: <200209022216.20206.afort@choqolat.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by guelah.shrubbery.net id g82CG4N27874 Sender: owner-rancid-discuss@shrubbery.net Precedence: bulk An architectural question has come up in a relatively large deployment of RANCID I'm working on.. brief: You operate an SP network, and you have software (RtConfig in our case) pushing out regular configuration changes to your routers, primarily consisting of prefix lists/ACL and route-map/policy-statement changes for your BGP routers. How do you cope with these regular changes operationally with RANCID? Architectural staff would like to avoid seeing the ACL/pfx.list changes that occur when customer registers a route with your IRR, but you'd still like to know when ops folk accidentally smoke some important part of the router config. The thoughts which come to mind for me are: 1. (messy) munge the rancid output for the filter changes when you do a nightly RANCID run after the RtConfig changes, grepping out ACLs and prefix lists. you still get a diff with a whole bunch of 'empty' diff section headers, however. 2. run RANCID 'quietly', immediately before and after each router's successful run. using 2.2.2, you could create a mail alias that goes to /dev/null and do do-diffs -r box -m nullmail for each box. 3. hack up your own version of do-diffs/control_rancid to perform 2. without mailing anyone/creating diffs in the first place. Other approaches? Also, how many devices do people have RANCID scaling to? I'm looking at a daily run of around 350 devices, with about 40 BGP routers that need to be treated using one of the methods above. Sofar it's scaling very well and the overall runtime (~ 1 hour) beats our existing config collection system by about 80% (snmp triggered tftp dumps). cheers -amf From owner-rancid-discuss@shrubbery.net Mon Sep 2 13:46:50 2002 Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ni.shrubbery.net (8.11.6/8.11.1) with ESMTP id g82Dkof16907 for ; Mon, 2 Sep 2002 13:46:50 GMT Received: (from majordom@localhost) by guelah.shrubbery.net (8.11.6/8.11.1) id g82Diuo28140 for rancid-discuss-outgoing; Mon, 2 Sep 2002 13:44:56 GMT Received: from jnull.rackspace.com (jnull.rackspace.com [64.39.30.151]) by guelah.shrubbery.net (8.11.6/8.11.1) with SMTP id g82DicN28135 for ; Mon, 2 Sep 2002 13:44:38 GMT Received: (qmail 27751 invoked by uid 301); 2 Sep 2002 13:46:59 -0000 Date: Mon, 2 Sep 2002 08:46:59 -0500 From: jnull To: Andrew Fort Cc: rancid-discuss@shrubbery.net Subject: Re: Ignoring regular differential updates Message-ID: <20020902134659.GA9416@jnull.rackspace.com> References: <200209022216.20206.afort@choqolat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200209022216.20206.afort@choqolat.org> User-Agent: Mutt/1.4i X-PGP-key: 0x54B1A25C X-Personal-URL: http://www.truerouting.com/ X-Work-URL: http://www.rackspace.com/ X-Disclaimer: echo "" | mail rancid-discuss@shrubbery.net X-MOTD: "There are 10 types of people in the world: those who understand binary, and those who don't." Sender: owner-rancid-discuss@shrubbery.net Precedence: bulk Andrew Fort(afort@choqolat.org)@2002.09.02 22:16:20 +0000: > How do you cope with these regular changes operationally with RANCID? > Architectural staff would like to avoid seeing the ACL/pfx.list changes that > occur when customer registers a route with your IRR, but you'd still like to > know when ops folk accidentally smoke some important part of the router > config. I've the same issue, save it is with static route entries for secondary IPs. Also, I don't care about saved configs. I asked a similar question, but was basically told that the current release doesn't support it. > 1. (messy) munge the rancid output for the filter changes when you do a Yes, messy should be the first and last word for this method. > 2. run RANCID 'quietly', immediately before and after each router's successful I think there is too much risk here, defeating a prime benefit of RANCID. > 3. hack up your own version of do-diffs/control_rancid to perform 2. without I've got this on my tuit list. As soon as I'm done hacking on a DoS det. app. > Other approaches? One could stay off "do-diffs" and just use clogin with your own commands and some easy shell scripts to parse the data--basically a shortcut to 3. > Also, how many devices do people have RANCID scaling to? I'm looking at a Yours it about equal to the largest I've heard of for a full implementation. Personally, I only use it for a subset of our devices for monitoring changes, mainly due to the issues you described above. However, for changing snmp strings or local passwords I'll use it across the board. -- > -amf Let me know if you opt on number 3, possibly we could QA each others work or swap some ideas. My time schedule puts it a few weeks out yet. -- sig=$header From owner-rancid-discuss@shrubbery.net Mon Sep 2 14:50:23 2002 Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ni.shrubbery.net (8.11.6/8.11.1) with ESMTP id g82EoNf18282 for ; Mon, 2 Sep 2002 14:50:23 GMT Received: (from majordom@localhost) by guelah.shrubbery.net (8.11.6/8.11.1) id g82EmE828363 for rancid-discuss-outgoing; Mon, 2 Sep 2002 14:48:14 GMT Received: from mta02bw.bigpond.com (mta02bw.bigpond.com [139.134.6.34]) by guelah.shrubbery.net (8.11.6/8.11.1) with ESMTP id g82EltN28359 for ; Mon, 2 Sep 2002 14:48:10 GMT Received: from milk.choqolat.org ([144.135.24.75]) by mta02bw.bigpond.com (Netscape Messaging Server 4.15 mta02bw May 23 2002 23:53:28) with SMTP id H1TFRN00.1AG; Tue, 3 Sep 2002 00:47:47 +1000 Received: from CPE-144-136-10-58.vic.bigpond.net.au ([144.136.10.58]) by bwmam03.mailsvc.email.bigpond.com(MailRouter V3.0n 26/2744309); 03 Sep 2002 00:47:47 Content-Type: text/plain; charset="iso-8859-1" From: Andrew Fort To: jnull Subject: Re: Ignoring regular differential updates Date: Tue, 3 Sep 2002 00:48:27 +1000 User-Agent: KMail/1.4.1 Cc: rancid-discuss@shrubbery.net References: <200209022216.20206.afort@choqolat.org> <20020902134659.GA9416@jnull.rackspace.com> In-Reply-To: <20020902134659.GA9416@jnull.rackspace.com> MIME-Version: 1.0 Message-Id: <200209030048.27706.afort@choqolat.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by guelah.shrubbery.net id g82EmBN28360 Sender: owner-rancid-discuss@shrubbery.net Precedence: bulk On Mon, 2 Sep 2002 23:46, jnull wrote: > I've the same issue, save it is with static route entries for > secondary IPs. Also, I don't care about saved configs. I asked a similar > question, but was basically told that the current release doesn't support > it. Yep, I remember your earlier post. Like I'd suspect most others, we want to use the saved configs for long term problem tracking across the whole network. I imagine you're interested in diffs of specific devices, minus one or two regularly changing bits. We'd like to ignore all changes made at a particular time in the day, as we run our major filter update only once daily. I'm guessing some NSPs that use RANCID deal with the matter operationally by having some person review the diffs; expected ACL changes, warts and all, and then bring/forward out-of-spec stuff to the architects. I'd like a meat-free approach to this.... > > 2. run RANCID 'quietly', immediately before and after each router's > > successful > > I think there is too much risk here, defeating a prime benefit of > RANCID. I think this is only an issue because you don't care about saved configurations. My thoughts go something along the lines of: 1. run a "regular" do-diffs immediately before you run your nightly routing maintenance job (that builds router configs and spits em out). 2. run your maintenance, updating router configs. 3. run a "quiet" do-diffs, so that configs are still in CVS, but the usual aliases aren't mailed with the diff output which will consist of the maintenance changes (which we dont care to see, but we'd like a record of incase they fail). You may have rogue operatives attempting to sneak config changes under your nose during this quiet diff, but 1. you still have the diffs in your CVS tree, and 2. you've got bigger problems to deal with if this is happening :). > > 3. hack up your own version of do-diffs/control_rancid to perform 2. > > without > > I've got this on my tuit list. As soon as I'm done hacking on a DoS > det. app. OT: If you publish your work/findings, drop me a line, working with netflow/etc data on attack analysis was an a challenging and enjoyable part of my work in my previous life (running a colo/hosting farm similar to rackspace) and I'm interested in all efforts and research in this area. > However, > for changing snmp strings or local passwords I'll use it across the board. I've been using a combination of scripts to do this, including pancho, but find rancid *login useful for its cross platform capabilty and scripting flexibility. > Let me know if you opt on number 3, possibly we could QA each others work or > swap some ideas. > My time schedule puts it a few weeks out yet. Right now, I'm learning towards a silent diff after the routing update due to my requirements (i.e., I'm looking filtering alot of stuff out of the diff, rather than just a little). The difference between exclusive and inclusive route filtering, I suppose, and likely just as religious an argument :-) -amf From owner-rancid-discuss@shrubbery.net Tue Sep 3 05:53:49 2002 Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ni.shrubbery.net (8.11.6/8.11.1) with ESMTP id g835rnf09981 for ; Tue, 3 Sep 2002 05:53:49 GMT Received: (from majordom@localhost) by guelah.shrubbery.net (8.11.6/8.11.1) id g835pMS01496 for rancid-discuss-outgoing; Tue, 3 Sep 2002 05:51:22 GMT Received: (from heas@localhost) by guelah.shrubbery.net (8.11.6/8.11.1) id g835p1101489; Tue, 3 Sep 2002 05:51:01 GMT Date: Tue, 3 Sep 2002 05:51:01 +0000 From: john heasley To: Andrew Fort Cc: rancid-discuss@shrubbery.net Subject: Re: Ignoring regular differential updates Message-ID: <20020903055101.A1305@shrubbery.net> References: <200209022216.20206.afort@choqolat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200209022216.20206.afort@choqolat.org>; from afort@choqolat.org on Mon, Sep 02, 2002 at 10:16:20PM +1000 X-note: live free, or die! X-homer: mmmm, forbidden doughnut. Sender: owner-rancid-discuss@shrubbery.net Precedence: bulk Mon, Sep 02, 2002 at 10:16:20PM +1000, Andrew Fort: > An architectural question has come up in a relatively large deployment of > RANCID I'm working on.. > > brief: You operate an SP network, and you have software (RtConfig in our case) > pushing out regular configuration changes to your routers, primarily > consisting of prefix lists/ACL and route-map/policy-statement changes for > your BGP routers. > > How do you cope with these regular changes operationally with RANCID? > Architectural staff would like to avoid seeing the ACL/pfx.list changes that > occur when customer registers a route with your IRR, but you'd still like to > know when ops folk accidentally smoke some important part of the router > config. > > The thoughts which come to mind for me are: > > 1. (messy) munge the rancid output for the filter changes when you do a > nightly RANCID run after the RtConfig changes, grepping out ACLs and prefix > lists. you still get a diff with a whole bunch of 'empty' diff section > headers, however. > > 2. run RANCID 'quietly', immediately before and after each router's successful > run. using 2.2.2, you could create a mail alias that goes to /dev/null and > do > > do-diffs -r box -m nullmail > > for each box. > > 3. hack up your own version of do-diffs/control_rancid to perform 2. without > mailing anyone/creating diffs in the first place. > > Other approaches? when someone bitched about nvram changes, i cooked up the following procmail recipe for them. perhaps you can adapt it for your needs. :0 H * ^Subject: .* config diffs * !^X-RLOOP: rancid #| egrep -v '\!Flash: nvram:' | formail -A "X-RLOOP: rancid" -s procmail | sed -e '/private-config/n' -e '/\!Flash: nvram:/d' | formail -A "X-RLOOP: rancid" -s procmail # /dev/null rancid msgs which have no diffs other than nvram: :0 HWi b * Subject: .* router config diffs$ | awk 'BEGIN{n=0;}{if(/...Flash: nvram:/)next; if(/^[-+]/){n++;}next;}END{exit n;}' i like things like these; it allows an individual see what they wish and preserves the whole of what rancid collects. > Also, how many devices do people have RANCID scaling to? I'm looking at a > daily run of around 350 devices, with about 40 BGP routers that need to be > treated using one of the methods above. Sofar it's scaling very well and the > overall runtime (~ 1 hour) beats our existing config collection system by > about 80% (snmp triggered tftp dumps). i've seen ~750 devices in < 1 hour, almost all bgp speakers. From owner-rancid-discuss@shrubbery.net Tue Sep 3 08:57:11 2002 Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ni.shrubbery.net (8.11.6/8.11.1) with ESMTP id g838vBf15786 for ; Tue, 3 Sep 2002 08:57:11 GMT Received: (from majordom@localhost) by guelah.shrubbery.net (8.11.6/8.11.1) id g838tEF03124 for rancid-discuss-outgoing; Tue, 3 Sep 2002 08:55:14 GMT Received: from mta04bw.bigpond.com (mta04bw.bigpond.com [139.134.6.87]) by guelah.shrubbery.net (8.11.6/8.11.1) with ESMTP id g838sqN03117; Tue, 3 Sep 2002 08:55:08 GMT Received: from milk.choqolat.org ([144.135.24.72]) by mta04bw.bigpond.com (Netscape Messaging Server 4.15 mta04bw May 23 2002 23:53:28) with SMTP id H1UU2U00.2LM; Tue, 3 Sep 2002 18:54:30 +1000 Received: from CPE-144-132-104-104.vic.bigpond.net.au ([144.132.104.104]) by bwmam02.mailsvc.email.bigpond.com(MailRouter V3.0n 17/4834977); 03 Sep 2002 18:54:30 Content-Type: text/plain; charset="iso-8859-1" From: Andrew Fort To: john heasley Subject: Re: Ignoring regular differential updates Date: Tue, 3 Sep 2002 18:55:10 +1000 User-Agent: KMail/1.4.1 Cc: rancid-discuss@shrubbery.net References: <200209022216.20206.afort@choqolat.org> <20020903055101.A1305@shrubbery.net> In-Reply-To: <20020903055101.A1305@shrubbery.net> MIME-Version: 1.0 Message-Id: <200209031855.10725.afort@choqolat.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by guelah.shrubbery.net id g838t9N03118 Sender: owner-rancid-discuss@shrubbery.net Precedence: bulk On Tue, 3 Sep 2002 15:51, john heasley wrote: > when someone bitched about nvram changes, i cooked up the following > procmail recipe for them. perhaps you can adapt it for your needs. > > i like things like these; it allows an individual see what they wish and > preserves the whole of what rancid collects. lovely, this type of approach fits our requirements quite nicely. thanks. -amf From owner-rancid-discuss@shrubbery.net Fri Sep 6 23:17:43 2002 Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ni.shrubbery.net (8.11.6/8.11.1) with ESMTP id g86NHhf15348 for ; Fri, 6 Sep 2002 23:17:43 GMT Received: (from majordom@localhost) by guelah.shrubbery.net (8.11.6/8.11.1) id g86NERh25174 for rancid-discuss-outgoing; Fri, 6 Sep 2002 23:14:27 GMT Received: from mail2.rogers.com (mail2.rogers.com [142.146.31.22]) by guelah.shrubbery.net (8.11.6/8.11.1) with ESMTP id g86NEMN25170 for ; Fri, 6 Sep 2002 23:14:23 GMT Received: from rssrgesnxd.rogers.com (rssrgesnxd [209.112.33.10]) by mail2.rogers.com (8.10.2+Sun/8.10.2) with ESMTP id g86NGOh15490 for ; Fri, 6 Sep 2002 19:16:24 -0400 (EDT) Received: from koenig.oss.cantel.rogers.com (oss.cantel.rogers.com [10.2.101.76]) by rssrgesnxd.rogers.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RP4LK6VA; Fri, 6 Sep 2002 19:13:58 -0400 Received: from gaea.oss.cantel.rogers.com ([10.64.31.51]) by koenig.oss.cantel.rogers.com (Netscape Messaging Server 3.6) with ESMTP id AAAB44 for ; Fri, 6 Sep 2002 19:13:58 -0400 Received: from oss.cantel.rogers.com ([10.64.31.186]) by gaea.oss.cantel.rogers.com (Netscape Messaging Server 3.6) with ESMTP id AAA6F59 for ; Fri, 6 Sep 2002 19:13:57 -0400 Message-ID: <3D7936B5.49A9BC84@oss.cantel.rogers.com> Date: Fri, 06 Sep 2002 19:13:57 -0400 From: Pierre Belanger Organization: Rogers AT&T X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rancid-discuss@shrubbery.net Subject: F5 support? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rancid-discuss@shrubbery.net Precedence: bulk Does RANCID support F5 Network stuff, like the BigIP? I don't have access to the F5 documentation right now... perhaps it's "compliant" with something "already" supported in RANCID? Thank you, Pierre B. From owner-rancid-discuss@shrubbery.net Fri Sep 6 23:30:14 2002 Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ni.shrubbery.net (8.11.6/8.11.1) with ESMTP id g86NUEf15628 for ; Fri, 6 Sep 2002 23:30:14 GMT Received: (from majordom@localhost) by guelah.shrubbery.net (8.11.6/8.11.1) id g86NToc25226 for rancid-discuss-outgoing; Fri, 6 Sep 2002 23:29:51 GMT Received: (from heas@localhost) by guelah.shrubbery.net (8.11.6/8.11.1) id g86NTka25221; Fri, 6 Sep 2002 23:29:46 GMT Date: Fri, 6 Sep 2002 23:29:46 +0000 From: john heasley To: Pierre Belanger Cc: rancid-discuss@shrubbery.net Subject: Re: F5 support? Message-ID: <20020906232946.A25121@shrubbery.net> References: <3D7936B5.49A9BC84@oss.cantel.rogers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D7936B5.49A9BC84@oss.cantel.rogers.com>; from pbelang1@oss.cantel.rogers.com on Fri, Sep 06, 2002 at 07:13:57PM -0400 X-note: live free, or die! X-homer: mmmm, forbidden doughnut. Sender: owner-rancid-discuss@shrubbery.net Precedence: bulk Fri, Sep 06, 2002 at 07:13:57PM -0400, Pierre Belanger: > Does RANCID support F5 Network stuff, like the BigIP? no. > I don't have access to the F5 documentation right now... > perhaps it's "compliant" with something "already" supported > in RANCID? it may; have never seen one. From EnciniasHighland@address.com Sun Sep 29 00:57:07 2002 Received: from gnome04.net.rol.ru (gnome04.net.rol.ru [194.67.1.185]) by ni.shrubbery.net (8.11.6/8.11.1) with ESMTP id g8T0v2u16843; Sun, 29 Sep 2002 00:57:06 GMT Received: from [194.186.222.250] ([194.186.222.250]:10259 "HELO address.com" ident: "NO-IDENT-SERVICE[2]" whoson: "-unregistered-" smtp-auth: TLS-CIPHER: TLS-PEER: ) by gnome04.net.rol.ru with SMTP id ; Sun, 29 Sep 2002 04:56:52 +0400 Subject: Tones of galleriez inside! (K76laRq0p5) Date: Sat, 28 Sep 2002 21:9:34 -0400 From: SprayberryResnikoff@address.com To: "Kimbral Sadorra" Reply-To: cottledow78h63o4yx@yahoo.com X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2100.0000 Errors-To: X-Accept-Language: en X-Comment: VEi MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Ql---Minemindfxxyf76mB6=" Content-Transfer-Encoding: 7bit Message-Id: <20020929005652Z5816957-11708+8057@gnome04.net.rol.ru> --Ql---Minemindfxxyf76mB6= Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="ISO-8859-1"
GUARANTEED 100% FREE PASSWORDS
GET INTO PAYSITES FOR FREE
Click Here to Enter!

Did you know that....

The laws governing the adult Internet business have recently become extremely strict to protect consumers. You now can, and should take advantage of this protection.

Click Here to Enter!

But there is more....

Companies that offer FREE PASSWORDS must, by law, honor this promise. Companies give away free access to their websites just to generate traffic to it so they can promote other things by using banners and such. Remember, if it says FREE, you are not obligated to buy anything.

Click Here to Enter!

Last but not least....

Some companies offer free trial memberships. So all you have to do is join the site as you would any normal site, and cancel before the trial period runs out. They make their $ when u either genuinely like the site and remain a member or when u forget to cancel. If you cancel on time YOU WILL NOT BE CHARGED!!!

Click Here to Enter!

we’ve compiled some of the biggest and best FREE hardcore sites on the net!

INSTANT ACCESS 100% FREE HARD-CORE


This email was sent to you because your email is part of a targeted opt-in list. If you do not wish to receive further mailings from this offer, please click below and enter your email to remove your email from future offers. Anti-SPAM Policy Disclaimer: Under Bill s.1618 Title III passed by the 105th U. S. Congress, mail cannot be considered spam as long as we include contact information and a remove link for removal from this mailing list. If this e-mail is unsolicited, please accept our apologies. Per the proposed H.R. 3113 Unsolicited Commercial Electronic Mail Act of 2000, further transmissions to you by the sender may be stopped at NO COST to you Do Not Reply To This Message To Be Removed. Easy Remove and contact: click here
2NXdeT46caTI0Y --Ql---Minemindfxxyf76mB6=--