From: Arun Arumuganainar (aarumuga@hotmail.com)
Date: Fri Nov 04 2005 - 04:20:35 GMT-3
Hi Scott ,
I think requirements of Jongsoo is pretty straight forward . The deployment
is termed as HUB & SPOKE MPLS VPN !!!You can find such deployment in real
life scenario ...Although it is not common !!!
Here are some of the common reasons why it is deployed in real life.
1) Security services (filters)
2) Traffic logging and/or accounting
3) Intrusion Detection systems
So the scenario is a valid and real one .
Coming back to your design . i.e Having Static routes on PE and allowing
CE-CE peering . This is very much a workable solution . But definitely not a
scalable one . Let me explain why it is not scalable . Suppose we have N CE
sites .
1) Then you would need N VRFs N interface /Subinterface on both HUB CE and
its connected PEs to complete the setup .
2) Also you need to maintain N number of CE-CE peering at the CE sites .
When this N is really large Scalability will get affected . Also let us a
argue this way . Why does the SP wanted to offload responsibilities to CEs .
SPs are increasingly tring to provide a value added services to customer .
This will definitely improve his topline . So smart SPs would like to take
up more responsibility with eye on more revenue being generated through
their value added service .
Cisco infact provides a scalable deployment method to tackle this kind of
problem . Ofcourse this will involve active participation of SPs . With this
solution no of VRF and subinterface in HUB CE is reduced to 2 irrespective
of the value of N . More over Peering at all CE is done beteween connected
PEs and Hence over head here is very very less .
http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chap
ter09186a0080442090.html
Thanks and Regards
Arun
----- Original Message -----
From: "Scott Morris" <swm@emanon.com>
To: "'Andrew Lissitz (alissitz)'" <alissitz@cisco.com>; "'Jongsoo'"
<bstrt2004@gmail.com>
Cc: "'C&S GroupStudy'" <comserv@groupstudy.com>; "'FORUM'"
<ccielab@groupstudy.com>
Sent: Friday, November 04, 2005 11:22 AM
Subject: We've moved to PE-CE routing! (SP-CCIE)
> 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
>
> _______________________________________________________________________
> 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