From: NoTe ^-^ (note@ji-net.com)
Date: Wed Jan 26 2005 - 15:52:15 GMT-3
Dear all expert.
Please see the detail in the attach file, May be help you for clarify in my
Question?
I have a question about core migration step for service provider..then If in
the old MPLS core network is used multiple OSPF area
for IGP & running MBGP for apply MPLS VPN service to customer. Different
service has binded in the different VRF, Existing core
have 4 core router ( P ) & run MBGP used to RR (Router Reflector) without
cluster for a lot of all PE client in several distributed area,
(I known that it is bad design haha!). 4 P core router have 2 peer group,
1st peer group is full mesh peering between 4 P & 2nd peer
group is Hub for all PE in the distributed area is connected to this P
?..All of PE can separate to 4 group by area, PE in each group
is peering to RR (P) with 1 peer via pysical interface. (1 PE have 1
neighbor peer to 1 P, P is promoted own to RR). Bad design again ?
PE is not have route reflector redundancy......but still stable...very
lucky!! until..subscriber has grown very fast..so we need to implement
new core for handle traffic from more subscibers ... Redesign routing
achitecture & route reflector with clustor should be done.... I am
redesigning for enhance routing update redundancy. 1 PE in all distributed
area group have 2 neighbor peer to 2 RR & select 2 PE
in the same & near distributed area group and promote to route reflector, 2
PE route refector in the same cluster id for avoid routing loop
then selected 4 PE in 4 distributed area and separate to 2 different cluster
group id.
Cluster 1 have 2 RR (2 PE) & all PE in the same distributed area of RR is a
client which have 2 peer to 1st RR in the same distributed area
2nd RR in nearly distributed area in the same cluster group id. Cluster 2 is
in the same concept.
In each 4 new RR (new PE) have 2 peer group, 1st is full mesh peer group for
advertise routing update to all 4 RR in the different 2 cluster.
Is it a good design ??? Do you have any comment?
Until.. implementation process about physical is already finished, but the
best difficult step that to say is migration service to new core !!!
New core have 4 new P & must cut over all PE in all distributed area to 4
New P. What is should be considered before migration service?
How can I do first?
In my opinion .. First step i will configuring 4 new P to same backbone OSPF
area of old core & recheck IGP all of them can update &
have correct path. Step to I will run MBGP with same AS number with old core
& full mesh neighbor peer between old 4 P (RR) to 4 New P
& create all of them to same cluster id group. But in the next
step..........????????
I'm not sure.... required suggestion from any expert to advise me for do in
the next step.. How to migrate old MPLS core which use old P to
Route Reflector without clustor which have 2 peer group (1st for full mesh
between 4RR (P) , 2st RR use Hub-spoke topology peer to PE).
All of PE have 1 peer to 1 RR(P) migratie to the newcore which have new 4 P
& select 4 new PE has promoted own to new 4RR & have
2 different clustor id ( 2PE in 1 clustor id), 4 new PE have 2 peer group
(1st for fullmesh peer between 4 RR across different clustor id ,
2nd is patial mesh peer to PE in distributed area). PE in distributed area
have 2 RR peer in same clustor for redundancy & avoid loop.
Don't forgot it about cut over step all PE in distributed area to the 4 new
P & 4 new P don't run BGP & Finally old 4 P is not use for RR.
New 4 P should be responsibility only for forwarding more packet so that is
not approriated for handle more routing update!
How can I continue do this for the migration step ?.......so difficult ...&
more complexity.. the best important issue is minimize all
downtime of the migration step procedure because it effected for the Large
Enterprise customer. Please help me!
Thanks you very very much in advance.
Best Regards,
Ralf.
Backbone Engineering & Services Development Team
Service Provider Solution & Network Engineering Department
Network Service Provider in Asia Pacific area.
[GroupStudy removed an attachment of type application/vnd]
This archive was generated by hypermail 2.1.4 : Wed Feb 02 2005 - 22:10:25 GMT-3