From: Jongsoo (bstrt2004@gmail.com)
Date: Thu Nov 03 2005 - 19:06:21 GMT-3
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
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:05 GMT-3