Mailing List Archive

[nsp] Methods for Non-BGP multihoming
Given the shakiness of WorldCom, I'm looking into implementing multihoming
for our internet connection. Currently leaning towards a metro ethernet
provider.

I've read a couple of Avi Freedman's BGP tutorials as well as a number of
documents from Cisco (BGP Case Studies, the ISPCon BGP presentation,
Configurations for Load Sharing with BGP in Single and Multihomed
Environments, etc). I feel like I've got a basic grasp of BGP but for
simplicity's sake I'm still inclined to go with the option of taking static
routes from each ISP and allowing them each to advertise our /16. I'm not
interested in load-balancing, only redundancy.

If both ISPs were to advertise our /16 address space (registered by us, not
an ISP), we wouldn't necessarily need an AS number, would we? Given that we
wouldn't be actually talking BGP with anybody and the ISPs would be
handling the route advertisements. We'd put a metric on our static routes
outbound so only one link would be used unless it failed.

Are there any serious gotchas to this sort of approach? Outbound routing
would be very simple, but I'm wondering about the logistics of having ISP A
and ISP B both advertising routes. When traffic comes inbound to our
network, is there any way to make sure that one provider is always used?
Does it even matter? It's the issue of how traffic finds its way to your
network when you're multihomed that I'm not quite clear on.

If any body knows a better way to do this, I'd be happy to hear about it.
I'm also curious about the pros and cons of running BGP with limited
routing tables or even BGP with full routing tables. At this point the
primary benefit of running full BGP appears to be improved visibility into
traffic patterns and easier troubleshooting.

thanks much,
-carl hirsch
RE: [nsp] Methods for Non-BGP multihoming [ In reply to ]
Comments inline.

-D

> -----Original Message-----
> From: cisco-nsp-admin@puck.nether.net
> [mailto:cisco-nsp-admin@puck.nether.net]On Behalf Of
> CARL.P.HIRSCH@sargentlundy.com
> Sent: Tuesday, July 23, 2002 12:36 PM
> To: cisco-nsp@puck.nether.net
> Subject: [nsp] Methods for Non-BGP multihoming
>
>
> Given the shakiness of WorldCom, I'm looking into
> implementing multihoming
> for our internet connection. Currently leaning towards a
> metro ethernet
> provider.
>
> I've read a couple of Avi Freedman's BGP tutorials as well as
> a number of
> documents from Cisco (BGP Case Studies, the ISPCon BGP presentation,
> Configurations for Load Sharing with BGP in Single and Multihomed
> Environments, etc). I feel like I've got a basic grasp of BGP but for
> simplicity's sake I'm still inclined to go with the option of
> taking static
> routes from each ISP and allowing them each to advertise our
> /16. I'm not
> interested in load-balancing, only redundancy.
>
> If both ISPs were to advertise our /16 address space
> (registered by us, not
> an ISP), we wouldn't necessarily need an AS number, would we?
> Given that we
> wouldn't be actually talking BGP with anybody and the ISPs would be
> handling the route advertisements. We'd put a metric on our
> static routes
> outbound so only one link would be used unless it failed.
>
> Are there any serious gotchas to this sort of approach?
> Outbound routing
> would be very simple, but I'm wondering about the logistics
> of having ISP A
> and ISP B both advertising routes. When traffic comes inbound to our
> network, is there any way to make sure that one provider is
> always used?
> Does it even matter? It's the issue of how traffic finds its
> way to your
> network when you're multihomed that I'm not quite clear on.
>

It is generally preferred to avoid asymetric routes, as this can confuse
higher layer protocols (different delay on incomming and outgoing
traffic).

One solution would be to have the backup provider pad their announcement
of your address (they would list their AS multiple times when announcing
the route). Given that essentially everyone uses AS path length to make
routing decisions, this usually works- that is, everyone sends the
traffic to the upstream with the non-padded path.

I would reccomend padding the AS path at least four or five times. I
would also reccomend asking your service provider if they provide this
service before you agree to a contract with them :^)


> If any body knows a better way to do this, I'd be happy to
> hear about it.

Plenty of options exist, especially if you are an outgoing only (all
traffic originates from inside your network) or if you are an
outgoing/small number of servers.

But given that you have a /16, I doubt that, and also you will likely
have little problem getting people to listen to the announcement for a
/16.

> I'm also curious about the pros and cons of running BGP with limited
> routing tables or even BGP with full routing tables. At this point the
> primary benefit of running full BGP appears to be improved
> visibility into
> traffic patterns and easier troubleshooting.

Well, you would also get to use both connections for traffic and the
likely improved performance of that. At least in the case of full
tables.

>
> thanks much,
> -carl hirsch
>
> _______________________________________________
> cisco-nsp mailing list
> cisco-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/cisco-nsp
>
>

-- Darren Bolding darren@bolding.org --
-- --
Re: [nsp] Methods for Non-BGP multihoming [ In reply to ]
On Tue, 23 Jul 2002 14:36:26 -0500 CARL.P.HIRSCH@sargentlundy.com wrote:
> I've read a couple of Avi Freedman's BGP tutorials as well as a number of
> documents from Cisco (BGP Case Studies, the ISPCon BGP presentation,
> Configurations for Load Sharing with BGP in Single and Multihomed
> Environments, etc). I feel like I've got a basic grasp of BGP but for
> simplicity's sake I'm still inclined to go with the option of taking
> static
> routes from each ISP and allowing them each to advertise our /16. I'm not
> interested in load-balancing, only redundancy.
>
> If both ISPs were to advertise our /16 address space (registered by us,
> not
> an ISP), we wouldn't necessarily need an AS number, would we?

Correct. However, this would give you no direct control over your BGP
advertisments. This would mean that if a provider has problems that don't
result in BGP dropping you'd either have to shut down the physical link
completely or contact them to stop advertising /16 which would take time.

There's also no guarantee that they'll set their routers up to correctly
stop advertising your /16 if the physical link drops, which could give you
problems.

> When traffic comes inbound to our
> network, is there any way to make sure that one provider is always used?

To prevent the 'net as a whole sending traffic down one link, it just needs
to be advertised with a long AS path length. The accepted way of doing this
is to prepend your own (Or your providers) AS number to the AS path three
or so times to make it seem artificially longer.

Within the ISPs you're connected to, they often prefer customer routes over
peering/transit routes regardless of AS-path length. If you're talking BGP
to the provider you can often set BGP communities to influence the
localpref set by the provider and change this behaviour but if you're not
talking BGP to them you'd have to ask them to do this for you, if they can.

> Does it even matter? It's the issue of how traffic finds its way to your
> network when you're multihomed that I'm not quite clear on.

It's a matter of personal taste. An Active/Passive failover setup means
that there's less points of failure but you might not spot problems with
the backup link until it's too late whereas the reverse is true for an
active/active setup.

> If any body knows a better way to do this, I'd be happy to hear about it.

If you don't want to get an AS number, you could talk BGP to your upstreams
using a private AS number and then have them filter that AS number. If
memory or processor power is a problem you need only take a default route
from both the providers. (You can just filter everything else even if they
do send it) This isn't *quite* as robust as a full feed but it's still
pretty good and you can eaisly alter metrics to change which provider is
preferred for traffic.

--
Ryan O'Connell - CCIE #8174
<ryan@complicity.co.uk> - http://www.complicity.co.uk

I'm not losing my mind, no I'm not changing my lines,
I'm just learning new things with the passage of time
Re: [nsp] Methods for Non-BGP multihoming [ In reply to ]
On Tue, 23 Jul 2002 CARL.P.HIRSCH@sargentlundy.com wrote:
...
> If both ISPs were to advertise our /16 address space (registered by us, not
> an ISP), we wouldn't necessarily need an AS number, would we? Given that we
> wouldn't be actually talking BGP with anybody and the ISPs would be
> handling the route advertisements. We'd put a metric on our static routes
> outbound so only one link would be used unless it failed.
>
> Are there any serious gotchas to this sort of approach? Outbound routing
> would be very simple, but I'm wondering about the logistics of having ISP A
> and ISP B both advertising routes. When traffic comes inbound to our
> network, is there any way to make sure that one provider is always used?
> Does it even matter? It's the issue of how traffic finds its way to your
> network when you're multihomed that I'm not quite clear on.
>

This configuration make your route inconsistent in the routing table since
the /16 will have 2 origins ASN. I'm not sure yours providers allow you to
do that.

A.
Re: [nsp] Methods for Non-BGP multihoming [ In reply to ]
On Tue, 23 Jul 2002 CARL.P.HIRSCH@sargentlundy.com wrote:
> Given the shakiness of WorldCom, I'm looking into implementing multihoming
> for our internet connection. Currently leaning towards a metro ethernet
> provider.
>
> I've read a couple of Avi Freedman's BGP tutorials as well as a number of
> documents from Cisco (BGP Case Studies, the ISPCon BGP presentation,
> Configurations for Load Sharing with BGP in Single and Multihomed
> Environments, etc). I feel like I've got a basic grasp of BGP but for
> simplicity's sake I'm still inclined to go with the option of taking static
> routes from each ISP and allowing them each to advertise our /16. I'm not
> interested in load-balancing, only redundancy.
>
> If both ISPs were to advertise our /16 address space (registered by us, not
> an ISP), we wouldn't necessarily need an AS number, would we? Given that we
> wouldn't be actually talking BGP with anybody and the ISPs would be
> handling the route advertisements. We'd put a metric on our static routes
> outbound so only one link would be used unless it failed.
>
> Are there any serious gotchas to this sort of approach? Outbound routing
> would be very simple, but I'm wondering about the logistics of having ISP A
> and ISP B both advertising routes. When traffic comes inbound to our
> network, is there any way to make sure that one provider is always used?
> Does it even matter? It's the issue of how traffic finds its way to your
> network when you're multihomed that I'm not quite clear on.
>
> If any body knows a better way to do this, I'd be happy to hear about it.
> I'm also curious about the pros and cons of running BGP with limited
> routing tables or even BGP with full routing tables. At this point the
> primary benefit of running full BGP appears to be improved visibility into
> traffic patterns and easier troubleshooting.

Yes, there are serious problems with this w.r.t. real failover and
stability.

The best solution considering the requirements is to run BGP with private
AS numbers to your ISP's and have them remove them in the advertisements.
That way you can have control on outbound/inbound traffic but don't need
an ASN.

--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
RE: [nsp] Methods for Non-BGP multihoming [ In reply to ]
>The best solution considering the requirements is to run BGP with private
>AS numbers to your ISP's and have them remove them in the advertisements.
>That way you can have control on outbound/inbound traffic but don't need
>an ASN.

If you are multihomed, most ISPs will not allow you to use a private AS, as
that will result in inconsistent originations for the prefix.

If you are going to use BGP in a multihomed situation, you will want to have
your own AS.

-andrew
RE: [nsp] Methods for Non-BGP multihoming [ In reply to ]
On Thu, 25 Jul 2002, Elliott, Andrew wrote:
> >The best solution considering the requirements is to run BGP with private
> >AS numbers to your ISP's and have them remove them in the advertisements.
> >That way you can have control on outbound/inbound traffic but don't need
> >an ASN.
>
> If you are multihomed, most ISPs will not allow you to use a private AS, as
> that will result in inconsistent originations for the prefix.
>
> If you are going to use BGP in a multihomed situation, you will want to have
> your own AS.

AFAIK it's perfectly acceptable to have a prefix with multiple origins.

--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Re: [nsp] Methods for Non-BGP multihoming [ In reply to ]
% On Thu, 25 Jul 2002, Elliott, Andrew wrote:
% > >The best solution considering the requirements is to run BGP with private
% > >AS numbers to your ISP's and have them remove them in the advertisements.
% > >That way you can have control on outbound/inbound traffic but don't need
% > >an ASN.
% >
% > If you are multihomed, most ISPs will not allow you to use a private AS, as
% > that will result in inconsistent originations for the prefix.
% >
% > If you are going to use BGP in a multihomed situation, you will want to have
% > your own AS.
%
% AFAIK it's perfectly acceptable to have a prefix with multiple origins.
%
% --
% Pekka Savola "Tell me of difficulties surmounted,

Its just a real pain to distinguish legit use of this tactic
from route theft. So while it's technically ok, its a tool
you want to be -very- careful with.

--
--bill
Re: [nsp] Methods for Non-BGP multihoming [ In reply to ]
On Fri, Jul 26, 2002 at 08:48:42AM +0300, Pekka Savola wrote:
> On Thu, 25 Jul 2002, Elliott, Andrew wrote:
> > >The best solution considering the requirements is to run BGP with private
> > >AS numbers to your ISP's and have them remove them in the advertisements.
> > >That way you can have control on outbound/inbound traffic but don't need
> > >an ASN.
> >
> > If you are multihomed, most ISPs will not allow you to use a private AS, as
> > that will result in inconsistent originations for the prefix.
> >
> > If you are going to use BGP in a multihomed situation, you will want to have
> > your own AS.
>
> AFAIK it's perfectly acceptable to have a prefix with multiple origins.

No.

--
Joe Provo Voice 508.486.7471
Director, Internet Planning & Design Fax 508.229.2375
Network Deployment & Management, RCN <joe.provo@rcn.com>
Re: [nsp] Methods for Non-BGP multihoming [ In reply to ]
Joe is right that is a big no no. The same prefix can not originate from
two different ASs as that would cause routing loop etc. So a public AS
and registration for RADB is just about mandatory for a multi-homed ISP.

On Fri, 2002-07-26 at 10:43, Joe Provo wrote:
> On Fri, Jul 26, 2002 at 08:48:42AM +0300, Pekka Savola wrote:
> > On Thu, 25 Jul 2002, Elliott, Andrew wrote:
> > > >The best solution considering the requirements is to run BGP with private
> > > >AS numbers to your ISP's and have them remove them in the advertisements.
> > > >That way you can have control on outbound/inbound traffic but don't need
> > > >an ASN.
> > >
> > > If you are multihomed, most ISPs will not allow you to use a private AS, as
> > > that will result in inconsistent originations for the prefix.
> > >
> > > If you are going to use BGP in a multihomed situation, you will want to have
> > > your own AS.
> >
> > AFAIK it's perfectly acceptable to have a prefix with multiple origins.
>
> No.
>
> --
> Joe Provo Voice 508.486.7471
> Director, Internet Planning & Design Fax 508.229.2375
> Network Deployment & Management, RCN <joe.provo@rcn.com>
> _______________________________________________
> cisco-nsp mailing list real_name)s@puck.nether.net
> http://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
Re: [nsp] Methods for Non-BGP multihoming [ In reply to ]
On Fri, 26 Jul 2002 10:43:16 -0400 Joe Provo <joe.provo@rcn.com> wrote:
> On Fri, Jul 26, 2002 at 08:48:42AM +0300, Pekka Savola wrote:
> > AFAIK it's perfectly acceptable to have a prefix with multiple origins.
>
> No.

Opinions seem divided on this topic - some ISPs will let you do it, others
don't. I've never heard of anyone that'd had any real operational
difficuties once they've convinced the ISPs concerned to do this however.

The limitations, as far as I'm aware, are with BGP support tools and
technologies like RIPE-181/RADB rather than BGP itself.

--
Ryan O'Connell - CCIE #8174
<ryan@complicity.co.uk> - http://www.complicity.co.uk

I'm not losing my mind, no I'm not changing my lines,
I'm just learning new things with the passage of time
Re: [nsp] Methods for Non-BGP multihoming [ In reply to ]
On Fri, Jul 26, 2002 at 06:33:23PM +0100, Ryan O'Connell wrote:
> On Fri, 26 Jul 2002 10:43:16 -0400 Joe Provo <joe.provo@rcn.com> wrote:
> > On Fri, Jul 26, 2002 at 08:48:42AM +0300, Pekka Savola wrote:
> > > AFAIK it's perfectly acceptable to have a prefix with multiple origins.
> >
> > No.
>
> Opinions seem divided on this topic - some ISPs will let you do it, others
> don't. I've never heard of anyone that'd had any real operational
> difficuties once they've convinced the ISPs concerned to do this however.
>
> The limitations, as far as I'm aware, are with BGP support tools and
> technologies like RIPE-181/RADB rather than BGP itself.

"No" is WRT "perfectly acceptable".

Some ISPs wouldn't notice if it were going on either, but that doesn't
make it right. "limitation" is NOT the correct word here. There's a
lot of things one can do that will "work" in IP in general, let alone
with BGP, but they are still not "perfectly acceptable".

Inconsistant origin AS => anycast beyond a routing domain scope - it
undermines any hope of deterministic behavior. It is perfectly
reasonable to presume that today's providers will throw away such
routing trash as potential hijacks. Or that tomorrow's implementations
could address the ambiguity in the spec and vendors give a knob (as
was done with the ambiguity nature of a null MED) such as "bgp
discard-inconsistent-as".

What is a remote AS supposed to decide for the proper path? It is
indeterminate and potentially flappy. As such, you have just given up
control and degraded your reachability. In my design playbook, one
strives to maximize one's reachability; if one is relying on protocol
ambiguities that can & should be filled or provider mistakes, then
one is setting up for a rude awakening.

To get back to the subject, non-BGP multihoming through provider-
specific space and NAT has been successfully deployed for years,*
without relying on spec ambiguities or any vendors' implementations
(or bugs). As such you can expect it to continure to work without
requiring a fire drill down the road.

Cheers,

Joe

* yes, yes NAT is not a universal solution. But it works well for many
leaf-node applications and if you're trying to avoid p;roper
multihoming, leaf-node is probably a good description.

--
Joe Provo Voice 508.486.7471
Director, Internet Planning & Design Fax 508.229.2375
Network Deployment & Management, RCN <joe.provo@rcn.com>
Re: [nsp] Methods for Non-BGP multihoming [ In reply to ]
On Fri, 26 Jul 2002 14:12:36 -0400 Joe Provo <joe.provo@rcn.com> wrote:
> On Fri, Jul 26, 2002 at 06:33:23PM +0100, Ryan O'Connell wrote:
> > Opinions seem divided on this topic - some ISPs will let you do it,
> > others don't. I've never heard of anyone that'd had any real operational
> > difficuties once they've convinced the ISPs concerned to do this
> > however.
>
> "No" is WRT "perfectly acceptable".

That depends on who decides what's "perfectly acceptable". I guess the
people on this list are a fair cross-section of those "in charge" on the
internet, so it would certainly be true to say it's not "perfectly
acceptable" as some people don't think it is.

> Inconsistant origin AS => anycast beyond a routing domain scope - it
> undermines any hope of deterministic behavior. It is perfectly
> reasonable to presume that today's providers will throw away such
> routing trash as potential hijacks.

I'm not aware of any that do, but ISPs do all sorts of things so I'm sure
there are some that do. Those that do should probably only throw away
the one not listed in the RADB - otherwise you're partially defeating the
purpose of doing it in the first place. It would be trivial to prepend the
victims AS onto an announcement to hijack anyway, so I'm not sure what
benefit you'd really get. I have no idea how many ISPs filter enough to
only accept $customer_as^ on announcements.

> Or that tomorrow's implementations
> could address the ambiguity in the spec and vendors give a knob (as
> was done with the ambiguity nature of a null MED) such as "bgp
> discard-inconsistent-as".

One would hope that if use of inconsistent-origin-as becomes widespread
that vendors wouldn't do this or at least that ISPs would not use it. I
can't see why anyone would want such a feature.

> What is a remote AS supposed to decide for the proper path? It is
> indeterminate and potentially flappy. As such, you have just given up
> control and degraded your reachability. In my design playbook, one
> strives to maximize one's reachability; if one is relying on protocol
> ambiguities that can & should be filled or provider mistakes, then
> one is setting up for a rude awakening.

BGP relies on AS-path length if all other things are equal - there's
no mention in the specification that origin ASes should be consistent nor
that routers should throw away such advertisments. Arguably, any
implementation that does is "broken".

> To get back to the subject, non-BGP multihoming through provider-
> specific space and NAT has been successfully deployed for years,*
> without relying on spec ambiguities or any vendors' implementations
> (or bugs). As such you can expect it to continure to work without
> requiring a fire drill down the road.
>
> * yes, yes NAT is not a universal solution. But it works well for many
> leaf-node applications and if you're trying to avoid p;roper
> multihoming, leaf-node is probably a good description.

I agree - for most situations, NAT is your friend. Particularly, if you
need less than a /20 of IP address space many ISPs won't listen to you
advertisments anyway. Unfortunatly, it's only effective if you only have
clients using the 'net, not servers, but it should be the first choice for
such situations.

--
Ryan O'Connell - CCIE #8174
<ryan@complicity.co.uk> - http://www.complicity.co.uk

I'm not losing my mind, no I'm not changing my lines,
I'm just learning new things with the passage of time
RE: [nsp] Methods for Non-BGP multihoming [ In reply to ]
RFC 1771 does indeed specify that inconsistant origin AS is an error state.

(snip)

>> BGP relies on AS-path length if all other things are equal - there's
> no mention in the specification that origin ASes should be consistent nor
> that routers should throw away such advertisments. Arguably, any
> implementation that does is "broken".
>
> > To get back to the subject, non-BGP multihoming through provider-
> > specific space and NAT has been successfully deployed for years,*
> > without relying on spec ambiguities or any vendors' implementations
> > (or bugs). As such you can expect it to continure to work without
> > requiring a fire drill down the road.
> >
> > * yes, yes NAT is not a universal solution. But it works well for many
> > leaf-node applications and if you're trying to avoid p;roper
> > multihoming, leaf-node is probably a good description.
>
> I agree - for most situations, NAT is your friend. Particularly, if you
> need less than a /20 of IP address space many ISPs won't listen to you
> advertisments anyway. Unfortunatly, it's only effective if you only have
> clients using the 'net, not servers, but it should be the first choice for
> such situations.
>

Almost every ISP will listen to less than a /20 announcement from a
customer. A few won't listed to less than a /20 from PEERs.


> --
> Ryan O'Connell - CCIE #8174
> <ryan@complicity.co.uk> - http://www.complicity.co.uk
>

- Daniel Golding
Re: [nsp] Methods for Non-BGP multihoming [ In reply to ]
> RFC 1771 does indeed specify that inconsistant origin AS is an error state.

Where does it say that?

Thanks,
Ray
Re: [nsp] Methods for Non-BGP multihoming [ In reply to ]
On Wed, 31 Jul 2002 14:05:49 -0400 Daniel Golding <dgolding@sockeye.com> wrote:
> RFC 1771 does indeed specify that inconsistant origin AS is an error
> state.

I just reread the RFC and I can't see that anywhere.

In fact, origin AS information is lost when AS_SEQUENCEs are converted to
AS_SETs from what I can tell so it would be difficult to enforce this anyway.

--
Ryan O'Connell - CCIE #8174
<ryan@complicity.co.uk> - http://www.complicity.co.uk

I'm not losing my mind, no I'm not changing my lines,
I'm just learning new things with the passage of time
Re: [nsp] Methods for Non-BGP multihoming [ In reply to ]
Some folks at Berkeley/ICSI wrote a paper on the subject:

http://www.icir.org/vern/imw-2001/imw2001-papers/88.pdf

Check out page 4, first column, last paragraph.

I read through 1771 and couldn't find Dan's specific reference.
In section 6.3 of RFC1771, the group states:

The AS_PATH attribute is checked for syntactic correctness. If the
path is syntactically incorrect, then the Error Subcode is set to
Malformed AS_PATH.

Syntactic correctness is not specifically defined.

Best,
Tim


On Fri, Aug 02, 2002 at 01:21:04PM +0200, Ray Davis wrote:
> > RFC 1771 does indeed specify that inconsistant origin AS is an error state.
>
> Where does it say that?
>
> Thanks,
> Ray
> _______________________________________________
> cisco-nsp mailing list real_name)s@puck.nether.net
> http://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

--
Re: [nsp] Methods for Non-BGP multihoming [ In reply to ]
Some folks at Berkeley/ICSI wrote a paper on the subject:

http://www.icir.org/vern/imw-2001/imw2001-papers/88.pdf

Check out page 4, first column, last paragraph.

I read through 1771 and couldn't find Dan's specific reference.
In section 6.3 of RFC1771, the group states:

The AS_PATH attribute is checked for syntactic correctness. If the
path is syntactically incorrect, then the Error Subcode is set to
Malformed AS_PATH.

Syntactic correctness is not specifically defined.

Best,
Tim


On Fri, Aug 02, 2002 at 01:21:04PM +0200, Ray Davis wrote:
> > RFC 1771 does indeed specify that inconsistant origin AS is an error state.
>
> Where does it say that?
>
> Thanks,
> Ray
> _______________________________________________
> cisco-nsp mailing list real_name)s@puck.nether.net
> http://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

--
RE: [nsp] Methods for Non-BGP multihoming [ In reply to ]
Actually, RFC 1930 has a more direct reference regarding inconsistent AS

http://asg.web.cmu.edu/rfc/rfc1930.html#sec-7


> -----Original Message-----
> From: Ryan O'Connell [mailto:ryan@complicity.co.uk]
> Sent: Friday, August 02, 2002 7:35 AM
> To: Daniel Golding; cisco-nsp@puck.nether.net; joe.provo@rcn.com
> Subject: Re: [nsp] Methods for Non-BGP multihoming
>
>
> On Wed, 31 Jul 2002 14:05:49 -0400 Daniel Golding
> <dgolding@sockeye.com> wrote:
> > RFC 1771 does indeed specify that inconsistant origin AS is an error
> > state.
>
> I just reread the RFC and I can't see that anywhere.
>
> In fact, origin AS information is lost when AS_SEQUENCEs are
> converted to
> AS_SETs from what I can tell so it would be difficult to
> enforce this anyway.

>
Re: [nsp] Methods for Non-BGP multihoming [ In reply to ]
I guess the author wasn't really sure either:

"Generally, a prefix can should belong to only one AS."
^^^^^^^^^^
:)

The statement in the RFC assumes that an IP address exists in only one
place. This isn't always true.

Probably the statement should be removed from the RFC since it doesn't
really say anything firm, gives no good reason and says it can and may
be otherwise anyway.

Cheers,
Ray

> Actually, RFC 1930 has a more direct reference regarding inconsistent AS
>
> http://asg.web.cmu.edu/rfc/rfc1930.html#sec-7
>
>
> > -----Original Message-----
> > From: Ryan O'Connell [mailto:ryan@complicity.co.uk]
> > Sent: Friday, August 02, 2002 7:35 AM
> > To: Daniel Golding; cisco-nsp@puck.nether.net; joe.provo@rcn.com
> > Subject: Re: [nsp] Methods for Non-BGP multihoming
> >
> >
> > On Wed, 31 Jul 2002 14:05:49 -0400 Daniel Golding
> > <dgolding@sockeye.com> wrote:
> > > RFC 1771 does indeed specify that inconsistant origin AS is an error
> > > state.
> >
> > I just reread the RFC and I can't see that anywhere.
> >
> > In fact, origin AS information is lost when AS_SEQUENCEs are
> > converted to
> > AS_SETs from what I can tell so it would be difficult to
> > enforce this anyway.
>
> >
> _______________________________________________
> cisco-nsp mailing list real_name)s@puck.nether.net
> http://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/