OSPF issue

[mahesh-gohil]

Dear netpro

i am having one issue with one of my customer running OSPF as PE-CE.

he is advt. me one pool 10.219.1.96/28 from PE1 .

But when I do trace from PE4 it goes to PE3---CE3---PE2---CE1.

Infact it should go directly to PE1-CE1

He is not advt this pool from CE3. When we change redistribution metric to 15 at PE1 to MPBGP problem get resolved .

But this seems to be temporary solution and I am seeking another solution to this issue.

Some output might be useful (Also attached diagram)

PE1#sh ip route vrf CE-M 10.219.1.96

Routing Table: CE-M

Routing entry for 10.219.1.96/28

Known via "ospf 4", distance 110, metric 20

Tag 125, type extern 2, forward metric 1

Redistributing via bgp 1234

Advertised by bgp 1234 match internal external 1 & 2

Last update from 10.254.225.74 on GigabitEthernet2/0/0.187, 03:51:52 ago

Routing Descriptor Blocks:

* 10.254.225.74, from 10.254.225.78, 03:51:52 ago, via GigabitEthernet2/0/0.187

Route metric is 20, traffic share count is 1

Route tag 125

PE4#sh ip route vrf CE-M 10.219.1.96

Routing entry for 10.219.1.96/28

Known via "bgp 1234", distance 200, metric 20, type internal

Redistributing via ospf 6

Advertised by ospf 6 subnets

Last update from 202.123.47.228 10:21:41 ago

Routing Descriptor Blocks:

* PE3 (Default-IP-Routing-Table), from RR, 10:21:41 ago

Route metric is 20, traffic share count is 1

AS Hops 0

PE3#sh ip route vrf CE-M 10.219.1.96

Routing entry for 10.219.1.96/28

Known via "ospf 6", distance 110, metric 20

Tag 125, type extern 2, forward metric 5

Redistributing via bgp xxxx

Advertised by bgp 1234 match internal external 1 & 2

Last update from 10.254.224.110 on GigabitEthernet8/1.318, 04:02:22 ago

Routing Descriptor Blocks:

* 10.254.224.110, from 10.254.225.78, 04:02:22 ago, via GigabitEthernet8/1.318

Route metric is 20, traffic share count is 1

Route tag 125

Regards

mahesh

[Harold Ritter]

Mohamed,

One more thing. Where did you see that the CEs were multi-VRF.

The purpose of the down bit would normally be to prevent a route that has been received from BGP and redistributed into OSPF to be reinjected into BGP. This specific route we are discussing is not redistributed from BGP but rather redistributed from some other protocol on CE1.

By the way, the cisco implementation doesn't use the down bit for the purpose of loop prevention for type 5 LSAs but only for type 3 LSAs. The type 5 LSAs loop prevention is done via the external route tag.

Regards

[Mohamed Sobair]

Harold,

I havent seen multi-vrf CE router, I assumed that or why else he wants to disable the down bit check?

The Second point:

I though the Cisco implementation takes the (Down-bit) for both Type-5 & 3 LSAs.

Thanks for the valuable info.

Mohamed

[Mohamed Sobair]

Harold,

By the way:

"From what you were saying regarding the (Down-bit) which makes sure the route from BGP when gets redistributed is never back, then the book needs to be corrected.

FROM what written and illustrated on the BOOK: The Down bit check has to be disabled in a multi-vrf CE router which should be configured on the PE connecting the Multi-vrf CE router. This doesnt include BGP or any redistribution from BGP to OSPF.

This Harold was shown by a diagram and written as well in (VRF-Lite) Implementation which doesnt include BGP!

Greatly appreciate your clarification,

Mohamed

[Harold Ritter]

Hi Mohamed,

Could you please give me a pointer to the book that you are referring to.

The only device that will set the down bit is the PE and as I said it will do it only for summary LSAs (type 3 LSAs).

It is true that if you receive a type 3 LSA on a CE running VRF-lite that you need to disable the down bit check using the command "capability vrf-lite" but this does not apply to type 5 LSAs.

I am still not sure were you saw that the original poster was using VRF-lite on the CE.

Regards

[Mohamed Sobair]

Hi Harold,

The book I was referring to is (MPLS Fundamentals), However, its well explained in MPLS VPN Architecture Volume 2 chapter 4 (Virtual router connectivity), while its not in MPLS fundamentals.

Thanks Harold for the info,

Mohamed

[mahesh-gohil]

Hi all,

Customer is not running multi vrf.

His main agenda is listern what customer is telling "if I have given prefix to PE1 why you are giving me back from PE2 to CE3 and again why your PE3 accepting this route back "

Why unnecessarily my BW from PE3 to CE3 utilised.

Guys I am seeking solution. route tag is the mechanism but my PE is not supporting same.

Does SOO solve this problem. I have also tried same but I can't see any soo cummunity when attached at PE1.

Ultimately what is the solution and solution should not be temporary (As I have already applied temporary solution by reducing metric)

Also provide me config of solution if possible or any link to that document

Regards

Mahesh

[Harold Ritter]

Mahesh,

I have already provided you the solution, which is to change the metric-typ from 2 to 1. Did you try it?

Regards

[marikakis]

Hello,

I totally agree with Harold. He has provided a good solution at a very early stage in this conversation. I independently thought of the same thing and suggested it, and although I was not very confident at the time, now that I think more clearly, I support Harold's view of this case. Any other solution means more configuration from your side in a non-scalable way. Keeping end-to-end metric information at redistribution points will ensure you will not soon face similar issues with other networks being accessible by any potential backup path that exists now and in the future.

Kind Regards,

M.

p.s. Also note that Harold typically provides good solutions at complex issues and helps everybody here to learn for years now.

And your issue doesn't have to do with SOO. SOO is typically utilized to solve issues with loops in routing information. You do not have such a problem here. Routing information flows correctly. The issue is that routing information does not have enough in it to make an educated decision about the preferred path. You need to inject more details in the routing information so that paths that are not equal are indeed considered as such.

[mahesh-gohil]

Dear Harold,

Can you provide me config as how can i change metric type 2 to 1. Do I need to do at PE or should I ask customer to do at CE.

Please guide

Regards

mahesh

[shivlu jain]

under OSPF process you can use the command given

redistribute static subnets metric-type 1

regards

shivlu jain

[Harold Ritter · Accepted solution]

Mahesh,

I had provided the sample config in a previous post. This need to be done on the router where the route (10.219.1.96/28) gets redistributed into OSPF.

Please refer to the following post for the configuration sample:

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Service%20Providers&topic=MPLS&topicID=.ee8558c&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40^1%40%40.2cd2496b/13#selected_message

Regards

[marikakis]

Just on thing: if redistribution commands keep resetting the metrics at the PEs, I think the solution will not be effective. What do you think Harold?

Still, even if some work needs to be done in PE redistribution commands (OSPF->BGP and BGP->OSPF), you need those commands anyway on your PEs and it does not increase your overhead much. Note, that you also have the option in other customer cases to consider unequal paths as seemingly equal to satisfy customer load balancing scenarios. And I think you also have the option to set things on the PEs only to avoid customer involvement in some cases.

[Harold Ritter]

Maria,

The PE should not reset the metric but just use it to set the MED as the route is redistributed into BGP.

Regards