MPLS not working on new Eth link.

Answered Question
Dec 13th, 2009

Hi,

We have recently provisioned a new p-t-p(eth) link between our cores for redundancy - The provider of the new link is currently filtering multicast, so ospf needed to be configured as unicast until they rectify the problem.

I have enabled mpls on the new link, and it is showing as active (sh mpls int on both R1+R3) but it is not showing up as an active neighbour.

Could the ospf multicast issue also be causing mpls problems?

#sh mpls interfaces
Interface              IP            Tunnel   Operational
Port-channel1.927      Yes (ldp)     No       Yes        
Port-channel1.86       Yes (ldp)     No       Yes        <--- New link


#sh mpls ldp neighbor
    Peer LDP Ident: 10.0.76.249:0; Local LDP Ident 10.0.76.238:0
        TCP connection: 10.0.76.249.42950 - 10.0.76.238.646
        State: Oper; Msgs sent/rcvd: 84353/84479; Downstream
        Up time: 6w2d
        LDP discovery sources:
          Port-channel1.927, Src IP addr: 10.0.66.174


R1 has p-t-p link to R2(Working ospf+mpls), and new p-t-p link to R3(Working ospf(Unicast), not working mpls)

R1

interface Port-channel1.927
description Link_to_R2
encapsulation dot1Q 927
ip address 10.0.66.173 255.255.255.252
ip ospf message-digest-key 10 md5 7 141314134D57787A
ip ospf cost 100
ip ospf mtu-ignore
no snmp trap link-status
mpls ip
mpls mtu 1530
end


interface Port-channel1.86
description Link_to_R3
encapsulation dot1Q 86
ip address 10.0.66.1 255.255.255.252
ip ospf message-digest-key 10 md5 7 141314134D57787A
ip ospf network non-broadcast
ip ospf cost 80
no snmp trap link-status
mpls ip
mpls mtu 1530
end


R2

interface GigabitEthernet0/1.927
description Link_to_R1
encapsulation dot1Q 927
ip address 10.0.66.174 255.255.255.252
ip ospf message-digest-key 10 md5 7 141314134D57787A
ip ospf cost 100
ip ospf mtu-ignore
mpls ip
mpls mtu 1530

R3

interface Port-channel1.86
description Link_to_R1
encapsulation dot1Q 86
ip address 10.0.66.2 255.255.255.252
ip mtu 1500
ip ospf message-digest-key 10 md5 7 141314134D57787A
ip ospf network non-broadcast
ip ospf cost 80
mpls mtu 1530
mpls ip


Thanks in advance.

I have this problem too.
0 votes
Correct Answer by Reza Sharifi about 6 years 12 months ago

Hi,

LDP hello exchange uses multicast address 224.0.0.2

Can you do a "debug mpls ldp transport connections"?

This comand should tell you if hellos are being exchanged between the 2 routers.

HTH

Reza

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Reza Sharifi Sun, 12/13/2009 - 16:24

Hi,

LDP hello exchange uses multicast address 224.0.0.2

Can you do a "debug mpls ldp transport connections"?

This comand should tell you if hellos are being exchanged between the 2 routers.

HTH

Reza

johnelliot6 Sun, 12/13/2009 - 16:37

Thanks Reza - Looks like I have an issue then if it requires multicast(Until provider fixes this)

debug output, I only see:

R1:

Dec 14 10:26:05.914 aest: ldp: Scan listening TCBs
Dec 14 10:27:05.946 aest: ldp: Scan listening TCBs
Dec 14 10:28:05.974 aest: ldp: Scan listening TCBs
Dec 14 10:29:06.002 aest: ldp: Scan listening TCBs

R3:

Dec 14 10:30:19.951 AEST: ldp: Scan listening TCBs
Dec 14 10:30:29.896 AEST: ldp: Data received!
Dec 14 10:30:35.552 AEST: ldp: Data received!
Dec 14 10:31:15.503 AEST: ldp: Data received!
Dec 14 10:31:19.955 AEST: ldp: Scan listening TCBs
Dec 14 10:31:28.016 AEST: ldp: Data received!
Dec 14 10:32:14.103 AEST: ldp: Data received!

Thanks again

Reza Sharifi Sun, 12/13/2009 - 17:30

Hi John,

Can you do a:

T-1#debug mpls ldp transport events

Below output is from my 2 routers connect via LDP.

LDP transport events debugging is on
T-1#
*Dec 14 02:47:52.460: ldp: Send ldp hello; GigabitEthernet0/1, src/dst 172.16.0.14/224.0.0.2, inst_id 0
*Dec 14 02:47:52.460: ldp: Rcvd ldp hello; GigabitEthernet0/1, from 172.16.0.13 (10.0.3.3:0), intf_id 0, opt 0xC
*Dec 14 02:47:56.836: ldp: Send ldp hello; GigabitEthernet0/1, src/dst 172.16.0.14/224.0.0.2, inst_id 0
*Dec 14 02:47:56.860: ldp: Rcvd ldp hello; GigabitEthernet0/1, from 172.16.0.13 (10.0.3.3:0), intf_id 0, opt 0xC
*Dec 14 02:48:00.980: ldp: Rcvd ldp hello; GigabitEthernet0/1, from 172.16.0.13 (10.0.3.3:0), intf_id 0, opt 0xC
*Dec 14 02:48:01.156: ldp: Send ldp hello; GigabitEthernet0/1, src/dst 172.16.0.14/224.0.0.2, inst_id 0


T-1#sh mpl ldp neighbor
    Peer LDP Ident: 10.0.3.3:0; Local LDP Ident 130.130.0.1:0
        TCP connection: 10.0.3.3.646 - 130.130.0.1.26088
        State: Oper; Msgs sent/rcvd: 200/170; Downstream
        Up time: 00:27:15
        LDP discovery sources:
          GigabitEthernet0/1, Src IP addr: 172.16.0.13
        Addresses bound to peer LDP Ident:
          10.0.4.1        10.0.2.5        172.16.0.13     10.0.4.13

HTH

Reza

johnelliot6 Sun, 12/13/2009 - 17:37

Hi Reza,

With debug mpls ldp transport events enabled, I see R1+R3 sending ldp hellos on the new link, but no rcvd's - So it looks like the filtering of multicast is causing my mpls issues(As you stated).

Thanks.

Actions

This Discussion

Related Content