From: Schulz, Dave (DSchulz@dpsciences.com)
Date: Thu Jul 21 2005 - 08:04:18 GMT-3
Richard - Wouldn't the tag accomplish the same purpose, and, with the
same procedure that you mentioned below?
Dave Schulz,
Email: dschulz@dpsciences.com
-----Original Message-----
From: richard.harvey@NBS.NHS.UK [mailto:richard.harvey@NBS.NHS.UK]
Sent: Thursday, July 21, 2005 4:39 AM
To: guxiaojian@gmail.com; rgallagh@cisco.com
Cc: j333smith@hotmail.com; geert.nijs@simac.be; Schulz, Dave;
ccielab@groupstudy.com
Subject: RE: Preventing routing loops in this BGP situation
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.
> >>
########################################################################
> >> #####
> >> ########
> >>
> >>
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:00:30 GMT-3