MPLS TE database does not receive a prefix from pure non-MPLS OSPF router?

[Vadym Belyayev]

Hello guys,

I am planning an MPLS TE topology and I came across one issue which I do not understand very well.

Considering this simple scenario

1. All the routers run OSPF and share all the routes

2. R4 and R5 both have tunnels pointing toward one another

3.When you enable autoroute on tunnels, they stop seeing 10.78.0.0/16 network which is being announced via OSPF

4. I see that this prefix disappears from TE topology database on R4 and R5 (If I enable mpls on R3, it appears on R4 and R5, if I run "no mpls traffic-eng area 0" on R3 and clear ospf process on R4 and R5, the prefix disappears.  Therefore the R4 and R5 cannot reach the prefix.

I am definitely missing some theory here, however, I was not able to find a clear answer on this in my books.

My questions are:

1. If my routing table has only Tunnel100 as outgoing interface, does this mean that I loose the ability to route via OSPF?

2. I have some 1900 routers in my network that run OSPF, does this mean that if I do not use them as mpls speakers (with mpls traffic-eng area 0 under OSPF process) their networks will become unavailable?

3. I thought that a packet toward a non-MPLS TE speaker is being forwardes to the tail-end router and then from there it travels via IP, am I mistaking?

Thanks a lot as usual!!

[Nagendra Kumar Nainar · Accepted solution]

Hi Vadym,

3.When you enable autoroute on tunnels, they stop seeing 10.78.0.0/16 network which is being announced via OSPF

<Nagendra> Do you mean "show ip route 10.78.0.0" is not showing any output in the routing table?. Can you get "show ip route <>" and "show ip cef <>" with and without autoroute?.

4. I see that this prefix disappears from TE topology database on R4 and R5 (If I enable mpls on R3, it appears on R4 and R5, if I run "no mpls traffic-eng area 0" on R3 and clear ospf process on R4 and R5, the prefix disappears.  Therefore the R4 and R5 cannot reach the prefix.

<Nagendra> THis is expected. Enabling "mpls traffic-eng tunnel area 0" under OSPF triggers the local router to originate Opaque LSA in addition to the traditional Router/network LSAs. These Opaque LSA are the one we will see in TE database. So when you disable the command on R3, it stops advertising the Opaque LSA and so you wont see any R3 related (or beyond) prefixes in TE database.

1. If my routing table has only Tunnel100 as outgoing interface, does this mean that I loose the ability to route via OSPF?

<Nagendra>When you enable autoroute, all the prefixes connected to the tunnel destination and any prefix that is over this node will be marked with tunnel as egress interface. If the tunnel is down, it takes the OSPF path. 

2. I have some 1900 routers in my network that run OSPF, does this mean that if I do not use them as mpls speakers (with mpls traffic-eng area 0 under OSPF process) their networks will become unavailable?

<Nagendra>Normally no. Though it is not very beneficial to run MPLS TE in selected node and not on other nodes within same domain. In your case, we need to check why the route is missing from RIB/FIB when enabling autoroute.

3. I thought that a packet toward a non-MPLS TE speaker is being forwardes to the tail-end router and then from there it travels via IP, am I mistaking?

<Nagendra> Right. In your case, R4 and R5 are back-to-back connected. So the TE label will be imp-null. When a packet is sent destinated to 10.78.0.0, it simply will forward without any label (as it is imp-null) to R5.

[Vadym Belyayev]

Thank you very much Nagendra, this was just a lab scenario.

In reality I am having issues with a production environment.

Especially with one particular network that is not pingable, but you can do tracertoute, it is weird and I think I have lost some important concept points here...

Let me tell you if I understand everything correctly.

My topology is almost the same as the other one

Basically I cannot reach 10.78.0.0/16 prefix beyond R3. In fact I cannot reach it via ping, but I can reach some devices in the network via traceroute.. However, some subnets cannot be discovered via Network Browser, it is weird..

I Cannot reach the 10.78.0.0/16 network from R1 via ping, but I can reach this network from R2, the network. It all starts when I enable autoroute on R1

What are the correct steps to check everything is ok?

1. First of all check if the route exists in the routing table and CEF table, but this serves what purpose? Just to check if I have the route to the destination which serves as an underlying thing for the MPLS?

2. One I checked I have the route, I usually go to the TE topology database and then to the OSPF opaque-area LSAs, but first the Link-ID 1.0.0.0 confuses me, because I do not see my prefix 10.78.0.0/16 in the TE database neither the OSPF opaque-area LSAs..

R3 full OSPF config

router ospf 100
 router-id 10.200.1.4
 auto-cost reference-bandwidth 10000
 area 0 authentication
 redistribute static subnets
 passive-interface default
 no passive-interface GigabitEthernet4/1
 no passive-interface GigabitEthernet4/4.727
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng area 0
 mpls traffic-eng multicast-intact

R2

router ospf 100
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng area 0
 mpls traffic-eng multicast-intact
 router-id 10.200.1.2
 auto-cost reference-bandwidth 10000
 area 0 authentication
 redistribute static subnets route-map STATIC
 redistribute eigrp 100 subnets route-map SUM
 passive-interface default
 no passive-interface GigabitEthernet0/1
 no passive-interface GigabitEthernet0/2.705
 no passive-interface GigabitEthernet0/2/0
 no passive-interface Vlan1
 no passive-interface Vlan316
 

R1

router ospf 100
 router-id 10.200.1.1
 auto-cost reference-bandwidth 10000
 area 0 authentication
 redistribute connected subnets
 redistribute static subnets route-map PRUEBAMPLS
 default-information originate
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng area 0
 mpls traffic-eng multicast-intact
!

[Nagendra Kumar Nainar]

Hi,

I see 10.78.0.0 is redistributd into OSPF. So R1 should have it as extenal and when autoroute is enabled, AFAIK it will point it over the tunnel.

Can you try disabling/removing "no routing dynamic" from under the TE tunnel?. I havent tried it under TE tunnel and not sure if it contributes to the issue.

-Nagendra

[Vadym Belyayev]

I still dont see the 10.78.0.0/16 in my opaque-area database.. Should I see the redistributed prefixes? Seems like I only see common standard intraarea networks

I have put routing dynamic under both tunnels

[Nagendra Kumar Nainar]

I still dont see the 10.78.0.0/16 in my opaque-area database.. Should I see the redistributed prefixes?

<Nagendra> No. You wont see it in opaque database. 

Seems like I only see common standard intraarea networks.

<Nagendra> This is expected.

Can you  get "show ip route 10.78.0.0" and "show ip cef 10.78.0.0" to see why is it not forwarding?.

-Nagendra

[Vadym Belyayev]

I have the tunnel without autoroute right now, otherwise it would affect some big production networks

Right now it looks like this

[Vadym Belyayev]

Ok Nagendra, should I have it in my mpls TE database then? Because it seems like I dont have it.. I dont understand how do I check the reachability to the prefix if it is not supposed to have it in OSPF database and TE database..

[Nagendra Kumar Nainar · Accepted solution]

TE database is required only to build your tunnel. In you case, the tunnel is not built with destination as 10.78.0.0 or it is not used as part of ERO. So it is not required to be in TE database. 

But in order to have reachability, it should be in OSPF database whcih I believe it is - as external LSA. We may need to check what you see in routing and CEF table when autoroute announce is enabled. You were mntioning about some lab setup. Do you have this issue in lab setup?. If so, can you get the output with autoroute announce enabld?.

[Vadym Belyayev]

Nagendra, I think I have got almost all answers from your posts. Unfortunately I was not able to reproduce this issue in Lab, dont know what may be different, maybe I will try to build a lab exactly the same as the production network.. Anyway I will be dealing with this issue during one of the upcoming weekends, just to not to affect anything.

I will check all you have told me and post the output if youre interested obviously, because you already helped me much

[Nagendra Kumar Nainar]

yea sure. share the output if you see the issue and accordingly we can check further.

-Nagendra

[Vadym Belyayev]

Nagendra, how are you?

The site is a bit critical and I am doing the same for another site and stumbled upon a similar issue, is it a bit weird and I do not know what else to do..

Here is the topology:

Basically the issue is the following:

1. I create a TE bidirectional tunnel104 between R2 and 2900

2. I enable autoroute announce on R2 Tunnel104, everything is ok

3. I do the same on the 2900 and things start to happen. All the pings are ok.. But!

All the pings from my PC 10.200.7.138 to 10.24.4.0/22 network pass through. Pings from SolarWinds Network browser discover only 20% of the network, the pings are simply not replied, I do not for what reason.

Also the web interface of the printer 10.24.4.251 and other printers does not answer when I enable autoroute on 2900..

The path is the following:

I reach the 10.24.4.0/22 network from 10.200.7.138 through and ASR which builds the DMPVN tunnel and forwards the traffic to R1. R1 has a connection with an ISP and forwards the encrypted packet to 1900. The 1900 decrypts the packet and forwards it to the destination.

The return traffic is via a static route on 1900 through 2900 to reach 10.200.7.0 (my management network), other things are through tunnel built through ISP, so it should pass through the tunnel when it comes back..

[Vadym Belyayev]

Nagendra, there was one issue I did not tell you about. One thing I need to check on all our 6500 routers.

Under the OSPF process we have redistribute static subnets and it is redistributing them without any filter. (only on 1 with filter), Before I had an issue that if I was enabling the tunnel,  I was getting a routing loop, because my tunnel route resulted shorter than a neighbors IGP path and the neighbor should send me his traffic toward this static route, instead of routing it to destination. Upon receiving the traffic I was sending it back to the neighbor and so on..

After I created the route-map and attached it to redistribute static subnets, denying some subnets I was able to get rid of the L3 loop. I am thinking that maybe I should do the similar tuning on all the 6500 Switches allowing those Static routes we already have and denying everything else and then try