Re: Issue in ASR 1002-X EoGRE tunnel creation with x86 linux PC

sanjay487 · ‎12-14-2018

I need to make a EoGRE tunnel from a x86 linux PC to cisco ASR 1002x.

I verified tunnel between PC's and similar approach followed with router.

Following are the commands used in router

WAG(config)#interface Tunnel1
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
WAG(config-if)#description "Cisco steps EOGRE tunnel deployment"
WAG(config-if)#ip address 10.10.20.1 255.255.255.0
WAG(config-if)#tunnel source GigabitEthernet 0/0/0
WAG(config-if)#mac-address 0000.5e00.5213
WAG(config-if)#tunnel mode ethernet gre ipv4
WAG(config-if)#tunnel key 1

WAG(config-if)#exit

WAG(config)#ip route 10.10.20.5 255.255.255.255 192.168.2.5

Following are the commands used in PC2

sudo ip link add gretap1 type gretap remote 192.168.2.1 local 192.168.2.5 dev enp2s0 key 1
sudo ip link set gretap1 up
sudo ip link set gretap1 mtu 1450
sudo ifconfig gretap1 10.10.20.1 netmask 255.255.255.0

sudo ip route add 10.10.20.1/32 via 192.168.2.1

I have attached topology diagram, where i have bridged ethernet and gretap in PC2 to forward Eogre traffic. I have received Eogre packets on Router Gi0/0/0 interface and I'm expecting decapsulated packets in tunnel1. I found these packets in tunnel are corrupted. Am i doing things right or not. I don't have any clue why it is not working.

I have taken capture on Gi0/0/0 and Tunnel 1 interfaces and attached the same.

If I put PC1 in 10.10.20.0/24 domain, I'm getting ARP response in proper Eogre frame from the router and reaching response to PC1 then the ICMP request is going but no response though. In this case if I capture in tunnel 1 the packets are still corrupted. The ARP response is genarated by Gi0/0/0 interface itself.

I'm looking forward for a solution. I dont understand where the problem exists. Why the packets in tunnel 1 are getting corrupted. Anything else need to be done

sanjay487 · ‎12-17-2018

Also some points on further analysis

Taken capture on Gi0/0/0 which is source interface of tunnel

Taken capture on Tunnel 1 which is actual tunnel

Comparing two captures(bootp and MDNS packets specifically) I found that

Tunnel is chipping off exact bytes as MAC header(14)+IP header(20)+GRE header(8) = 42 bytes from the payload instead of headers

Is there any configuration mismatch I have done? What does this issue means?

PFA: Attached captures on Gi0/0/0 and Tunnel interfaces

sanjay487 · ‎12-26-2018

Attached running-config&tunnellogs, tunnel config, packet captures I'm trying to find the issue as mentioned in previous reply where tunnel packets are getting malformed.

Snapshots of the packet captures in Gi0/0/0 and tunnel 1 are as shown below:

From the above snapshots EoGRE bootp packet which is on Gi0/0/0 is 384 bytes.

Expected the same packet without outer MAC(14bytes), IP(20 bytes) and GRE(8 bytes) headers in tunnel 1 and this shall be 342 bytes. Observed the same size in tunnel but the 42 bytes from payload is removed instead of headers.

What could be the cause of the issue?

sanjay487 · ‎12-26-2018

Sadettin Sahiner · ‎08-06-2019

Hi,

Did you find any solution ? I am trying to do same thing but I could not. When I try to ping from linux site to ASR tunnel interface IP "debug tunnel" command giving some logs like below :

652486: Aug 6 17:47:05.857: Tunnel1000: Ethernet-GRE/IP (PS) to decaps 10.194.0.175->192.168.72.33 (tbl=0,"default" len=66 ttl=59)
652487: Aug 6 17:47:05.857: Tunnel1000: Rcvd from src mac 9e14.935c.b4ef dst mac ffff.ffff.ffff
652488: Aug 6 17:47:05.857:
652489: Aug 6 17:47:05.857: TUN ETHER: Enqueue a message to server via non-punt path
652490: Aug 6 17:47:05.858: TUN ETHER: Posting TUNNEL_ETHER_CP_INFRA_INFO
652491: Aug 6 17:47:05.858: TUN ETHER: XOS msg send success
652492: Aug 6 17:47:05.858: Pak Decapsulated on GigabitEthernet0/0/0, ptype 0x806, nw start 0x393761E8, mac start 0x393761DA, datagram size 42 link type 0x7

652493: Aug 6 17:47:05.858: Tunnel1000: GRE decapsulated RFC826_ARP packet (linktype=1, len=42)
652494: Aug 6 17:47:05.858: Tunnel1000: GRE decapsulated RFC826_ARP packet (linktype=1, len=42)
652495: Aug 6 17:47:05.858: TUN ETHER: TUNNEL_ETHER_CP_INFRA_INFO event triggered
652496: Aug 6 17:47:05.858: TUN ETHER: Tunnel Infra update received in cp
652497: Aug 6 17:47:05.858: TUN ETHER: process the infra update in cp
652498: Aug 6 17:47:05.858: TUN ETHER: tun_ether_get_or_create_info_node
652499: Aug 6 17:47:05.858: TUN ETHER: tunnel_ether_info_find
652500: Aug 6 17:47:05.858: TUN ETHER: transport and vlan addr is same
652501: Aug 6 17:47:05.858: TUN ETHER: Cleaning up the infra info

And show tunnel mac-table tunnel 1000 outputs also like below

router#sh tunnel mac-table tunnel 1000
overlay-address UNKNOWN, transport-address 10.194.0.175
mac-address 9e14.935c.b4ef, vlan 0 Mac Age 00:00:03

sanjay487 · ‎09-23-2019

Hi Sadettin Sahiner,

My issue got solved after I upgraded my router to Cisco IOS XE Software, Version 16.06.05,

In your logs, overlay-address shows UNKOWN. It seems your client does not get IP from your router. In this case router will not process your client packet, because "dynamic arp learning" will not happen for EoGRE case. To solve this issue try to create DHCP pool in you router for provide IP to your clients. It may help.

Sadettin Sahiner · ‎09-30-2019

Hi sanjay487,

My problem also solved. I had problem with my GRETAP interface's IP address and routing on this interface. In my opinion the gretap interface does not have to have an IP address, because it is working as pseudowire between client device and ISG.

I just created new bridge and gretap interface binded with client side interface. It is working now.

Thank you.

Dr. Klaus Heck · ‎03-22-2022

Hi Sadettin,

Do you stil have the configurations for the gretap tunnel from linux to cisco? I have exactly the same issue as you in your post from ‎08-06-2019 08:00. Would be happy if you could assist.

Thank you.