From: Andrew Lissitz \(alissitz\) (alissitz@cisco.com)
Date: Fri Nov 04 2005 - 10:23:28 GMT-3
Good morning,
A very very very large service provider does static on many CE and PE
remote sites... It is administratively burdensome but it does has some
advantages. For one thing, it takes less processor to runs static than
a IGP. Also, running IGPs for all the different customer VRFs on one PE
is not easy either or light. In either case ... this is not related to
lab prep.
Static option:
Default static on CE
Statics on all PEs, redistribute this to MPiBGP
The hub will learn all routes
On the hub, I am not sure why you mention you would need one interface
per remote site... Did I understand what you are saying? Are you saying
that using static routes requires more interfaces and VRFs? Again the
CEs, whether these are remotes or hub, are ignorant of what goes on
within ISP network. If your central site is multipoint, then one site
reaches all remotes. Please clarify if I misunderstand what you were
saying.
Having two links @ hub is common. One for inter-site vpn connectivity
and one for internet access.
Arun, nice link. I had never heard of half duplex VRFs for remote
sites. Another way to limit what routes are learned @ a remote site...
-----Original Message-----
From: Arun Arumuganainar [mailto:aarumuga@hotmail.com]
Sent: Friday, November 04, 2005 2:21 AM
To: Scott Morris; Andrew Lissitz (alissitz); 'Jongsoo'
Cc: 'C&S GroupStudy'; 'FORUM'
Subject: Re: We've moved to PE-CE routing! (SP-CCIE)
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!!!
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:05 GMT-3