GroupStudy.com GroupStudy.com - A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: Preventing routing loops in this BGP situation posted 07/21/2005
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


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@xxxxxxxx>
Reply-To: "Geert Nijs" <geert.nijs@xxxxxxxx>
To: "Schulz, Dave" <DSchulz@xxxxxxxxxxxxxx>
CC: <ccielab@xxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxx]
Sent: woensdag 20 juli 2005 13:12
To: Geert Nijs
Cc: ccielab@xxxxxxxxxxxxxx
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@xxxxxxxxxxxxxx


-----Original Message----- From: nobody@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx] 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