From: Arun Arumuganainar (aarumuga@hotmail.com)
Date: Fri Jul 22 2005 - 09:49:51 GMT-3
RE: Preventing routing loops in this BGP situationHi Sculz ,
Command history says it was introduced in 10.0 so pretty older command . I
remember reference of this command in Jeff Doyle ( If I am correct , it is in
redistribution and sub topic route tagging in Vol 1 ) .
Actually there is one correction on tag-ibgp filter in my original mail You
will not be able to filter using tags here ( Once you are inside bgp tag has
not meaning .) . Instead use as path filter . Note : Here the idea is
advertise routes whos AS path is empty .
ip as-path access-list 1 permit ^$
!
route-map tag-ibgp permit 10
match as-path 1
Thanks and Regards
Arun
----- Original Message -----
From: Schulz, Dave
To: Arun Arumuganainar ; Jian Gu ; Geert Nijs
Cc: Joe Smith ; ccielab@groupstudy.com ; Richard Gallagher
Sent: Friday, July 22, 2005 5:10 PM
Subject: RE: Preventing routing loops in this BGP situation
That is interesting informaiton, Arun. In what version was the automatic
route tagging released? (is it on the current version being used in the lab).
That could be a very useful feature.
Dave
-----Original Message-----
From: Arun Arumuganainar
To: Jian Gu; Geert Nijs
Cc: Joe Smith; Schulz, Dave; ccielab@groupstudy.com; Richard Gallagher
Sent: 7/22/2005 6:47 AM
Subject: Re: Preventing routing loops in this BGP situation
This is general BGP best practice :
Routes that are redistributed from BGP in to an IGP should not be
distributed back in to BGP .
Reason for the Above guideline : While redistribution AS path
information
will be lost . And hence basic route-loop check in BGP would miserably
fail
Enforcing such rule is challenge in Real life environment . Some methods
involve changes to IGP protocol . For Ex in OSPF and ISIS has made one
modification on MPLS VPN environment , down bit was introduced . This
is
set when VRF interface is advertising a route to its peer . Upon
receiving a
route it does a down bit check . If down bit is set it drop the prefix
and
will not advertise this to BGP .This will be particularly useful in Dual
Homed CE scenario .
So in our case Best practice would be to do like this .
On R2 do the following
!
router eigrp 10
redistribute bgp 100 metric 1500 50 150 200 1500 route-map tagg
!
route-map tagg permit 10
set automatic-tag
Note : automatic-tag will just copy the AS Path of the route being
distributed in to the tag feild of routes .
***********************************************
On the R3
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network X.X.X.X mask X.X.X.X route-map tag-2-aspath
bgp ibgp-neighbor route-map tag-ibgp out
!
!note : ibgp-neighbor is peer group to which all ibgp
!....neighbors are members
route-map tag-ibgp deny 10
match tag
!
route-map tag-ibgp permit 20
!
route-map tag-2-aspath permit 10
set as-path tag
!
*********************************************
Some FAQs
Why tag-2-aspath is needed ?
This will restore the as-path . Hence BGP loop check will return correct
results when it is advertised via eBGP( otherwise AS path info will be
lost
and loops can occur outside your own AS ). This should be applied to all
the
routes learned locally via Network statements and redistribute
statements.
Why tag-ibgp is needed ?
One of IBGP condition says that a route learned from IBGP should not be
send
back to other IBGP peers . This will have to be ensured as there is no
loop
prevention mechanism built in to iBGP .
In our case route will necessarily be learned via one of its iBGP
neighbor
in case it has a tag on it . Allowing a tagged route to be sent to iBGP
peers will amount to violation of the IBGP rule .
If we can have the above schemes in place , then we will not be landing
in
to route loop problems ..
Thanks and Regards
Arun
----- Original Message -----
From: "Jian Gu" <guxiaojian@gmail.com>
To: "Geert Nijs" <geert.nijs@simac.be>
Cc: "Joe Smith" <j333smith@hotmail.com>; <DSchulz@dpsciences.com>;
<ccielab@groupstudy.com>; "Richard Gallagher" <rgallagh@cisco.com>
Sent: Thursday, July 21, 2005 10:19 PM
Subject: Re: Preventing routing loops in this BGP situation
> If you just want to make it work, why don't you just simply set higher
> weight on R2 for routes advertised from R1? This way R2 will never
> prefer routes advertised back from R3.
>
> hostname R2
> router bgp 2
> neighbor <R1> weight 65535
>
>
> On 7/21/05, Geert Nijs <geert.nijs@simac.be> wrote:
> > 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
> >
> > _________________________________________________________________
> > 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