From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Fri Dec 05 2003 - 13:03:55 GMT-3
At 9:55 AM -0500 12/5/03, Bob Sinclair wrote:
>Howard,
>
>My reading of the portion of RFC 3065 quoted below would seem to be in
>accord with the Halabi's reference. Am I misreading it?
>
>quote>
>
> It shall be legal for a BGP speaker to advertise an unchanged
> NEXT_HOP and MULTI_EXIT_DISCRIMINATOR (MED) attribute to peers in a
> neighboring AS within the same confederation. In addition, the
> restriction against sending the LOCAL_PREFERENCE attribute to peers
> in a neighboring AS within the same confederation is removed. Path
> selection criteria for information received from members inside a
> confederation MUST follow the same rules used for information
> received from members inside the same autonomous system, as specified
> in [1].
>
>end quote.
I stand corrected as far as the current confederations RFC. Still,
I'll argue that while the restriction has been removed, it's still a
good idea. I believe the major motivations for doing confederations
is to gain greater policy control and isolation among the sub-AS. If
all you are trying to do is reduce the iBGP load in the "entire" AS,
that's what route reflectors are for. Both confederations and route
reflectors still need to be designed with care (talking real world,
not CCIE lab) with respect to RFC 3345 persistent route oscillation.
Leaking LOCAL_PREFERENCE defeats the goal of isolation. If you
really want to transfer a particular LOCAL_PREFERENCE, say, just to
the sub-AS, I would define a community that is interpreted by the
receiving AS to set a local preference on a route. On that same
route (or NLRI if you prefer), you can use additional communities
like LOCAL-AS or NO-EXPORT to give a much better control of the scope
of propagation.
I'd also observe that there's no good way to tell, during
troubleshooting, if you have a leaked LOCAL_PREFERENCE or one
generated in the true local AS.
This may be worth a search of the archived IETF IDR Working Group,
leading up to 3065, to see the rationale for removing the
restriction. I've definitely seen cases where it's pointed out, in
the IETF, that a given draft or RFC is somewhat vague about whether
something is permitted or not. The philosophy of "be conservative in
what you send, be liberal in what you receive" then is invoked to say
that someone, sometime, might want to send you something you should
understand if you receive it -- but not necessarily that it's a good
idea to be able to send it. I could be wrong, and find someone did
propose a viable reason to want to do this.
In fairness to everyone in this thread, I have the impression that
the original question came up more in the context of a practice
scenario, with the intent of finding out if you COULD do something
with IOS commands.
My perspective on BGP is often more from "does this make sense to do
in the real world" than "is it something that might appear in the
CCIE lab." I dearly hope that Cisco, someday, at least relaxes the
static/default route restrictions in the ISP CCIE lab, if for no
other reason than blackhole routes to advertise aggregates. Very
often, the way I look at a proposed BGP behavior is "could I express
this routing policy either informally or, preferably, in the Routing
Policy Specification Language." Then, I'll ask, what problem would
implementing such a policy serve?
>
>----- Original Message -----
>From: "Howard C. Berkowitz" <hcb@gettcomm.com>
>To: <ccielab@groupstudy.com>
>Sent: Friday, December 05, 2003 9:10 AM
>Subject: Re: The bgp confederation peers as-number [... as-number] command
>
>
>> At 10:29 PM -0500 12/4/03, Bob Sinclair wrote:
>> >CCIE2B,
>> >
>> >Doyle V2 is the only reference I can find that explicitly says that you
>only
>> >have to include sub-AS's with with you actually peer (page 289). If a
>> >particular router does not peer with a router in another sub-AS, then it
>> >does not need to list that sub-AS in the confederation peer statement.
>This
>> >makes sense given Halabi's explanation of this command:
>> >
>> >quote from page 421>
>> >
>> >RTG uses the router command bgp confederation peers 65060 to preserve all
>> >the attributes, such as local preference and next hop when traversing the
>> >EBGP session to AS 65060
>> >
>> >end quote.
>>
>> I'm a little confused by that quote. next_hop is a mandatory
>> attribute, but local preference shouldn't go outside the sub-AS.
>> Even between sub-AS, you should be using MED or other preference
>> setting mechanisms such as communities with route maps.
>>
>> >
>> >In other words, the command qualifies a peer statement. If there is no
>peer
>> >statement to a given sub-AS, then there is no need to qualify it.
>> >
>> >Hope that helps,
>> >
>> >-Bob Sinclair
>> > CCIE #10427, CISSP, MCSE
>> > bsinclair@netmasterclass.net
>> >
>> >
>> >----- Original Message -----
>> >From: "ccie2be" <ccie2be@nyc.rr.com>
>> >To: "kasturi cisco" <kasturi_cisco@hotmail.com>; <ccielab@groupstudy.com>
>> >Sent: Wednesday, December 03, 2003 8:50 AM
>> >Subject: Re: The bgp confederation peers as-number [... as-number]
>command
>> >
>> >
>> >> Hi Kasturi,
>> >>
>> >> Thanks for your response. I think, however, you didn't quite
>understand
>> >what
>> >> I was asking.
>> >>
>> >> What you said is correct but doesn't address the question I had. My
>> >question
>> >> was which sub AS's should be specified with this command. There are 2
>> >> possible choices: List all sub AS's in the confed or list just those
>sub
>> >AS's
>> >> to which the router is peering.
>> >> ----- Original Message -----
>> >> From: kasturi cisco
>> >> To: ccie2be@nyc.rr.com ; ccielab@groupstudy.com
>> >> Sent: Wednesday, December 03, 2003 8:08 AM
>> >> Subject: RE: The bgp confederation peers as-number [... as-number]
>> >command
>> >>
>> >>
>> >> Hi,
>> >>
>> >> The way i have used it and seen it being used is follows:
>> >>
>> >> If there is a Confed with multiple Sub-As then the confed peers is
>for
>> >> routers which have another Sub As peer. Routers within confed-sub-As
>> >and/or
>> >> routers with no peering to another sub AS need not use the command.
>> >>
> > > > As always correct me if needed.
This archive was generated by hypermail 2.1.4 : Sat Jan 03 2004 - 08:25:36 GMT-3