From: Jongsoo (bstrt2004@gmail.com)
Date: Tue Nov 08 2005 - 23:04:41 GMT-3
Andrew
I was wondering if in yoru lab, you could config inter-VRF static
route between VRF's ( not global).
Here is the config that I have in mind but is not labbed yet.
(This will require an inter-VRF static routing, which I am not 100% sure of .)
##### pre-condition ######
Hub
CE1 .2-- 10.1.1.0--.1 f1 PE1
CE2 .2-- 10.2.2.0--.1 f2 PE2
CE3 .3-- 10.3.3.0--.1 f3 PE3
CE2 has 2.0.0.0/8 network
CE3 has 3.0.0.0/8 network
CE1 has a static route for 2.0.0.0/8 and 3.0.0.0/8 to PE1
CE2 and CE3 has a default route to PE2 and PE3 respectively
Baiscally, each PE has two uni-direction VRFs but only one VRF has the
interface between PE and CE and the other VRF has just static route(
Inter VRF)
######## PE1 Hub ###########
ip vrf up
rd 100:1
route-target export 100:1
ip vrf down
rd 100:2
route-target import 100:1
int f1
ip address 10.1.1.1 255.255.255.0
ip vrf forwarding down
ip route vrf up 0.0.0.0 0.0.0.0 f1 10.1.1.2
( defaut inter vrf route from vrf up to vrf down toward CE1)
router bgp 100
neighbor PE2, PE3 remote-as 100
neighbor PE2, PE3 route-reflector-client
address-family vpnv4
neighbor PE2, PE3 activate
neighbor PE2, PE3 send-community extended
neighbor PE2, PE3 route-reflector-client
address-family ipv4 vrf up
redistribute static
address-family ipv4 vrf down
######## PE2 spoke ###########
ip vrf up
rd 100:1
route-target import 100:2
ip vrf down
rd 100:2
route-target export 100:2
int f2
ip address 10.2.2.1 255.255.255.0
ip vrf forwarding up
ip route vrf down 2.0.0.0 255.0.0.0 f2 10.2.2.2
( static inter vrf route from vrf down to vrf up toward CE2 for 2.0.0.0/8)
router bgp 100
neighbor PE1 remote-as 100
address-family vpnv4
neighbor PE1 activate
neighbor PE1 send-community extended
address-family ipv4 vrf down
redistribute static
address-family ipv4 vrf up
######## PE3 spoke ###########
ip vrf up
rd 100:1
route-target import 100:2
ip vrf down
rd 100:2
route-target export 100:2
int f3
ip address 10.3.3.1 255.255.255.0
ip vrf forwarding up
ip route vrf down 3.0.0.0 255.0.0.0 f3 10.3.3.2
( static inter vrf route from vrf down to vrf up toward CE3 for 3.0.0.0/8)
router bgp 100
neighbor PE1 remote-as 100
address-family vpnv4
neighbor PE1 activate
neighbor PE1 send-community extended
address-family ipv4 vrf down
redistribute static
address-family ipv4 vrf up
-------------end of config----------------
Jongsoo
On 11/8/05, Andrew Lissitz (alissitz) <alissitz@cisco.com> wrote:
> No pretty, although it works. I only used two routers in my lab (lab
> not yet complete), here is what I got:
>
> Spoke CE3:192.3.3.3 (static default to PE3) -- Spoke PE3 (static vrf
> route to get to CE2)
>
> Hub PE2 (static route to VRF interface) --- Hub CE 2:192.2.2.2 (Static
> default to PE2)
>
> Challenges:
>
> When you remove a route-target import statement on a PE (for
> uni-directional VRF), the default behavior of BGP is to not allow any
> routes for that VRF's route-target inbound. This is what we want, since
> we removed the import statement on the spoke PE. Now how should this
> spoke PE, route VRF traffic now? The answer is statically, since we do
> not have any dynamic protocols inbound.
>
> On the CE3:192.3.3.3 router:
>
> ip route 0.0.0.0 0.0.0.0 x.x.x.x (PE3) --> spoke CE device defaults to
> spoke PE
>
> On the PE3 router:-
>
> Ip route vrf xyz 192.2.2.2 255.255.255.255 x.x.x.x global (x.x.x.x =
> PE2 ibgp next hop)
>
> --> need to tell PE3 to reference the global table to find this next
> hop. The reason I had to put a global next hop address for PE2, is
> because the local VRF does not import any routes from the remote PE...
> normally you would see a iBGP route with the iBGP next hop of PE2 for
> VRF routes found on PE2.
>
> Without this iBGP route for the remote PE, how then will this PE3 know
> to reach the far side PE2 router for this destination VRF? The answer
> is to configure it statically since we are not importing any dynamic
> routes into this VRF.
>
> From PE3's perspective, the only known next hop for PE2 is a global one
> (nothing in VRF route table). This is how we will send traffic to the
> far side PE router.
>
> ON CE2:192.2.2.2 router:
>
> ip route 0.0.0.0 0.0.0.0 x.x.x.x (PE2)
>
> On the PE2 router:
>
> Since previously we had configured static routing on the hub PE router,
> there is nothing more to do within the VRF. The PE2 router is importing
> route information for the remote PEs still, and knows how to route back
> to them. This means there is nothing to do for return traffic.
>
> However, this traffic from the remote spoke PEs is coming in to a global
> destination (PE2 iBGP address) and needs to routed to a VRF interface.
> On PE2:
>
> ip route 192.2.2.2 255.255.255.255 eth 2/0 --> ethe 2/0 is the vrf
> interface that leads to CE2
>
> This is probably the most tricky aspect of this solution. If anyone
> configured this in a different manner, please share. This was how I got
> this to work.
>
> ***** end of lab *****
>
> An easier method would be to use iBGP as usual, and continue to import
> routes to remote spoke PEs. Create static default @ hub, redist into
> PE2 iBGP vrf configs, and share routes normally. The remotes will get
> this default pointing to hub router.
>
> I labbed this up as well, it works ... And with a lot less concern.
>
>
>
>
> -----Original Message-----
> From: Jongsoo [mailto:bstrt2004@gmail.com]
> Sent: Monday, November 07, 2005 7:48 PM
> To: swm@emanon.com
> Cc: Andrew Lissitz (alissitz); C&S GroupStudy; FORUM
> Subject: Re: We've moved to PE-CE routing! (SP-CCIE)
>
> Scott
>
> right now...I like to develop any config as long as it has great chance
> to work.
> I am so hungry fo waiting for 3.0 workbook from IE( Dec is just too
> long)...so that my gut feeling is running out as well(???)...except for
> the one before.
>
> 1) Basically, two uni-directional VRFs, 1) from spoke CE-to HUB CE (
> up) and 2) from HUB CE to spoke CE ( down) seem to have a good chance
> to work.
> But in this case of two uni-directional VRFs, I am not sure if we can
> make it work using any IGP between CE and PE replacing static because we
> will need inter-VRF routing and I think only static is the only option
> for that.
>
> for 2nd config, checked "Hub and spoke VPN #2"
>
>
> Jongsoo
>
>
>
>
>
> On 11/6/05, Scott Morris <swm@emanon.com> wrote:
> > Correct. As long as the spoke would route through the 0/0 route back
> > to the hub, then you would achieve what you wanted.
> >
> > A little odd, but very workable!
> >
> > Scott
> >
> > -----Original Message-----
> > From: Jongsoo [mailto:bstrt2004@gmail.com]
> > Sent: Sunday, November 06, 2005 12:23 AM
> > To: Andrew Lissitz (alissitz)
> > Cc: swm@emanon.com; C&S GroupStudy; FORUM
> > Subject: Re: We've moved to PE-CE routing! (SP-CCIE)
> >
> > What I am trying to do is to make two uni-direction VRF forwarding
> > table 1) from spoke to hub and 2) from hub and spoke.( not from spoke
> > to spoke
> > directly)
> >
> > In order to prevent the connection from spoke to spoke, I think I have
>
> > to place a route filtering to block one spoke's static routes
> > announcement from MP-BGP to the other spoke's VRF...
> >
> > Something like this
> >
> > PE1
> > ip vrf up
> > ...
> > route-target export 100
> >
> > ip vrf down
> > ...
> > route-target import 200
> >
> > PE2
> >
> > ip vrf up
> > ...
> > route-target import 100
> >
> > ip vrf down
> > ...
> > route-target export 200
> >
> > PE3
> >
> > ip vrf up
> > ...
> > route-target import 100
> >
> >
> > ip VRF down
> > ...
> > route-target export 200
> >
> >
> > If PE1 is not RR and there are only two MP-iBGP session 1) between PE1
>
> > and
> > PE2 and 2) between PE1 and PE2 ( not between PE2 and PE3), then I
> > figure I may not need this route-target manupulation.
> >
> > I am dying to lab this out. But no time. I may do rack rental I also
> > like to come up with another way...
> >
> > Jongsoo
> >
> >
> > On 11/5/05, Andrew Lissitz (alissitz) <alissitz@cisco.com> wrote:
> > >
> > >
> > >
> > > Hello Jongsoo,
> > >
> > >
> > >
> > > I have not labbed this up for you ... so there may be something to
> > > modify or add to your config thoughts, but here goes. Your
> > > questions / my
> > comments:
> > >
> > >
> > > * Can I use the next hop address instead of interface for "ip route
> > > vrf up 0.0.0.0 0.0.0.0 fe1" command ? The answer is yes. Personal
> > > preference, I like to use next hop on any multi-access interface.
> > > Once you added the vrf keyword to this command, you have told the
> > > router which routing table to look in. The next hop address should
> > > be found on a connected interface, so this is fine.
> > >
> > > * For traffic flow from Hub to Spoke - Once you add a static route
> > > on the
> > > PE2 and PE3 routers pointing the CE2 and CE3 networks, the VRF
> > > routing table contains routing information to reach the networks
> > > behind CE2 and CE3. This is only within the PE2 and PE3 VRF route
> > > table until you
> > redist into MPBGP.
> > > Within the ipv4 vrf up and vrf down address families, you will
> > > need to redist static. As you mentioned all PEs will learn this via
>
> > > MPBGP and update their VRF tables as needed.
> > >
> > > So after PE1 knows how to reach these networks, it will send the
> > > traffic to the correct PE.
> > >
> > > * What are we missing? Well ... in each of these case the CEs only
> > > have one way to go and that is to the PE. For the Hub CE, if it
> > > runs static routing, will it know where to go? A default static
> > > should be added here as well as to all the CEs.
> > >
> > > Real world perspective ... (sorry about this) ... The hub router
> > > would likely be running BGP or an IGP with the PE. In this case,
> > > the CE would learn routing information dynamically. In this limited
>
> > > example, the hub router only has one link to the ISP network... so
> > > this is more
> > simple.
> > >
> > > Jongsoo, I did not follow the route-target comments you made.
> > > Perhaps this is from when you labbed this up? No worries ... I am
> > > sure in the lab this up becomes clear.
> > >
> > > We are all lacking my man ... especially me!!!!
> > >
> > >
> > > ________________________________
> > > From: Jongsoo [mailto:bstrt2004@gmail.com]
> > > Sent: Friday, November 04, 2005 8:27 PM
> > > To: swm@emanon.com; Andrew Lissitz (alissitz)
> > > Cc: C&S GroupStudy; FORUM
> > > Subject: Re: We've moved to PE-CE routing! (SP-CCIE)
> > >
> > >
> > > Guys
> > >
> > > Thanks for the information. I am obviously lacking some "basics"
> > > about MPLS VPN.
> > > ( I realized I have to think multi-dimensionally to figure out
> > > routing behavior among VRFs via MP-BGP and MPLS tags)
> > >
> > > Anyway, using the static method explained by Scott, Andrew and
> > > Arun, I came up with more details hoping I get it right.
> > >
> > >
> > > 1) Static routes only
> > > PE1 is RR and all three PEs are in full-mash.
> > > There are two VRFs of up( from spoke to hub) and down( from hub to
> > > spoke) configured in each PE.
> > >
> > >
> > > CE1-----VRF=down-fe1-PE1-----Pe2-fe2----VRF=Up---CE2 (
> > > 10.2.2.0/24)
> > > |
> > > |
> > > PE3
> > > fe3
> > > |
> > > VRF Up
> > > |
> > > |
> > > CE3( 10.3.3.0/24)
> > >
> > > 1-1) for a traffic flow from spoke( CE2, CE3) to Hub ( CE1) ( VRF =
> > > up) In PE1 config,
> > > A) put a default static route to CE1 = "ip route vrf up 0.0.0.0
> > > 0.0.0.0
> > fe1"
> > > ( fe1 is the out-going interface to CE1)
> > > B) Redistribute the static to bgp, route-export = 100 ( due to
> > > full-mash Mp-ibgp, PE2 and PE3 learn this route), In PE2 and PE3
> > > A) put the interface connecting CEs to VRF=up
> > > B) Import routes w/ route target =100 from MP-BGP
> > > C) CE2 and CE3 have a default route to PEs
> > >
> > > In this way, any traffic from CE2 and CE3 should come into PE1 via
> > > MPLS and go out via the fe1 interface of PE1 to CE1 Can I use the
> > > next hop address instead of interface for "ip route vrf up 0.0.0.0
> > > 0.0.0.0 fe1" command ?
> > >
> > >
> > > 1-2) for a traffic flow Hub to Spoke ( VRF = down)
> > >
> > > In PE2 config,
> > > A) put a static route to CE2 = "ip route vrf down 10.2.2.0
> > > 255.255.255.0 fe2" ( fe2 is an out-going interface to CE2)
> > > B) Redistribute the static to bgp, route-export = 200 ( due to
> > > full-mash Mp-ibgp, PE1 and PE3 learn this route but only PE1 imports
>
> > > it), In PE3 config,
> > > A) put a static route to CE3 = "ip route vrf down 10.3.3.0
> > > 255.255.255.0 fe3" ( fe3 is an out-going interface to CE3)
> > > B) Redistribute the static to bgp, route-export = 200 ( due to
> > > full-mash Mp-ibgp, PE1 and PE2 learn this route only PE1 imports
> > > it), In PE1
> > > A) put the interface connecting CE1 to VRF down
> > > B) Import routes w/ route target =200 from MP-BGP advertised by PE2
> > > and PE3
> > > C) CE1 have static routes to PE1 for ip prefix destined to CE2 and
> > > CE3
> > >
> > > In this way, any traffic from CE1 to CE2 or CE2 will be sent to PE1,
>
> > > which will forward it based on VRF down routing table.
> > >
> > > What am I missing?
> > >
> > >
> > > Jongsoo
> > >
> > >
> > >
> > > On 11/4/05, Scott Morris <swm@emanon.com> wrote:
> > > > This is definitely fun to keep the SP list alive, although I'm
> > > > surprised
> > > we
> > > > haven't irritated the R&S guys yet!
> > > >
> > > > Anyway... If I were presented a situation (again, real life
> > > > thinking)
> > > where
> > > > someone said they wanted to essentially set the "hub" site up as a
>
> > > > route-reflector, my first inclination would be to do static routes
>
> > > > between the PE and CE and let their CE routers peer with each
> > > > other and not with
> > > the
> > > > PE at all. That would seem to be a simple way of the SP saying
> > > > "not my problem" and save a few headaches.
> > > >
> > > > Like Andrew says, the goal here is to make the CE fairly ignorant
> > > > of the VRF's existance (although with allowas-in, it kinda makes
> > > > that
> > moot).
> > > >
> > > > If this were a lab scenario, you'd certainly need to look at what
> > > > things
> > > you
> > > > were or were not allowed to do, but I'd keep it as simple as
> possible!
> > > >
> > > > Scott
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> > > > Behalf Of Andrew Lissitz (alissitz)
> > > > Sent: Friday, November 04, 2005 12:43 AM
> > > > To: Jongsoo
> > > > Cc: C&S GroupStudy; FORUM
> > > > Subject: RE: "neighbor allowas-in" command ( SP CCIE)
> > > >
> > > > You are right Jongsoo ... I need to keep my head out of reality
> > > > for the
> > > CCIE
> > > > prep ...
> > > >
> > > > As you know, for CCIE lab, so much will depend on wording of
> question.
> > > > Thanks for the diagram, it helps.
> > > >
> > > > So if CE2 and CE3 must go through CE1, then these two sites must
> > > > choose to route to the hub site first.
> > > >
> > > > Normal routing would work. Forgive me if this is boring anyone ...
>
> > > > I am
> > > just
> > > > going to 'think out loud' in this email.
> > > >
> > > > The CE and the PE share routes. The PE keeps these routes in the
> > > > VRF, the CE is (typically) ignorant of VRF and does not know what
> > > > goes on within
> > > the
> > > > PE. Using iBGP all PEs will share this information so that any PE
>
> > > > with
> > > the
> > > > same customer VRF will have a converged routing table.
> > > >
> > > > So depending on what you are or are not permitted to do you can
> > > > focus on
> > > CE
> > > > or PE route manipulation. If this is done via the CE, then
> > > > manipulate or filter your IGP so that the next hop is the hub.
> > > > The PEs simply share
> > > what
> > > > they have learned, unless you have configured them otherwise.
> > > >
> > > > If you do this on the PEs, then filter routing information so the
> > > > spoke
> > > CEs
> > > > think that the hub is the next hop for any where. This could be
> > > > done
> > > either
> > > > iBGP, or if the PE and CE run a IGP between them, then filter the
> > > > routing information via the PE IGP. The CE IGP will only learn
> > > > what is administratively allowed.
> > > >
> > > > If you can redistribute a static default on the hub PE, cool. You
>
> > > > can
> > > allow
> > > > only this default to the remotes and allow all | m the spokes to
> > > > the
> > hub.
> > > >
> > > > Suggestion to the group... Do you all think we should start a new
> > > > email string to discuss these options? If we are done with this
> > > > allowas-in discussion, then lets create another email string.
> > > >
> > > > Jongsoo, thanks man for keeping these emails going. You going for
>
> > > > your SP CCIE helps us all!!!
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Jongsoo [mailto:bstrt2004@gmail.com]
> > > > Sent: Thursday, November 03, 2005 8:08 PM
> > > > To: Andrew Lissitz (alissitz)
> > > > Cc: C&S GroupStudy; FORUM
> > > > Subject: Re: "neighbor allowas-in" command ( SP CCIE)
> > > >
> > > > 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
> > > >
> > > >
> > > ____________________________________________________________________
> > > __
> > > _
> > > > 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