From: Geert Nijs (geert.nijs@simac.be)
Date: Thu Jul 21 2005 - 16:35:04 GMT-3
Jian,
Good thinking.
Ill have it checked out in the lab though, just to see that there arent
any adverse effects. but it looks like a valid solution....
thx !
Geert
-----Oorspronkelijk bericht-----
Van: Jian Gu [mailto:guxiaojian@gmail.com]
Verzonden: donderdag 21 juli 2005 18:49
Aan: Geert Nijs
CC: Joe Smith; DSchulz@dpsciences.com; ccielab@groupstudy.com; Richard
Gallagher
Onderwerp: Re: Preventing routing loops in this BGP situation
If you just want to make it work, why don't you just simply set higher
weight on R2 for routes advertised from R1? This way R2 will never
prefer routes advertised back from R3.
hostname R2
router bgp 2
neighbor <R1> weight 65535
On 7/21/05, Geert Nijs <geert.nijs@simac.be> wrote:
> Joe,
>
> I have tested this just yesterday in the lab and it works ! Router R2
> tags ALL routes it learnes from EBGP when redistributing in IGP (ie
> EIGRP) And router R3 will never inject a tagged route back into BGP,
> using the route-map statement on the network command.
> So router R3 will only inject "native" (untagged) EIGRP routes, just
the
> way it should be.
>
> Great !
>
> Geert
>
> -----Oorspronkelijk bericht-----
> Van: nobody@groupstudy.com [mailto:nobody@groupstudy.com] Namens Joe
> Smith
> Verzonden: woensdag 20 juli 2005 17:54
> Aan: Geert Nijs; DSchulz@dpsciences.com
> CC: ccielab@groupstudy.com
> Onderwerp: RE: Preventing routing loops in this BGP situation
>
>
> How about tagging the BGP that is redistributed into EIGRP on R2?
>
> R2:
> redistribute bgp 2 route-map TEST
>
> route-map TEST permit 10
> set tag 50
>
>
> R3:
> router bgp 2
> network x.x.x.x route-map TEST
>
> route-map TEST deny 10
> match tag 50
> !
> route-map TEST permit 20
>
>
> >From: "Geert Nijs" <geert.nijs@simac.be>
> >Reply-To: "Geert Nijs" <geert.nijs@simac.be>
> >To: "Schulz, Dave" <DSchulz@dpsciences.com>
> >CC: <ccielab@groupstudy.com>
> >Subject: RE: Preventing routing loops in this BGP situation
> >Date: Wed, 20 Jul 2005 15:03:55 +0200
> >
> >Dave,
> >
> >No that doesnt work. have tried both.
> >
> >PS. It is the purpuse that network x.x.x.x comes from AS1. This
> >should be allowed. The only mistake in the topology is that someone
> >forgot to remove the network statement on R3, where this network was
> >previously situated.
> >
> >1) setting the noexport community on R2 will not prevent R2 from
> >putting the route in EIGRP. Also R3 would still advertise the network
> >to R2.
> >
> >I have been thinking about some sort of filtering on R3 so that the
> >network x.x.x.x command will only inject networks into BGP when a)
> >they
>
> >are in the routing table en b) they are NOT tagged. I would tag
> >redistributed routes on R2...but i havent found a way to implement
> >this...
> >
> >Geert Nijs
> >CCIE #13729
> >
> >-----Original Message-----
> >From: Schulz, Dave [mailto:DSchulz@dpsciences.com]
> >Sent: woensdag 20 juli 2005 13:12
> >To: Geert Nijs
> >Cc: ccielab@groupstudy.com
> >Subject: RE: Preventing routing loops in this BGP situation
> >
> >Geert -
> >
> >I believe that if you were to use the community attribute in BGP and
> >set it to No Export this would break the loop. Or, we could also
> >create an expression with an as-path list to only allow networks that
> >originated from the advertising AS. Does this work for you?
> >
> >
> >Dave Schulz,
> >Email: dschulz@dpsciences.com
> >
> >
> >-----Original Message-----
> >From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> >Of
>
> >Geert Nijs
> >Sent: Wednesday, July 20, 2005 3:34 AM
> >To: lab
> >Subject: Preventing routing loops in this BGP situation
> >
> >Hi group,
> >
> >I wonder how service providers prevent routing loops in the following
> >situation:
> >
> >R1 is part of AS1
> >R2 and R3 are part of AS2
> >R2 and R3 are also running an IGP like ie EIGRP
> >R4 is part of AS4
> >
> >**** On router R2 and R3 redistribution of BGP into EIGRP is
> >configured
>
> >!
> >
> >R1 (AS1) ---- EBGP ----- R2 (AS2) ----------- IBGP + EIGRP
> >----------- R3 (AS2) --------- EBGP ---------- R4 (AS4)
> >
> >On router R3 someone forgot to remove a network statement, so router
> >R3
>
> >contains the statement: router bgp 2
> > network x.x.x.x
> >
> >but network x.x.x.x is not in the routing table so it is not
> >advertised
>
> >(no problems yet).
> >
> >Now, the problems begin when AS1 (R1) starts advertising this network
> >x.x.x.x
> >
> >The network x.x.x.x enters AS2 through router R2, this router
> >redistributes the route into EIGRP, and now, the network x.x.x.x is
> >part of the routing table on router R3, so R3 suddenly starts
> >advertising network x.x.x.x back to R2 over IBGP R2 prefers this
> >route (AS path is empty). R2 starts advertising network x.x.x.x back
> >out AS2 to R1 and stops redistributing x.x.x.x into EIGRP (by
> >default, no redistribution of IBGP routes). So the route is removed
> >from the routing table on R3, so that R3 stops advertising the route
> >again. When R2 removes the route from BGP table, it prefers back the
> >route received from R1 and starts advertising the route again to R3
> >over EIGRP.... and so we have a beautifull routing loop and lots of
> >constant BGP advertisements going on forever.....
> >
> >I am looking for a method to prevent this from happening. Any ideas ?
> >
> >
> >Geert Nijs
> >CCIE #13729 <http://www.cisco.com/en/US/learning/le3/ccie/index.html>
> >
> >#####################################################################
> >##
> >#
> >#####
> >########
> >Simac N.V. trades under the commercial name Simac ICT Belgium.
> >This e-mail and any attached files are confidential and may be
legally
> >privileged.
> >If you are not the addressee, any disclosure, reproduction, copying,
> >distribution,
> >or other dissemination or use of this communication is strictly
> >prohibited.
> >If you have received this transmission in error please notify Simac
> >immediately
> >and then delete this e-mail.
> >
> >Simac has taken all reasonable precautions to avoid virusses in this
> >email. Simac does not accept liability for damage by virusses, for
> >the correct and complete
> >transmission of the information, nor for any delay or interruption of
> >the
> >transmission,
> >nor for damages arising from the use of or reliance on the
information.
> >
> >All e-mail messages addressed to, received or sent by Simac or Simac
> >employees are deemed to be professional in nature. Accordingly, the
> >sender or recipient of
> >these messages agrees that they may be read by other Simac employees
> >than the
> >official
> >recipient or sender in order to ensure the continuity of work-related
> >activities
> >and allow supervision thereof.
>
>#######################################################################
> #
> >#####
> >########
> >
> >_____________________________________________________________________
> >__
> >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
>
> _________________________________________________________________
> Dont just search. Find. Check out the new MSN Search!
> http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>
> ______________________________________________________________________
> _
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:00:30 GMT-3