ALU interop GRE tunnel

Question

I've been trying to figure out how to setup a GRE tunnel between an ALU 7750SR and a 3rd party vendor. I think it's balking at the VC-ID in the SDP but i'm hoping someone has experience getting a GRE tunnel to come up in a multi-vendor environment with ALU.

Here's the requested syntax:

sdp 9999 create
far-end 1.1.1.1 
path-mtu 1500 
keep-alive 
exit

ies 9998 customer 1 create 
 interface "PACKET_DESIGN" create 
 address 10.128.105.6/30 
 spoke-sdp 9999:1 create 
 no shutdown 
 exit 
no shutdown

Could you provide a bit more info? What have you tried, why do you think the VC-ID might be the cause, which 3rd party vendor, ... — Gerben, May 17 '13 at 07:42
What is the network setup? Does this pass a firewall or is it configured on the firewall? In case of a firewall, did you allow traffic of GRE and TCP Ports? Please provide a network scheme like this: LAN1 => Firewall1 == GRE Tunnel == Firewall2 <= LAN2 — Bulki, May 17 '13 at 14:02
@Bulki
There are no firewalls involved. I'm trying to get this to tunnel a ISIS L1 adjacency to a Route Explorer/Packet Design server but for all intents and purposes you can imagine i'm trying to do a tunnel to a Cisco router (as i can get a GRE tunnel to work from Cisco to Packet Design with no special syntax on the Cisco side). The network scheme is as simple as it sounds: LAN1--GRE Tunnel--LAN2. Standard MPLS core, no TE is taking place as the SDP is being set as GRE. — Mud, May 19 '13 at 03:41
@Gerben It was my understanding (and i could be entirely wrong) that ALU's VC-ID is the same thing as Cisco's VPN tag, so even though this is supposed to be a GRE tunnel, the ALU is sending a VPN tag that the PE router won't know how to deal with and expecting one in return that it's not going to get. — Mud, May 19 '13 at 03:43
You need to shutdown KA and signalling. I realize I'm super late to the party. eg: sdp 2 create signaling off far-end 10.0.0.1 keep-alive shutdown exit no shutdown exit — Gopalakrishnan Mallappan, Oct 02 '13 at 14:49

score 3 · Accepted Answer · answered May 27 '13 at 07:09

3

AFAIK GRE support is limited to VPN services or as an access-pseudowire. At least according to ALU there is no way to use GRE as a logical tunnel on the 'network' side. This would require a service blade. However, I haven't tested this but it seems to be the official story.

answered May 27 '13 at 07:09

aakso

316
1
3

In playing I've definitely been able to make GRE tunnels work on the network side ALU to ALU, and have ISIS adjacencies form across the tunnel. It's when it's ALU to anything else that it doesn't work. I'm positive the problem is the SVC-ID Label coming across to the non-ALU device (and the non-ALU device not sending one back to ALU) but i can't think of a way to fix it. It just seems mind boggling that there isn't an easy way to turn up an RFC standard GRE tunnel in ALU to a different vendor. – Mud May 27 '13 at 23:33
Your configuration implies tldp signalling as it is turned on by default. It can be turned off with "signaling off". I tested this configuration - however it still seems that using "spoke-sdp" in IES/VPRN context invokes service label to be used in data plane. I need to verify this with packet captures though. The "real" tunnel interface afaik requires MS-ISA blade. Then you can greate logical tunnel-saps which have GRE destination. – aakso May 28 '13 at 15:33

score 1 · Answer 2 · edited Feb 21 '14 at 16:06

I've tried this before. Let me show you what've done.

First I have created the SDPs as GRE.

far-end 10.1.0.6
signaling off
keep-alive
 shutdown
exit
no shutdown

Then create your IES service. Now, when creating the spoke-spd and as signaling is off (since you are using GRE), then you need to manually establish ingress and egress vc-labels.

ies 100 customer 1 create
 interface "to_SARA_2" create
  address 192.168.0.1/30
  spoke-sdp 12:100 create
   ingress
    vc-label 2048
   exit
   egress
    vc-label 2048
   exit
  exit
 exit
 no shutdown
exit

This last thing does the trick and you can then forward traffic using GRE instead of MPLS ...

score 0 · Answer 3 · answered May 26 '13 at 13:06

0

Often you have to set the MTU to 1440 or less from memory to allow the GRE header through to the other site> very useful and easy to understand (not a 100 page whitepaper either)

Calculating GRE IPSec Tunnel Mode Overhead Point to Point GRE IPSEC

I would say refer to this article to get more information: I set one up the other day with 2 ciscos - just remove the IPSec stuff from your config, but as I said > lower the MTU on both sides to match (and you should really implement IPSEC)

answered May 26 '13 at 13:06

alex_da_gr8

41
6

1

The end-to-end interface MTU is standardized at 9212 (that number includes L2 overhead). Using the "path-mtu" command was more of a "hail mary" while I was trying to make this work. For kicks I modified the path-mtu statement to 1400, 1300, 1200 and 1100 and it remained operationally down.
Your link doesn't address the difference in delivery between ALU and Cisco, and setting up a GRE tunnel between two Cisco's is not the issue. Also IPSEC is not needed as this tunnel does not leave our own AS.
– Mud May 26 '13 at 22:03

ALU interop GRE tunnel

3 Answers3