OSPF Area Range and MPLS

[juandyb01]

Hello:

I have an scenario with OSPF and MPLS.

OPSF is configured with multiple areas and in the ABRs I'm using the area range command to aggregate the IP addresses on the area 0 to improve the size of the IP routing tables.

All the routers have MPLS LDP configured on all the interfaces and I have noted the following showing the MPLS Forwarding Table.

The Mpls Forwarding table for the Ingress LSR have the aggregated prefix of another are with a Local tag and Outgoing tag.

In the ABR of this area the router have the aggregated prefix with the incoming label the same as the remote label of the remote label of the previous router. But the Outgoing label is "Pop Tag" and the LSP isn't finished.

The next router in the LSP is the ABR of the destination area and this LSR have the normal prefix (not aggregated) in the MPLS forwarding table with an local tag and the Outgoing tag is "Pop Tag" (because this ABR is the Penultimate router).

Why mpls ignores prefixes aggregates and creates different associations?

If I quit the OSPF Area Range Command the first ABR doesn't show the outgoing label as "Pop Tag". So it seem that Aggregate Addresses are not a good idea in MPLS.

Thanks for your help.

[Renan Abreu]

Hi Juan,

     When you configure area range there's a new route created by ABR and thus a new mpls label as well, the problem is, the ABR will be the one to generate that label, so, the adjacent router would perform PHP and then you broke your LSP.  Usually you shouldn't have multiple areas in your core, but maybe, maybe, if you disable php this problem disappears, I have doubts if it should, but it is worth the try.

[juandyb01]

Hello:

Thanks for your answer. If i understand the best is not to interrupt the LSP with don't use aggregate routes ¿this is correct?

I will try disabling the PHP and I will tell you something.

Thanks for your help.

[Renan Abreu]

Absolutely, maybe PHP works, but I wouldn't use aggregates and I'd leave PHP on.

[juandyb01]

In conclussion. when you use MPLS have higher routing tables but with the advantage of having in forwarding through label switching.

I haven't try to quit PHP, I don't know how to do it and I think PHP is good feature of MPLS.

¿This is a good conclussion? Thanks for your help.

[Renan Abreu]

Well, not necessarily a bigger routing table (and the advantages for MPLS are various), usually you would summarize at the PE, if you do it you're good to go, If you do summarization on the core you will have this problem. If you have a hierarchical network (Core/Aggregation) you can shorten your RIB not redistributing one IGP into another if you want (assuming you have one IGP for CORE and another one for the aggregation ntw), this is called unified MPLS.

http://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/116127-configure-technology-00.html

[juandyb01]

Hello:

Thanks for your answer.

My ISP does not have the client routes as OSPF external routes.

In the PE I have used a network command to include the client routes in OSPF makig the interfaces to clients as passive. The command to summary address on the ASBR (PE) does is the summary-address command and I'm not sure if it works with non external routes or only is for external routes.

My ISP have OSPF as IGP and MPLS for the traffic inside the ISP, also I have BGP with multiples ISPs, so I do not have more than one IGP as your describe.

Thanks for your answer. With regards, Juan.

[Renan Abreu]

Hi Juan,

     Yes, in your case, does not seem you have much possibility :-(

[juandyb01]

I have included the clients IP addresses by this way to make it as internal routes of OSPF and avoid problems if i redistribute OSPF into BGP.

Making this by this way instead of redistribute client routes into OSPF is one thing that i have seen recommended in Cisco CCNP Route book in the chapter of EIGRP.

I'm not preparing the CCNP, this is for my final career project, and I'm learning a lot reading the books and asking here  ... So thanks for your reply :)

With regards, Juan

[Renan Abreu]

Not a problem :-)

Just for reference, you can redistribute OSPF external into BGP, but you would need to evaluate pretty well what you are doing

redistribute ospf x match internal external 1 external 2