Ok I've had a few responses on and off list on this but arent really getting
this idea, as I said tho I've not done this so perhaps thats where I'm missing
the crucial points..
1) It would only remove the must default clause if the provider either
stripped (or overrode) the local-as, or if
--- Stephen J. Wilcox [EMAIL PROTECTED]
wrote:
3) One advantage of using a public, albeit common,
customer ASN is that if a
customer has RIR-allocated space, those IPs will
make it onto the global
table, and will not suffer the filtering which may
be present for the
provider's own
In a message written on Thu, Dec 11, 2003 at 11:07:03PM +, Stephen J. Wilcox wrote:
Perhaps I'm missing something having not done this myself but why arent the
customers just using private ASNs? That would also remove the 'must default'
clause.
Not enough, customers already use them
On Thu, Dec 11, 2003 at 11:07:03PM +, Stephen J. Wilcox wrote:
Perhaps I'm missing something having not done this myself but why arent the
customers just using private ASNs? That would also remove the 'must default'
clause.
What if you have more customers than there are private ASNs?
--- Stephen J. Wilcox [EMAIL PROTECTED]
wrote:
Most (all) large ISP's have a customer ASN.
This allows a customer
to connect in multiple places, run BGP, and get
something approximating
real redundancy to that carrier. However, rather
than allocate one
ASN to each customer, all
The J vendor expects to see these this when receiving BGP routes,
there is a switch in their software to allow this to put the routes
into the forwarding table. Their explanation was that the RFC actually
said that it was the receiving hosts job to decide what to do with this
not that it
* [EMAIL PROTECTED] (Ben Crocker) [Tue 09 Dec 2003, 10:44 CET]:
[..]
In our case a customer using BGP to our network from the same AS in two
locations but not running an IGP between them (our's is not to reason
why and all that)
A commonly accepted definition of AS is as follows:-
| An
In a message written on Tue, Dec 09, 2003 at 03:13:12PM +0100, Niels Bakker wrote:
One cannot have discontiguous networks in the same ASN. It's pretty
simple: two routing policies, two ASes, two ASNs. Unfortunately you
weren't able to convince your customer of this.
This is simply not true,
* [EMAIL PROTECTED] (Leo Bicknell) [Tue 09 Dec 2003, 16:00 CET]:
In a message written on Tue, Dec 09, 2003 at 03:13:12PM +0100, Niels Bakker wrote:
One cannot have discontiguous networks in the same ASN. It's pretty
simple: two routing policies, two ASes, two ASNs. Unfortunately you
weren't
Hi.
Apologies if this posting is off topic.
I'd observed some loops in the AS Paths as seen by the Route-Views
routeserver.
In one particular snapshot -- about 2% of the paths involved such
loops.
Here are some examples.(taken from route-views).
11608 2914 1239 12064 22773
Jaideep Chandrashekar [EMAIL PROTECTED] writes:
Hi.
Apologies if this posting is off topic.
I'd observed some loops in the AS Paths as seen by the Route-Views
routeserver.
In one particular snapshot -- about 2% of the paths involved such
loops.
Here are some
On Mon, Dec 08, 2003 at 03:50:21PM -0500, Robert E. Seastrom wrote:
Jaideep Chandrashekar [EMAIL PROTECTED] writes:
[snip]
11608 2914 1239 12064 22773 12064 11836
1221 4637 1239 12064 22773 12064 11836
[snip]
In many (most?) these loops are intentional, and a result of playing
prepending
Joe Provo [EMAIL PROTECTED] writes:
While this is an explataion of the behavior, it should not be
an endorsement. Prepending someone else's AS is a bad practive.
Not only does it munge 'pure' research data, but fowls some
levels of peer evaluation [in the example, and as-701 connected
13 matches
Mail list logo
