Ip routing path vs mpls path which is choosen?

I'm on a wedding right now and this just pop up on my mind. I have a router with two interfaces one have MPLS LDP enable and the other interface does not. Both interfaces have ospf, what path is choose?
I can't wait to get home to test this, but I would like know before that. I want to enjoy the wedding.

Find more posts tagged with

Comments

amb1s1

I think is going to use the interface that is on the Routing table. If the mpls enable interface is on the routing table, it will push the label and send the packet on that interface. If the one that does not have mpls enable is on the ip routing, it will forward the packet on that interface.

srg

They would both be used, which probably would be fine if the incoming packet are IP, but if its MPLS its possible that the wrong path is chosen and the packet becomes unlabeled.

networker050184

Is the incoming traffic being label switched? Is it an incoming IP packet and the destination a labeled destination?

srg

networker050184 wrote: »

Is the incoming traffic being label switched? Is it an incoming IP packet and the destination a labeled destination?

I dont think this matters.

networker050184

It does matter. If you have a packet that comes in labeled as part of an LSP it's going to follow that LSP rather than the IP routing table. Obviously an interface not participating in MPLS will not be part of the LSP.

srg

networker050184 wrote: »

It does matter. If you have a packet that comes in labeled as part of an LSP it's going to follow that LSP rather than the IP routing table. Obviously an interface not participating in MPLS will not be part of the LSP.

I had that in the back of my head as well, but when setting this up in lab Im not seeing this. Might be release dependent.

In lab I have this:

R3#sh mpls forwarding-table  | incl 6.6.6.6
21         18         6.6.6.6/32       0             Fa1/1      10.3.5.5
           No Label   6.6.6.6/32       0             Fa1/0      10.3.4.4
R3#sh ip cef 6.6.6.6 det
6.6.6.6/32, epoch 0, per-destination sharing
  local label info: global/21
  nexthop 10.3.4.4 FastEthernet1/0
  nexthop 10.3.5.5 FastEthernet1/1 label 18
R3#

Even if I send packets destined to 6.6.6.6 with label 21 it might still choose the unlabeled path via Fa1/0 and pop my stack.

networker050184

How are you testing it? It shouldn't label switch onto a non labeled path. I just went though this exact argument and lab testing a couple months ago with someone thinking this caused one of our outages.

srg

I do agree with you, however my lab don't. So I have this topology:

R2-R3-R5-R6 is a LDP labeled path.

R2#sh ip cef 6.6.6.6 detail
6.6.6.6/32, epoch 0
  local label info: global/22
  nexthop 10.2.3.3 FastEthernet0/0 label 21

R2#sh mpls forwarding-table 6.6.6.6
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
22         21         6.6.6.6/32       0             Fa0/0      10.2.3.3

And this is from R3:

R3#sh ip cef 6.6.6.6 det
6.6.6.6/32, epoch 0, per-destination sharing
  local label info: global/21
  nexthop 10.3.4.4 FastEthernet1/0
  nexthop 10.3.5.5 FastEthernet1/1 label 18

R3#sh mpls forwarding-table 6.6.6.6
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
21         18         6.6.6.6/32       0             Fa1/1      10.3.5.5
           No Label   6.6.6.6/32       252           Fa1/0      10.3.4.4

Pings from R2 to R6 gets imposed with label 21 towards R3, but it still doesn't necessarily follow the R2-R3-R5-R6 LSP:

R2#traceroute 6.6.6.6 source lo0

Type escape sequence to abort.
Tracing the route to 6.6.6.6

  1 10.2.3.3 [MPLS: Label 21 Exp 0] 60 msec 32 msec *
  2 10.3.4.4 52 msec 20 msec 40 msec
  3 10.4.6.6 68 msec 76 msec 64 msec

I can get R1 to use it though, which of course results in the label 18 beeing imposed at R3:

R1#traceroute 6.6.6.6 source lo0

Type escape sequence to abort.
Tracing the route to 6.6.6.6

  1 10.1.3.3 20 msec 28 msec 20 msec
  2 10.3.5.5 [MPLS: Label 18 Exp 0] 16 msec 32 msec 36 msec
  3 10.5.6.6 64 msec 72 msec 64 msec

mpls.jpg

networker050184

I was working more with RSVP end-to-end LSPs rather than an LDP hop by hop approach which it looks like you have so that might be a difference. I was also testing with L3VPN connectivity.

I'll have to lab this up and see whats going on. What platform/version are you on?

Thanks for the output!

srg

networker050184 wrote: »

I was working more with RSVP end-to-end LSPs rather than an LDP hop by hop approach which it looks like you have so that might be a difference. I was also testing with L3VPN connectivity.

I'll have to lab this up and see whats going on. What platform/version are you on?

Thanks for the output!

Ah yeah might be different with an end to end RSVP state. L3VPN wouldn't matter here as it would fail as well.

This was done on 7200 with 12.2(33)SRE3

networker050184

Pretty close IOS version. I was using SRD4.

deth1k

In this case you have two equal cost paths and CEF makes decision on how to distribute traffic, it doesn't care about labels at this time if traffic is originated from R3. Check "sh ip cef exact-route", there can be an instance where even label'ed traffic will get blackholed onto non MPLS enabled interface. Also when i say blackholed i mean that it will break IPVPN connectivity and not IP traffic so testing ICMP in this case would be incorrect unless done from simulated CPE.