On Sat, Dec 20, 2008, Ingo Flaschberger wrote:
> I'm not shure if this setup would ever be "stable".
> also with ucarp tweaks.
> hopefully freebsd supports soon more than 1 route.
>
FreeBSD, like all good open source projects, gets features supported when
people code them up.
So if you'd like t
On Sun, Dec 21, 2008 at 8:31 AM, Justin Shore wrote:
> I should have said it earlier when I mentioned config backups. I'm already
> a heavy user of RANCID, archiving my configs hourly. Been using it since
> right around v2.0-2.1 which would be several years ago (feels like a
> lifetime). So my
Suresh Ramasubramanian wrote:
Heck, you could store all that in Rancid .. even cvs/svn
I should have said it earlier when I mentioned config backups. I'm
already a heavy user of RANCID, archiving my configs hourly. Been using
it since right around v2.0-2.1 which would be several years ago (
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 20, 2008, at 8:11 PM, Suresh Ramasubramanian wrote:
On Sun, Dec 21, 2008 at 6:52 AM, Justin Shore
wrote:
Does anyone have any preferred ways to manage their customer-facing
BGP
details? I'm thinking about the customer's ASN (SP assigned
On Sun, Dec 21, 2008 at 6:52 AM, Justin Shore wrote:
> Does anyone have any preferred ways to manage their customer-facing BGP
> details? I'm thinking about the customer's ASN (SP assigned private ASN or
> RIR assigned ASN), permitted prefixes, etc? While I'm sure this could be
> easily stored i
On Sat, 20 Dec 2008, Justin Shore wrote:
Does anyone have any preferred ways to manage their customer-facing BGP
details? I'm thinking about the customer's ASN (SP assigned private ASN or
RIR assigned ASN), permitted prefixes, etc? While I'm sure this could be
easily stored in a spreadsheet
Does anyone have any preferred ways to manage their customer-facing BGP
details? I'm thinking about the customer's ASN (SP assigned private ASN
or RIR assigned ASN), permitted prefixes, etc? While I'm sure this
could be easily stored in a spreadsheet I'm not sure if there is any
merit to stor
> Well, the J-series are fully software-based routers. Still, they have
> their own routing daemons and such.
The difference is that Juniper, even on th J-series box, completely
separates the control plane and fowarding plane.
The forwarding plane on a M or T series is going to be a ppc based
ch
Once upon a time, David Coulson said:
> Comparing Imagestream and Vyatta to Juniper is crazy. The first two are
> software based platforms (with perhaps some hardware off-load for
> checksums and whatnot), where as the Juniper pretty much just uses BSD
> for control-plane features (BGP, for exa
On Dec 18, 2008, at 9:43 PM, 정치영 wrote:
Suresh,
Yes, I guess my concern is close to the second meaning.
It seems so simple. Currently annoucement of /24 seems to be okey,
most upstream providers accept this.
However I wonder if there is any ground rule based on any standard
or official re
* David Coulson:
> Comparing Imagestream and Vyatta to Juniper is crazy. The first two
> are software based platforms (with perhaps some hardware off-load for
> checksums and whatnot), where as the Juniper pretty much just uses BSD
> for control-plane features (BGP, for example, and controlling th
"Brandon Galbraith" writes:
> But it's definitely not cool when my credit card company cuts off my card
> due to "abnormal charges" when I'm abroad and suddenly can't get ahold of
> customer service via their international phone number. Automation in the
> right places works wonders for both conve
Hi Marc,
> We are a software development firm that currently delivers our install ISOs
> via Sourceforge. We need to start serving them ourselves for marketing
> reasons and are therefore increasing our bandwidth and getting a 2nd ISP in
> our datacenter. Both ISPs will be delivering 100mbit/
13 matches
Mail list logo
