12

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
Improve this question
7
  • 1
    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
    Commented May 17, 2013 at 7: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
    Commented May 17, 2013 at 14:02
  • Can you post a config example to give some context?
    – Baldrick
    Commented May 17, 2013 at 17:29
  • @javano I added the syntax to the main post.
    – Mud
    Commented May 19, 2013 at 3:40
  • @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
    Commented May 19, 2013 at 3:41

3 Answers 3

Reset to default
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.

Improve this answer
2
  • 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
    Commented May 27, 2013 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
    Commented May 28, 2013 at 15:33
1

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 ...

Improve this answer
0
  1. 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)

Improve this answer
1
  • 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
    Commented May 26, 2013 at 22:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.