MetroEthernet Connection Not Able to ping but can be seen in CDP neighbors

[Jose Alejandro Rodriguez Rodriguez]

   Hello,

I got a problem with a router connected via Metro Ethernet,

They are connected via Metro Ethernet and encapsulation is dot1q 720.

The problem is that i can't ping the remote breanch but i'm able to see it via cdp neighbors.

Somebody can help me!!!

Thanks in advance...

In attachments you can see the configuration....

[Peter Paluch]

Hello Jose,

A couple of questions and suggestions:

1. Your router can indeed see the RT-DFA-SAN via CDP. However, can RT-DFA-SAN also see your router in its CDP table? What is the exact show cdp neighbor output on that router?
2. If you issue the show cdp entry RT-DFA-SAN command on your router, can you see the IP address of the RT-DFA-SAN in this output? Does this IP address fall into the range 172.16.20.18 - 172.16.20.22?
3. The fact that your router can see the RT-DFA-SAN on its Fas 0/1.720 is interesting by itself. Unless the CDP implementation has changed recently, it is my experience that CDP messages are always sent from interface that is placed into VLAN1 (regardless of whether it is the native VLAN or not). However, if RT-DFA-SAN sends the CDP packets from its interface in VLAN1, how is it possible they are processed on your router on a subinterface in VLAN 720? That would mean that the CDP frames sent in VLAN1 somehow leak into VLAN720.

This seems very much like a native VLAN mismatch or some strange VLAN operation (renumbering) taking place. That may be the actual reason why the ping is not working - because you are probably leaking two different VLANs together, each using a different IP network space.

Can you check this with your Metro Ethernet operator?

Best regards,

Peter

[Jose Alejandro Rodriguez Rodriguez]

Thanks for your quickly answers,

I'll be trying to quickly answer to get a solution fast:

1. I can not see my router through RT-DFA-SAN because i'm not located in that locality.

Here's the  output of show cdp neighbor in my router:

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
RT-DFA-SAN       Fas 0/1.720        170        R S I      CISCO1941/Gig 0/1

2. Yes, it does fall in that range. Here you can have the output:

Duttyfree_Caracas#show cdp entry RT-DFA-SAN
-------------------------
Device ID: RT-DFA-SAN
Entry address(es):
  IP address: 172.16.20.19
Platform: Cisco CISCO1941/K9,  Capabilities: Router Switch IGMP
Interface: FastEthernet0/1.720,  Port ID (outgoing port): GigabitEthernet0/1
Holdtime : 153 sec

Version :
Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.1(1)T2, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Fri 22-Oct-10 23:24 by prod_rel_team

advertisement version: 2
VTP Management Domain: ''
Duplex: full

3. Interesting your comment about leaking the VLANs. But how can it become leaked? The Metro Operator can mix the VLANs?. Could it be that my remote router has "native" word in encapsulation command?.

Thanks in advance!!

Regards

José

[Peter Paluch]

Hi Jose,

1. I can not see my router through RT-DFA-SAN because i'm not located in that locality. 

Okay, and can somebody that is located at that site check the show cdp neighbor for you?

2. Yes, it does fall in that range. Here you can have the output:
Duttyfree_Caracas#show cdp entry RT-DFA-SAN
-------------------------
Device ID: RT-DFA-SAN
Entry address(es):
  IP address: 172.16.20.19
Platform: Cisco CISCO1941/K9,  Capabilities: Router Switch IGMP
Interface: FastEthernet0/1.720,  Port ID (outgoing port): GigabitEthernet0/1

Hmmm, indeed.

3. Interesting your comment about leaking the cdp frames. But how can it  become leaked? The Metro Operator can mix the VLANs?. Could it be that  my remote router has "native" word in encapsulation command?

Yes, the Metro Ethernet operator can manipulate the VLAN tags. Moreover, the remote router is reported to use its Gi0/1 interface to connect to you. As this is a physical interface, there is no encapsulation dot1q native command supported on it so I do not believe this could be caused by a misplaced native keyword. In fact, a physical interface sends untagged frames. However, if your router receives them on its Fa0/1.720 subinterface, it means that they have become tagged with the VLAN 720 while in transit through the provider's network.

I wonder - do you at least see the remote router's MAC address in the ARP table when you try to ping it and immediately after pinging, enter the show ip arp 172.16.20.19 command?

In fact, I wonder why the Metro Ethernet provider told you about the VLAN at all. Usually, on Metro Ethernet, you use your own VLANs as you please, while the operator is encapsulating all your traffic into yet another VLAN assigned to you as a customer but this VLAN does not need to be known to the customer at all. However, there are some scenarios in which the operator actually expects the customer to perform the double tagging himself.

Can you do a little experiment for me? On Fa0/1.720, try replacing the

encapsulation dot1q 720

with

encapsulation dot1q 720 second-dot1q 1

This will configure the subinterface to perform double tagging itself. Perhaps this is what the MetroE operator needs you to do. If this does not help, though, please revert back to the original configuration.

Best regards,

Peter

[Jose Alejandro Rodriguez Rodriguez]

Hi Peter,

Thanks for your answers,

The main idea is to avoid going to the remote site because our company has to spend a lot of money to go to it

There's not people specialized in Cisco there and its located in the border between Venezuela and Brasil.

As for the show ip arp, i'm not able to see the MAC ADRESS, here is the output:

Duttyfree_Caracas#sh ip arp

Protocol  Address          Age (min)  Hardware Addr   Type   Interface

Internet  201.249.236.204        19   000e.5310.dcc3  ARPA   FastEthernet0/0

Internet  201.249.236.201         -   001b.d581.3786  ARPA   FastEthernet0/0

Internet  201.249.236.202        95   0011.112c.d667  ARPA   FastEthernet0/0

Internet  201.249.236.203         3   001b.2fff.8b6d  ARPA   FastEthernet0/0

Internet  172.16.20.17            -   001b.d581.3787  ARPA   FastEthernet0/1.720

Duttyfree_Caracas#ping 172.16.20.19

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.20.19, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Duttyfree_Caracas#sh ip arp

Protocol  Address          Age (min)  Hardware Addr   Type   Interface

Internet  201.249.236.204        19   000e.5310.dcc3  ARPA   FastEthernet0/0

Internet  201.249.236.201         -   001b.d581.3786  ARPA   FastEthernet0/0

Internet  201.249.236.202        95   0011.112c.d667  ARPA   FastEthernet0/0

Internet  201.249.236.203         3   001b.2fff.8b6d  ARPA   FastEthernet0/0

Internet  172.16.20.17            -   001b.d581.3787  ARPA   FastEthernet0/1.720

Internet  172.16.20.19            0   Incomplete      ARPA  

Duttyfree_Caracas#

The command encapsulation dot1q 720 second-dot1q is not accepted, Here is the output:

Duttyfree_Caracas(config-subif)#encapsulation dot1Q 720 ?

  native  Make this as native vlan

As for the double tagging, I have done a lot of deployments based on this configuration.

The branches get connected using tagging on sub interfaces receiving the service. The ISP calls it VPLS. The router is connected to a 1424 Telindus One access which transforms the signal from digital to electric.

With the output of the cdp neighbors. Can you assure that the interface gi0/1 of the remote router was configured with ip address 172.16.20.19 instead of the gi0/1.720 that had to be configured?

Thanks for your answers,

They are appreciated a lot,

Regards

Josè

[Biotek]

Hi Jose,

We are having the same issue you experienced, how did you fix it in the end?

Thanks a lot!!