From: Howard C. Berkowitz (hcb@xxxxxxxxxxxx)
Date: Sat Jun 01 2002 - 22:03:38 GMT-3
>Nigel/Howard,
>
>Thanks for your answers/insights.
>
>No, this scenario is *not* a practical scenario, I havent even come across
>it anywhere. There isnt anything in particular that I am trying to acheive
>here, except trying to know "how many ways to change a light bulb" thats
>all.
>
>I am sorry, if my excuse doesnt amuse you. I think Advertise-map, etc.
>feature is a relatively new one, which made me think if I could acheive it
>in some other way, and hence the Question.
Nick, let me offer some very sincere advice. I didn't get proficient
in BGP until I understood how to describe more abstract routing
policies, first with RIPE-181 and then with RPSL, followed by looking
at real-world routing policies and case studies. Only then did the
light really go on in terms of what you can and cannot do with BGP.
If you want to have a real understanding of BGP, get an understanding
of routing policy and THEN do the "how many ways to configure" thing.
You see, many of the BGP knobs are intended to carry out something
specific in routing policy. Another way of stating that is that
there was a reason for introducing a capability. When you know what
the capability was that motivated a command being placed in IOS,
you'll have a much better understanding of the use of the command.
The nature of BGP networks of any real scalability requires a great
deal of attention to scoping the propagation of routes. The general
goal is to see how little information you can advertise, rather than
how much.
I was not looking for amusement in my answer to you. I was
attempting to share how I began getting a real understanding of a
complex subject, and hopefully to save you from some blind alleys
that I wandered into. This response is a further attempt to get that
idea across.
>
>Nigel, thanks for you answer. I will lab it up and check (prima facie, it
>seems that it will succeed).
>
>rgds
>Nick
>-----Original Message-----
>From: Nigel Taylor <nigel_taylor@hotmail.com>
>To: ccielab@groupstudy.com <ccielab@groupstudy.com>
>Date: Sunday, 2 June 2002 9:23
>Subject: Re: BGP conditional Advertisement
>
>
>>Nick,
>> I understand what it is you're trying to accomplish by trying to
>>find another way to perform BGP conditional route advertising.
>>However, as Howard points out the question would be why? I've looked at
>the
>>scenario you've posted and based on the information
>>you provided, I don't see how we can get the BGP process in RtrC to
>>conditionally source the Y/24 network, without some type of
>>tracking of routes in the BGP table. You mentioned the goal is to
>>accomplish this without specifically using the
>>"advertise-map & non-exist-map" neighbor command. The only other options
>>left would be using filter-list, distribute-list, and route-maps
>>which would be static configurations.
>>
>>I did some thinking and it came to me that maybe the only other way I could
>>think of to accomplish this would be to, identify the X/24 route being
>>received from RtrA at RtrC using a route-map and setting a community string
>>on the X/24 route. Then under the bgp process of RtrC you could
>>use the "network" command with a "route-map" to set another community
>string
>>for the Y/24 route. Lastly you could set and outbound route-map
>>to RtrB(on RtrC) using the 'no-advertise" attribute to filter the Y/24
>route
>>based on if the X/24(community) route is present or not.
>>
>>Nigel
>>
>>
>>----- Original Message -----
>>From: "Howard C. Berkowitz" <hcb@gettcomm.com>
>>To: <ccielab@groupstudy.com>
>>Sent: Saturday, June 01, 2002 2:54 PM
>>Subject: Re: BGP conditional Advertisement
>>
>>
>>> At 7:08 PM +1000 6/1/02, Nick Shah wrote:
>>> >Nigel,
>>> >
>>> >All routers are running in different AS's
>>> >
>>> >No IGP's running between all of the 3 routers.
>>> >
>>> >X/24 is being originated from RtrA
>>> >y/24 is to be *conditionally * originated by RtrC (if RtrC stops
>>receiving
>>> >X/24 from RtrA)
>>>
>>> I, too, don't quite have enough detail to give a definitive answer,
> >> particularly as to where y/24 is and how router C knows about it.
>>>
>>> What is the address relationship between x and y? What problem are
>>> you trying to solve? This doesn't seem a plausible backup scenario,
>>> unless y is an alternate address that will be tried in recovery by a
>>> host connected to rtrB.
>>>
>>> Approaches that might be considered include making the next hop in C
>>> for y primarily dependent on the reachability of a next hop in A.
>>> Another approach might be to use outbound route filtering in B to C,
>>> in which B tells C not to advertise y as long as it is receiving x
>>> originated by A.
>>>
>>> >
>>> >thanks
>>> >Nick
>>> >-----Original Message-----
>>> >From: Nigel Taylor <nigel_taylor@hotmail.com>
>>> >To: ccielab@groupstudy.com <ccielab@groupstudy.com>
>>> >Date: Saturday, 1 June 2002 3:43
>>> >Subject: Re: BGP conditional Advertisement
>>> >
>>> >
>>> >>Nick,
>>> >> I have a couple of questions?
>>> >>
>>> >>1. What AS's are the 3 routers in? could you be more specific.
>>> >>2. The X and Y routes where do they originate? both from RtrA, X from
>>> >RtrA,
>>> >>Y from RtrC?
>>> >>3. Are there any IGPs running between all the routers.
>>> >>
>>> >>Nigel
>>> >>
>>> >>----- Original Message -----
>>> >>From: "Nick Shah" <nshah@connect.com.au>
>>> >>To: <ccielab@groupstudy.com>
>>> >>Sent: Friday, May 31, 2002 11:11 PM
>>> >>Subject: BGP conditional Advertisement
>>> >>
>>> >>
>>> >>> Guys,
>>> >>>
>>> >>> I am trying to achieve a behaviour similar to BGP conditional
>>> >>advertisement
>>> >>> *without* using non-exist-map and/or advertise-map. Basically ...
>>> >>>
>>> >>> RtrA ------- RtrC-----------RtrB
>>> >>>
>>> >>> RtrA advertises route X/24 to RtrC under normal circumstances, when
>>RtrC
>>> >>is
>>> >>> receiving X/24 from RtrA it suppresses the advertisement of Y/24
>>(doesnt
>>> >>> advertise) to RtrB.
>>> >>> But if RtrA stops sending prefix X/24 to RtrC, RtrC starts sending
>>Y/24
>>> >to
>>> >>> RtrB.
>>> >>>
> >> >>> All this to be done *without* using advertise-map & non-exist-map
This archive was generated by hypermail 2.1.4 : Tue Jul 02 2002 - 08:12:20 GMT-3