First time poster, long time lurker.
Also if you are going RADIUS route. There's a simple web shell boot version
available at
http://www.zeroshell.net/eng/radiusdetails/
that support RADIUS.
-bn
On Fri, Nov 7, 2008 at 3:04 PM, Buhrmaster, Gary <[EMAIL PROTECTED]>wrote:
>
> > Do you have any
> Do you have any suggestions for a free tacacs server which
> will run on linux ? I have so far been unable to find any
> and the tacacs+ source code hasn't been updated since
> around 2000
Available (and maintained) at:
http://www.shrubbery.net/tac_plus/
(direct download link: ftp://ftp.shru
It's not free, but I want to praise Radiator
(http://www.open.com.au/radiator/) as a great radius/tacacs+ server.
(I have previously battled both with freeradius and openradius.)
- d.
On Fri, 7 Nov 2008, Leslie wrote:
Do you have any suggestions for a free tacacs server which will run on l
We use tac_plus with good results:
http://www.shrubbery.net/tac_plus/
On Nov 7, 2008, at 2:56 PM, Leslie wrote:
Do you have any suggestions for a free tacacs server which will run
on linux ? I have so far been unable to find any and the tacacs+
source code hasn't been updated since around 2
Do you have any suggestions for a free tacacs server which will run on
linux ? I have so far been unable to find any and the tacacs+ source
code hasn't been updated since around 2000
Leslie
On Nov 7, 2008, at 2:43 PM, Eddy Martinez wrote:
I second the TACACS+
Thats what you want. Same eff
I second the TACACS+
Thats what you want. Same effort for the most part, to implement.
Eddy
On Nov 7, 2008, at 2:39 PM, Steven King wrote:
I disagree with the RADIUS suggestion. TACACS+ is a much more secure
protocol. It encrypts the packet contents and has a more secure
handshake procedure.
I disagree with the RADIUS suggestion. TACACS+ is a much more secure
protocol. It encrypts the packet contents and has a more secure
handshake procedure.
Leslie wrote:
> The best answer actually does seem to be to use freeradius instead of
> tacacs, so I will probably go with that (though if anyon
Hi,
You can extract information from this doc : Installation of Tacacs+,
Rancid, Cvsweb
http://www.debian-administration.org/articles/429
Freeradius will need more time to implement, but easier to manage after.
--
Raphaël Maunier
NEO TELECOMS
Engineering Manager
2 rue du Chemin Vert
92110 Cli
The best answer actually does seem to be to use freeradius instead of
tacacs, so I will probably go with that (though if anyone has any good
tips on freeradius, please, let me know)
Leslie
On Nov 7, 2008, at 1:30 PM, Leslie wrote:
Hi --
We are currently trying to set up a TACACS server fo
Hi,
On Fri, 7 Nov 2008 13:30:32 -0800
Leslie <[EMAIL PROTECTED]> wrote:
> We are currently trying to set up a TACACS server for authentication
> to our network gear and have it run on suse linux hosts. Does anyone
> have any advice/good webpages or guides regarding this?
I really don't mean
Hi --
We are currently trying to set up a TACACS server for authentication
to our network gear and have it run on suse linux hosts. Does anyone
have any advice/good webpages or guides regarding this?
Thank you very much in advance!
Leslie
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
Daily listings are sent to [EMAIL PROTECTED]
For historical data, please see http://thyme.apnic.net.
If you have any comments please contact Philip Smith <[EMAIL PROTECTED]
On Fri, 07 Nov 2008 08:27:58 +0100, Mikael Abrahamsson said:
> for ECN to actually be useful, we (the ISPs) have to turn this option on
> in the routers as well. Is anyone doing this today? What vendors support
> it?
The only thing that's *required* for it to help is that the routers and
firewal
First, let me say that I think peering regulation is a terrible idea.
No matter how cleverly you plan it, the result will be that fewer
small companies can participate. That's the character of regulation:
compliance creates more barriers to entry than it removes.
That having been said, jurisdic
On Fri, 7 Nov 2008, David Freedman wrote:
Implementing this in an MPLS core is not an easy task, you can really
only do this on the edge, when the MPLS labelled packet arrives at an
LSR, we don't know if it contains a TCP segment or not (fancy deep h/w
implementations excluded), all we know is
This report has been generated at Fri Nov 7 21:37:28 2008 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date
Interesting , I hadn't followed this since draft-ietf-mpls-ecn-00,
, I eagerly await a vendor implementation :)
Dave.
Bjørn Mork wrote:
> David Freedman <[EMAIL PROTECTED]> writes:
>
>> Implementing this in an MPLS core is not an easy task, you can really
>> only do this on the edge, when the MP
BGP Update Report
Interval: 06-Oct-08 -to- 06-Nov-08 (32 days)
Observation Point: BGP Peering with AS131072
TOP 20 Unstable Origin AS
Rank ASNUpds % Upds/PfxAS-Name
1 - AS9583 190435 1.7% 169.6 -- SIFY-AS-IN Sify Limited
2 - AS10396 163475 1.5%
David Freedman <[EMAIL PROTECTED]> writes:
> Implementing this in an MPLS core is not an easy task, you can really
> only do this on the edge, when the MPLS labelled packet arrives at an
> LSR, we don't know if it contains a TCP segment or not (fancy deep h/w
> implementations excluded), all we kn
Well, don't know about anybody else, but I've been asking vendors for
LDP6 for a while now, every time we approach them for new projects and
they always look embarrassed when they realise that they
a. don't have it
b. are not involved in the standards process (draft-manral-mpls-ldp-ipv6-02)
So p
> When I thought about it, the IP core (10G links etc) first came to mind,
> and there it's fairly easy to roll out (since I guess a lot of us do
> WRED already), but what about on slower links? Would it make sense to
> have our DSLAMs do this? What about DSL/cable modems (well, vendors
> should fi
21 matches
Mail list logo
