[nsp] Css 11800 content replication

[Tim D.]

The solution to this problem is to enable delete access to the ftp site
configured in the ftp-record.  Otherwise, (undocumented) the css 'puts' and
'deletes' some sort of checksum files (I had 10,000 on my ftp).  These files
contain the text, 'justalittlefile'.  Does anyone know what kind of traffic
I'm looking at based on WAN replication and a default size of 11kb per file?
Just how often, and why are these checksums sent?  Is there a formulae used
to calculate the bandwidth used by this mechanism?


> I should also mention that the CSS continues to pass traffic without much
> latency (although most of that is on a different card, different asic).
> Also I have recified a mistake in my first paragraph.....
>
> > Hello,
> >
> > I have been attempting to do content replication on my css 11800's.
> >
> > I basically have one css monitoring ftp roots on 2 servers.  If content
in
> a
> > root directory changes
> > on either of the machines, the file gets replicated to a sub directory
on
> both
> > servers.  That is, I have one publishing service for each IP monitoring
> the
> > root of themselves.  If either of their roots change, the CSS will
> > replicate to the sub folder on both machines.  I currently have no
content
> > rule defined.
> >
> > However, when I enable this, the 11800's cpu for that line card (only
that
> > card) goes ballistic, and my telnet/console session is lost, never to
> > return.  A solution is to reboot the css, and then remove/suspend the
> > services.  This is not really a solution though ;).
> >
> > I am running webNS 5.02.
> >
> > Am I doing something wrong?  From what I can tell reading *all* of the
> docs
> > (regarding content replication) online, my configuration is unique in
that
> I
> > have two subscribers configured on one service.
> >
> > Can someone please inform me as to a source of more information on
content
> > replication scenario literature?  If you have any additional information
> as
> > to what is possibly causing this problem, I would be very open to
> > suggestions as well.
> >
> >
> > _______________________________________________
> > cisco-nsp mailing list  real_name)s@puck.nether.net
> > http://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>