cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1015
Views
5
Helpful
3
Replies

Guys , what the Unified MPLS Solve , i watched INE ,they explain : "Scalability"

Ibrahim Jamil
Level 6
Level 6

Hello Overseas Freinds

 

Guys , what the Unified MPLS Solve , i watched INE ,they explain : "Scalability"

 

we could have IGP Islands (IGP + Label) and BGP in the Core connect these IGP Islands ( BGP + Label)

 

sitill dont understand what the UMPLS solved over MPLS Backbone

 

guys , pls explain to me in Plain english

3 Replies 3

Adam Vitkovsky
Level 3
Level 3

Hi

 

In single area approach for the whole MPLS network, each node (PE/P/RR) in the network would have to hold at least all PE loopback routes and their associated transport labels for all other PEs in the backbone

-this is because link-state IGP (like OSPF or ISIS) demands that each node in an area/level must have the same link-state database (LSDB).

So if you have 100,000 PEs in the network each one of these PEs need to hold 100,000 loopbacks in its LSDB and RIB and FIB.

You simply can’t choose what you’ll accept and what not (it’s basically all or nothing)

 

Now imagine you have this group of PEs that only need to talk to just a few other PEs in the core of this huge MPLS network (imagine this group of PEs is interested only in a specific service that is offered just by a handful of PEs in the core) –so there’s no need for PEs in this group to hold information about how to get to all the 100,000 other PEs in the whole network (it’s just a waste of resources for these guys to hold that many routes for no reason) –they just need to know how to get to these couple other PEs that provide this one specific service that’s it.

 

Now to address this problem what we can do is to group these lucky PEs that don’t need to talk to everyone but to just a few selected PEs into a separate OSPF area or ISIS level 1 or actually have them run their own IGP protocol that is completely separated from the rest of the network and the IGP that the rest of the network runs. This solves the problem because now this separate OSPF area or ISIS level 1 or IGP can carry just a few prefixes so problem solved.

Well not so fast,

Now we still need to make sure this separated group of PEs is getting the routes for the few PEs in the core that they need to be able to talk to cause these are providing the special services these PEs are after, and vice versa these PEs in the core providing the special service need to know how to get to all PEs in this separate area/level/IGP.

But now you actually have a choice what information to leak down to this group of lucky PEs, you’re in control , no more all or nothing rule.

You can now decide what routes should be

  1. redistributed from core IGP to this area/level/IGP
  2. advertised to PEs in this area via BGP-LU

 

So this seamless MPLS or hierarchical MPLS is about giving the control back to operators for how the network is scaled, as now you can chose what information and how much of it will be leaked to these areas/levels/IGP domains.

Which is very important since in practice these areas/levels/IGP domains usually contain PE routers that ate not very powerful (don’t have much RAM or CPU)

 

adam

 

netconsultings.com

::carrier-class solutions for the telecommunications industry::

 

adam

a-gould
Level 1
Level 1

I was trying out BGP-LU in my lab.  I was trying using a xconnect mpls pseudowire from end to end, each PE being in its own separate disjointed igp domain.... so trying to use BGP-LU to link them together for the end to end "unified" mpls L2 service.  When I tried at the igp boundaries using ebgp, directly on the link, it wouldn't work... but when I used ebgp between loopbacks with m-hop 2, it worked.  I wonder why I had to do ebgp mhop between loopbacks to make this work.

Hi @a-gould ,

It should work without eBGP multi hop. I am not sure what the issue you experienced is. We do not have enough information to help at this point and please next time, try to open a new discussion to get help from the community, rather than reusing old discussions. It makes it less confusing.

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México