> > Geo-topological addressing refers to RIRs reserving large
> > blocks of designated addresses for areas served my large
> > cities (over 100,000) population. When end users are located
> > in fringe areas roughly equidistant between two or more such
> > centers, the RIR simply asks the end user
I'd really like to know how I can get ahold of the people that do the
Drone Army reports, as I am a serveradmin on an irc network that was
identified as being abusive.
If you're responding as part of the Drone Army, please reply to me off list.
Allen Parker
This report has been generated at Fri Feb 17 21:46:53 2006 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table Hist
And just to update, those drafts have made it into RFC 4271
http://www.ietf.org/rfc/rfc4271.txt
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Danny McPherson
Sent: Tuesday, January 03, 2006 3:49 PM
To: [EMAIL PROTECTED]
Subject: Re: metric 0 vs 'no met
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]
If you have any comments please contact Philip Smith <[EMAIL PROTECTED]>.
Routing Table Report 04:00 +10GMT Sat 18 Feb, 2006
No need anymore, I've already spoken with both Gadi and Randy on the
matter that concerned me.
Thanks,
Allen
On 2/17/06, Roland Dobbins <[EMAIL PROTECTED]> wrote:
>
> cc'ing Gadi.
>
> On Feb 17, 2006, at 2:10 AM, infowolfe wrote:
>
> >
> > I'd really like to know how I can get ahold of the peopl
Peering BOF XI Meeting Minutes
Facilitator: William B. Norton <[EMAIL PROTECTED]>
Agenda
1. Notes from the Field - wbn
2. ad Hoc Transit Survey – Dave Wodelet
3. Paid Peering as an Adjunct to Settlement Free Interconnect (15 min). -wbn
4. The Great Peering Debate (30 min) ras, ianai
5. Peering Con
Greetings all,
Would anyone who has every done MLPPP over MPLS care to share their experiences
with this type of network?
We have a customer that is implementing an MPLS network that will have 2 to 6
T1 feeds at some locations that will be using MLPPP for channel bonding. This
is a telco provi
I've used MLPPP before with T1s...not the hardest thing to do...in fact,
MLFR is a little bigt nastier, but still nothing that the average CCNA
couldn't wrap their brain around...
Erik Amundson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Jon R. Kib
On Fri, 17 Feb 2006, Jon R. Kibler wrote:
We have a customer that is implementing an MPLS network that will have 2
to 6 T1 feeds at some locations that will be using MLPPP for channel
bonding. This is a telco provided network that will be customer managed.
It's not clear from your message, b
On Thu, 16 Feb 2006, Warren Kumari wrote:
> If your primary is connected to ISP_A and the backup is connected to ISP_B,
> customers connected to ISP_B MAY still flow to your backup DC (ISP_B will
> probably set local preference on all customer routes - you should be able to
> override this behavi
On Fri, 17 Feb 2006, Todd Vierling wrote:
>
> On Thu, 16 Feb 2006, Warren Kumari wrote:
>
> > If your primary is connected to ISP_A and the backup is connected to ISP_B,
> > customers connected to ISP_B MAY still flow to your backup DC (ISP_B will
> > probably set local preference on all customer
On Fri, 17 Feb 2006, Christopher L. Morrow wrote:
> > > If your primary is connected to ISP_A and the backup is connected to
> > > ISP_B,
> > > customers connected to ISP_B MAY still flow to your backup DC (ISP_B will
> > > probably set local preference on all customer routes - you should be abl
On Fri, 17 Feb 2006, Todd Vierling wrote:
> > I might be crazy, but couldn't you just prepend the route enough to
> > effectively poison it at ingress to 'backup-isp' ?
>
> Some route decision override schemes don't care what the path length is at
> all, or factor it in with such a low weight, su
What I heard from Cisco is that there may be some issue with MLPPP and
MPLS - maybe QoS? -.
The issue is for general IOS support issue for MLPPP/MPLS combination.
For that reason, Cisco recommended Multi-link Frame Relay(MLFR) to
overcome that issue.
Hyun
Jon R. Kibler wrote:
> Greetings all,
>
Hyunseog Ryu wrote:
>
> What I heard from Cisco is that there may be some issue with MLPPP and
> MPLS - maybe QoS? -.
> The issue is for general IOS support issue for MLPPP/MPLS combination.
> For that reason, Cisco recommended Multi-link Frame Relay(MLFR) to
> overcome that issue.
>
> Hyun
>
H
You can find the information and update here:
http://blogs.securiteam.com/index.php/archives/298
Apparently nanog drops email messages with long subject lines.
Thanks,
Gadi.
--
http://blogs.securiteam.com/
"Out of the box is where I live".
-- Cara "Starbuck" Thrace, Battlest
Maybe next monday I can ask for detailed info, but I wasn't on the
meeting to discuss this in detail.
Based on outcome of discussion with Cisco, we decided to go with MLFR
instead of MLPPP.
Hyun
Jon R. Kibler wrote:
> Hyunseog Ryu wrote:
>
>> What I heard from Cisco is that there may be some
On Feb 17, 2006, at 1:25 PM, Christopher L. Morrow wrote:
On Fri, 17 Feb 2006, Todd Vierling wrote:
On Thu, 16 Feb 2006, Warren Kumari wrote:
If your primary is connected to ISP_A and the backup is connected
to ISP_B,
customers connected to ISP_B MAY still flow to your backup DC
(ISP_B
We're a small facilities based ISP in Chicago and I am looking for a
public exchange point for peering. I have been told, by someone at SBC,
that the public NAP here is no longer accepting connections and is
essentially going to shut down over time. Has anyone else heard this? Are
there other
On Fri, Feb 17, 2006 at 08:46:34PM -0600, sjk wrote:
>
> We're a small facilities based ISP in Chicago and I am looking for a
> public exchange point for peering. I have been told, by someone at SBC,
> that the public NAP here is no longer accepting connections and is
> essentially going to sh
On Fri, 17 Feb 2006, Warren Kumari wrote:
> On Feb 17, 2006, at 1:25 PM, Christopher L. Morrow wrote:
>
> > I might be crazy, but couldn't you just prepend the route enough to
> > effectively poison it at ingress to 'backup-isp' ? so they kept
> > chosing
> > the remote path and never really acc
22 matches
Mail list logo
