RE: Preventing routing loops in this BGP situation

From: Geert Nijs (geert.nijs@simac.be)
Date: Thu Jul 21 2005 - 05:43:12 GMT-3


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



This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:00:30 GMT-3