From: Koen Zeilstra (koen@koenzeilstra.com)
Date: Wed Oct 24 2007 - 05:48:20 ART
This works for me. Thanks!!!
Quoting Con Spathas <con@spathas.net>:
> I was thinking about the BGP config I initially tested with and I really
> didn't like it tbh...
> I've quickly labbed this up and appears to have the same functionality in
> conjunction with the tracked obbjects etc...
> It's alot safer than using a network statement...
>
> Just modified the bgp config and added a prefix-list/route-map combo.
>
> ---------------------
> !
> track 1 list boolean and
> object 2
> object 3
> !
> track 2 ip route 1.1.1.0 255.255.255.0 reachability
> !
> track 3 ip route 2.2.2.0 255.255.255.0 reachability
> !
> interface Loopback1
> ip address 1.1.1.1 255.255.255.0
> !
> interface Loopback2
> ip address 2.2.2.2 255.255.255.0
> !
> interface FastEthernet0/0
> ip address 100.100.100.1 255.255.255.0
> duplex auto
> speed auto
> !
> router bgp 100
> no synchronization
> bgp log-neighbor-changes
> neighbor 100.100.100.2 remote-as 100
> neighbor 100.100.100.2 default-originate route-map CHECK_DEFAULT
> no auto-summary
> !
> ip route 0.0.0.0 0.0.0.0 Null0 track 1
> !
> ip prefix-list DEFAULT seq 5 permit 0.0.0.0/0
> !
> route-map CHECK_DEFAULT permit 10
> match ip address prefix-list DEFAULT
> !
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Usankin, Andrew
> Sent: Tuesday, 23 October 2007 18:42
> To: ccielab@groupstudy.com
> Subject: RE: RE: conditional default advertising in BGP with multiple routes
> tomonitor
>
> Works like a charm Con! Just got it labbed.
>
> You have cracked this one :)
> I'm taking my word back about "default-info originate", you don't need that
> if you use "network 0.0.0.0".
>
> Andrew
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Usankin, Andrew
> Sent: Tuesday, October 23, 2007 10:24 AM
> To: ccielab@groupstudy.com
> Subject: RE: RE: conditional default advertising in BGP with multiple routes
> tomonitor
>
>
> Perfect! I'm going to lab it right away to se how it works.
>
> By the way you missed one command in router bgp 100:
> default-information originate.
>
> Anyway thanks for advise Con!
>
> Andrew
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Con
> Spathas
> Sent: Tuesday, October 23, 2007 2:31 AM
> To: 'Koen Zeilstra'; 'Benedict Munyao'
> Cc: ccielab@groupstudy.com
> Subject: RE: RE: conditional default advertising in BGP with multiple routes
> tomonitor
>
> Thought I'd kick my $0.02 in - imho I don't think I'd ever use this possible
> solution in production but kinda fun in a lab - however here
> goes:
>
> I setup BGP peering with 2 routers - R1 <-> R2.
> The goal - have R1 only send R2 a 0/0 via BGP if 2 seperate routes were
> reachable on R1.
>
> On R1 I setup a boolean track and added a static route for 0/0 to null
> watching the boolean track.
>
> !
> track 1 list boolean and
> object 2
> object 3
> !
> ip route 0.0.0.0 0.0.0.0 Null0 track 1
> !
>
> The 2 track objects (2 & 3) are just 2 connected interfaces - but I suppose
> you could track anything in the the routing table:
>
> !
> track 2 ip route 1.1.1.0 255.255.255.0 reachability
> !
> track 3 ip route 2.2.2.0 255.255.255.0 reachability !
>
> Finally I setup BGP - the iffy part here is getting 0/0 into the bgp table
> so I added the 0.0.0.0 network to keep it simple.
>
> !
> router bgp 100
> no synchronization
> bgp log-neighbor-changes
> network 0.0.0.0
> neighbor 100.100.100.2 remote-as 1000
> no auto-summary
> !
>
> Careful filtering would need to be in place to even consider doing something
> like this in production.
> Imagine the potential havoc if you unleashed a 0/0 into BGP!!!! <grin>
>
> So now if I kill either of the 1.1.1.0/24 or the 2.2.2.0/24 networks on
> R1 - the static 0/0 route will be withdrawn from the routing table and thus
> the bgp table.
> This in turn will cause BGP to withdraw the 0/0 route to R2. Therefore both
> tracked routes must be reachable before the 0/0 gets sent to the neighbor.
>
> Anyhow with the limited testing I did it seems like a possible solution to
> the AND problem.
>
> Cheers.
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Koen
> Zeilstra
> Sent: Tuesday, 23 October 2007 07:38
> To: Benedict Munyao
> Cc: ccielab@groupstudy.com
> Subject: Re: RE: conditional default advertising in BGP with multiple routes
> tomonitor
>
> Correct. However for watching two routes this isn't a solution.
>
> Two match clauses in different subblocks cause the default to be announced
> when the first clause is a match. What we need is de default to be announced
> when BOTH match clauses have a positive match.
>
> Quoting Benedict Munyao <bmunyao@gmail.com>:
>
>> The first solution examined in this thread included using "neighbor
>> default-originate route-map" command. The Doccd clarifies why it only
>> uses the "or" logic when comparing the two ACLs:
>>
>> http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/
>> hirp_r/rte_pih.htm#wp1123413
>>
>> "Like matches in the same route map subblock are filtered with "or"
>> semantics. If any one match clause is matched in the entire route map
>> subblock, this match is treated as a successful match. Dissimilar
>> match clauses are filtered with "and" semantics. So dissimilar matches
>
>> are filtered logically. If the first set of conditions is not met, the
>
>> second match clause is filtered."
>>
>> HTH
>> Benedict Munyao
>>
>>
>>
>> On 10/19/07, Koen Zeilstra <koen@koenzeilstra.com> wrote:
>>>
>>> Balmik has email this nice solution to me which I would like to share
>
>>> with the group.
>>>
>>> Balmik, I hope you don't mind that I send this to the group.
>>>
>>> I have tested this on my lab and the results in various situations on
>
>>> different platforms
>>>
>>> Situation 1. It only checks line 10 of the route-map, and ignores the
>
>>> rest.
>>> Situation 2. It does a OR. So both routes have to dissapear to remove
>
>>> the default instead of one.
>>>
>>> From:
>>>
>>> http://www.cisco.com/en/US/products/ps6566/products_feature_guide0918
>>> 6a00801a7f7a.html#wp1038479
>>>
>>> I read that outbound BGP route-maps only are supported. I would say
>>> this is a outbound BGP route-map. The only different from standard
>>> advertisement is de conditional default. Maybe it is only intended
>>> for match and set operations on advertised routes.
>>>
>>>
>>>
>>> ----- Forwarded message from balmik@staff.iinet.net.au -----
>>> Date: Fri, 19 Oct 2007 14:07:49 +0800
>>> From: Balmik Soin <balmik@staff.iinet.net.au>
>>> Reply-To: Balmik Soin <balmik@staff.iinet.net.au>
>>> Subject: RE: conditional default advertising in BGP with multiple
>>> routes tomonitor
>>> To: Koen Zeilstra <koen@koenzeilstra.com>, Bob Sinclair
>>> <bob@bobsinclair.net>
>>> Cc: Saul Arjona <saul.arjona.bueno@gmail.com>
>>>
>>> (Removing CCIE groupstudy list for this email)
>>>
>>> I'm not able to test this at the moment, but can I suggest you try a
>>> CONTINUE route-map statement to try and get an AND working?
>>>
>>> Something like a
>>>
>>> Route-map XXX permit 10
>>> Match ip address prefix-list 1
>>> Continue 30
>>>
>>> Route-map XXX deny 20
>>>
>>> Route-map XXX permit 30
>>> Match ip address prefix-list 2
>>>
>>> I don't know if "continue" will work for these kinds of route-maps,
>>> but it's worth a try - if it works, then you can post it to
>>> GroupStudy. I just didn't want to post a "perhaps" email to the group
>
>>> without testing it, and ending up wasting people's time :)
>>>
>>> --
>>> Balmik Soin
>>> Voice Network Engineer Desk: +61-8-9213-1370
>>> Voice Engineering - Network Services Mobile: +61-414-429-266
>>> iiNet Limited balmik@staff.iinet.net.au
>>>
>>>
>>> > -----Original Message-----
>>> > From: Koen Zeilstra [mailto:koen@koenzeilstra.com]
>>> > Sent: Friday, 19 October 2007 1:14 PM
>>> > To: Bob Sinclair
>>> > Cc: Balmik Soin; Saul Arjona; ccielab@groupstudy.com
>>> > Subject: Re: conditional default advertising in BGP with multiple
>>> routes
>>> > tomonitor
>>> >
>>> > Yes we do have a solution for the OR, now we still need a solution
>>> > for the AND function. Matching both routes for one descision.
>>> >
>>> >
>>> >
>>> > Quoting Bob Sinclair <bob@bobsinclair.net>:
>>> >
>>> > > Koen Zeilstra wrote:
>>> > >> Correct. The conditions are never met for ACL 10.
>>> > >>
>>> > >> I have labbed the original and this solution up, no AND just OR.
>>> > >>
>>> > > Absolutely right! I stand corrected. So do we have a solution
>>> > > for
>>> OR?
>>> > >
>>> > > --
>>> > >
>>> > >
>>> > > Bob Sinclair CCIE 10427 CCSI 30427 www.netmasterclass.net
>>> >
>>>
>>>
>>>
>>> ----- End forwarded message -----
>>>
>>> _____________________________________________________________________
>>> __ Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>
>> ______________________________________________________________________
>> _ Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> The content contained in this electronic message is not intended to
> constitute formation of a contract binding TWTC. TWTC will be contractually
> bound only upon execution, by an authorized officer, of a contract including
> agreed terms and conditions or by express application of its tariffs.
>
> This message is intended only for the use of the individual or entity to
> which it is addressed. If the reader of this message is not the intended
> recipient, or the employee or agent responsible for delivering the message
> to the intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this message is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> replying to the sender of this E-Mail or by telephone.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> The content contained in this electronic message is not intended to
> constitute formation of a contract binding TWTC. TWTC will be contractually
> bound only upon execution, by an authorized officer, of a contract including
> agreed terms and conditions or by express application of its tariffs.
>
> This message is intended only for the use of the individual or entity to
> which it is addressed. If the reader of this message is not the intended
> recipient, or the employee or agent responsible for delivering the message
> to the intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this message is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> replying to the sender of this E-Mail or by telephone.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Nov 16 2007 - 13:11:18 ART