I got an answer for my question.
7018/ATT does ACCEPT /24 routes from 701/mci.
e.g
24.143.13.0/24 on route-server.ip.att.net
has AS-PATH (7018 701 13368).
Is 7018 preferring 19094 over 701 regardless of
AS-PATH length? Or, 7018 will not take prefixes from
other peers if a particular prefix is co
On Wed, 19 Oct 2005, Kyaw Khine wrote:
> I opened ticket with both 701 and 19094 when we did
> failover 2 weeks ago. Both 701 and 19094 insist that
> they just take the route and send it out to the rest
> of the world. And at that time, I thought it was RADB
yup, we're just passing it along as
I opened ticket with both 701 and 19094 when we did
failover 2 weeks ago. Both 701 and 19094 insist that
they just take the route and send it out to the rest
of the world. And at that time, I thought it was RADB
problem and agreed to close the tix.
Now that RADB is fixed, I'm back at square one wi
On Wed, 19 Oct 2005, Kyaw Khine wrote:
>
> Says .. I pick 7018/AT&T.
> 7018 is accepting 701/mci customer routes. But is 7018
> accepting 701/mci customer /24 routes ???
>
> 7018 is definitely accepting 19094/telcove /24 routes
> because I see 64.9.17.0/24 on ATT route-server
> (route-server.ip.
On Wed, 19 Oct 2005, Kyaw Khine wrote:
> Hmmm..
> When /24 gets to those ISP (direct connected to
> 19094/telcove), shouldn't they prefer 701/mci path?
depends on their relationship with 701 probably, and their internal
decision criteria... they might filter or pref or... who knows :(
> AS-PAT
Says .. I pick 7018/AT&T.
7018 is accepting 701/mci customer routes. But is 7018
accepting 701/mci customer /24 routes ???
7018 is definitely accepting 19094/telcove /24 routes
because I see 64.9.17.0/24 on ATT route-server
(route-server.ip.att.net)
So, why is 7018 receiving/accepting /24 from so
Hmmm..
When /24 gets to those ISP (direct connected to
19094/telcove), shouldn't they prefer 701/mci path?
AS-PATH is longer through 19094 than through 701 ...
provided that those ISP are accepting/receiving path
from 701.
--- "Christopher L. Morrow"
<[EMAIL PROTECTED]> wrote:
>
> On Thu, 20 Oc
There are a few ISP they are seeing path from 701. But
very few compare to prepended path via 19094.
e.g
route-server.colt.net (2914 701 33105)
route-views.bmcag.net (1239 701 33105)
--- Jon Lewis <[EMAIL PROTECTED]> wrote:
>
> On Wed, 19 Oct 2005, Kyaw Khine wrote:
>
> >
> > routeviews is
On Thu, 20 Oct 2005, Jon Lewis wrote:
>
> On Wed, 19 Oct 2005, Kyaw Khine wrote:
>
> >
> > routeviews is seeing both paths.
> >
> > 64.9.17.0/24
> > AS 33105
> >
> > ISP-A = 701 :)
> > ISP-B = 19094
>
> You might talk to 701 about why for instance, all I see is your
> prepended path via 19094 th
I've heard and seen those filters a few years ago. In
this particular case, I've seen a bunch of other /24s
(from remote ASs) on the looking glasses.
Looks like filters are base on other criteria on top
of prefix length and I wonder which criterion this /24
falls into.
--- "Christopher L. Morrow
On Wed, 19 Oct 2005, Kyaw Khine wrote:
routeviews is seeing both paths.
64.9.17.0/24
AS 33105
ISP-A = 701 :)
ISP-B = 19094
You might talk to 701 about why for instance, all I see is your
prepended path via 19094 through 3356, 6461, 4323, and 19962.
Maybe 701 is only propogating your rou
routeviews is seeing both paths.
64.9.17.0/24
AS 33105
ISP-A = 701 :)
ISP-B = 19094
Thanks ...
--- Randy Bush <[EMAIL PROTECTED]> wrote:
>
> try a peek at route views
>
> and, if you want help debugging, folk will want to
> know the
> prefix and the asn
>
> randy
>
>
try a peek at route views
and, if you want help debugging, folk will want to know the
prefix and the asn
randy
On Wed, 19 Oct 2005, Kyaw Khine wrote:
> I've contacted both ISPs and they both claimed they
> are announcing our /24 to the rest of the world,
> without manipulation.
>
> What am I missing here?
some providers (for whatever reason, not really relevant to this
conversation) do filter at boundar
I'm having trouble announcing a single /24 from an
ASN. ASN is multi-homed to ISP-A and ISP-B, prepending
on ISP-B side.
ASN in question has one and only one /24 which
originally was from ISP-B /17 block.
Some ISP only sees path from ISP-A and some from ISP-B
and very few sees both paths. Apparen
On Wed, 19 Oct 2005, Owen DeLong wrote:
Yes and no. Most people that will spend the $$ for routers with enough
memory to handle multiple full feeds are also looking to get a certain
amount of TE capability out of the deal, and, at that point, babysitting
the TE becomes more than 0.01 FTE (clos
--On October 19, 2005 11:17:02 PM -0400 Jon Lewis <[EMAIL PROTECTED]> wrote:
On Wed, 19 Oct 2005, Owen DeLong wrote:
I've done simple ASN/BGP based multihoming for a number of businesses,
and, it can be done on a mostly set-and-forget basis. If you have your
upstreams supply 0.0.0.0/0 via B
--- David Conrad <[EMAIL PROTECTED]> wrote:
> On Oct 17, 2005, at 10:39 PM, Paul Jakma wrote:
> >> Wrong issue. What I'm unhappy about is not the
> size of the
> >> address - you'll notice that I didn't say "make
> the whole address
> >> space smaller." What I'm unhappy about is the
> exce
On Wed, 19 Oct 2005, Owen DeLong wrote:
I've done simple ASN/BGP based multihoming for a number of businesses, and,
it can be done on a mostly set-and-forget basis. If you have your upstreams
supply 0.0.0.0/0 via BGP and no other routes, and, you advertise your
networks, believe it or not, tha
Daniel,
I think it is safe, even with projected AS and IP uptake, to assume
Moore's law can cope with this.
Moore will keep up reasonably with both the CPU needed to keep BGP
perking, and with memory requirements for the RIB, as well as other
non-data-path functions of routers.
Th
PS: Btw, anyone can give me a hint on where to discuss new ideas for
e.g. routing schemes (and finding out whether it's an old idea)?
You might start with the routing-discussion mailing list:
http://www.rtg.ietf.org/
Please expect that your idea has been discussed before. We're an old
On Thu, Oct 20, 2005 at 03:18:35AM +0100, Paul Jakma scribed:
> On Wed, 19 Oct 2005, David G. Andersen wrote:
>
> >If you can run Squid, you can multihome your web connections today.
> >It's a little bit awkward to configure, but then again, so is
> >Squid. People are welcome to poke at, fold, s
On Wed, 19 Oct 2005, David G. Andersen wrote:
If you can run Squid, you can multihome your web connections today.
It's a little bit awkward to configure, but then again, so is
Squid. People are welcome to poke at, fold, spindle, or mutilate:
http://nms.lcs.mit.edu/ron/ronweb/#code
(Part of m
On Wed, Oct 19, 2005 at 10:19:28PM +, Paul Vixie scribed:
>
> [EMAIL PROTECTED] (Jared Mauch) writes:
>
> > it will be interesting to see if this has acutal impact on
> > ASN allocation rates globally.
>
> i don't think so. multihoming without bgp isn't as hard as qualifying for
> PI s
if one is looking at origin-as in routing annoucements in route views,
there are some asns that should be ignored, e.g., . is there a
good list of these somewhere.
randy
Hi,
On Wed, 19 Oct 2005, Iljitsch van Beijnum wrote:
On 17-okt-2005, at 14:18, Jeroen Massar wrote:
Another alternative is to force-align allocation and topology in some
way /other/ than by "Providers" (geographical allocation in whatever
hierarchy, IX allocation, whatever), such that networ
lest we forget...
- Forwarded message -
Bill,
Could you forward to NANOG for me?
Thanks,
[snip]
Jon, I'm sorry I forgot until just today...
http://www.postel.org/postel.html
- End forwarded message -
Sorry for the interruption, but I couldn't let these two
anniversaries pass without bringing them to your attention.
http://fergdawg.blogspot.com/2005/10/in-memoriam-abha-ahuja.html
[and]
http://fergdawg.blogspot.com/2005/10/belatedly-october-16-1998-rip-jon.html
I'll crawl back under my rock
[EMAIL PROTECTED] (Todd Vierling) writes:
> > The customer wants redundancy.
>
> That's why SLAs exist.
no. sla's exist because actuarial tables and lawyers and accountants exist.
--
Paul Vixie
[EMAIL PROTECTED] (Jared Mauch) writes:
> it will be interesting to see if this has acutal impact on
> ASN allocation rates globally.
i don't think so. multihoming without bgp isn't as hard as qualifying for
PI space. i think we'll finally see enterprise-sized multihoming NAT/proxy
produ
On 17-okt-2005, at 14:18, Jeroen Massar wrote:
Another alternative is to force-align allocation and topology in
some
way /other/ than by "Providers" (geographical allocation in whatever
hierarchy, IX allocation, whatever), such that networks were easily
aggregatable. Lots of objections though
> Always remember: For every customer, their stuff _is_ mission
> critical. So everyone will take the multihoming road if they
> can afford it.
>
> We can make it more expensive, or we can offer other solutions.
>
Why should we do either? Why not fix the way we do routing so
that it's OK for eve
>> That's the operators' view, but not the customer's.
>> The customer wants redundancy.
>
> That's why SLAs exist.
>
No... SLAs exist to extract some compensation when the level of service
doesn't meet the need. In a mission critical situation, SLAs are
pretty worthless. The primary benefit of
5 9s can be measured all sorts of ways...
Network wide, it probably isn't even a blip. Even in terms of all of
California service its probably not much more than a blip.
Vicky Rode wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wonder what ever happened to redundancy? I guess 5 9s
> Well, not necessarily.
>
> Tier-2s should be given much more credit than they typically are in
> write-ups like this. When a customer is single homed to a tier-2 that has
> multiple tier-1 upstreams, and uses a delegated netblock from the tier-2's
> aggregations, that means one less ASN and one
Or you can get automated bogon feeds from our good friends at cymru..
http://www.cymru.com/BGP/bogon-rs.html
Peter Kranz
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Patrick W. Gilmore
Sent: Wednesday, October 19, 2005 12:49 PM
To:
On Oct 19, 2005, at 3:31 PM, Mark Radabaugh wrote:
John Payne wrote:
[...]
If you don't have multihoming requirements other than availability
then it really can be fire and forget.
Except for those pesky bogon filters which corporations seem to
like
to "fire and forget".
Perhaps
On Wed, 19 Oct 2005, John Payne wrote:
> Hrm, people keep saying that BGP is hard and takes time.
>
> As well as my end-user-facing network responsibilities, I also have corporate
> network responsibilities here. All of our corporate hub locations are
> multi-homed (or soon will be)... and I hon
John Payne wrote:
>
> Hrm, people keep saying that BGP is hard and takes time.
>
> As well as my end-user-facing network responsibilities, I also have
> corporate network responsibilities here. All of our corporate hub
> locations are multi-homed (or soon will be)... and I honestly can't
> re
On Oct 19, 2005, at 12:20 PM, Todd Vierling wrote:
Many customers would rather not multihome directly, and prefer "set
it and
forget it" connectivity. It's much easier to maintain a multi-pipe
connection that consists of one static default route than a pipe to
multiple
carriers. The forme
[EMAIL PROTECTED] (Mike Tancsa) wrote:
> >The customer wants redundancy.
>
> The customer wants reliability
That's what you know and what I know. The customer has already jumped
one step ahead from "reliability" to "multiple providers", just like
he does with parcel services etc.
> There are b
At 11:59 AM 19/10/2005, Elmar K. Bins wrote:
[EMAIL PROTECTED] (Todd Vierling) wrote:
> Tier-2s should be given much more credit than they typically are in
> write-ups like this. When a customer is single homed to a tier-2 that has
> multiple tier-1 upstreams, and uses a delegated netblock fr
At 01:05 PM 10/19/2005, John Dupuy wrote:
For the customer with an Internet "mission critical app", being tied
to a Tier 2 has it's own set of problems, which might actually be
worse than being tied to a Tier 1.
The key word is "might". In fact, I would posit that a Tier 2 with
multiply red
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wonder what ever happened to redundancy? I guess 5 9s (dunno what the
going number is) got blown out of the water for them.
regards,
/virendra
David Lesher wrote:
>
> Speaking on Deep Background, the Press Secretary whispered:
>
>>
>>I'm not c
For the customer with an Internet "mission critical app", being tied
to a Tier 2 has it's own set of problems, which might actually be
worse than being tied to a Tier 1.
The key word is "might". In fact, I would posit that a Tier 2 with multiply
redundant transit to all of the Tier 1s could
TV> Date: Wed, 19 Oct 2005 12:20:25 -0400 (EDT)
TV> From: Todd Vierling
TV> That's why SLAs exist.
I thought SLAs existed to comfort nontechnical people into signing
contracts, then denying credits via careful weasel words when the time
comes for the customer to collect. Or maybe I'm just cyn
On Wed, 19 Oct 2005, Todd Vierling wrote:
That's the operators' view, but not the customer's.
The customer wants redundancy.
That's why SLAs exist.
SLAs exist to provide a means of allowing a vendor to 'feel your pain'
when you experience some type of a service outage. They generally do n
On Oct 19, 2005, at 12:34 PM, Edward Lewis wrote:
At 12:20 -0400 10/19/05, Todd Vierling wrote:
That's why SLAs exist.
Do SLA's say "if you are out of the water for 30 minutes we will
also cover your lost business revenue?" There are some times with
service guarantees just are not enou
At 12:20 -0400 10/19/05, Todd Vierling wrote:
That's why SLAs exist.
Do SLA's say "if you are out of the water for 30 minutes we will also
cover your lost business revenue?" There are some times with service
guarantees just are not enough (e.g., manned space flight support).
--
-=-=-=-=-=
[EMAIL PROTECTED] (Patrick W. Gilmore) wrote:
> The problems with a small provider might include:
>
> * Business viability
> * Global reach
> * Capacity
> * Redundant architecture
> * Etc., etc., etc.
Thanks - understood ;-)
I see, btw, a lot of Tier-3 (or -4, -5) providers that have
On Oct 19, 2005, at 12:08 PM, Elmar K. Bins wrote:
[EMAIL PROTECTED] (Patrick W. Gilmore) wrote:
For the customer with an Internet "mission critical app", being tied
to a Tier 2 has it's own set of problems, which might actually be
worse than being tied to a Tier 1.
Please elaborate.
I pr
On Wed, 2005-10-19 at 12:03 -0400, Patrick W. Gilmore wrote:
> For the customer with an Internet "mission critical app", being tied
> to a Tier 2 has it's own set of problems, which might actually be
> worse than being tied to a Tier 1.
I think this is largely dependant on the specific topolo
On Wed, 19 Oct 2005, Elmar K. Bins wrote:
> > Tier-2s should be given much more credit than they typically are in
> > write-ups like this. When a customer is single homed to a tier-2 that has
> > multiple tier-1 upstreams, and uses a delegated netblock from the tier-2's
> > aggregations, that me
[EMAIL PROTECTED] (Patrick W. Gilmore) wrote:
> For the customer with an Internet "mission critical app", being tied
> to a Tier 2 has it's own set of problems, which might actually be
> worse than being tied to a Tier 1.
Please elaborate.
Elmar.
On Wed, 19 Oct 2005, Todd Vierling wrote:
> On Wed, 19 Oct 2005, Christopher L. Morrow wrote:
>
> > > > "Gartner said every location that requires mission-critical
> > > > internet connectivity, including externally hosted
> > > > websites, should be multi-homed"
> > >
> > > 200k routes, here
On Oct 19, 2005, at 11:54 AM, Todd Vierling wrote:
"Gartner said every location that requires mission-critical
internet connectivity, including externally hosted
websites, should be multi-homed"
200k routes, here we come!
it is just good common sense though, eh?
Well, not necessarily.
[EMAIL PROTECTED] (Todd Vierling) wrote:
> Tier-2s should be given much more credit than they typically are in
> write-ups like this. When a customer is single homed to a tier-2 that has
> multiple tier-1 upstreams, and uses a delegated netblock from the tier-2's
> aggregations, that means one l
On Wed, 19 Oct 2005, Christopher L. Morrow wrote:
> > > "Gartner said every location that requires mission-critical
> > > internet connectivity, including externally hosted
> > > websites, should be multi-homed"
> >
> > 200k routes, here we come!
>
> it is just good common sense though, eh?
We
In a message written on Wed, Oct 19, 2005 at 11:31:32AM -0400, Jared Mauch
wrote:
> it will be interesting to see if this has acutal impact on
> ASN allocation rates globally.
I have done no analysis, but I do believe this is having an effect
on the number of prefixes announced by many of t
On Wed, 19 Oct 2005, Todd Vierling wrote:
>
> On Wed, 19 Oct 2005, Brandon Butterworth wrote:
>
> > "Gartner said every location that requires mission-critical
> > internet connectivity, including externally hosted
> > websites, should be multi-homed"
>
> 200k routes, here we come!
it is just
On Wed, 19 Oct 2005, Brandon Butterworth wrote:
> "Gartner said every location that requires mission-critical
> internet connectivity, including externally hosted
> websites, should be multi-homed"
200k routes, here we come!
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
On Wed, Oct 19, 2005 at 03:48:09PM +0100, Brandon Butterworth wrote:
>
> "Firms must defend against ISP clashes, warns Gartner
> Commercial row between ISPs shows vulnerability of single sourcing
> says analyst"
> http://www.computerweekly.com/Articles/Article.aspx?liArticleID=212391
>
> Look
On Oct 19, 2005, at 9:39 AM, [EMAIL PROTECTED] wrote:
Why is it that whenever people suggest that the IP networking
world can learn from the experience of the telephony world,
some people assume that the proposal is to imitate the telephony
world in every detail?
Seems to me to be a species
"Firms must defend against ISP clashes, warns Gartner
Commercial row between ISPs shows vulnerability of single sourcing
says analyst"
http://www.computerweekly.com/Articles/Article.aspx?liArticleID=212391
Looks like it's about to enter the corporate rule book
"Gartner said every location tha
> Survey says... BZT.
Yaur argument is fallacious.
> Read about SS7 LNP implementation before speaking, please.
I never said anything about SS7 implementation of LNP.
> They are very different creatures. Something that resembles telephony
LNP
> will not scale to the quantity of micro-st
Elmer:
You are not cooking for the routing table (hence loss of information).
You are cooking for the forwarding entries in the line cards..
As to architectural discussion, I believe the IRTF is publishing work
from
On NG architecture. I'll be glad to send you pointers. 2 panels of
routing exp
On Wed, 19 Oct 2005, [EMAIL PROTECTED] wrote:
> > Again, phone numbers and their portability can and should not be
> > compared with the IP address portability issues. They're very
> > different animals.
>
> That's your elephant. My elephant looks different.
Survey says... BZT.
Read about
On Wed, 19 Oct 2005, Andre Oppermann wrote:
the rationale behind MPLS. However here we need something that
administratively and politically works inter-AS like prefix+BGP
today. Maybe the new 32bit AS number may serve as such a perfect
match routing identifier.
Interesting idea.
That'd m
On Wed, 2005-10-19 at 09:31 +0200, Elmar K. Bins wrote:
> Susasn,
>
> > Using the compression ("cooking") per router can provide one level of
> > abstraction [reduction of prefix space] at router. So cooking down your
> > Large number of routes to a "minimum" set of routes can provide some
> > l
Tony Li wrote:
Andre,
capacity = prefix * path * churnfactor / second
capacity = prefixes * packets / second
I think it is safe, even with projected AS and IP uptake, to assume
Moore's law can cope with this.
This one is much harder to cope with as the number of prefixes and
the link sp
[EMAIL PROTECTED] (Andre Oppermann) wrote:
> >Apart from that, IMHO cooking down the prefixes only buys time, but does
> >not solve the problem. More people will multihome, and with the current
> >mechanisms and routing cloud, they have to do it by injecting prefixes.
>
> And this won't change i
Elmar K. Bins wrote:
Susasn,
Using the compression ("cooking") per router can provide one level of
abstraction [reduction of prefix space] at router. So cooking down your
Large number of routes to a "minimum" set of routes can provide some
leverage against the prefix growth.
By cooking down
On Tue, 2005-10-18 at 15:52 -0700, David Conrad wrote:
> Hmm. Are the aliens who took the _real_ IETF and replaced it with
> what's there now going to give it back? :-)
>
Sure they'll hand it back ... when there is no more money to be made
from IETF-related technology and politicians no lon
> Again, phone numbers and their portability can and should not be
> compared with the IP address portability issues. They're very
> different animals.
That's your elephant. My elephant looks different.
Phone numbers and IP addresses are exactly the same.
They are numbers used to identify the l
> Obviously if the RIRs contacted the folks responsible for a given block
and
> were provided justification for its continued allocation, then it should
not
> be reclaimed. On the other hand, folks sitting on several class Bs and
not
> using them could have their blocks reclaimed trivially;
Susasn,
> Using the compression ("cooking") per router can provide one level of
> abstraction [reduction of prefix space] at router. So cooking down your
> Large number of routes to a "minimum" set of routes can provide some
> leverage against the prefix growth.
By cooking down the prefixes you
76 matches
Mail list logo
