Ipv6 ISATAP tunneling


OVERVIEW

Comparing with other tunneling techniques like 6to4, ISATAP (Intra-site Automatic Tunnel Addressing Protocol) tunneling builds a tunnel for transport of IPv6 traffic over IPv4 within an IPv4 network, not between IPv6 networks.

ISATAP treats IPv4 network as NBMA and determines the destination on a per packet-basis (point-to-multipoint).

There is two ISATAP node behaviors, client and server : Each client builds a static tunnel to the server and requests an IPv6 address. The server (dedicated router or Windows any *nix server) with ipv6 functionalities enabled, will advertise IPv6 network information and allow IPv6 nodes to configure their applications as they were connected to an Ethernet interface.

In this Lab a server 2003 is configured as a ISATAP client node and a Cisco Router as an advertiser, ISATAP server.

The client ISATAP configuration is also applicable to windows XP workstations as well.

ISATAP address scheme is developed as follow:

64-bit link-local or global unicast prefix + 0000:5EFE + <IPv4 of ISATAP link>

0000:5EFE == the ISATAP identifier.

DEPLOYMENT

ISATAP router configuration:


Router Ethernet interface should be configured to communicate with all nodes that want to communicate in IPv4.

interface FastEthernet0/0
ip address 192.168.43.103 255.255.255.0
no sh
ISATAP-srv#
ISATAP-srv#sh ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.43.103 YES manual up up

Tunnel0 unassigned YES unset up up

ISATAP-srv#ping 192.168.43.104

Type escape sequence to abort.

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

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/22/40 ms

ISATAP-srv#

The interface is up and the ipv4 address connectivity is verified, this allows the communication between IPv6 nodes and the router to automatically configure their ISATAP information.

On the tunnel interface, IPv6 RA (router advertisement) is disabled by default and need to be re-enabled, also the ISATAP is specified under IPv6 over ipv4 tunnel mode.

ipv6 unicast-routing
interface Tunnel0
ipv6 address 2001:DB8:2:1::/64 eui-64
no ipv6 nd suppress-ra
tunnel source FastEthernet0/0

tunnel mode ipv6ip isatap

no sh

IPv6 information are correctly configured and verified:

ISATAP-srv#sh ipv6 int brief
FastEthernet0/0 [up/up]
 Tunnel0 [up/up]

FE80::5EFE:C0A8:2B67

2001:DB8:2:1:0:5EFE:C0A8:2B67

ISATAP-srv#

ISATAP node configuration:

First of all ipv6 protocol must be enabled on windows server 2003 /XP, then within “netsh”  ISATAP ipv6 mode must be specified.

Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\>netsh interface ipv6 isatap set router \\192.168.43.103
Ok.
C:\>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : mngmnt
Primary Dns Suffix . . . . . . . : nouri.com

Node Type . . . . . . . . . . . . : Hybrid

IP Routing Enabled. . . . . . . . : No

WINS Proxy Enabled. . . . . . . . : No

DNS Suffix Search List. . . . . . : nouri.com

Ethernet adapter loopback:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Microsoft Loopback Adapter

Physical Address. . . . . . . . . : 02-00-4C-4F-4F-50

DHCP Enabled. . . . . . . . . . . : No

IP Address. . . . . . . . . . . . : 192.168.43.104

Subnet Mask . . . . . . . . . . . : 255.255.255.0

IP Address. . . . . . . . . . . . : fe80::4cff:fe4f:4f50%6

Default Gateway . . . . . . . . . : 192.168.43.103

DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1

fec0:0:0:ffff::2%1

fec0:0:0:ffff::3%1

Tunnel adapter Teredo Tunneling Pseudo-Interface:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface

Physical Address. . . . . . . . . : FF-FF-FF-FF-FF-FF-FF-FF

DHCP Enabled. . . . . . . . . . . : No

IP Address. . . . . . . . . . . . : fe80::ffff:ffff:fffd%5

Default Gateway . . . . . . . . . :

NetBIOS over Tcpip. . . . . . . . : Disabled

Tunnel adapter Automatic Tunneling Pseudo-Interface:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Automatic Tunneling Pseudo-Interface

Physical Address. . . . . . . . . : C0-A8-2B-68

DHCP Enabled. . . . . . . . . . . : No

IP Address. . . . . . . . . . . . : fe80::5efe:192.168.43.104%2

Default Gateway . . . . . . . . . :

DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1

fec0:0:0:ffff::2%1

fec0:0:0:ffff::3%1

NetBIOS over Tcpip. . . . . . . . : Disabled

C:\>

ISATAP router and ipv6 node are communicating with success as the node is reached through its dynamically configured address:

ISATAP-srv#ping ipv6 fe80::5efe:c0a8:2b68
Output Interface: tunnel 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::5EFE:C0A8:2B68, timeout is 2 seconds:
!!!!!

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

ISATAP-srv#

Figure2: IPv6 traffic capture

ROUTER CONFIGURATION

Router ISATAP-srv configuration:

ISATAP-srv#sh run
ipv6 unicast-routing
interface Tunnel0

ipv6 address 2001:DB8:2:1::/64 eui-64

no ipv6 nd suppress-ra

tunnel source FastEthernet0/0

tunnel mode ipv6ip isatap
!
interface FastEthernet0/0
ip address 192.168.43.103 255.255.255.0
Advertisements

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=0x800 ttl=254 tos=0x0)

    !!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=0x800 ttl=254 tos=0x0)

    *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=0x800 ttl=254 tos=0x0)


    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 0x0(0)/0x0(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=0x800 ttl=254 tos=0x0)

    *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=0x800 ttl=254 tos=0x0)

    *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=0x800 ttl=254 tos=0x0)

    *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=0x800 ttl=254 tos=0x0)

    *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=0x800 ttl=254 tos=0x0)

    *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=0x800 ttl=254 tos=0x0)

    *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=0x800 ttl=254 tos=0x0)

    *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=0x800 ttl=254 tos=0x0)

    *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=0x800 ttl=254 tos=0x0)

    *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=0x800 ttl=254 tos=0x0)

    *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=0x800 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.

Frame Relay connectivity


Frame Relay is was one of the main topics of the CCIE lab exam until v5.0 before being replaced by MPLS technology. But Some Enterprises still using it and it is nice to have some understanding about some related concepts like point-to-point and multipoint interfaces, sub-interfaces, enabled/disabled inverse ARP… etc.

In this post two main topologies will be treated: the first with point-to-point interfaces and sub-interfaces and the second with multipoint interfaces and sub-interfaces. For each case inverse ARP will be enabled and disabled.

  1. Point-to-point

I-a) No Inverse ARP

  • Interface
  • Sub-interface
  • Connectivity check

I-b) Inverse ARP

  • Interface
  • Sub-interface
  1. Point-to-multipoint

II-a) No Inverse ARP

  • Interface
  • Sub-interface

II-b) Inverse ARP

  • Interface
  • Sub-interface

First let’s start by a very brief recall of “LMI” and “inverse ARP”:

LMI (Local Management Interface): Manage local access link between the FR router and service provider switch, it maintains the status between the two devices.

The router sends status enquiry message each 10 seconds and the FR switch responds with a status message (keepalive) with the sixth message carrying information about PVC and DLCI routed to the interface of the router.

Also LMI trigger the router to send inverse ARP message (router IP over the VC).

Inverse ARP: allow a FR router to react to a received LMI message “PVC up” and announce its IP address to the other end of the PVC, this is particularly useful when the IP address of the other end of the PVC is not known or when a FR router interface/sub-interface ends more than one PVC.

I-Point-to-point


I-a) NO InverseARP

Interface

– When using a “physical interface” to end a point-to-point PVC with a “sub-interface” in the other side, a static mapping is needed to map the local DLCI to the next-hop ip.

SpokeA:

interface Serial0/0
ip address 172.16.0.18 255.255.255.240

encapsulation frame-relay

ip ospf network point-to-point

frame-relay map ip 172.16.0.17 110 broadcast

frame-relay interface-dlci 110

no frame-relay inverse-arp

SpokeB:

interface Serial0/0
ip address 172.16.0.34 255.255.255.240

encapsulation frame-relay

ip ospf network point-to-point

frame-relay map ip 172.16.0.33 201 broadcast

frame-relay interface-dlci 201

no frame-relay inverse-arp

Sub-interface

– Only interface local DLCI.

– No need for static mapping to the other side, because it is a point-to-point “sub-interface” and there is only one DLCI in the other side.

HUB:

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

ip ospf network point-to-point

frame-relay interface-dlci 101

!

interface Serial0/0.102 point-to-point

ip address 172.16.0.33 255.255.255.240

ip ospf network point-to-point

frame-relay interface-dlci 102

!

interface Serial0/0.103 point-to-point

ip address 172.16.0.49 255.255.255.240

ip ospf network point-to-point

frame-relay interface-dlci 103

SpokeC:

interface Serial0/0
no ip address

encapsulation frame-relay

no frame-relay inverse-arp

!

interface Serial0/0.301 point-to-point

ip address 172.16.0.50 255.255.255.240

ip ospf network point-to-point

frame-relay interface-dlci 301

!! it doesn’t matter whether inverse ARP is configured or not

!!no frame-relay inverse-arp

Connectivity check

HUB:

HUB#ping 172.16.0.18
Type escape sequence to abort.

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

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 20/55/96 ms

HUB#ping 172.16.0.34

Type escape sequence to abort.

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

!!!!!

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

HUB#ping 172.16.0.50

Type escape sequence to abort.

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

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/84/168 ms

HUB#

I-b) InverseARP

Interface

– When using a “physical interface” to end a point-to-point PVC, with a “sub-interface” in the other side, and inverse ARP enabled, there is no need for a static mapping.

Sub-interface

– Only interface local DLCI is configured.

– No need for static mapping to the other side, because it is a point-to-point “sub-interface” and there is only one DLCI in the other side.

II) Point-to-multipoint


NO InverseARP

Interface

– With inverse ARP disabled you have to set static mapping of the local DLCI (PVC) to next hop IP addresses because the interface ends more than one PVC.

SpokeB:

interface Serial0/0
ip address 172.16.0.34 255.255.255.240

encapsulation frame-relay

ip ospf network point-to-multipoint

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

Sub-interface

– As with physical interfaces, in sub-interfaces you need to set static mapping of interface local DLCI to remote IP because the sub-interface ends more than one PVC.

HUB:

interface Serial0/0
no ip address

encapsulation frame-relay

no frame-relay inverse-arp

!

interface Serial0/0.102 multipoint

ip address 172.16.0.33 255.255.255.240

ip ospf network point-to-multipoint

frame-relay map ip 172.16.0.34 102 broadcast

frame-relay map ip 172.16.0.35 103 broadcast

SpokeC:

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

ip ospf network point-to-multipoint

frame-relay map ip 172.16.0.33 301 broadcast

frame-relay map ip 172.16.0.34 302 broadcast

Connectivity check

HUB:

HUB#sh frame map
Serial0/0.102 (up): ip 172.16.0.34 dlci 102(0x66,0x1860), static,

broadcast,

CISCO, status defined, active

Serial0/0.102 (up): ip 172.16.0.35 dlci 103(0x67,0x1870), static,

broadcast,

CISCO, status defined, active

Serial0/0.101 (up): point-to-point dlci, dlci 101(0x65,0x1850), broadcast

status defined, active

HUB#

HUB#sh ip route

172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks

C       172.16.0.32/28 is directly connected, Serial0/0.102

O       172.16.0.34/32 [110/64] via 172.16.0.34, 00:19:49, Serial0/0.102

O       172.16.0.35/32 [110/64] via 172.16.0.35, 00:19:49, Serial0/0.102

C       172.16.0.16/28 is directly connected, Serial0/0.101

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

O IA    10.10.0.1/32 [110/65] via 172.16.0.18, 00:19:49, Serial0/0.101

C       10.0.1.0/24 is directly connected, Loopback0

O IA    10.30.0.1/32 [110/65] via 172.16.0.35, 00:19:49, Serial0/0.102

O IA    10.20.0.1/32 [110/65] via 172.16.0.34, 00:19:49, Serial0/0.102

HUB#

HUB#ping 172.16.0.34
Type escape sequence to abort.

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

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 28/84/132 ms

HUB#ping 172.16.0.35

Type escape sequence to abort.

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

!!!!!

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

HUB#ping

Protocol [ip]:

Target IP address: 10.20.0.1

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: 10.0.1.1

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

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

Packet sent with a source address of 10.0.1.1

!!!!!

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

HUB#

InverseARP

Inteface

Whether it is a sub-interface or a physical interface with inverse ARP enabled with point-to-multipoint, it is nor required to map statically local DLCI’s to next-hop’s:

SpokeB:

interface Serial0/0
ip address 172.16.0.34 255.255.255.240

encapsulation frame-relay

ip ospf network point-to-multipoint

ip ospf priority 0

serial restart-delay 0

no dce-terminal-timing-enable

frame-relay interface-dlci 201

frame-relay interface-dlci 203

Sub-interface

– Inverse ARP will discover what DLCI to use to reach a particular adjacent IP address, for that LMI triggers the router to send inverse ARP messages.

– IT is recommended to disable inverse ARP in the CCIE lab exam, otherwise routers will be connected not according to the lab exam. In general pay a particular attention to default configuration and parameters.

HUB:

interface Serial0/0
no ip address

encapsulation frame-relay

!

interface Serial0/0.102 multipoint

ip address 172.16.0.33 255.255.255.240

ip ospf network point-to-multipoint

frame-relay interface-dlci 102

frame-relay interface-dlci 103

SpokeC:

interface Serial0/0
no ip address

encapsulation frame-relay

!

interface Serial0/0.300 multipoint

ip address 172.16.0.35 255.255.255.240

ip ospf network point-to-multipoint

frame-relay interface-dlci 301

frame-relay interface-dlci 302

Connectivity check

HUB:

HUB(config-subif)#do sh frame map
Serial0/0.102 (up): ip 172.16.0.34 dlci 102(0x66,0x1860), dynamic,

broadcast,

CISCO, status defined, active

Serial0/0.102 (up): ip 172.16.0.35 dlci 103(0x67,0x1870), dynamic,

broadcast,

CISCO, status defined, active

Serial0/0.101 (up): point-to-point dlci, dlci 101(0x65,0x1850), broadcast

status defined, active

HUB(config-subif)#

HUB(config-subif)#do ping
Protocol [ip]:

Target IP address: 10.20.0.1

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: 10.0.1.1

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

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

Packet sent with a source address of 10.0.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 44/80/156 ms

HUB(config-subif)#

SpokeB:

SpokeB(config-if)#do sh frame map
Serial0/0 (up): ip 172.16.0.33 dlci 201(0xC9,0x3090), dynamic,

broadcast,

CISCO, status defined, active

Serial0/0 (up): ip 172.16.0.35 dlci 203(0xCB,0x30B0), dynamic,

broadcast,, status defined, active

SpokeB(config-if)#

SpokeC:

SpokeC(config-subif)#do sh frame map
Serial0/0.300 (up): ip 172.16.0.33 dlci 301(0x12D,0x48D0), dynamic,

broadcast,

CISCO, status defined, active

Serial0/0.300 (up): ip 172.16.0.34 dlci 302(0x12E,0x48E0), dynamic,

broadcast,

CISCO, status defined, active

SpokeC(config-subif)#

Debugging LMI:

HUB#

*Mar 1 08:55:48.173: Serial0/0(out): StEnq, myseq 152, yourseen 20, DTE up

*Mar 1 08:55:48.173: datagramstart = 0x7B6D434, datagramsize = 13

*Mar 1 08:55:48.177: FR encap = 0xFCF10309

*Mar 1 08:55:48.177: 00 75 01 01 01 03 02 98 14

*Mar 1 08:55:48.201:

*Mar 1 08:55:48.205: Serial0/0(in): Status, myseq 152, pak size 13

*Mar 1 08:55:48.205: RT IE 1, length 1, type 1

*Mar 1 08:55:48.209: KA IE 3, length 2, yourseq 21, myseq 152

*Mar 1 08:55:58.173: Serial0/0(out): StEnq, myseq 153, yourseen 21, DTE up

*Mar 1 08:55:58.173: datagramstart = 0x7B6D2F4, datagramsize = 13

*Mar 1 08:55:58.177: FR encap = 0xFCF10309

*Mar 1 08:55:58.177: 00 75 01 01 01 03 02 99 15

*Mar 1 08:55:58.185:

*Mar 1 08:55:58.213: Serial0/0(in): Status, myseq 153, pak size 13

*Mar 1 08:55:58.217: RT IE 1, length 1, type 1

*Mar 1 08:55:58.217: KA IE 3, length 2, yourseq 22, myseq 153

*Mar 1 08:56:08.173: Serial0/0(out): StEnq, myseq 154, yourseen 22, DTE up

*Mar 1 08:56:08.177: datagramstart = 0x7B6CDF4, datagramsize = 13

*Mar 1 08:56:08.177: FR encap = 0xFCF10309

*Mar 1 08:56:08.177: 00 75 01 01 01 03 02 9A 16

*Mar 1 08:56:08.185:

*Mar 1 08:56:08.221: Serial0/0(in): Status, myseq 154, pak size 37

*Mar 1 08:56:08.221: RT IE 1, length 1, type 0

*Mar 1 08:56:08.225: KA IE 3, length 2, yourseq 23, myseq 154

*Mar 1 08:56:08.225: PVC IE 0x7 , length 0x6 , dlci 101, status 0x2 , bw 0

*Mar 1 08:56:08.229: PVC IE 0x7 , length 0x6 , dlci 102, status 0x0 , bw 0

*Mar 1 08:56:08.229: PVC IE 0x7 , length 0x6 , dlci 103, status 0x2 , bw 0

*Mar 1 08:56:18.173: Serial0/0(out): StEnq, myseq 155, yourseen 23, DTE up

*Mar 1 08:56:18.173: datagramstart = 0x7B6D6B4, datagramsize = 13

*Mar 1 08:56:18.177: FR encap = 0xFCF10309

*Mar 1 08:56:18.177: 00 75 01 01 01 03 02 9B 17

*Mar 1 08:56:18.185:

What is DMVPN ?


The complexity of DMVPN resides in the multitude of concepts involved in this technology: NHRP, mGRE, and IPSec. So to demystify the beast it crucial to enumerate the advantages, disadvantages, and conditions related to different NBMA topologies and their evolution.

Spokes with permanent public addresses

Hub and Spoke topology

Pro:

– Ease of configuration on spokes, only HUB parameters are configured and the HUB routes all traffic between spokes.

Con:

– Memory and CPU resource consumption on the HUB.

– Static configuration burdensome, prone to errors and hard to maintain for very large networks.

– Lack of scalability and flexibility.

– No security, network traffic is not protected.

Full/partial mesh topology

Pros:

– Each spoke is able to communicate with other spokes directly.

Cons:

– Static configuration burdensome, prone to errors and hard to maintain for very large networks.

– Lack of scalability and flexibility.

– Additional memory and CPU resource requirements on branch routers for just occasional and non-permanent spoke-to-spoke communications.

– No security, network traffic is not protected.

Point-to-point GRE

Pro:

– Lack of scalability: need static configuration between each spoke and the HUB in a HUB and Spoke topology; and between each pair of spokes in a full/partial mesh topology.

– GRE supports IP broadcast and multicast to the other end of the tunnel.

– GRE is a unicast protocol, so can be encapsulated using IPSec and provide routing/multicasting in a protected environment.

Cons:

– Lack of security.

Point-to-multipoint GRE

Pros:

– A single tunnel interface can terminate all GRE tunnels from all spokes.

– No configuration complexity and resolves the issue of memory allocations.

Cons:

– Lack of security.

Full/partial mesh topology + IPSec

Pros:

– Each spoke is able to communicate with other spokes directly.

– Security.

Cons:

– Static configuration burdensome, prone to errors and hard to maintain.

– Lack of scalability and flexibility.

– Additional memory and CPU resource requirements on branch routers for just occasional and non-permanent spoke-to-spoke communications.

– IPsec doesn’t support multicast/broadcast, so cannot deploy routing protocols.

– Need pre-configured access-list for interesting traffic that will trigger IPSec establishment so need manual intervention in case applications changes.

– IPSec establishment will take [1-10] seconds, hence packet drops in the beginning.

Hub and Spoke topology + IPSec

Pro:

– Ease of configuration on spokes, only HUB parameters are configured and the router routes all traffic between spokes.

Con:

– Memory and CPU resource consumption on the HUB.

– Static configuration burdensome, prone to errors and hard to maintain in very large networks.

– Lack of scalability and flexibility.

– IPSec doesn’t support multicast/broadcast, so cannot deploy routing protocols.

– IPSec needs pre-configured access-list for interesting traffic that will trigger IPSec establishment.

– IPSec establishment will take [1-10] seconds, so packet drops.

Point-to-point GRE + IPSec

Pro:

– Lack of scalability: need static configuration between each spoke and the HUB in a HUB and Spoke topology; and between each pair of spokes in a full/partial mesh topology.

– GRE supports IP broadcast and multicast to the other end of the tunnel.

– GRE is a unicast protocol, so can be encapsulated using IPSec and provide routing/multicasting in a protected environment.

– Security.

Cons:

– Need pre-configured access-list for interesting traffic that will trigger IPSec establishment so need manual intervention in case applications changes.

– IPSec establishment will take [1-10] seconds, hence packet drops in the beginning.

Point-to-multipoint GRE + IPSec

Pros:

– A single tunnel interface can terminate all GRE tunnels from all spokes.

– No configuration complexity and resolves the issue of memory allocations.

Cons:

– Need pre-configured access-list for interesting traffic that will trigger IPSec establishment so need manual intervention in case applications changes.

– IPSec establishment will take [1-10] seconds, hence packet drops in the beginning.

Spokes with dynamic public addresses

Issue:

Whether it is GRE, mGRE, Hub and Spoke, full mesh, on HUB or on spokes, tunnel establishment require pre-configured tunnel source and destination.

Here comes NHRP (Next-Hop Resolution Protocol).

NHRP is used by spokes when startup to provide the HUB with the dynamic public ip and the associated tunnel ip.

NHRP is used by the HUB to respond to spokes requests about each other public ip addresses.

So the overall solution will be Point-to-multipoint GRE + IPSec + NHRP which is called DMVPN (Dynamic Multipoint VPN).

You will find the previously mentioned topologies in the subcategory “DMVPN” of the category “Security”

I reserved a separated sub-category called “DMVPN” inside the parent category “Security” in which  I will post the previously mentioned topologies.

Ipv6 QoS


If you already grasp QoS concepts for IPv4, IPv6 QoS is a piece of cake!

As with IPv4, IPv6 uses MQC (Modular QoS CLI)to configure Diffserv (Differentiated services) QoS.

IPv6 QoS is very similar to IPv4 QoS except for some details:

  • NBAR, the first version, doesn’t support IPv6.
  • cRTP (Compressed-RTP).
  • No way to match directly RTP.
  • CAR (Committed Access Rate) replaced by CB- Policing already in IPv4 and no need to keep supporting it in IPv6.
  • PQ/CQ replaced by MQC (Modular QoS CLI).
  • IPv6 supports only named ACL.
  • Layer2 (802.1q) commands works only with CEF- Switched ports not with process- switched nor router originated traffic.

The following is the topology used to deploy IPv6 QoS, no IPv4 addressing scheme. The serial link between the two routers is the bottleneck of the network where QoS is needed.

Figure1: Topology


Classification & Marking

The first and the most crucial step in deploying QoS is classification of traffic.

In this step you need to:

  • identify various applications and protocols running on your network.
  • understand the application behavior with respect to the available network resources.
  • identify the mission critical and non-critical application.
  • Categorize the applications and protocols in different classes of service accordingly.

The classification is based on packet native classifiers like:

  • source/destination IPv6 addresses, IP protocol and source/destination ports.
  • precedence and dscp.
  • source/destination MAC.
  • TCP/IP header parameters (packet length…).
  • IPv6 specific classifiers (not currently used).
  • IPv6 (traffic class) used in the same way as IPv4 (ToS).

IPv4 can take advantage of NBAR, very useful to automatically recognize applications and provides statistics about bandwidth utilization. Without NBAR, you will need to manually determine which classifiers define the application you want QoS to handle. Unfortunately NBAR doesn’t support IPv6, NBAR2 does.

For IPv6 traffic, you can use other tools such “Netflow” or any traffic analyzer software for more granular inspection, then build IPv6 ACLs matching the relevant classifiers with the relevant values.

table1: Application classification and marking

ACL name

Permit/

Deny

Protocol

Source

Destination

IP

mask

Src port

IP

Mask

Dst port

FTP

permit

tcp

2001:b:b:b::b

ftp (21)

any

permit

tcp

2001:b:b:b::b

ftp-data (20)

any

UStream

permit

udp

any

any

1234

Table1 summarizes the applications used in the lab for demonstration purpose.

Table2: Application classification and marking

Application

Bandwidth allocated

Flow direction

traffic classifiers

Class

Markers

unicast streaming

700 kbps

From HostB to HostA

dest IPv6=2001:a:a:a::a

MatchUStream

dscp=ef

protocol I =Pv6

dest port 1234

FTP download

30 kbps

From HostB to HostA

src port 21 (control)

MatchFTP

dscp=af41

protocol I =Pv6

src port 20 (data)

scavenger appli

video streaming

150 kbps

From HostB to Host A

src port …

Generally dscp “ef” is reserved for VoIP which requires the most stringent QoS, in this lab we use the dscp marking  just to check at the destination host (hostA) whether the classification works.

The end-to-end model used to test IPv6 QoS is depicted in Figure2.

Figure2: End-to-End QoS model


Congestion Management & avoidance

For the purpose of the lab, the unicast streaming application is given the highest priority and it is supposed to have stringent bandwidth, latency, delay and jitter requirements, LLQ (Low Latency Queuing) is the most appropriate queuing mechanism for such applications.

The FTP traffic is considered critical with a minimum of  30kbps of bandwidth guaranteed .

Any other traffic, default-class is considered “scavenger” and will have no privilege during congestion.

Each application is being allocated the needed bandwidth to perform correctly.

Table3: Classes and bandwidth allocation

Class Bandwidth reserved Queue DSCP Priority
MatchUStream 700 kbps LLQ af41 High
MatchFTP 30 kbps CBWFQ af21 Medium
class-default no guarantee WFQ 0 Low
policy-map QoS_Policy
  class MatchUStream
   set dscp ef

   priority 700

  class MatchFTP

   set dscp af41

   bandwidth 30

  class class-default

   fair-queue

   set dscp default

Figure3 and 4 show a summary of general QoS mechanisms and queuing system types.

Figure3: Software and Hardware queuing systems


Figure4: QoS mechanisms


RouterB:

ipv6 access-list FTP
permit tcp host 2001:B:B:B::B eq ftp any
permit tcp host 2001:B:B:B::B eq ftp-data any

!

ipv6 access-list UStream

sequence 20 permit udp any any eq 1234

!

class-map match-all MatchFTP

  match protocol ipv6

  match access-group name FTP

class-map match-all MatchUStream

  match protocol ipv6

  match access-group name UStream

Monitoring:

RouterB(config-pmap-c)#do show policy-map int s1/0
Serial1/0
  Service-policy output: QoS_Policy

    Class-map: MatchUStream (match-all)

      23625 packets, 32602500 bytes

      30 second offered rate 538000 bps, drop rate 0 bps

      Match: protocol ipv6

      Match: access-group name UStream

      QoS Set

        dscp ef

          Packets marked 23624

      Queueing

        Strict Priority

        Output Queue: Conversation 264

        Bandwidth 700 (kbps) Burst 17500 (Bytes)

        (pkts matched/bytes matched) 1455/2007900

        (total drops/bytes drops) 1/1380

    Class-map: MatchFTP (match-all)

      5886 packets, 8192512 bytes

      30 second offered rate 135000 bps, drop rate 0 bps

      Match: protocol ipv6

      Match: access-group name FTP

      QoS Set

        dscp af41

          Packets marked 5929

      Queueing

        Output Queue: Conversation 265

        Bandwidth 30 (kbps) Max Threshold 64 (packets)

        (pkts matched/bytes matched) 3486/4784640

        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: class-default (match-any)

      105 packets, 8292 bytes

      30 second offered rate 0 bps, drop rate 0 bps

      Match: any

      Queueing

        Flow Based Fair Queueing

        Maximum Number of Hashed Queues 256

        (total queued/total drops/no-buffer drops) 0/0/0

      QoS Set

        dscp default

          Packets marked 50

RouterB(config-pmap-c)#

RouterB(config-pmap-c)#do sh int s1/0
Serial1/0 is up, line protocol is up
  Hardware is M4T

  MTU 1500 bytes, BW 1024 Kbit, DLY 20000 usec,

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

  Encapsulation HDLC, crc 16, loopback not set

  Keepalive set (10 sec)

  Restart-Delay is 0 secs

  Last input 00:00:07, output 00:00:00, output hang never

  Last clearing of “show interface” counters 00:08:49

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 21

  Queueing strategy: weighted fair

  Output queue: 0/1000/64/1 (size/max total/threshold/drops)

     Conversations  0/3/256 (active/max active/max total)

     Reserved Conversations 1/1 (allocated/max allocated)

     Available Bandwidth 38 kilobits/sec

  30 second input rate 4000 bits/sec, 8 packets/sec

  30 second output rate 666000 bits/sec, 59 packets/sec

     4066 packets input, 261676 bytes, 0 no buffer

     Received 61 broadcasts, 0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

     32082 packets output, 44217146 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     0 output buffer failures, 0 output buffers swapped out

     0 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

RouterB(config-pmap-c)#

Shaping & Policing

Shaping and policing work exactly as in IPv4.

Policing:

  • Applied inbound and outbound.
  • Drops non conforming traffic.
  • More efficient in term of memory utilization.
  • Drops packets more often, therefore more TCP retransmission.

Shaping:

  • Applied only outbound.
  • Queues excess traffic.
  • Less efficient because of additional queuing, but less dropping  (only when congestion occurs).
  • Causes variable delay (jitter) and increases buffer utilization, therefore more delays.

Figure5 shows the mechanism of token bucket used in shaping and policing.

Figure5: shaping and policing


Here is how the FTP traffic diagram looks like before any shaping or policing:

Figure6: FTP before shaping and policing


The following figurex shows different behaviors based on three configurations of shaping and traffic:

Figure7: FTP with shaping and traffic


The first part of the graph corresponds to FTP traffic with just a configured guaranteed bandwidth of 30kbps.

policy-map QoS_Policy
  class MatchFTP
   bandwidth 30

In the second part of the graph, a high limit is set for FTP class using policing at 100kbps, you can note that this results in a frequent TCP global synchronization, a TCP protocol behavior when congestion occurs somewhere in the path to the destination, as long as the congestion exists the source continues to receive requests to decrease the sending rate back from zero and so on, hence the form of the graph (repeated short bursts from the bottom to the maximum).

policy-map QoS_Policy
  class MatchFTP
   bandwidth 30

   police 100000

The third part of the graph represents the result of using shaping instead of policing, more optimal use of the bandwidth. Instead of dropping the TCP traffic and causing global synchronization, the exceed packets are queued for a certain amount of time and then sent, hence the higher used average bandwidth.

policy-map QoS_Policy
  class MatchFTP
   bandwidth 30

   shape average 100000

RouterB#sh policy-map int s1/0

    Class-map: MatchFTP (match-all)

      32045 packets, 47038153 bytes

      30 second offered rate 99000 bps, drop rate 0 bps

      Match: protocol ipv6

      Match: access-group name FTP

      QoS Set

        dscp af41

          Packets marked 32074

      Queueing

        Output Queue: Conversation 265

        Bandwidth 30 (kbps) Max Threshold 64 (packets)

        (pkts matched/bytes matched) 17595/26364666

        (depth/total drops/no-buffer drops) 0/0/0

      Traffic Shaping

           Target/Average   Byte   Sustain   Excess    Interval  Increment

             Rate           Limit  bits/int  bits/int  (ms)      (bytes)

           100000/100000    2000   8000      8000      80        1000

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping

        Active Depth                         Delayed   Delayed   Active

        –      11        17134     25746208  17096     25689056  yes

Conclusion

Make sure you understand first IPv4 QoS, especially the difference between shaping and policing and their impact on your own applications.

 

IPv6 EIGRP


IPv6 EIGRP and IPV4 EIGRP are very similar in concept except for the following differences:

  • IPv6 is configured on interface basis (like OSPFv3 and RIPng) and networks are advertised based on interface command.
  • When configured on interface, IPv6 EIGRP is initially placed in “shutdown” state.
  • As with OSPFv3, IPv6 EIGRP require a router-id in IPv4 format.
  • Passive interfaces can only be configured in the routing process mode.
  • Need for extra memory resources and supported in IOS 12.4(6)T and later.
R1#sh ver | i Version

Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 12.4(6)T, RELEASE SOFTWARE (fc1)

BOOTLDR: 7200 Software (C7200-ADVIPSERVICESK9-M), Version 12.4(6)T, RELEASE SOFTWARE (fc1)

6 slot VXR midplane, Version 2.1

R1#

  • No split horizon in IPv6 because it is possible to get multiple prefixes per interface.
  • No concept of classful routing in IPv6 EIGRP consequently no automatic summary.

Figure1 depicts the Lab topology used for IPv6 EIGRP deployment, R1, R2 and R3 are connected to each other through a Frame Relay cloud and R2, R3 and R4 are connected to each other through LAN.

Each router protect its own set of local networks.

This lab covers the following topics related to the deployment of IPv6 EIGRP

  • IPV6 addressing
  • Frame Relay configuration
  • IPv6 routing configuration
  • IPv6 route manipulation 

Figure1 IPv6 EIGRP topology:


I) DEPLOYMENT

  1. IPV6 addressing: 

First unicat IPv6 and link local addresses are configured.

Link local addresses are statically configured to make their manipulation easier.

R1(config)#int s1/0

R1(config-if)#ipv6 address 2001:1:1:210::1/60

R1(config-if)#ipv6 address FE80::210:1 link-local

R1(config-if)#no sh 

 

R2(config-if)#int s1/0

R2(config-if)#ipv6 address 2001:1:1:210::2/60

R2(config-if)#ipv6 address FE80::210:2 link-local

R2(config-if)#no sh

 

R2(config)#int fa 0/0

R2(config-if)#ipv6 address 2001:1:1:410::2/60

R2(config-if)#ipv6 address FE80::410:2 link-local

R2(config-if)#no sh 

 

R3(config-if)#int s1/0

R3(config-if)#ipv6 address 2001:1:1:210::3/60

R3(config-if)#ipv6 address FE80::210:3 link-local

R3(config-if)#no sh

 

R3(config-if)#int fa 0/0

R3(config-if)#ipv6 address 2001:1:1:410::3/60

R3(config-if)#ipv6 address FE80::410:3 link-local

R3(config-if)#no sh

 

R4(config-if)#int fa 0/0

R4(config-if)#ipv6 address 2001:1:1:410::4/60

R4(config-if)#ipv6 address FE80::410:4 link-local

R4(config-if)#no sh

  1. FR Configuration:

For each interface connected to the Frame relay cloud FR encapsulation is set, Inverse ARP disabled and Static mapping is performed using next-hop unicat ipv6 as well as next-hop link local ipv6.

R1(config-if)#int s1/0

R1(config-if)#encapsulation frame-relay

R1(config-if)#frame-relay map ipv6 2001:1:1:210::2 102 broadcast

R1(config-if)#frame-relay map ipv6 FE80::210:2 102

R1(config-if)#frame-relay map ipv6 2001:1:1:210::3 103 broadcast

R1(config-if)#frame-relay map ipv6 FE80::210:3 103

 

R2(config)#int s1/0

R2(config-if)#encapsulation frame-relay

R2(config-if)#frame-relay map ipv6 2001:1:1:210::1 201 broadcast

R2(config-if)#frame-relay map ipv6 FE80::210:1 201

R2(config-if)#frame-relay map ipv6 2001:1:1:210::3 203 broadcast

R2(config-if)#frame-relay map ipv6 FE80::210:3 203

 

R3(config)#int s1/0

R3(config-if)#encapsulation frame-relay

R3(config-if)#frame-relay map ipv6 2001:1:1:210::1 301 broadcast

R3(config-if)#frame-relay map ipv6 FE80::210:1 301

R3(config-if)#frame-relay map ipv6 2001:1:1:210::2 302 broadcast

R3(config-if)#frame-relay map ipv6 FE80::210:2 302

Before continuing further, it is recommended to check connectivity:

Frame Relay cloud:

unicast:

R1#ping ipv6 2001:1:1:210::2

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:1:1:210::2, timeout is 2 seconds:

!!!!!

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

 

R1#ping ipv6 2001:1:1:210::3

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:1:1:210::3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 32/73/88 ms

R1#

Link-local:

R1#ping ipv6 FE80::210:2

Output Interface: Serial1/0

Type escape sequence to abort.

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

Packet sent with a source address of FE80::210:1

!!!!!

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

R1#

 

R1#ping ipv6 FE80::210:3

Output Interface: Serial1/0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to FE80::210:3, timeout is 2 seconds:

Packet sent with a source address of FE80::210:1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 44/54/92 ms

R1#

Ethernet :
Unicast:

R2#ping ipv6 2001:1:1:410::3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:1:1:410::3, timeout is 2 seconds:

!!!!!

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

R2#ping ipv6 2001:1:1:410::4

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:1:1:410::4, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 48/74/96 ms

R2#

 Link-local:

R2#ping ipv6 FE80::410:3

Output Interface: FastEthernet0/0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to FE80::410:3, timeout is 2 seconds:

Packet sent with a source address of FE80::410:2

!!!!!

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

R2#ping ipv6 FE80::410:4

Output Interface: FastEthernet0/0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to FE80::410:4, timeout is 2 seconds:

Packet sent with a source address of FE80::410:2

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 48/71/96 ms

R2#

Routing Configuration:

 Steps:
Now let’s proceed with IPv6 EIGRP:

  • Enable unicast IPV6 routing globally.
  • enable IPV6 on FR interface.
  • enable IPv6 EIGRP per interface-basis.
  • manually set IPv6 EIGRP router-id in IPv4 format.
  • no shutdown EIGRP process.
R1(config)#ipv6 unicast-routing

R1(config)#int s1/0

R1(config-if)#ipv6 enable

R1(config-if)#ipv6 eigrp 10

R1(config-if)#exit

R1(config)#ipv6 router eigrp 10

R1(config-rtr)#router-id 1.1.1.1

R1(config-rtr)#no sh

 Verify the IPv6 EIGRP protocol:

R1(config)#do sh ipv6 protocols

IPv6 Routing Protocol is “connected”

IPv6 Routing Protocol is “static”

IPv6 Routing Protocol is “eigrp 10”

EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0

EIGRP maximum hopcount 100

EIGRP maximum metric variance 1

Interfaces:


Serial1/0

Redistribution:

None

Maximum path: 16

Distance: internal 90 external 170

 

R1(config)#

 Repeat previous steps for R2 and R3 and make sure that IPV6 eigrp PROCESS id match.

R2(config)#ipv6 unicast-routing

R2(config)#int s1/0

R2(config-if)#ipv6 enable

R2(config-if)#ipv6 eigrp 10

R2(config-if)#exit

R2(config)#ipv6 router eigrp 10

R2(config-rtr)#router-id 2.2.2.2

R2(config-rtr)#no sh

 

R2(config-rtr)#int fa 0/0

R2(config-if)#ipv6 enable

R2(config-if)#ipv6 eigrp 10

R2(config-if)#exit

R2(config)#

 

R3(config)#ipv6 unicast-routing

R3(config-if)#int s1/0

R3(config-if)#ipv6 enable

R3(config-if)#ipv6 eigrp 10

R3(config-if)#exit

R3(config)#ipv6 router eigrp 10

R3(config-rtr)#router-id 3.3.3.3

R3(config-rtr)#no sh

 

R3(config-rtr)#int fa 0/0

R3(config-if)#ipv6 enable

R3(config-if)#ipv6 eigrp 10

R3(config-if)#exit

R3(config)#

 

R4(config)#ipv6 unicast-routing

R4(config-rtr)#int fa 0/0

R4(config-if)#ipv6 enable

R4(config-if)#ipv6 eigrp 10

R4(config-if)#exit

R4(config)#

 Let’s check neighbor relationships and IPv6 routing table on R1 for example:

R1(config)#do sh ipv6 eigrp neigh

IPv6-EIGRP neighbors for process 10

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

1 Link-local address: Se1/0 154 00:01:16 32 200 0 5


FE80::210:3

0 Link-local address: Se1/0 163 00:04:56 48 288 0 3


FE80::210:2

R1(config)#sh ipv6 eigrp neighbor

IPv6-EIGRP interfaces for process 10

 

Xmit Queue Mean Pacing Time Multicast Pending

Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes

Se1/0 2 0/0 40 0/15 175 0

R1(config)#

 You can note that as in OSPFv3, IPv6 EIGRP use link-local addresses to establish neighbor relationships with its neighbors.

R1(config)#do sh ipv6 route eigrp

IPv6 Routing Table – 35 entries

Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP

U – Per-user Static route

I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary

O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2

ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2

D – EIGRP, EX – EIGRP external

D 2001:1:1:410::/60 [90/2172416]


via FE80::210:2, Serial1/0


via FE80::210:3, Serial1/0

R1(config)#

 R1 has learnt the LAN network 2001:1:1:410::/60 from both R2 and R3 and it is perfectly reachable:

R1(config)#do ping ipv6 2001:1:1:410::4

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:1:1:410::4, timeout is 2 seconds:

!!!!!

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

R1(config)#

R1#traceroute ipv6 2001:1:1:410::4

Type escape sequence to abort.

Tracing the route to 2001:1:1:410::4

 

1 2001:1:1:210::2 80 msec


2001:1:1:210::3 120 msec


2001:1:1:210::2 68 msec

2 2001:1:1:410::4 144 msec 120 msec 144 msec

R1#

 R1 load-balanced ICMP packets between the two paths through R2 and R3.

  1. Route manipulation:

To practice IPv6 route summarization, loopback interfaces are created to simulated local networks for each router (figure1) and ipV6 EIGRP is enabled on each interface.
The result is as follow:

R4:

R4# sh ipv6 route eigrp

IPv6 Routing Table – 22 entries

Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP

U – Per-user Static route

I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary

O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2

ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2

D – EIGRP, EX – EIGRP external

D 2001:1:1:110::/60 [90/2300416]

via FE80::410:3, FastEthernet0/0

via FE80::410:2, FastEthernet0/0

D 2001:1:1:120::/60 [90/2300416]

via FE80::410:3, FastEthernet0/0

via FE80::410:2, FastEthernet0/0

D 2001:1:1:130::/60 [90/2300416]

via FE80::410:3, FastEthernet0/0

via FE80::410:2, FastEthernet0/0

D 2001:1:1:140::/60 [90/2300416]

via FE80::410:3, FastEthernet0/0

via FE80::410:2, FastEthernet0/0

D 2001:1:1:150::/60 [90/2300416]

via FE80::410:3, FastEthernet0/0

via FE80::410:2, FastEthernet0/0

D 2001:1:1:160::/60 [90/2300416]

via FE80::410:3, FastEthernet0/0

via FE80::410:2, FastEthernet0/0

D 2001:1:1:170::/60 [90/2300416]

via FE80::410:3, FastEthernet0/0

via FE80::410:2, FastEthernet0/0

D 2001:1:1:180::/60 [90/2300416]

via FE80::410:3, FastEthernet0/0

via FE80::410:2, FastEthernet0/0

D 2001:1:1:190::/60 [90/2300416]

via FE80::410:3, FastEthernet0/0

via FE80::410:2, FastEthernet0/0

D 2001:1:1:1A0::/60 [90/2300416]

via FE80::410:3, FastEthernet0/0

via FE80::410:2, FastEthernet0/0

D 2001:1:1:1B0::/60 [90/2300416]

via FE80::410:3, FastEthernet0/0

via FE80::410:2, FastEthernet0/0

D 2001:1:1:1C0::/60 [90/2300416]

via FE80::410:3, FastEthernet0/0

via FE80::410:2, FastEthernet0/0

D 2001:1:1:1D0::/60 [90/2300416]

via FE80::410:3, FastEthernet0/0

via FE80::410:2, FastEthernet0/0

D 2001:1:1:1E0::/60 [90/2300416]

via FE80::410:3, FastEthernet0/0

via FE80::410:2, FastEthernet0/0

D 2001:1:1:1F0::/60 [90/2300416]

via FE80::410:3, FastEthernet0/0

via FE80::410:2, FastEthernet0/0

D 2001:1:1:210::/60 [90/2172416]

via FE80::410:3, FastEthernet0/0

via FE80::410:2, FastEthernet0/0

R4#

 22 entries, only routes to FR network routes and R1 fifteen local networks, you just imagine if we add R2 and R3 local networks, or even worse in a production network with hundreds of site and thousands of routes!

Here is where summarization comes, to lessen the complexity of handling routes individually.

As in IPv4 EIGRP after configuring the summarization command the router drops IPv6 EIGRP relationships to reestablish them again, this renew input events and make neighbors rebuild their topology tables and perform DUAL algorithm local computation again using the new advertisements from the router who reconfigured summarization.

The summarization command is performed on interface-basis, so make sure than it is executed on all EIGRP interfaces through which you want to spread summary route.

R1:

R1(config-if)#int s1/0

R1(config-if)#ipv6 summary-address eigrp 10 2001:1:1:1::/56

*Jun 13 10:36:44.871: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 10: Neighbor FE80::210:3 (Serial1/0) is down: summary configured

*Jun 13 10:36:44.927: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 10: Neighbor FE80::210:2 (Serial1/0) is down: summary configured

R1(config-if)#

*Jun 13 10:37:01.919: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 10: Neighbor FE80::210:3 (Serial1/0) is up: new adjacency

*Jun 13 10:37:02.019: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 10: Neighbor FE80::210:2 (Serial1/0) is up: new adjacency

R1(config-if)#

 Now let’s take a look at R4 routing table:

R4# sh ipv6 route eigrp

IPv6 Routing Table – 10 entries

Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP

U – Per-user Static route

I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary

O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2

ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2

D – EIGRP, EX – EIGRP external

D 2001:1:1:100::/56 [90/2300416]

via FE80::410:2, FastEthernet0/0

via FE80::410:3, FastEthernet0/0

D 2001:1:1:210::/60 [90/2172416]

via FE80::410:2, FastEthernet0/0

via FE80::410:3, FastEthernet0/0

D 2001:1:1:300::/56 [90/156160]

via FE80::410:3, FastEthernet0/0

D 2001:1:1:600::/56 [90/156160]

via FE80::410:2, FastEthernet0/0

R4#

 The routing table is reduced to 10 entries with only summary routes to R1, R2 and R3 local networks.

II) CONCLUSION

As with other IPv6 routing protocols there is practically nothing to do if you grasp the concept of the IPv4 version of the protocol as well as IPV6 addressing.

CBAC Context-Based Access Control


 CBAC is a Cisco Router security tool used to provide more sophisticated way of perimeter security than simple access control lists to mitigate threats from unprotected networks; it provides dynamic inspection of a specific traffic as it traverse the IOS FW.

This lab provides basic configuration guideline and general recommendations for CBAC deployment and shows how it can prevent some attacks like SYN flood.

 

Figure1 : CBAC Lab topology

I) CBAC Configuration guideline:

  1. Select interfaces controlled by CBAC:

CBAC router:

Remember that the inspection rule is applied to a particular interface in a particular direction, therefore CBAC will control, by either dynamical allowing or denying, the traffic entering interfaces in the direction opposed to the inspection rule.

Fa0/0: Internal interface– from where any sessions can be originated to any destination, CBAC will decide whether to allow traffic entering Fa1/0 and Fa2/0 (that would normally be blocked) if it the returning traffic of the one originated from Fa0/0 (That would normally be allowed by ACL).

Fa1/0: DMZ interface – traffic generated from other areas toward DMZ servers should be inspected from one point Fa1/0. Only servers are supposed to reside in the DMZ not hosts.

CBAC will decide whether to allow traffic back from DMZ (that would normally be blocked).

 

  1. Configure Access Control Lists:
  • Identify the applications that need to be inspected and make sure that the outgoing traffic, from the protected zone, is not blocked by any ACL.
  • Set ACLs to block traffic from unprotected interfaces, CBAC will take care of dynamically allowing holes in the ACL to permit legitimate returning traffic.
  • Packets entering the IOS FW are inspected by CBAC only if they first pass the inbound ACL at the interface.
  • One Blocking ACL should be bound to the outside interface Fa2/0 inbound and another to the DMZ interface, also inbound, therefore blocking illegitimate traffic before entering the IOS FW.
  • In production environment you have to take into account address space filtering according to RFC2827, in other words blocking private addresses from outside, broadcast, bogons and ip spoofing addresses etc.
  • Don’t forget the implicit “deny ip any any” in ACLs.

 

Table1 : Access control lists

ACL name 

Permit/

deny 

Protocol 

Source 

Src port 

Destination 

Dst

port

Ip 

Mask 

Ip 

mask 

FROM_DMZ 

deny 

Ip 

Any 

 

 

Any 

 

 

FROM_INSIDE 

permit 

Ip 

192.168.11.0 

24 

 

Any 

 

 

FROM_OUTSIDE 

Permit 

tcp 

any 

 

 

10.10.10.1 

32 

www

permit 

tcp 

any 

 

 

10.10.10.1 

32 

telnet

permit 

tcp 

any 

 

 

10.10.10.1 

32 

ssh

permit

tcp

any

10.10.10.1

32

smtp

permit 

tcp 

any 

 

 

10.10.10.1 

32 

ftp 

permit 

icmp 

any 

 

 

10.10.10.1 

32 

echo* 

permit 

icmp 

any 

 

 

192.168.11.0 

24 

echo* 

permit 

icmp 

any 

 

192.168.11.0 

24 

time-exceeded* 

permit 

icmp 

any 

 

 

192.168.11.0 

24 

unreachable* 

deny 

Ip 

any 

 

 

any 

 

 

*For ICMP traffic the ICMP type is filled in the column “dst port”

ip access-list extended FROM_DMZ
deny ip any any
ip access-list extended FROM_INSIDE
permit ip 192.168.11.0 0.0.0.255 any
ip access-list extended FROM_OUTSIDE

permit tcp any host 10.10.10.1 eq www

permit tcp any host 10.10.10.1 eq 22

permit tcp any host 10.10.10.1 eq telnet

permit tcp any host 10.10.10.1 eq smtp

deny ip any any

 

  1. Set global timeouts and thresholds:

Table3 : Generic protocol timeouts and thresholds (default values)

protocol  Timeout and thresholds  value 
TCP  One-minute  Low 

400 ½ opened sessions 

  High 

500 ½ opened sessions 

Max-incomplete  Low 

400 ½ opened sessions

High 

500 ½ opened sessions 

Per host  ½ opened sessions 

50 

Block-time 

0 min 

Synwait-time   

30 s 

Finwait-time   

5 s 

Idle-time   

3600 s 

UDP  Idle-time   

30 s 

 

  1. Define the inspection rule:

For the purpose of this lab a standard inspection rule is defined for general TCP and UDP application.

Each protected Zone will have its own Inspection rule.

ip inspect name MyGENERIC_inside tcp
ip inspect name MyGENERIC_inside udp
ip inspect name MyGENERIC_inside http
ip inspect name MyGENERIC_inside icmp
ip inspect name MyGENERIC_inside ftp

ip inspect name MyGENERIC_dmz tcp

ip inspect name MyGENERIC_dmz udp

 

  1. Apply inspection rules to interfaces:

Inspection rule is applied to interfaces where the traffic should be inspected.

GENERIC applied to fa 0/0 inbound
GENERIC applied to fa 1/0 outbound
 interface FastEthernet0/0
ip access-group FROM_INSIDE in

ip inspect MyGENERIC_inside in

 

interface FastEthernet1/0

ip access-group FROM_DMZ in

ip inspect MyGENERIC_dmz out

 

interface FastEthernet2/0

ip access-group FROM_OUTSIDE in

 

Connectivity check:

To lessen the clutter of troubleshooting CBAC it is highly recommended to check the connectivity between all devices before beginning to apply the inspections rules and access.

From DMZ, after applying CBAC & associated ACL:

DMZ hosts cannot initiate any connection to neither outside nor inside.

DMZ#192.168.40.105
Trying 192.168.40.105 …

% Destination unreachable; gateway or host down

DMZ#192.168.11.105

Trying 192.168.11.105 …

% Destination unreachable; gateway or host down

DMZ#

 

From outside, after applying CBAC and associated ACL:

OUTSIDE can initiate connections only to predefined DMZ services in the inspection rules and allowed by an ACL, not to inside hosts.

outside#192.168.11.105
Trying 192.168.11.105 …

% Destination unreachable; gateway or host down

outside#10.10.10.1

Trying 10.10.10.1 … Open

User Access Verification

Username:

Password:

 

DMZ#

 

Monitoring from CBAC router:

  • The following is a summary of CBAC configuration from the output of “show ip inspect all”:
CBAC(config-if)#do sh ip inspect all
Session audit trail is disabled
Session alert is enabled
one-minute (sampling period) thresholds are [400:500] connections
max-incomplete sessions thresholds are [400:500]

max-incomplete tcp connections per host is 50. Block-time 0 minute.

tcp synwait-time is 30 sec — tcp finwait-time is 5 sec

tcp idle-time is 3600 sec — udp idle-time is 30 sec

dns-timeout is 5 sec

Inspection Rule Configuration

Inspection name MyGENERIC_inside

tcp alert is on audit-trail is off timeout 3600

udp alert is on audit-trail is off timeout 30

http alert is on audit-trail is off timeout 3600

icmp alert is on audit-trail is off timeout 10

ftp alert is on audit-trail is off timeout 3600

Inspection name MyGENERIC_dmz

tcp alert is on audit-trail is off timeout 3600

udp alert is on audit-trail is off timeout 30

 

Interface Configuration


Interface FastEthernet0/0


Inbound inspection rule is MyGENERIC_inside

tcp alert is on audit-trail is off timeout 3600

udp alert is on audit-trail is off timeout 30

http alert is on audit-trail is off timeout 3600

icmp alert is on audit-trail is off timeout 10

ftp alert is on audit-trail is off timeout 3600

Outgoing inspection rule is not set


Inbound access list is FROM_INSIDE

Outgoing access list is not set


Interface FastEthernet1/0

Inbound inspection rule is not set

Outgoing inspection rule is MyGENERIC_dmz

tcp alert is on audit-trail is off timeout 3600

udp alert is on audit-trail is off timeout 30


Inbound access list is FROM_DMZ

Outgoing access list is not set

 

Established Sessions

Session 6509A4A8 (192.168.10.2:63377)=>(10.10.10.1:23) tcp SIS_OPEN

Session 6509A230 (192.168.40.105:4916)=>(10.10.10.1:23) tcp SIS_OPEN

CBAC(config-if)#

 

CBAC#sh ip inspect statistics
Packet inspection statistics [process switch:fast switch]
tcp packets: [3:181]
Interfaces configured for inspection 2
Session creations since subsystem startup or last reset 3

Current session counts (estab/half-open/terminating) [2:0:0]

Maxever session counts (estab/half-open/terminating) [2:1:1]

Last session created 00:01:31

Last statistic reset never

Last session creation rate 0

Last half-open session total 0

 

CBAC#

 

  • telnet connections from inside to DMZ zone
CBAC#debug ip inspect detailed
INSPECT Detailed Debug debugging is on
CBAC#

*Mar 1 02:18:23.023: CBAC: Finding pregen session for src_tableid:0, src_addr:192.168.10.2, src_port:24819, dst_tableid:0, dst_addr:10.10.10.1, dst_port:23

CBAC#

CBAC#

  • telnet from inside to outside

inside#192.168.40.105

Trying 192.168.40.105 … Open

Welcome to Microsoft Telnet Service

 

login: <adminlogin>

password:

 

*===============================================================

Welcome to Microsoft Telnet Server.

*===============================================================

C:\Documents and Settings\<adminlogin>.MNGMNT.001>

 

CBAC#

*Mar 1 02:22:52.315: CBAC: Finding pregen session for src_tableid:0, src_addr:192.168.10.2, src_port:29067, dst_tableid:0, dst_addr:192.168.40.105, dst_port:23

CBAC#

 

  • the IOS FW router can detect and refuse replayed packets according to its records in its inspection table
CBAC#
*Mar 1 02:35:03.503: CBAC: Finding pregen session for src_tableid:0, src_addr:192.168.40.105, src_port:4946, dst_tableid:0, dst_addr:10.10.10.1, dst_port:23
*Mar 1 02:35:13.547: CBAC: Finding pregen session for src_tableid:0, src_addr:192.168.40.105, src_port:4946, dst_tableid:0, dst_addr:10.10.10.1, dst_port:23
*Mar 1 02:35:23.567: CBAC: Finding pregen session for src_tableid:0, src_addr:192.168.40.105, src_port:4946, dst_tableid:0, dst_addr:10.10.10.1, dst_port:23

 

CBAC#sh ip inspect sessions
Established Sessions
Session 65099FB8 (192.168.10.2:29067)=>(192.168.40.105:23) tcp SIS_OPEN
Session 6509A4A8 (192.168.10.2:63377)=>(10.10.10.1:23) tcp SIS_OPEN
CBAC#clear

 

  • The IOS router react as expected to SYN flood attack (100 packet every 10ms) by blocking ½ half opened sessions that exceed the configured value.
CBAC#
*Mar 1 04:11:43.562: %FW-4-HOST_TCP_ALERT_ON: Max tcp half-open connections (50) exceeded for host 10.10.10.1.
CBAC#
CBAC#sh ip inspect stat
Packet inspection statistics [process switch:fast switch]

tcp packets: [2884:12563]

Interfaces configured for inspection 2

Session creations since subsystem startup or last reset 409

Current session counts (estab/half-open/terminating) [0:0:0]

Maxever session counts (estab/half-open/terminating) [3:51:1]

Last session created 00:00:50

Last statistic reset never

Last session creation rate 76

Last half-open session total 0

CBAC#

 

  • With an aggressive attack (more than 500 ½ sessions per minute) the IOS FW react by dropping sessions.
*Mar 1 04:14:44.530: %FW-4-ALERT_ON: getting aggressive, count (51/500) current 1-min rate: 501
CBAC#

 

  • As soon as the number of ½ opened sessions drop below the low threshold of 400 sessions per minutes, the IOS stop dropping sessions
CBAC#
*Mar 1 04:16:38.294: %FW-4-ALERT_OFF: calming down, count (0/400) current 1-min rate: 0
CBAC#

 

  • This can cause Denial Of Service of the router if no protections against such type of attacks in a production environment.
CBAC#sh proc cpu
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 8%

CBAC#sh proc cpu
CPU utilization for five seconds: 41%/56%; one minute: 6%; five minutes: 8%


CBAC#sh proc cpu

CPU utilization for five seconds: 18%/100%; one minute: 9%; five minutes: 9%


CBAC#sh proc cpu

CPU utilization for five seconds: 17%/100%; one minute: 15%; five minutes: 11%

II) Conclusion:

A successful deployment of CBAC rely on the understanding of application traffic that traverses the IOS Firewall as well as where to apply ACL and inspection rules and over all make sure that everything works fine before applying CBAC.

 

 

%d bloggers like this: