From: Jongsoo (bstrt2004@gmail.com)
Date: Thu Nov 03 2005 - 22:07:56 GMT-3
Andrew / All
I totally agree about normal ISP environment. However, in CCIE lab is
far beyond the normal.
Let me give a scenario
CE1------Pe1-----Pe2--CE2
|
|
Pe3---CE3
CE1 is HQ,
CE2 and CE3 are small office.
For whatever reason( perhaps for virus checking...), CE1 need to be a
hub, CE2 and CE3 need to be spokes. So that a direct traffic between
CE2 and CE3 is not allowed, it must go through CE1.
I am looking for how many ways exist to design this topology.
Thanks
Jongsoo
On 11/3/05, Andrew Lissitz (alissitz) <alissitz@cisco.com> wrote:
> Hey Dude,
>
> ISPs run iBGP between PEs (more common to use RRs but same concept), so
> the idea of a PE seeing it's own ASN in the path is not likely. The PE
> may see different AS numbers repeated in the path, but what does it
> care? As long as it does not see its own ASN and detect a loop, all is
> well.
>
> Some ISPs give the customers one ASN for all the customer sites. In
> this case, this problem will occur. The CE will see the routes from the
> remotes sites and see it's ASN in the path. Refer to that earlier
> diagram.
>
> Other ISPs give the customers different ASN for each site... but for
> obvious reasons this does not scale.
>
> So, in the case of hub and spoke (is this common, have you all seen this
> in production?), each PE is running iBGP with each other or the hub is a
> RR. Each PE will not see it's own ASN. Each PE has learned BGP routes
> from it's CE and will pass these between peers. Each peer will run the
> best path process and select the best route. Only best routes are
> advertised ...
>
> If for some reason, your BGP speakers will see what appears to be a
> loop, then allowas will work. You can also override the ASN as well.
>
> Andrew rule of thumb (does not mean much ... will not even get you free
> coffee): allowas-in would be configured on CEs because they are
> receiving these routes, and as-override would be configured on routers
> advertising routes ... more than likely the PEs.
>
> Jongsoo, I do not feel as though I have fully answered your question ...
> Sorry about that.
>
> Andrew
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Jongsoo
> Sent: Thursday, November 03, 2005 5:06 PM
> To: Andrew Lissitz (alissitz)
> Cc: C&S GroupStudy; FORUM
> Subject: Re: "neighbor allowas-in" command ( SP CCIE)
>
> When I wrote the below email, my stomach was a little empty :)
>
> Regarding my point 2) "advertize iBGP routes to iBGP peers ( normal
> behavior of iBGP is not to advertize iBGP routes to any iBGP peers)",
>
> First, this thought is from CCO descprition "One Virtual Private Network
> routing/forwarding instance (VRF) receives prefixes with ASNs from all
> PE routers and then advertises them to neighboring PE routers."
>
> I figured from the description that a PE receives a prefix with its own
> ASN from PE router and advertize
>
> Let's say "neighbor allowas-in 1" in AS 100 in three PE's( pe1, pe2,
> pe3).
>
> If via MP-BGP, PE1 and PE2 learn from PE3 a VPN route 10.0.0.0/24 with
> as-path = null, I think PE1 will annouce back 10.0.0.0/24 with
> as-path=100 to PE2 and PE3 as well as PE2 will do the same to PE1 and
> PE3, which is not normal iBGP behavior. But 10.0.0.0/24 with AS-path 100
> from PE1 and PE 2 can't beat 10.0.0.0/24 with as-path null from PE3.
>
> But the interesting result is if PE2 is not importing 10.0.0.0/24 with
> as-path=null from PE3, then PE2 will only have 10.0.0.0/24 with
> as-path=100 from PE1.
> This will achieve hub-and-spoke VPN topology ( PE1 = hub and PE2 and
> PE3 = spokes)
>
> Please feel free to correct me if I am wrong.
>
> Jongsoo
>
> On 11/2/05, Andrew Lissitz (alissitz) <alissitz@cisco.com> wrote:
> > 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
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:05 GMT-3