No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

FAQ-Why Does An Incorrect GRE Tunnel Interface Number on an NE40E Lead to Tunnel Down?

Publication Date:  2019-03-27 Views:  11 Downloads:  0
Issue Description

Most tunnel down events occurred after GRE configuration are caused by an incorrect tunnel interface number. Why does an incorrect GRE tunnel interface number on an NE40E lead to tunnel down?

Solution

1. In V5, GRE can be bound to loopback interfaces only. In V8, GRE can be bound to loopback interfaces, GE interfaces, Eth-Trunk interfaces, GE sub-interfaces, and Eth-Trunk interfaces.

To view the binding relationship, run the binding tunnel gre command.

2. V8 supports GRE on one-dimensional tunnel interfaces.

One-dimensional interface: Tunnel x

Three-dimensional interface: Tunnel x/y/z (x indicates the slot ID of the bound board)

The NE40E supports the following types of GRE:

Distributed GRE tunnel: The tunnel interface is one-dimensional (named only by the interface number). GRE packets are encapsulated and decapsulated directly on the inbound interface board.

Integrated GRE tunnel: The tunnel interface is three-dimensional (named by the slot ID, subcard ID, and interface number). GRE packets are encapsulated and decapsulated directly on a service processing board.

If the target-board slot-number [ backup slave-slot-number ] command is not run, the GRE tunnel interface must be one-dimensional (distributed GRE).

For an integrated GRE tunnel whose tunnel interface is a three-dimensional interface, this command must be run before GRE is bound to the interface using the binding tunnel gre command. After the configuration is complete, the GRE tunnel sends packets received from the source tunnel interface to the corresponding GRE service boards for processing.

END