GRE (Generic Routing Encapsulation) : Point-to-point & multipoint GRE


- GRE (Generic Routing Encapsulation) IP protocol 47 is a tunneling protocol that encapsulate any network layer packet.

GRE provide the possibility to route IP packets between private IP networks across public networks with globally routed IP addresses. GRE is a unicast protocol hence the big advantage of encapsulating broadcast, multicast traffic (multicast streaming or routing protocols) or other non-IP protocols, and being protected by IPSec that doesn’t support unicast.

Here is the structure of the post:

Point-to-point

  • Tunnel configuration
  • Routing

Multipoint

  • Tunnel configuration
  • Routing
    • OSPF
    • EIGRP
  1. Point-to-point

    Figure1 depicts the physical topology on which point-to-point GRE tunneling is configured.

    Figure1:FR topology with point-to-point sub-interfaces


  2. Tunnel configuration

    Table1: Point-to-point GRE parameters on HUB

    Tunnelling parameters

    SpokeA

    SpokeB

    SpokeC

    Tunnel interface Tunnel 1 Tunnel 1 Tunnel 1
    Tunnel ip address &mask 192.168.10.1/24 192.168.20.1/24 192.168.30.1
    Tunnel source interface s0/0.101 s0/0.102 s0/0.103
    Tunnel destination interface 172.16.0.17 172.16.0.34 172.16.0.50

    Tunnel with SpokeA:

    HUB:

    HUB(config-if)#int tunnel1
    HUB(config-if)#ip address 192.168.10.1 255.255.255.0
    HUB(config-if)#tunnel mode gre ip

    HUB(config-if)#tunnel source s0/0.101

    HUB(config-if)#tunnel destination 172.16.0.18

    HUB(config-if)#

    *Mar  1 01:36:42.875: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

    HUB(config-if)#

    SpokeA:

    Table2:  Point-to-point GRE parameters on SpokeA

    Tunnelling parameters

    HUB

    Tunnel interface Tunnel 1
    Tunnel ip address &mask 192.168.10.2
    Tunnel source interface s0/0
    Tunnel destination interface 172.16.0.17
    SpokeA(config)#int tunnel 1
    SpokeA(config-if)#ip address
    SpokeA(config-if)#ip address 192.168.10.2 255.255.255.0

    SpokeA(config-if)#tunnel mode gre ip

    SpokeA(config-if)#tunnel source s0/0

    SpokeA(config-if)#tunnel destination 172.16.0.17

    SpokeA(config-if)#

    *Mar  1 01:38:27.703: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

    SpokeA(config-if)#

    Connectivity check and debugging:

    SpokeA(config-if)#do ping 192.168.10.1
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:

    !!!!!

    Success rate is 100 percent (5/5), round-trip min/avg/max = 76/102/128 ms

    SpokeA(config-if)#

    HUB#debug tunnel

    Tunnel Interface debugging is on

    HUB#

    *Mar  1 01:45:25.311: Tunnel1: GRE/IP to classify 172.16.0.18->172.16.0.17 (len=124 type=0×800 ttl=254 tos=0×0)

    !!GRE packet source and destination

    *Mar  1 01:45:25.315: Tunnel1: GRE/IP to decaps 172.16.0.18->172.16.0.17 (len=124 ttl=254)

    *Mar  1 01:45:25.319: Tunnel1: GRE decapsulated IP 192.168.10.2->192.168.10.1 (len=100, ttl=254)

    !! the encapsulated packet source and destination

    *Mar  1 01:45:25.323: Tunnel1: GRE/IP encapsulated 172.16.0.17->172.16.0.18 (linktype=7, len=124)

    *Mar  1 01:45:25.419: Tunnel1: GRE/IP to classify 172.16.0.18->172.16.0.17 (len=124 type=0×800 ttl=254 tos=0×0)

    *Mar  1 01:45:25.423: Tunnel1: GRE/IP to decaps 172.16.0.18->172.16.0.17 (len=124 ttl=254)

    *Mar  1 01:45:25.427: Tunnel1: GRE decapsulated IP 192.168.10.2->192.168.10.1 (len=100, ttl=254)

    *Mar  1 01:45:25.431: Tunnel1: GRE/IP encapsulated 172.16.0.17->172.16.0.18 (linktype=7, len=124)

    *Mar  1 01:45:25.483: Tunnel1: GRE/IP to classify 172.16.0.18->172.16.0.17 (len=124 type=0×800 ttl=254 tos=0×0)


    HUB#

    SpokeB:

    Table3:  Point-to-point GRE parameters on SpokeB

    Tunnelling parameters

    HUB

    Tunnel interface Tunnel 1
    Tunnel ip address &mask 192.168.20.2
    Tunnel source interface s0/0
    Tunnel destination interface 172.16.0.34

    HUB:

    HUB(config)#int tunnel 2
    HUB(config-if)#ip address 192.168.20.1 255.255.255.0
    HUB(config-if)#tunnel mode gre ip

    HUB(config-if)#tunnel source s0/0.102

    HUB(config-if)#tunnel destination 172.16.0.34

    HUB(config-if)#

    *Mar  1 01:56:36.851: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up

    HUB(config-if)#

    SpokeB:

    SpokeB(config)#int tunnel 1
    SpokeB(config-if)#ip addres
    SpokeB(config-if)#ip address 192.168.20.2 255.255.255.0

    SpokeB(config-if)#tunnel mode gre ip

    SpokeB(config-if)#tunnel source s0/0

    SpokeB(config-if)#tunnel dest 172.16.0.33

    SpokeB(config-if)#

    *Mar  1 02:03:10.971: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

    SpokeB(config-if)#

    Connectivity Check:

    SpokeB(config-if)#do ping 192.168.20.1

    Type escape sequence to abort.

    Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:

    !!!!!

    Success rate is 100 percent (5/5), round-trip min/avg/max = 60/87/112 ms

    SpokeB(config-if)#

    SpokeC:

    Table4:  Point-to-point GRE parameters on SpokeC

    Tunnelling parameters

    HUB

    Tunnel interface Tunnel 1
    Tunnel ip address &mask 192.168.30.2
    Tunnel source interface s0/0.301
    Tunnel destination interface 172.16.0.49

    HUB:

    HUB(config-if)#int tunnel 3
    HUB(config-if)#ip address 192.168.30.1 255.255.255.0
    HUB(config-if)#tunnel mode gre ip

    HUB(config-if)#tunnel source s0/0.103

    HUB(config-if)#tunnel destination 172.16.0.50

    HUB(config-if)#

    *Mar  1 01:59:07.255: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel3, changed state to up

    SpokeC:

    SpokeC(config)#int tunnel 1
    SpokeC(config-if)#ip address 192.168.30.2 255.255.255.0
    SpokeC(config-if)#tunnel mode gre ip

    SpokeC(config-if)#tunnel source s0/0.301

    SpokeC(config-if)#tunnel des 172.16.0.49

    SpokeC(config-if)#

    *Mar  1 02:08:17.751: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

    SpokeC(config-if)#

    Connectivity check:

    SpokeC(config-if)#do ping 192.168.30.1

    Type escape sequence to abort.

    Sending 5, 100-byte ICMP Echos to 192.168.30.1, timeout is 2 seconds:

    !!!!!

    Success rate is 100 percent (5/5), round-trip min/avg/max = 24/94/144 ms

    SpokeC(config-if)#

  3. Routing

    Routing protocols:

    HUB:

    HUB(config-if)#router ospf 10
    HUB(config-router)#router-id 1.1.1.1
    HUB(config-router)#net 192.168.10.0 0.0.0.255 area 0

    HUB(config-router)#net 192.168.20.0 0.0.0.255 area 0

    HUB(config-router)#net 192.168.30.0 0.0.0.255 area 0

    HUB(config-router)#net 10.0.1.0 0.0.0.255 area 10

    HUB(config-router)#

    Connectivity check:

    HUB#sh ip ospf int s0/0.101

    %OSPF: OSPF not enabled on Serial0/0.101

    Note that OSPF is not enabled over the interface facing the public network with routable IP (172.16.0.0/16 for the purpose of the lab), but over tunnel interfaces; and the default OSPF mode is point-to-point which match the GRE tunnel mode.

    HUB:

    HUB#sh ip ospf int tunnel 1
    Tunnel1 is up, line protocol is up
    Internet Address 192.168.10.1/24, Area 0

    Process ID 10, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 11111

    Transmit Delay is 1 sec, State POINT_TO_POINT,

    Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

    oob-resync timeout 40

    Hello due in 00:00:03

    Supports Link-local Signaling (LLS)

    Index 1/1, flood queue length 0

    Next 0×0(0)/0×0(0)

    Last flood scan length is 0, maximum is 0

    Last flood scan time is 0 msec, maximum is 0 msec

    Neighbor Count is 0, Adjacent neighbor count is 0

    Suppress hello for 0 neighbor(s)

    HUB#

    HUB(config-router)#do sh ip route


    C    192.168.30.0/24 is directly connected, Tunnel3

    C    192.168.10.0/24 is directly connected, Tunnel1

    172.16.0.0/28 is subnetted, 3 subnets

    C       172.16.0.48 is directly connected, Serial0/0.103

    C       172.16.0.32 is directly connected, Serial0/0.102

    C       172.16.0.16 is directly connected, Serial0/0.101

    C    192.168.20.0/24 is directly connected, Tunnel2

    10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

    O IA    10.10.0.1/32 [110/11112] via 192.168.10.2, 00:01:17, Tunnel1

    C       10.0.1.0/24 is directly connected, Loopback0

    O IA    10.30.0.1/32 [110/11112] via 192.168.30.2, 00:01:16, Tunnel3

    O IA    10.20.0.1/32 [110/11112] via 192.168.20.2, 00:01:17, Tunnel2

    HUB(config-router)#

    Received Inter-area routes point to tunnel interfaces and reachable through the other side of GRE tunnels.

  4. Multipoint

    Figure2 depicts the Frame Relay topology on which multipoint GRE tunneling is configured, multipoint GRE operates at the network layer, nevertheless the layer3 topology must be consistent with the layer below, where Frame Relay operates and where PVC are strictly configured and mapped to NBMA addresses.

    Figure2:FR topology with multipoint sub-interfaces


  5. Tunnel configuration

    HUB:

    Table5: multipoint GRE parameters on HUB

    Tunnelling parameters

    Any multipoint tunnel peer

    Tunnel interface Tunnel 1
    Tunnel ip address &mask 192.168.123.1/24
    Tunnel source interface s0/0.102
    Tunnel destination interface ??????????????????????

    HUB:

    HUB(config-if)#int tunnel 2
    HUB(config-if)#ip address 192.168.123.1 255.255.255.0
    HUB(config-if)#tunnel mode gre multipoint

    HUB(config-if)#tunnel source s0/0.102

    HUB(config-if)#

    *Mar  1 01:00:07.707: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up

    SpokeB:

    Table6: multipoint GRE parameters on SpokeB

    Tunnelling parameters

    Any multipoint tunnel peer

    Tunnel interface Tunnel 1
    Tunnel ip address &mask 192.168.123.2/24
    Tunnel source interface s0/0
    Tunnel destination interface ??????????????????????

    SpekeB:

    SpokeB(config-if)#int tunnel 1
    SpokeB(config-if)#ip address 192.168.123.2 255.255.255.0
    SpokeB(config-if)#tunnel mode gre multipoint

    SpokeB(config-if)#tunnel source s0/0

    SpokeB(config-if)#

    *Mar  1 01:00:27.419: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

    SpokeC:

    Table7: multipoint GRE parameters on SpokeC

    Tunnelling parameters

    Any multipoint tunnel peer

    Tunnel interface Tunnel 1
    Tunnel ip address &mask 192.168.123.3/24
    Tunnel source interface s0/0.300
    Tunnel destination interface ??????????????????????

    SpokeC :

    SpokeC(config-subif)#int tunnel 1
    SpokeC(config-if)#ip address 192.168.123.3 255.255.255.0
    SpokeC(config-if)#tunnel mode gre multipoint

    SpokeC(config-if)#tunnel source s0/0.300

    SpokeC(config-if)#

    *Mar  1 01:02:13.995: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

    HUB:

    HUB(config-if)#do sh int tunnel 2
    Tunnel2 is up, line protocol is up
    Hardware is Tunnel

    Internet address is 192.168.123.1/24

    MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

    reliability 255/255, txload 1/255, rxload 1/255

    Encapsulation TUNNEL, loopback not set

    Keepalive not set

    Tunnel source 172.16.0.33 (Serial0/0.102), destination UNKNOWN

    Tunnel protocol/transport multi-GRE/IP

    Key disabled, sequencing disabled

    Checksumming of packets disabled

    Fast tunneling enabled

    Tunnel transmit bandwidth 8000 (kbps)

    Tunnel receive bandwidth 8000 (kbps)


    HUB(config-if)#

    At this point you cannot miss the fact that it is not possible to set in advance the tunnel destination interface (GRE destination address) for multipoint GRE, here resides the concept of mGRE: one interface that ends multiple tunnels; hence the need for a mechanism that will identify  the remote peer’s tunnel end point ip address in advance, NHRP (Next Hop Resolution Protocol).

    Each spoke has been configured with a static map of the HUB tunnel IP address (192.168.123.1) and its NBMA address (172.16.0.33)

    ip nhrp map 192.168.123.1 172.16.0.33

    So each spoke NHRP starts registering itself by forming a tunnel with the HUB, the destination interface is taken from the previously configured static map.

    Finally the concept is very similar to the mapping in Frame Relay where a destination NBMA IP (layer3) is mapped to a DLCI ( PVC, layer 2) either statically or dynamically through inverse ARP.

    With mGRE a tunnel (logical source and destination IP’s) is necessary delimited by NBMA addresses, the destination one being unknown can be resolved statically through NHRP map or dynamically by requesting the NHRP server, the HUB. (figure3)

    Figure3: FR mapping and mGRE mapping


    Once resolved each Spoke forms a tunnel with the HUB, here comes the routing protocol, OSPF is announced on tunnel interfaces, so adjacency relationships will be formed with the HUB, it is important to tell routers that broadcast and multicast will be sent to the HUB, so they could exchange routing information.

    ip nhrp map multicast 172.16.0.33

    The command is very similar to FR:

    frame-relay map ip <nbma-dest-ip-next-hop> <local-dlci> broadcast

    Though the routing information between spokes is exchanged through the router, routing information populated in routing tables points to logical addresses (tunnel IP’s) and the NBMA addresses still  unknown.

    mGRE needs to resolve the NBMA destination address; spokes ask the HUB (NHS) what NBMA address correspond to a particular tunnel (logical) IP, the HUB respond from its NHRP records, the spoke use the obtained NBMA address as a destination and communicate directly with the destination spoke.

    The following command  instruct spokes where to forward the NHRP requests, if not specified the spoke will take the next-hop from the routing table.

    ip nhrp nhs 192.168.123.1

    Figure4 depicts the data flow between spokes and HUB:

    Figure4: Data flow


    TableX: NHRP commands

    ip nhrp network-id <number> Logical NBMA cloud to which the interface belongs.
    ip nhrp interest <ACL> Tells the router when to send NHRP requests.
    ip nhrp used <number> Send NHRP requests when there are certain number of packets for a destination.
    ip nhrp map <x.x.x.x> <data-link> Statically configure a router interface with NHRP data link layer (not needed with PVC)
    ip nhrp map multicast <remote_NBMA_desti_IP> Broadcast/multicast will be sent to a particular end- point of the tunnel.
    ip nhrp nhs <x.x.x.x> network <network> Statically configure NHS, otherwise NHRP will follow routing information that will point to a HUB.
    ip nhrp authentication <string> Configure authentication for NHRP peering
    ip nhrp max-send <packets> every <time- interval> Control the maximum rate of NHRP messages sent, by default 5 packets every 10 seconds.
    ip nhrp responder <inttype X/X> Set the source address of NHRP server replies.
    ip nhrp holdtime <sec> <sec> Lifetime of NHRP information, default 7200sec (2 hours) for negative and positive responses.

    Here is how all configuration commands look like:

    HUB:

    interface Tunnel2
    ip address 192.168.123.1 255.255.255.0

    ip nhrp authentication cisco

    ip nhrp map multicast dynamic

    ip nhrp network-id 123

    ip ospf network broadcast

    ip ospf priority 10

    tunnel source Serial0/0.102

    tunnel mode gre multipoint

    tunnel key 123  !! ===> If you have set a tunnel key, it should be the same on all

    !! routers that participate to the tunnel

    !

    interface Serial0/0

    no ip address

    encapsulation frame-relay

    no frame-relay inverse-arp

    !

    interface Serial0/0.101 point-to-point

    ip address 172.16.0.17 255.255.255.240

    frame-relay interface-dlci 101

    !

    interface Serial0/0.102 multipoint

    ip address 172.16.0.33 255.255.255.240

    ip ospf network broadcast

    ip ospf priority 10

    frame-relay map ip 172.16.0.34 102 broadcast

    frame-relay map ip 172.16.0.35 103 broadcast

    SpokeB:

    interface Tunnel1
    ip address 192.168.123.2 255.255.255.0

    ip nhrp authentication cisco

    ip nhrp map multicast 172.16.0.33

    ip nhrp map 192.168.123.1 172.16.0.33

    ip nhrp network-id 123

    ip nhrp nhs 192.168.123.1

    ip ospf network broadcast

    ip ospf priority 0

    tunnel source Serial0/0

    tunnel mode gre multipoint

    tunnel key 123

    !

    interface Serial0/0

    ip address 172.16.0.34 255.255.255.240

    encapsulation frame-relay

    frame-relay map ip 172.16.0.33 201 broadcast

    frame-relay map ip 172.16.0.35 203 broadcast

    no frame-relay inverse-arp

    SpokeC:

    interface Tunnel1
    ip address 192.168.123.3 255.255.255.0

    ip nhrp authentication cisco

    ip nhrp map multicast 172.16.0.33

    ip nhrp map 192.168.123.1 172.16.0.33

    ip nhrp network-id 123

    ip nhrp nhs 192.168.123.1

    ip ospf network broadcast

    ip ospf priority 0

    tunnel source Serial0/0.300

    tunnel mode gre multipoint

    tunnel key 123

    !

    interface Loopback0

    ip address 10.30.0.1 255.255.0.0

    !

    interface Serial0/0

    no ip address

    encapsulation frame-relay

    no frame-relay inverse-arp

    !

    interface Serial0/0.300 multipoint

    ip address 172.16.0.35 255.255.255.240

    frame-relay map ip 172.16.0.33 301 broadcast

    frame-relay map ip 172.16.0.34 302 broadcast

    Make sure that tunnel key match with all routers participating in the same mGRE.

    Monitoring:

    HUB:

    HUB#sh ip nhrp

    192.168.123.2/32 via 192.168.123.2, Tunnel2 created 00:55:29, expire 01:43:40

    Type: dynamic, Flags: authoritative unique registered

    NBMA address: 172.16.0.34

    192.168.123.3/32 via 192.168.123.3, Tunnel2 created 00:55:52, expire 01:44:07

    Type: dynamic, Flags: authoritative unique registered

    NBMA address: 172.16.0.35

    HUB#

    Note from the following tunnel debugging that though tunnel destination is not pre-configured, as a result of NHRP, the router resolved the detination source interface of the tunnel according to the logical destination it wanted to reach:

    HUB#ping  10.30.0.1
    !!==>We want to reach SpokeC private network
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 10.30.0.1, timeout is 2 seconds:

    !!!!!

    *Mar  1 01:00:30.171: Tunnel2: GRE/IP to classify 172.16.0.35->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

    *Mar  1 01:00:30.179: Tunnel2: GRE/IP to decaps 172.16.0.35->172.16.0.33 (len=128 ttl=254)

    *Mar  1 01:00:30.183: Tunnel2: GRE decapsulated IP 10.30.0.1->192.168.123.1 (len=100, ttl=254)

    *Mar  1 01:00:30.311: Tunnel2: GRE/IP to classify 172.16.0.35->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

    *Mar  1 01:00:30.315: Tunnel2: GRE/IP to decaps 172.16.0.35->172.16.0.33 (len=128 ttl=254)

    *Mar  1 01:00:30.319: Tunnel2: GRE decapsulated IP 10.30.0.1->192.168.123.1 (len=100, ttl=254)

    Success rate is 100 percent (5/5), round-trip min/avg/max = 64/126/216 ms

    HUB#

    *Mar  1 01:00:30.451: Tunnel2: GRE/IP to classify 172.16.0.35->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

    *Mar  1 01:00:30.459: Tunnel2: GRE/IP to decaps 172.16.0.35->172.16.0.33 (len=128 ttl=254)

    *Mar  1 01:00:30.459: Tunnel2: GRE decapsulated IP 10.30.0.1->192.168.123.1 (len=100, ttl=254)

    *Mar  1 01:00:30.531: Tunnel2: GRE/IP to classify 172.16.0.35->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

    *Mar  1 01:00:30.539: Tunnel2: GRE/IP to decaps 172.16.0.35->172.16.0.33 (len=128 ttl=254)

    *Mar  1 01:00:30.543: Tunnel2: GRE decapsulated IP 10.30.0.1->192.168.123.1 (len=100, ttl=254)

    *Mar  1 01:00:30.595: Tunnel2: GRE/IP to classify 172.16.0.35->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

    *Mar  1 01:00:30.599: Tunnel2: GRE/IP to decaps 172.16.0.35->172.16.0.33 (len=128 ttl=254)

    *Mar  1 01:00:30.603: Tunnel2: GRE decapsulated IP 10.30.0.1->192.168.123.1 (len=100, ttl=254)

    *Mar  1 01:00:32.415: Tunnel1: GRE/IP encapsulated 172.16.0.17->172.16.0.18 (linktype=7, len=104)

    HUB#

    HUB#

    HUB#ping 10.20.0.1
    !!==> Now we want to reach SpokeB private network

    Type escape sequence to abort.

    Sending 5, 100-byte ICMP Echos to 10.20.0.1, timeout is 2 seconds:

    !!!!!

    Success rate is 100 percent (5/5), round-trip min/avg/max = 76/121/164 ms

    HUB#

    *Mar  1 01:01:55.943: Tunnel2: GRE/IP to classify 172.16.0.34->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

    *Mar  1 01:01:55.947: Tunnel2: GRE/IP to decaps 172.16.0.34->172.16.0.33 (len=128 ttl=254)

    *Mar  1 01:01:55.951: Tunnel2: GRE decapsulated IP 10.20.0.1->192.168.123.1 (len=100, ttl=254)

    *Mar  1 01:01:56.111: Tunnel2: GRE/IP to classify 172.16.0.34->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

    *Mar  1 01:01:56.115: Tunnel2: GRE/IP to decaps 172.16.0.34->172.16.0.33 (len=128 ttl=254)

    *Mar  1 01:01:56.119: Tunnel2: GRE decapsulated IP 10.20.0.1->192.168.123.1 (len=100, ttl=254)

    *Mar  1 01:01:56.239: Tunnel2: GRE/IP to classify 172.16.0.34->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

    *Mar  1 01:01:56.243: Tunnel2: GRE/IP to decaps 172.16.0.34->172.16.0.33 (len=128 ttl=254)

    *Mar  1 01:01:56.247: Tunnel2: GRE decapsulated IP 10.20.0.1->192.168.123.1 (len=100, ttl=254)

    *Mar  1 01:01:56.315: Tunnel2: GRE/IP to classify 172.16.0.34->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

    *Mar  1 01:01:56.319: Tunnel2: GRE/IP to decaps 172.16.0.34->172.16.0.33 (len=128 ttl=254)

    *Mar  1 01:01:56.323: Tunnel2: GRE decapsulated IP 10.20.0.1->192.168.123.1 (len=100, ttl=254)

    *Mar  1 01:01:56.395: Tunnel2: GRE/IP to classify 172.16.0.34->172.16.0.33 (len=128 type=0×800 ttl=254 tos=0×0)

    *Mar  1 01:01:56.403: Tunnel2: GRE/IP to decaps 172.16.0.34->172.16.0.33 (len=128 ttl=254)

    *Mar  1 01:01:56.407: Tunnel2: GRE decapsulated IP 10.20.0.1->192.168.123.1 (len=100, ttl=254)un all

    *Mar  1 01:01:58.083: Tunnel1: GRE/IP to classify 172.16.0.18->172.16.0.17 (len=104 type=0×800 ttl=254 tos=0xC0)

    *Mar  1 01:01:58.087: Tunnel1: GRE/IP to decaps 172.16.0.18->172.16.0.17 (len=104 ttl=254)

    *Mar  1 01:01:58.091: Tunnel1: GRE decapsulated IP 192.168.10.2->224.0.0.5 (len=80, ttl=1)

    All possible debugging has been turned off

    HUB#

    The following debug detail the process of the initial NHRP registration when SpokeB tunnel goes up:

    HUB#

    *Mar  1 01:15:02.575: NHRP: Receive Registration Request via Tunnel2 vrf 0, packet size: 81

    *Mar  1 01:15:02.579:  (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

    *Mar  1 01:15:02.579:      shtl: 4(NSAP), sstl: 0(NSAP)

    *Mar  1 01:15:02.579:  (M) flags: “unique”, reqid: 5

    *Mar  1 01:15:02.583:      src NBMA: 172.16.0.34

    *Mar  1 01:15:02.583:      src protocol: 192.168.123.2, dst protocol: 192.168.123.1

    *Mar  1 01:15:02.587:  (C-1) code: no error(0)

    *Mar  1 01:15:02.591:        prefix: 255, mtu: 1514, hd_time: 7200

    *Mar  1 01:15:02.591:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0

    *Mar  1 01:15:02.595: NHRP: Send Registration Reply via Tunnel2 vrf 0, packet size: 101

    *Mar  1 01:15:02.599:  src: 192.168.123.1, dst: 192.168.123.2

    *Mar  1 01:15:02.603:  (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1

    *Mar  1 01:15:02.603:      shtl: 4(NSAP), sstl: 0(NSAP)

    *Mar  1 01:15:02.607:  (M) flags: “unique“, reqid: 5

    *Mar  1 01:15:02.607:      src NBMA: 172.16.0.34

    *Mar  1 01:15:02.611:      src protocol: 192.168.123.2, dst protocol: 192.168.123.1

    *Mar  1 01:15:02.615:  (C-1) code: no error(0)

    *Mar  1 01:15:02.615:        prefix: 255, mtu: 1514, hd_time: 7200

    *Mar  1 01:15:02.619:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0

    *Mar  1 01:15:03.659: %OSPF-5-ADJCHG: Process 10, Nbr 2.2.2.2 on Tunnel2 from LOADING to FULL, Loadi    ng Done

    HUB#

    And  here the process of NHRP request for resolution from SpokeC that wants to reach SpokeB private network:

    HUB#
    *Mar  1 01:21:51.131: NHRP: Receive Registration Request via Tunnel2 vrf 0, packet size: 81
    *Mar  1 01:21:51.135: NHRP: netid_in = 123, to_us = 0

    *Mar  1 01:21:51.135: NHRP: Finding next idb with in_pak id: 0

  6. Routing
  7. OSPF

    When using OSPF make sure that you announce networks through the tunnel interfaces and that the OSPF network mode is either broadcast or point-to-multipoint, not the default point-to-point.

  8. EIGRP

    With EIGRP make sure that you disabled split-horizon.

About these ads

About ajnouri
Se vi deziras sekure komuniki eksterbloge, jen mia publika (GPG) ŝlosilo: My public key for secure communication: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x41CCDE1511DF0EB8

14 Responses to GRE (Generic Routing Encapsulation) : Point-to-point & multipoint GRE

  1. Vignesh says:

    Hi,
    Thanks a lot for wonderful tutorial. Keep up the good work

    Vignesh

  2. shivlu jain says:

    The explanation is really wonderful.

  3. Ronnie_Hitman says:

    Awesome… i got it what i was looking for … any differences if those multipoint tunnels are created over IPSEC…??

    • cciethebeginning says:

      Hi Ronnie,
      Site-to-Site IPSec is Point-to-Point, so a secure tunnel must be established between a pre-configured source and destination; this is namely a disadvantage of IPSec in full mesh topologies where any router should have the possibility to establish a secure tunnel with any other router.
      mGRE allows to dynamically establish any-to-any GRE tunnels, once this is done IPsec will establish a PTP encryption tunnel for any given dynamically established GRE tunnel.
      It is the subject of the post Building DMVPN with mGRE, NHRP and IPSec VPN.

  4. Raghu says:

    Fabulous explanation…Is it necesary that the 2& 3 tunnel number of hub should be matching with respect to tunnel number of 2 and 3 spokes.?

    • cciethebeginning says:

      Thank you Shukla. You can make communicate a multipoint interface with multiple point-to-point interfaces depending on your needs. Just configure each type of interface appropriately :
      – PTP interface will bind its local DLCI to a unique Next-hop IP to form a single PVC.
      – PTM interface will have multiple local DLCIs bound to different Next-hop IPs to differentiate between multiple PVCs.

  5. Ramon says:

    great submit, very informative. I’m wondering why the opposite specialists of this sector do not realize this. You must continue your writing. I’m confident, you have a great readers’ base already!

  6. emmak says:

    this is great !
    but i have a doubt on how you configured ur hub router sub-interfaces on the point-to-point

    • cciethebeginning says:

      You are absolutely right Emmak, there was indeed some “harmless” discrepancies in shown subnet addresses (figure1)
      Now corrected.

      PVC between HUB & spoke A (subnet 172.16.0.16/28)
      HUB interface s0/0.101 point-to-point : 172.16.0.17/28
      SpokeA : 172.16.0.18/28

      PVC between HUB & spoke B (subnet 172.16.0.32/28)
      HUB interface s0/0.102 point-to-point : 172.16.0.33/28
      SpokeB : 172.16.0.34/28

      PVC between HUB & spoke C (subnet 172.16.0.48/28)
      HUB interface s0/0.103 point-to-point : 172.16.0.49/28
      SpokeC : 172.16.0.50/28

      Thanks Emmak and well done !

  7. Great help for me, good sharing! thank you!

  8. dIEGO says:

    hi, IN TUNEL GRE I CAN USE KEEPALIVE, IN MGRE WHAT COMMAND I CAN USE??

  9. Pingback: Frame Relay Notes | Agus Setiawan's Blog

  10. Pingback: DMVPN animation | CCIE, the beginning!

  11. Pingback: Frame Relay Notes | Agus Setiawan

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: