From: richard.harvey@nbs.nhs.uk
Date: Thu Jul 21 2005 - 05:39:19 GMT-3
Site of Origin (SoO) is a useful community attribute to prevent route feedback in this situation. An eBGP interface facing a 'site' can be configured with an arbitary value that will be applied to all routes being redistributed into BGP. These can then be filtered out from being re-imported at the other entry points into the site.
-----Original Message-----
From: MIME :guxiaojian@gmail.com Sent: 21 July 2005 08:05
To: rgallagh@cisco.com
Cc: j333smith@hotmail.com; geert.nijs@simac.be; DSchulz@dpsciences.com; ccielab@groupstudy.com
Subject: Re: Preventing routing loops in this BGP situation
Setting up tags or communities on R2 when redistributing to IGP and
then on R3 put deny the tags/commnunites route-map behind "network
xxxx" will work, but that only works IF R2 knows which networks are
going to cause the loop, this solution does not solve the problem in
general.
I don't think there is an easy way to build the intelligence in router
to prevent such loop introduced by misconfiguration. An extreme
example: how can you prevent a routing loop if such loop is
intentionally or unintentionaly introduced by static routes?
On 7/20/05, Richard Gallagher <rgallagh@cisco.com> wrote:
> BGP does not support tagging, the only thing close is to use
> communities. Not sure this will help in this situation though.
> > Rich
> > Joe Smith wrote:
> > 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
> > _______________________________________________________________________
> 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