From: Nick Shah (nshah@xxxxxxxxxxxxxx)
Date: Sat Jun 01 2002 - 23:42:27 GMT-3
Howard,
I agree with you completely. Perhaps I used the word *amuse* in a wrong way
(sorry, if I have offended you/Nigel in any way by that). I actually use BGP
in my day to day work life, and certainly do understand the workings (of
course, not at the level at which you would), but my sole purpose of finding
an alternative way was *exam/lab* purposes only. Or rather should I say, I
had a clue that I could use route-maps, but was lacking a *trigger/clue*
I agree with you in that the scenario I put forward was absolute bizarre,
bordering onto insanity. But prolly the same could be said about the lab
(who said, they test us on production scenarios).
Once again, I wont let the opportunity go to mention that I really
appreciate your understanding of subject matter and I really hold high
regards for your knowledge & input.
rgds
Nick
-----Original Message-----
From: Howard C. Berkowitz <hcb@gettcomm.com>
To: ccielab@groupstudy.com <ccielab@groupstudy.com>
Date: Sunday, 2 June 2002 11:43
Subject: Re: BGP conditional Advertisement
>>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