mpls and ospf

jonathan johnson · ‎10-13-2013

Hi,

I was hoping someone might be able to clarify a question I have regarding my network setup.

I have 4 7204's that all have mpls running between them (2 edges and 2 cores). I'm also using ospf as a routing protocol across all 4 routers. Because of historic reasons I have "redistribute connected subnets" and "redistribute static subnets" configured.

When I look at the CEF table - sh cef x.x.x.x detail there is no reference to mpls tags in the output - whereas a Cisco example I was looking at did.

As it stands I have connectivity to all connected networks from one end of the network to the other. However, as I understand it, mpls shoud, create a label for each network and distrubte that across all mpls routers. If my understanding is correct, do I need to have the redistribute statements in the router configs? I'm aware that I'll need to have a network statement within OSPF for the loopback that identified the router within mpls "network 10.10.10.1 0.0.0.0 area 0.0.0.0"

Thanks in advance,

Jonathan

Peter Paluch · ‎10-13-2013

Jonathan,

I've done a quick and dirty test in my dynagen - four routers in a row, R1---R2---R3---R4, all running OSPF and MPLS, with R1 having three loopbacks, 192.168.{1,2,3}.0/24 redistributed into OSPF via redistribute connected. The labels appear to be assigned throughout the path:

R4#show mpls forwarding-table

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface

16 Pop tag 10.255.255.3/32 0 Fa0/0 10.0.34.3

17 16 10.255.255.2/32 0 Fa0/0 10.0.34.3

18 17 10.255.255.1/32 0 Fa0/0 10.0.34.3

19 18 10.0.12.0/24 0 Fa0/0 10.0.34.3

20 Pop tag 10.0.23.0/24 0 Fa0/0 10.0.34.3

21 20 192.168.3.0/24 0 Fa0/0 10.0.34.3

22 21 192.168.2.0/24 0 Fa0/0 10.0.34.3

23 22 192.168.1.0/24 0 Fa0/0 10.0.34.3

R4#traceroute 192.168.3.1

Type escape sequence to abort.

Tracing the route to 192.168.3.1

1 10.0.34.3 [MPLS: Label 20 Exp 0] 56 msec 56 msec 40 msec

2 10.0.23.2 [MPLS: Label 20 Exp 0] 76 msec 60 msec 60 msec

3 10.0.12.1 56 msec * 24 msec

R4#traceroute 192.168.2.1

Type escape sequence to abort.

Tracing the route to 192.168.2.1

1 10.0.34.3 [MPLS: Label 21 Exp 0] 60 msec 60 msec 52 msec

2 10.0.23.2 [MPLS: Label 21 Exp 0] 64 msec 60 msec 60 msec

3 10.0.12.1 56 msec * 32 msec

R4#traceroute 192.168.1.1

Type escape sequence to abort.

Tracing the route to 192.168.1.1

1 10.0.34.3 [MPLS: Label 22 Exp 0] 52 msec 52 msec 60 msec

2 10.0.23.2 [MPLS: Label 22 Exp 0] 64 msec 52 msec 40 msec

3 10.0.12.1 56 msec * 52 msec

R4#show ip route ospf

10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks

O 10.0.12.0/24 [110/30] via 10.0.34.3, 00:05:11, FastEthernet0/0

O 10.255.255.2/32 [110/21] via 10.0.34.3, 00:05:11, FastEthernet0/0

O 10.255.255.3/32 [110/11] via 10.0.34.3, 00:05:11, FastEthernet0/0

O 10.255.255.1/32 [110/31] via 10.0.34.3, 00:05:11, FastEthernet0/0

O 10.0.23.0/24 [110/20] via 10.0.34.3, 00:05:11, FastEthernet0/0

O E2 192.168.1.0/24 [110/20] via 10.0.34.3, 00:04:15, FastEthernet0/0

O E2 192.168.2.0/24 [110/20] via 10.0.34.3, 00:04:15, FastEthernet0/0

O E2 192.168.3.0/24 [110/20] via 10.0.34.3, 00:04:15, FastEthernet0/0

R4#

The CEF naturally also contains the labels:

R4#show ip cef 192.168.1.0 | i imposed
    fast tag rewrite with Fa0/0, 10.0.34.3, tags imposed: {22}
    tag rewrite with Fa0/0, 10.0.34.3, tags imposed: {22}
R4#show ip cef 192.168.2.0 | i imposed
    fast tag rewrite with Fa0/0, 10.0.34.3, tags imposed: {21}
    tag rewrite with Fa0/0, 10.0.34.3, tags imposed: {21}
R4#show ip cef 192.168.3.0 | i imposed
    fast tag rewrite with Fa0/0, 10.0.34.3, tags imposed: {20}
    tag rewrite with Fa0/0, 10.0.34.3, tags imposed: {20}

There is a little gotcha with loopback interfaces in OSPF: if included via network command, they will be advertised in OSPF using /32 netmasks, not their own netmasks, unless they are also configured with ip ospf network point-to-point command. If injected via redistribute connected command, they will be advertised using their true netmasks. LDP that advertises label-to-prefix bindings always uses the true netmask. If the netmask advertised in OSPF does not match the netmask in LDP, the label binding will not be created. This is how it looks on R2 if I remove all redistribute connected from R1 and replace it with appropriate network commands:

R2(config-if)#do show mpls fo

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface

16 Pop tag 10.255.255.3/32 0 Fa0/1 10.0.23.3

17 Pop tag 10.255.255.1/32 0 Fa0/0 10.0.12.1

18 19 10.255.255.4/32 0 Fa0/1 10.0.23.3

19 Pop tag 10.0.34.0/24 3696 Fa0/1 10.0.23.3

23 Untagged 192.168.3.1/32 0 Fa0/0 10.0.12.1

24 Untagged 192.168.2.1/32 0 Fa0/0 10.0.12.1

25 Untagged 192.168.1.1/32 0 Fa0/0 10.0.12.1

In correct state, R2 should say Pop tag instead of Untagged on the three 192.168.x.x entries, but because R1 advertises 192.168.x.1/32 in OSPF and 192.168.x.0/24 in LDP, R2 is unable to put these two information together. R3 and R4 will have label bindings for these networks, though, because R2 has assigned ingress labels to these entries and advertised them further (i.e. R2 knows about these networks and also assigns labels to them on its own, so on R3, both OSPF and LDP claim the same prefix 192.168.x.1/32, hence the label mapping suceeds).

Would anything of this appear to apply to your situation?

Best regards,

Peter

jonathan johnson · ‎10-14-2013

Hi Peter,

Thanks for reply.

With regards to the loopbacks, I have each router configured with a /32 and also configure them as a /32 in the ospf config.

I just removed the redistribution statement and added it back in and now I'm seeing the tag info when doing a "sh ip cef x.x.x.x detail"

Which is a little strange... but I'll look into that a bit more.

This is from R4

sh ip cef 192.168.89.1 detail

192.168.89.0/24, epoch 0, flags need ps clean

local label info: global/664

nexthop 10.17.60.45 GigabitEthernet0/1.41 label 17

The nexthop IP is R3 - is this correct or should it be R1 (which is where the 192.168.89.1 IP exists)?

For my own undertanding, without the "redistribute connected subnets" and mpls enabled on the interface facing the next router should the tag/label information distributed be sufficient to allw end-to-end connectivity?

Thanks again,

Jonathan

Peter Paluch · ‎10-14-2013

Hi Jonathan,

With regards to the loopbacks, I have each router configured with a /32 and also configure them as a /32 in the ospf config.

Very well.

I just removed the redistribution statement and added it back in and now I'm seeing the tag info when doing a "sh ip cef x.x.x.x detail"

Which is a little strange... but I'll look into that a bit more.

This looks like a bug. If all you did was remove and reenter the redistribute connected then this suggests a nondeterministic behavior which is out of question for OSPF/MPLS.

sh ip cef 192.168.89.1 detail

192.168.89.0/24, epoch 0, flags need ps clean

local label info: global/664

nexthop 10.17.60.45 GigabitEthernet0/1.41 label 17

The nexthop IP is R3 - is this correct or should it be R1 (which is where the 192.168.89.1 IP exists)?

The next hop is okay. MPLS works in conjunction with normal routing: the routing table tells you who is the next hop for a particular destination, so you label the packets for that destination using the particular label value suggested by the particular next hop for that destination, and send the packets towards that next hop.

For my own undertanding, without the "redistribute connected subnets"  and mpls enabled on the interface facing the next router should the  tag/label information distributed be sufficient to allw end-to-end  connectivity?

I am not sure if I entirely understand this scenario but let's put it this way: with MPLS, you still have a routing table so you can still use it. If you receive an unlabeled IP packet and you can find a destination network in your routing table then by all means, you will simply route that packet through the appropriate next hop. If, in addition, you also know an MPLS label value from that next hop, you will also add that label while you forward the packet to the next hop.

Please feel welcome to ask further!

Best regards,

Peter

jonathan johnson · ‎10-14-2013

Hi Peter,

Thanks for your reply.

I think I might be almost there with my understanding.

Just to clarify my last question. In all of the example configurations that I've seen by Cisco, they do not have the "redistribute connected subnets" command configured in their OSPF section.

However, if I remove the "redistribute connected subnets", I lose connectivity to the interfaces on the router where I removed the command from. My network appears to need to the redistribute commands in ospf to maintain end to end connectivity.

I was under the impression that MPLS would lookup the destination host in its forwarding table, find the label and sent the packet on it's way.

Thanks again,

Jonathan

Peter Paluch · ‎10-14-2013

Jonathan,

In all of the example configurations that I've seen by Cisco, they do not have the "redistribute connected subnets" command configured in their OSPF section.

However, if I remove the "redistribute connected subnets", I lose connectivity to the interfaces on the router where I removed the command from. My network appears to need to the redistribute commands in ospf to maintain end to end connectivity.

The example documents by Cisco most probably do not use the redistribute connected subnets because instead, they include the connected networks into OSPF using the network command. The network command is the preferred way.

If your routers do not include some of the directly connected network into OSPF using the network command then without the redistribute connected subnets command, these networks are not advertised at all. This causes the reachability issues you have observed. I am somewhat surprised at your use of redistribute connected, anyway. Usually, this is not what you want - even though the networks are your own, they are injected into OSPF as being external. Is there a purpose behind this?

I was under the impression that MPLS would lookup the destination host  in its forwarding table, find the label and sent the packet on it's way.

It does not work exactly that way. MPLS first needs a complete and working routing table to know which networks it can enumerate by the labels. Only then it builds the MPLS forwarding table, the LFIB, that does not really contain destination hosts or networks. It just contains incoming and outgoing labels constructed from the local label assigned to a particular network (known your own routing table) and the remote label assigned by that network's next hop (according to your own routing table). So in basic MPLS like this one, you need a full IP connectivity before even starting MPLS. Basic MPLS just adds labels on what is already known in routing tables. If something is missing from routing tables, basic MPLS can not assign any value to it (because it does not even know it exists).

There are applications like VPNs in which internal routers do not know the customer networks. However, those are more complex topics, but they nevertheless require full connectivity and full visibility of all provider's routers, so at the core, there is again the necessity for internal provider's network to have all its own routes known before they can be labeled.

Best regards,

Peter

jonathan johnson · ‎10-15-2013

Hi Peter,

That all makes sense now - thanks for clearing it up.

With regards to using the "redistribute connected subnets" instead of a network statement - I've been looking into changing over to this, but I'm still trying to determine if the change will have any benefit in the network as it stands.

Thanks for your assistance with the topic, your help is greatly apprecicated.

Jonathan.