EOMPLS issue with MX480 as CE1

[ioanbranet]

Hello group,

I have the following setup
CE1(Juniper MX480) xe3/1/0.999 -----Te7/3.999 PE1(Cisco 7600)----PE2(Cisco 7600)Gi2/2.999---SVI 999(7600)CE2

I configured EOMPLS between PE1 and PE2 and if I use Cisco 7600 as CE1 I am able to ping between CE1 and CE2
If I use MX480 Juniper I cant ping between CE1 and CE2.

Here is my config:
CE1:

show configuration interfaces xe-3/1/0
description "** Link To PE1-Te7/3-EOMPLS **";
vlan-tagging;
link-mode full-duplex;
gigether-options {
    no-auto-negotiation;
}
unit 999 {
    bandwidth 10g;
    vlan-id 999;
    family inet {
        accounting {
            source-class-usage {
                input;
            }
        }
        no-redirects;
        sampling {
            input;
        }
        address 150.1.1.2/30 {
            primary;
            preferred;
        }
    }
}


PE1:

sh running-config interface te7/3
Building configuration...

Current configuration : 139 bytes
!
interface TenGigabitEthernet7/3
 description Link to CE1 - xe-3/1/0 for EoMPLS
 mtu 9216
 no ip address
 load-interval 30
end

sh running-config interface te7/3.999
Building configuration...

Current configuration : 116 bytes
!
interface TenGigabitEthernet7/3.999
 encapsulation dot1Q 999
 xconnect 2.2.2.2  9999 encapsulation mpls
end


int lop0
ip add 1.1.1.1 255.255.255.255

PE2:
interface GigabitEthernet2/2
 description Link to CE2 for EoMPLS
 mtu 9216
 no ip address

interface GigabitEthernet2/2.999
 description EOMPLS_TEST
 encapsulation dot1Q 999
 xconnect 1.1.1.1  9999 encapsulation mpls
end

int loop0
ip add 2.2.2.2 255.255.255.255

CE2:

sh running-config interface gi2/2
Building configuration...

Current configuration : 633 bytes
!
interface GigabitEthernet2/2
 description Link to PE2
 switchport
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 999
 switchport mode trunk

interface Vlan999
 ip address 150.1.1.1 255.255.255.252
end

I have the EOMPLS circuit up but I cant ping between Juniper CE1 and Cisco CE2

sh mpls l2transport vc 9999 detail
Local interface: Gi2/2.999 up, line protocol up, Eth VLAN 999 up
  MPLS VC type is Eth VLAN, interworking type is Ethernet
  Destination address: 1.1.1.1, VC ID: 9999, VC status: up
    Output interface: Vl894, imposed label stack {2419 5896}
    Preferred path: not configured 
    Default path: active
    Next hop: x.x.x.x
  Create time: 00:00:06, last status change time: 00:00:06
  Signaling protocol: LDP, peer 1.1.1.1:0 up
    Targeted Hello: x.x.x.x(LDP Id) -> y.y.y.y
    MPLS VC labels: local 1684, remote 5896
    Group ID: local 0, remote 0
    MTU: local 9216, remote 9216
    Remote interface description:
  Sequencing: receive disabled, send disabled
  VC statistics:
    packet totals: receive 0, send 0
    byte totals:   receive 0, send 0
    packet drops:  receive 0, send 0

PE1
#show mpls l2transport vc 9999 detail
Local interface: Te7/3.999 up, line protocol up, Eth VLAN 999 up
  MPLS VC type is Eth VLAN, interworking type is Ethernet
  Destination address: 2.2.2.2, VC ID: 9999, VC status: up
    Output interface: Te4/3, imposed label stack {5673 1692}
    Preferred path: not configured 
    Default path: active
    Next hop: x.x.x.x
  Create time: 00:00:06, last status change time: 00:00:06
  Signaling protocol: LDP, peer 2.2.2.2:0 up
    Targeted Hello: x.x.x.x(LDP Id) -> y.y.y.y
    MPLS VC labels: local 2083, remote 1692
    Group ID: local 0, remote 0
    MTU: local 9216, remote 9216

  Sequencing: receive disabled, send disabled
  VC statistics:
    packet totals: receive 2, send 0
    byte totals:   receive 128, send 0
    packet drops:  receive 0, send 0

It seems that i send arp-reply from Juniper and the Juniper is learning arp from CE2:
show arp no-resolve | match xe-3/1/0     
00:16:9c:6d:42:80 150.1.1.1       xe-3/1/0.999   none


Juniper PCAP Flags [Ext, In], PCAP Extension(s) total length 22
          Device Media Type Extension TLV #3, length 1, value: Ethernet (1)
          Logical Interface Encapsulation Extension TLV #6, length 1, value: Ethernet (14)
          Device Interface Index Extension TLV #1, length 2, value: 193
          Logical Interface Index Extension TLV #4, length 4, value: 126
          Logical Unit Number Extension TLV #5, length 4, value: 32767
        -----original packet-----
        0:16:9c:6d:42:80 > Broadcast, ethertype 802.1Q (0x8100), length 64: vlan 999, p 0, ethertype ARP, arp who-has 150.1.1.2 tell 150.1.1.1
11:34:01.878596 Out
        Juniper PCAP Flags [Ext], PCAP Extension(s) total length 22
          Device Media Type Extension TLV #3, length 1, value: Ethernet (1)
          Logical Interface Encapsulation Extension TLV #6, length 1, value: Ethernet (14)
          Device Interface Index Extension TLV #1, length 2, value: 193
          Logical Interface Index Extension TLV #4, length 4, value: 126
          Logical Unit Number Extension TLV #5, length 4, value: 32767
        -----original packet-----
        0:21:59:a7:c4:30 > 0:16:9c:6d:42:80, ethertype 802.1Q (0x8100), length 46: vlan 999, p 0, ethertype ARP, arp reply 150.1.1.2 is-at 0:21:59:a7:c4:30.

If i replace the Juniper with a 7600 evrything looks ok.

I tried to use alsa a GE interface for EOMPLS between CE1 and PE1 instead of 10G interface and it works also:

show configuration interfaces ge-1/1/1  
description "**Link to ro-PE1-ForEoMPLS**";
vlan-tagging;
link-mode full-duplex;
gigether-options {
    no-auto-negotiation;

unit 564 {         
    description "** EOMPLS **";
    vlan-id 564;
    family inet {
        accounting {
            source-class-usage {
                output;
            }
            destination-class-usage;
        }
       
        address 150.1.1.1/30;

sh running-config interface Gi9/12.564
Building configuration...

Current configuration : 208 bytes
!
interface GigabitEthernet9/12.564
 description EOMPLS CE1
 encapsulation dot1Q 564
 xconnect 2.2.2.2 9999 encapsulation mpls
 
end


Any feedback is appreciated.
Thank you,
Regards,
John

[aarseniev]

Hi Ioan,

Check if you are hitting something similar to this Cisco bug id CSCsq83540:

CSCsq83540

Symptoms: A Cisco 12000 works as a PE, and an Eng5 SIP line card is used to face the CE. In the VRF, the default route 0.0.0.0 is learned from the remote PE. When the problem occurs, all traffic from the CE that is forwarded via the VRF default route is dropped.

Conditions: This symptom is observed on a Cisco 12000 Eng5 SIP line card that is running Cisco IOS Release 12.0(32)SY04, 12.0(32)SY05, or 12.0(32)SY06. When VRFs are created and deleted, new VRFs that are created will have a problem if they are allocated with a table ID allocated for older deleted VRFs.

Workaround:

1. Reload the ingress Eng5 line card that is facing the CE.

or

2. If the customer does not want to reload the line card, a second workaround can be attempted, but it is not a reliable workaround and may not always be successful. Create a new VRF without removing any VRFs, which gets a new table ID, and apply the VRF configuration completely wherever the old VRF configuration is applied.

Further Problem Description: This problem cannot be cleared by using the clear cef linecard x or clear ip route vrf xxx 0.0.0.0 commands. 

 http://www.cisco.com/en/US/docs/ios/12_0s/release/ntes/120SCAVS.html

Are you using Engine5 cards, BTW?

Rgds

Alex

[ioanbranet]

Hello,

I do not have x-connect interface attached as I can see:

 #show MPLS platform EoMPLS | include 7/3

#

If I create an EOMPLS on a 6500 with 10G interface connected to the same Juniper it works ,i can ping between CE1 and CE2 so the problem seemd to be on the 7600.

Thank you, John