I have following situation:
(7600)PE1----(7600 sup720BXL)P ------ PE2 (ME3600X)
Link (which is not under my administrative domain) stopped transmiting multicast between P and PE2 (unicast works fine, i.e ping etc.).
Ofcourse LDP and OSPF went down due to multicast blocking (link PE1-P works ok).
I'm waiting for "link provider" to fix the problem but in the meantime I tried few things to enable my MPLS link.
Both solutions didn't work:
I tried to configure "static neighbor OSPF" and "targeted MPLS" (since both of them uses unicast)
OSPF with static neighbors works ok (OSPF is up).
MPLS with: mpls ldp neighbor 10.10.10.2 targeted ldp is up.
Targeted session is UP but labels are not ok:
on P: show mpls forwading-table "PE2 address": shows "no label" (it should be "pop label")
Traffic doesn't flow (due to "no label")
sh mpls forwarding-table 10.10.10.2
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
253 no label 10.10.10.2/32 578742 Gi 2/0/1 192.168.100.2
Question: Will this targeted LDP session work if P-PE2 link is not MPLS enabled (pure L3 subnet)?
(if P-PE2 have only ipv4 addresess and no "mpls ip" under interface)
Is it mandatory for targeted LDP session that all links (path), which targeted session crosses, have MPLS IP enabled?
I tried MPLS over GRE. But this also doesn't work:
I configured on link P-PE2(on both sides):
ip address 192.168.0.2 255.255.255.252
ip ospf cost 1
ip ospf 1 area 0
tunnel source Loopback1
tunnel destination 10.11.11.2
-OSPF is up (with static neighbors)
-LDP is up
-labels are all fine and as should be (on PE1, P, and PE2)
but traffic doesn't flow!
I tried on P (7600) to enter command: "mls mpls tunnel-recir". It didn't help, traffic didn't flow.
This link (P-PE2) is on ES20 card on 7600 (P). For "MPLS over GRE" does it have to be SIP card?
Does "MPLS over GRE" work on ME3600X platform (is it supported)?
Please help if anyone have some other idea how to solve this.
Thanks in advance,
For solution 1, I doubt it will work even if "mpls ip" is enabled on those interfaces and if you dont receive LDP hellos from neighbor. Per my understanding, an LSR uses the nexthop for a prefix from CEF table, goes to LDP discovery table (or the hello table) to get the LDP ID that advertise this nexthop address, check if it receives hello from this LDP ID and then goes to LIB database to get the label advertised.
In your case, it wont have any hello received on this interface and so will not use it for label switching.
For solution 2, are you seeing LDP hellos both xmit and receive on Tunnel1?.
MPLS over GRE on 7600 should be supported AFAIK. From the above output, I see that the routing entry for 10.10.10.2/32 is still using G2/0/1 as egress interface and I hope LDP hello is failing on this interface.
Do you have any IGP over the GRE tunel?. Can you try configuraing static route for 10.10.10.2/32 over GRE tunnel and see if it marks it as POP?
Do you maybe have some advice for solution 2?
Is it feaseble (MPLS over GRE) with ME3600X platform and 7600 (ESM20G as a client card)?