Hi,

We had a similar issue with below Logs & Label 3 being assigned.

09:06:30.610: %BGP-3-INVALID_MPLS: Invalid MPLS label (3)
             received in update for prefix 1xxx:123:10.0.0.0/8 from w.x.y.z

Only to find that auto-summary was enabled under customer vrf address-family. This was negated & resolved the problem.

Jul 27 11:06:30 MYT: %BGP-3-INVALID_MPLS: Invalid MPLS label (3)received in update for prefix 65000:1:172.18.4.164/30 from 172.18.255.2

If you observe what is happening here is.

The cause for this log message is that you have configured EBGP as you PE-CE routing protocol for a VRF. ( this is the condition for the bug to trigger and is indicated by the log message you received)

And this can affect PIM adjacency across a VRF tunnel because of loss of MDT messages by BGP. ( this is the effect, doesnt not necessarly mean you have configured PIM, but if you do then you wont be able to form PIM adjacency across a VRF tunnel - Applicable only for MVPN)

HTH-Cheers,

Swaroop

For reference once again the Bug Case Details:

PIM neighbor not recognised with multicast vrf tunnel.

(Effect)

Symptoms: PIM neighbors do not recognize each other via a VRF tunnel

interface because multicast does not receive MDT updates from BGP. The output

of the show log command shows the following debug message:

%BGP-3-INVALID_MPLS: Invalid MPLS label (3) received in update for prefix

2:55:1111:192.168.31.1/32 from 192.168.31.1

(Trigger/Cause)

Conditions: This symptom is observed on a Cisco router and is not

platform-dependent. The symptom occurs when a VRF instance is configured with

BGP as the Exterior Gateway Protocol (EGP).

Workaround: There is no workaround.

Hi,

The PE-CE is using static routes or OSPF. There is no EBGP used between any of the PE-CE link. The bug's description doesn't really apply here.

or is there any other possible cause besides the bug ?

thanks

This bug is the closest to your symptom.

Since you have already identified it, the trigger condition would not be PIM as in your previous post, but EBGP between PE-CE.

Although if you do not have EBGP then I would suggest you should open a TAC case and they could probably update the case notes with this new behaviour.

The recommended tools to be used for any unexplicable error messages would be the

1) Error Message Decoder 2) Release Notes in the Caveats section.

HTH-Cheers,

Swaroop

Can you please attach a "show ver" from 172.18.255.2.

Regards,

sh ver

Cisco Internetwork Operating System Software

IOS (tm) s72033_rp Software (s72033_rp-ADVIPSERVICESK9_WAN-M), Version 12.2(18)SXF6, RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2006 by cisco Systems, Inc.

Compiled Mon 18-Sep-06 23:03 by tinhuang

Image text-base: 0x40101040, data-base: 0x42D90000

ROM: System Bootstrap, Version 12.2(17r)S2, RELEASE SOFTWARE (fc1)

BOOTLDR: s72033_rp Software (s72033_rp-ADVIPSERVICESK9_WAN-M), Version 12.2(18)SXF6, RELEASE SOFTWARE (fc1)

uptime is 34 weeks, 6 days, 17 hours, 42 minutes

Time since switched to active is 34 weeks, 6 days, 17 hours, 31 minutes

System returned to ROM by Stateful Switchover (SP by power on)

System restarted at 00:40:31 MYT Fri Dec 1 2006

System image file is "disk0:s72033-advipservicesk9_wan-mz.122-18.SXF6.bin"

This product contains cryptographic features and is subject to United

States and local country laws governing import, export, transfer and

use. Delivery of Cisco cryptographic products does not imply

third-party authority to import, export, distribute or use encryption.

Importers, exporters, distributors and users are responsible for

compliance with U.S. and local country laws. By using this product you

agree to comply with applicable laws and regulations. If you are unable

to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:

http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to

export@cisco.com.

cisco CISCO7609 (R7000) processor (revision 1.2) with 983008K/65536K bytes of memory.

Processor board ID FOX101504K9

SR71000 CPU at 600Mhz, Implementation 0x504, Rev 1.2, 512KB L2 Cache

Last reset from power-on

SuperLAT software (copyright 1990 by Meridian Technology Corp).

X.25 software, Version 3.0.0.

Bridging software.

TN3270 Emulation software.

Channelized E1, Version 1.0.

1 Enhanced FlexWAN controller (8 E1).

2 SIP-400 controllers (2 GigabitEthernet)(2 POS).

5 Virtual Ethernet/IEEE 802.3 interfaces

78 Gigabit Ethernet/IEEE 802.3 interfaces

3 Serial network interfaces

2 Packet over SONET network interfaces

1917K bytes of non-volatile configuration memory.

8192K bytes of packet buffer memory.

65536K bytes of Flash internal SIMM (Sector size 512K).

Configuration register is 0x2102

Could you please do a "show ip bgp vpnv4 vrf xxx labels" from 172.18.255.2, where xxx is the VRF for RD 65000:1.

Regards,

Hi,

Attached the show output.

Send on behalf Boon Teong.

Regards

Hi,

There are several scenarios, when a PE might send label 3, which is imp-null and thus should not be used with VPNv4 prefixes:

They are addressed in CSCsg55591.

An IOS upgrade might be required on the routers affected.

Hope this helps!

Regards, Martin

Martin,

I agree that the issue looks like CSCsg55591. The upgrade will not help at this point as this DDTS has not yet been integrated in 12.2(18)SXF or in 12.2(33)SRA and SRB.

Regards,

Hello,

we have a similar problem, but with MPLS label 0:

%BGP-3-INVALID_MPLS: Invalid MPLS label (0)
             received in update for prefix 58368:0:28056466:112.0.0.0/5 from 10.0.0.2

This message is seen on a Cisco 7206VXR NPE-G2 with IOS 12.4(24)T4. The box with the IP 10.0.0.2 is a Catalyst 3750 Metro with IOS 12.2(54)SE.

A "show ip bgp vpnv4 vrf xxx labels" (with xxx for the vrf) on the ME3750 shows the correct routes, there is no 112.0.0.0/5 seen (btw, the prefix 112.0.0.0/5 doesn't exist in the global routing table either).

Any ideas?

Thanks in advance