From: Scott Morris (swm@emanon.com)
Date: Thu Nov 03 2005 - 20:08:15 GMT-3
I agree... The as-override makes much more sense. It's cleaner IMHO.
It is part of the address-family configuration, although if you specify
address-family ipv4 unicast, I don't see why not. *shrug*
-----Original Message-----
From: Jongsoo [mailto:bstrt2004@gmail.com]
Sent: Thursday, November 03, 2005 5:25 PM
To: Arun Arumuganainar; Andrew Lissitz (alissitz)
Cc: Olopade Olorunloba; Scott Morris; C&S GroupStudy; FORUM
Subject: Re: "neighbor allowas-in" command ( SP CCIE)
Arun/Andrew
Great discussion!!!
Just simple question regarding "When BGP is used as PE-CE protocol"
Let's say a toplogy like below
CE1 ASN100---ebgp--> ASN200 PE1 ---ibgp---ASN 200 PE2---ebgp-->ASN 100 CE2.
CE1 announces 10.0.0.0/24 to CE2. But in normal case, CE2 will see
10.0.0.0/24 with as-path 200 100 so that it will block it.
Per Andrew, we have two choices to resolve this, as-override in PE1 or
allowas-in in CE2.
I prefer as-override to allowas-in.
The fact bothering me is if we use allowas-in, then we have to configure CE2
and CE2 will have just normal eBGP connection not address-family. Can this
command be still allowed in a normal ipv4 eBGP config?
Even if it allows, it will requir customer to configure the router
(CE) in unusual way.
Jongsoo
On 11/3/05, Arun Arumuganainar <aarumuga@hotmail.com> wrote:
> Default Behavior in BGP : When ever a prefix is received , router
> checks the AS Path for its own AS number . If its AS is found in the
> prefix's AS path attribute , it infers a loop and the prefix will not
> be imported in to its BGP table .
>
> With Allowas-in feature turned on this ****AS PATH LOOP DETECTION
> CHECK**** is not performed at all . That is all it does and nothing else
!!!
>
> To the best of my knowledge this is not at all related to SOO .
>
> Where do we really use Allowas-in feature ?
>
> When BGP is used as PE-CE protocol , it allows all CE sites that
> belongs to single customer to use the same AS number . And nothing else .
>
> It is also used in HUB/SPOKE VPN as two VRFs are configured on PE to
> same CE device ( HUB Router ) !!!
>
> Pls. Note : SOO is a loop detection feature that will be useful in
> Multi Homed CEs or a Site with multiple CE routers .You might or might
> not use allowas-in feature depending on choice of AS u use in your
> deployment . In case all the CEs across all the sites uses same AS you
> will have to use allowas-in . Otherwise there is no need for turning this
on .
>
> Thanks and Regards
> Arun
> ----- Original Message -----
> From: "Olopade Olorunloba" <lolopade@ipnxnigeria.net>
> To: "'Scott Morris'" <swm@emanon.com>; "'Andrew Lissitz (alissitz)'"
> <alissitz@cisco.com>; "'Jongsoo'" <bstrt2004@gmail.com>; "'C&S
GroupStudy'"
> <comserv@groupstudy.com>; "'FORUM'" <ccielab@groupstudy.com>
> Sent: Thursday, November 03, 2005 12:29 PM
> Subject: RE: "neighbor allowas-in" command ( SP CCIE)
>
>
> > Now I'm getting confused. I thought by setting the SOO on the
> > inbound updates, the Cisco IOS automatically checks for loops, and I
> > do not have
> to
> > use things like communities to filer?
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of Scott Morris
> > Sent: 03 November 2005 03:03
> > To: 'Andrew Lissitz (alissitz)'; 'Jongsoo'; 'C&S GroupStudy'; 'FORUM'
> > Subject: RE: "neighbor allowas-in" command ( SP CCIE)
> >
> > Not to my knowledge, but I haven't really looked at that either.
> >
> > And yes, you'll still detect loops.
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of Andrew Lissitz (alissitz)
> > Sent: Wednesday, November 02, 2005 8:59 PM
> > To: swm@emanon.com; Jongsoo; C&S GroupStudy; FORUM
> > Subject: RE: "neighbor allowas-in" command ( SP CCIE)
> >
> > Thanks Scott,
> >
> > So ... with SoO being set, you will still have loop detection? Also
> > I
> asked
> > Robert a question of whether or not SoO is set automatically. Can
> > you comment on this Scott? Just quick comments, nothing lengthy
> > needed
> > ;-)
> >
> > Andrew
> >
> >
> >
> > -----Original Message-----
> > From: Scott Morris [mailto:swm@emanon.com]
> > Sent: Wednesday, November 02, 2005 8:08 PM
> > To: Andrew Lissitz (alissitz); 'Jongsoo'; 'C&S GroupStudy'; 'FORUM'
> > Subject: RE: "neighbor allowas-in" command ( SP CCIE)
> >
> > You can still use this in conjunction with SOO to determine which
> > router REALLY originated it. This is also used (IMHO) when you
> > don't entirely trust your SP to clear out everything necessry on the
> > BGP feeds. ;)
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of Andrew Lissitz (alissitz)
> > Sent: Wednesday, November 02, 2005 7:50 PM
> > To: Jongsoo; C&S GroupStudy; FORUM
> > Subject: RE: "neighbor allowas-in" command ( SP CCIE)
> >
> > Hey Buddy,
> >
> > Here is a live example, I have not done the hub and spoke labs like
> several
> > others on this mail list have:
> >
> > CE ---bgp---PE ---(ISP Cloud)--- PE---bgp---CE
> >
> > Each CE runs AS 65000 and shares routes with the PE. The PEs share
> > routes via iBGP. The remote PE shares routes with the remote CE,
> > and the CE sees the routes from AS 65000.
> >
> > What is BGP to do? It sees its own AS number and realizes there is
> > a problem.
> >
> > Solution: Either PE changes the AS number with as-override or the CE
> allows
> > its own AS number to come in via the allowed-as command. The number
> > @ the end is how many times the CE will allow it's own AS number to
> > be present
> in
> > the path string of the incoming route information.
> >
> > Concerning your gut feelings (btw ... hope you are not writing on
> > empty stomach), number one sounds good, but with number 2, you are
> > essentially saying that this command will override bgp split
> > horizon. This is not
> what
> > it will do, if a route is already coming in, and it contains the
> > BGP's AS number in the path, then let this in. Not whether or not
> > to advertise to other peers. I have not seen this command change BGP
> > split horizon
> behavior
> > ...
> >
> > BGP best path selection still occurs, it is just that the routes
> > will not
> be
> > rejected because of loop detection. I have not seen multiple routes
> > being accepted as best paths... Can multiple routes exist without
> > the BGP multipath command?
> >
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of Jongsoo
> > Sent: Wednesday, November 02, 2005 7:33 PM
> > To: C&S GroupStudy; FORUM
> > Subject: "neighbor allowas-in" command ( SP CCIE)
> >
> > I am trying to understand this command will allow to receive MP-bgp
> > vpn routes with the same ASN.
> >
> > If I see usage guide in CCO, it says
> >
> > ##################################
> > Usage Guidelines
> > In a hub and spoke configuration, a PE router readvertises all
> > prefixes containing duplicate autonomous system numbers. Use the
> > neighbor
> allowas-in
> > command to configure two VRFs on each PE router to receive and
> > readvertise prefixes are as follows:
> >
> > One Virtual Private Network routing/forwarding instance (VRF)
> > receives prefixes with ASNs from all PE routers and then advertises
> > them to neighboring PE routers.
> >
> > The other VRF receives prefixes with ASNs from the customer edge
> > (CE) router and readvertises them to all PE routers in the hub and
> > spoke configuration.
> >
> > You control the number of times an ASN is advertised by specifying a
> number
> > from 1 to 10. "
> > ################################################
> >
> > In my gut feeling, basically, this command seems allow two things,
> > 1) receive BGP routes with its own ASN from PE or CE, ( normal
> > behavior of
> BGP
> > blocks BGP route with its own ASN in order to prevent loop) and
> > 2) advertize iBGP routes to iBGP peers ( normal behavior of iBGP is
> > not to advertize iBGP routes to any iBGP peers).
> >
> > What seems interesting is this feature will creates a lot of
> > redundant routes but the length of AS path will quickly determine
> > the best routes so that there won't be any loop...
> >
> > This will be a perfect command to make hub and spoke topology to work...
> >
> > The biggest question I have now is " am I right or wrong?".
> > Someone please correct me if I am wrong.
> >
> > Thanks
> >
> >
> > Jongsoo
> >
> > ____________________________________________________________________
> > ___ 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
> >
> > ____________________________________________________________________
> > ___ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > ____________________________________________________________________
> > _ Subscription information:
> > http://www.groupstudy.com/list/comserv.html
> >
> > ____________________________________________________________________
> > _ Subscription information:
> > http://www.groupstudy.com/list/comserv.html
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:05 GMT-3