ISR 2851 to Etherswitch communication trouble

Philippe Latu · ‎09-01-2008

Hello,

This is my first post so please forgive my poor english ...

We have a ISR 2851 + NME-16ES-1G with per-vlan subinterfaces defined at the router level.

The Gigabit internal link is used as a trunk between these subinterfaces and the network module ports.

After upgrading to 12.4(15)T7 IOS the native VLAN traffic doesn't go through the gi internal link.

I send a sample config attachment.

Has anyone encountered a similar problem ?

Thanks in advance for your help ;)).

- Philippe

Philippe Latu · ‎09-01-2008

Hello again,

A followup to my previous message. I gathered relevant information from debug but I can't find a way to correct the problem while searching into the documentation.

# sh logging | include 189

002386: *Sep 1 19:44:28.059 EDT: IP: tableid=0, s=194.214.182.102 (GigabitEthernet0/0.2), d=194.214.189.100 (GigabitEthernet1/0.241), routed via RIB

002387: *Sep 1 19:44:28.059 EDT: IP: s=194.214.182.102 (GigabitEthernet0/0.2), d=194.214.189.100 (GigabitEthernet1/0.241), g=194.214.189.100, len 42, forward

002388: *Sep 1 19:44:28.059 EDT: IP: s=194.214.182.102 (GigabitEthernet0/0.2), d=194.214.189.100 (GigabitEthernet1/0.241), len 42, encapsulation failed

What action should be taken to correct this encapsulation failed on a gi link ?

- Philippe

Richard Burts · ‎09-01-2008

Philippe

Frequently the encapsulation failed error is a result of problems when the ARP request does not find the MAC address of the destination IP. I suspect this is the problem here. And the solution of the ARP issue is almost certainly to solve the issue with the trunk and the native VLAN.

Perhaps something is different about the NM-16ES (and I do not have much experience with that particular card, so I can not say for sure) but I would suggest that you add a parameter on the encapsulation command for interface GigabitEthernet1/0.241 to indicate that it is the native vlan, so the command would be:

encapsulation dot1Q 241 native

Here is a paragraph which discusses this in the Command Reference for Switching Commands:

Do not configure encapsulation on the native VLAN of an IEEE 802.1Q trunk without the native keyword. (Always use the native keyword when vlan-id is the ID of the IEEE 802.1Q native VLAN.)

Give it a try and let us know if it helps.

HTH

Rick

HTH

Rick

Philippe Latu · ‎09-01-2008

Hello Rick,

Thanks for your answer.

The encapsulation problem is related to arp requests as we have incomplete entries in arp table.

I tested the 'native' keyword after the encapsulation instruction.

The problem is still there and:

. the 'native' keyword vanishes after a few minutes from the running config,

. encapsulation failed entries are the same as before.

The native VLAN seems to be properly configured at the Etherswitch level :

sh int fa1/0/6 switchport

Name: Fa1/0/6

Switchport: Enabled

Administrative Mode: trunk

Operational Mode: trunk

Administrative Trunking Encapsulation: dot1q

Operational Trunking Encapsulation: dot1q

Negotiation of Trunking: Off

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 241 (gear)

Administrative Native VLAN tagging: enabled

Voice VLAN: none

Administrative private-vlan host-association: none

Administrative private-vlan mapping: none

Administrative private-vlan trunk native VLAN: none

Administrative private-vlan trunk Native VLAN tagging: enabled

Administrative private-vlan trunk encapsulation: dot1q

Administrative private-vlan trunk normal VLANs: none

Administrative private-vlan trunk associations: none

Administrative private-vlan trunk mappings: none

Operational private-vlan: none

Trunking VLANs Enabled: 241,500

Pruning VLANs Enabled: 2-1001

Capture Mode Disabled

Capture VLANs Allowed: ALL

Protected: false

Unknown unicast blocked: disabled

Unknown multicast blocked: disabled

Appliance trust: none

Any other hint ?