Skip to content

Inbound GRE configuration Guide - #1114

Merged
Chr1st0ph3rTurn3r merged 4 commits into
masterfrom
inbound-gre
Aug 13, 2026
Merged

Inbound GRE configuration Guide#1114
Chr1st0ph3rTurn3r merged 4 commits into
masterfrom
inbound-gre

Conversation

@MichaelBaj

Copy link
Copy Markdown
Contributor

No description provided.

Comment thread docs/howto_gre_cloud_peering.md Outdated
sidebar_label: GRE Cloud Peering
---

Cloud security and SD-WAN services — such as Akamai — commonly terminate customer traffic over Generic Routing Encapsulation (GRE) tunnels and monitor tunnel liveness by sending inbound ICMP echo requests (health checks) to the customer end of each tunnel. As described in [Native GRE Tunnels](config_gre_tunnel.md), an SSR `gre-tunnel` network-interface does not answer these inbound ICMP probes on its own, so the far-end service can mark an otherwise healthy tunnel as down.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a need to call out the other vendor? I feel this can be left as a "generic third party security appliance" or something like that.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can be left completely generic, although I find that specific examples are better for associating reference docs.

## Overview

SSR native GRE (`type gre-tunnel`) does not pass inbound ICMP echo requests to the Linux stack, so a health-checking peer receives no reply. The workaround is to create a `host`-type device interface (KNI) with the same IP address as the GRE tunnel's `internal-address`. The Linux host stack answers the ICMP echo replies, and SSR services steer inbound GRE and ICMP traffic into that host interface.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The term host-type device interface is used several times in this document and it is ambiguous. Can you please clarify for me? Is it a device interface acting like a host? Is it supposed to be host-type device-interface? Is it just a host device-interface that AI keeps trying to classify?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A device-interface can be defined as a type depending on its purpose. From the 128T datamodel:

                leaf type {
                    type enumeration {
                        enum ethernet {
                            description
                                "A physical ethernet interface.";
                        }
                        enum kni {
                            status obsolete;
                            description
                                "A logical interface to VM, host process, or container instance.";
                        }
                        enum pppoe {
                            description
                                "An interface using the Point-to-Point Protocol over Ethernet (PPPoE).";
                        }
                        enum host {
                            description
                                "A logical interface to the host system.";
                        }
                        enum bridged {
                            description
                                "A logical interface bridged to a target interface.";
                        }
                        enum lte {
                            description
                                "An interface using LTE.";
                        }
                        enum t1 {
                            description
                                "An interface using a T1 card.";
                        }
                        enum bond {
                            description
                                "An aggregated group of ethernet interfaces.";
                        }
                        enum conduit {
                            description
                                "An interface which is used as a connection to a switch device.";
                            t128-internal:visibility hidden;
                        }
                    }

@Chr1st0ph3rTurn3r
Chr1st0ph3rTurn3r self-requested a review August 13, 2026 18:06
@Chr1st0ph3rTurn3r
Chr1st0ph3rTurn3r merged commit 19ae1b8 into master Aug 13, 2026
1 check passed
@Chr1st0ph3rTurn3r
Chr1st0ph3rTurn3r deleted the inbound-gre branch August 13, 2026 18:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants