RE: Preventing routing loops in this BGP situation

From: Schulz, Dave (DSchulz@dpsciences.com)
Date: Wed Jul 20 2005 - 10:08:35 GMT-3


Geert -

For tagging ....would it be acceptable to tag them in a route-map with
an access-list within the redistribute command?

Dave

-----Original Message-----
From: Geert Nijs [mailto:geert.nijs@simac.be]
Sent: Wednesday, July 20, 2005 9:04 AM
To: Schulz, Dave
Cc: ccielab@groupstudy.com
Subject: RE: Preventing routing loops in this BGP situation

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.
########################################################################
#####
########



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