Category: Labs

Intermediate System to Intermediate System (IS-IS)

Intermediate System to Intermediate System (IS-IS) is a dynamic link-state routing protocol widely used in large-scale networks, especially in service provider environments. One of its features is interlevel routing, which allows communication between IS-IS levels (Level 1 and Level 2). This post explains IS-IS interlevel routing and provides configuration examples to implement it in practical scenarios.

IS-IS Lab Setup

Using Cisco’s Modeling Labs (CML) I build the following IS-IS topology:

• 2 x L2 Router ( Top )  (R1, R2) running XRv with IOS-XR.
• 2 x L1L2 Router ( left ) (R3, R4) running XRv with IOS-XR.
• 2 x L1 Router ( left ) (R9, R10) running IOS with IOSv.
• 2 x L1L2 Router ( Center ) (R5, R6) running XRv with IOS-XR.
• 2 x L1 Router ( Center ) (R11, R12) running IOS with IOSv.
• 2 x L1L2 Router ( Right ) (R7, R8) running XRv with IOS-XR.
• 2 x L1 Router ( Right ) (R13, R14) running IOS with IOSv.

Logical View:

Physical View:

(more…)

What is MPLS Traffic Engineering (MPLS-TE)?

MPLS Traffic Engineering (MPLS-TE) is a technology that enhances the capabilities of MPLS (Multiprotocol Label Switching) to enable more granular control over traffic flow within a network.

Traffic engineering refers to the practice of optimizing the flow of network traffic in a way that ensures efficient use of network resources, avoids congestion, and achieves better overall performance. In traditional IP networks, traffic generally follows the shortest path, which can lead to suboptimal usage of network capacity and congestion. MPLS-TE allows operators to move beyond shortest-path routing by explicitly setting up paths through the network that distribute traffic in a desired way.

In this lab I am going to configure a tunnel to overrule the IGP shortest path and chose a different path.

MPLS Lab Setup

Using Cisco’s Modeling Labs (CML) I build the following MPLS lab using OSPF and LDP neighbor relationships using virtual routers running IOSv.

• 3 x P routers (Router1, Router2, Router3)
• 2 x PE router (Router4, Router5)
• 2 x CE router (Router6, Router7)

Default Behaviour
The default traffic flow behaviour from PE Router4 towards PE Router5 will follow the IGP shortest path via P Router3. This path is one hop instead of traversing via Router1+Router2 being two hops away and double the cost.

MPLS-TE
With MPLS-TE we can define a different path via Router1+Router2. 
There can be many reasons why we would want to do this and many ways how we can achieve this. In this Lab I am going to enable MPLS-TE and simply exclude Router3 from our path. 

IP Addressing:
The point-to-point links are configured with the following IP addressing scheme:

• “10.<Lowest Router Id>.<Highest Router Id>.<Router Id>./24.”

For example the link between Router1 and Router2 gives on Router1: 10.1.2.1/24 and on Router2: 10.1.2.2/24. 

Verification on Router3 (P):

Router3#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
4.4.4.4           0   FULL/  -        00:00:35    10.3.4.4        GigabitEthernet0/0
1.1.1.1           0   FULL/  -        00:00:38    10.1.3.1        GigabitEthernet0/1
2.2.2.2           0   FULL/  -        00:00:35    10.2.3.2        GigabitEthernet0/2
5.5.5.5           0   FULL/  -        00:00:33    10.3.5.5        GigabitEthernet0/3

Router3#sh mpls interfaces
Interface              IP            Tunnel   BGP Static Operational
GigabitEthernet0/0     Yes (ldp)     No       No  No     Yes
GigabitEthernet0/1     Yes (ldp)     No       No  No     Yes
GigabitEthernet0/2     Yes (ldp)     No       No  No     Yes
GigabitEthernet0/3     Yes (ldp)     No       No  No     Yes

Router3#sh mpls ldp neighbor
    Peer LDP Ident: 5.5.5.5:0; Local LDP Ident 3.3.3.3:0
        TCP connection: 5.5.5.5.57381 - 3.3.3.3.646
        State: Oper; Msgs sent/rcvd: 46/45; Downstream
        Up time: 00:26:54
        LDP discovery sources:
          GigabitEthernet0/3, Src IP addr: 10.3.5.5
        Addresses bound to peer LDP Ident:
          10.2.5.5        5.5.5.5         10.3.5.5
    Peer LDP Ident: 4.4.4.4:0; Local LDP Ident 3.3.3.3:0
        TCP connection: 4.4.4.4.42087 - 3.3.3.3.646
        State: Oper; Msgs sent/rcvd: 44/46; Downstream
        Up time: 00:26:54
        LDP discovery sources:
          GigabitEthernet0/0, Src IP addr: 10.3.4.4
        Addresses bound to peer LDP Ident:
          10.3.4.4        4.4.4.4         10.1.4.4
    Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 3.3.3.3:0
        TCP connection: 2.2.2.2.646 - 3.3.3.3.23943
        State: Oper; Msgs sent/rcvd: 45/45; Downstream
        Up time: 00:26:51
        LDP discovery sources:
          GigabitEthernet0/2, Src IP addr: 10.2.3.2
        Addresses bound to peer LDP Ident:
          10.1.2.2        10.2.5.2        10.2.3.2        2.2.2.2
    Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 3.3.3.3:0
        TCP connection: 1.1.1.1.646 - 3.3.3.3.22044
        State: Oper; Msgs sent/rcvd: 45/45; Downstream
        Up time: 00:26:51
        LDP discovery sources:
          GigabitEthernet0/1, Src IP addr: 10.1.3.1
        Addresses bound to peer LDP Ident:
          10.1.2.1        10.1.3.1        10.1.4.1        1.1.1.1

Router1, Router2, Router2#

#---- MPLS ranges and LDP
#---- Modify label range per router
mpls label range 100 199
mpls label protocol ldp
mpls ldp router-id Loopback0 force


#---- Interface configuration with MPLS & OSPF
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip ospf 1 area 0
!
interface GigabitEthernet0/0
 ip address 10.1.2.1 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
 mpls ip
!
interface GigabitEthernet0/1
 ip address 10.1.3.1 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
 mpls ip
!
interface GigabitEthernet0/3
 ip address 10.1.4.1 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
 mpls ip
!

PE Routers: (Router4, Router5)

The PE routers are configured with the standard subnetting scheme from the table above in combination with OSPF area 0 and LDP as the labelling protocol.
Each PE routers has an IBGP session to the other PE router (Router4 <-> Router5) for CE traffic.

Router4 (PE)


# ============= MPLS
mpls label range 400 499
mpls label protocol ldp
mpls ldp router-id Loopback0 force

# ===== Interfaces 

interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ip ospf 1 area 0
!
interface GigabitEthernet0/0
 ip address 10.3.4.4 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
 mpls ip
!
interface GigabitEthernet0/1
 ip vrf forwarding CUST
 ip address 10.4.6.4 255.255.255.0
!
interface GigabitEthernet0/3
 ip address 10.1.4.4 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
 mpls ip

# ============= OSPF
router ospf 1
 router-id 4.4.4.4
!

# =========== BGP
router bgp 65000
 template peer-session IBGP
  remote-as 65000
  transport connection-mode active
  update-source Loopback0
 exit-peer-session
 !
 bgp router-id 4.4.4.4
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 5.5.5.5 inherit peer-session IBGP
 neighbor 5.5.5.5 transport connection-mode passive
 !
 address-family ipv4
 exit-address-family
 !
 address-family vpnv4
  neighbor 5.5.5.5 activate
  neighbor 5.5.5.5 send-community extended
  neighbor 5.5.5.5 next-hop-self
 exit-address-family
 !
 address-family ipv4 vrf CUST
  neighbor 10.4.6.6 remote-as 65006
  neighbor 10.4.6.6 activate
  neighbor 10.4.6.6 as-override
 exit-address-family

Router5 (PE)


# ============= MPLS
mpls label range 500 599
mpls label protocol ldp
mpls ldp router-id Loopback0 force

# ===== Interfaces 

interface Loopback0
 ip address 5.5.5.5 255.255.255.255
 ip ospf 1 area 0
!
interface GigabitEthernet0/1
 ip address 10.2.5.5 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
 mpls ip
!
interface GigabitEthernet0/2
 ip vrf forwarding CUST
 ip address 10.5.7.5 255.255.255.0
!
interface GigabitEthernet0/3
 ip address 10.3.5.5 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
 mpls ip

# ============= OSPF
router ospf 1
 router-id 5.5.5.5
!

# =========== BGP
router bgp 65000
 template peer-session IBGP
  remote-as 65000
  transport connection-mode active
  update-source Loopback0
 exit-peer-session
 !
 bgp router-id 5.5.5.5
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 4.4.4.4 inherit peer-session IBGP

 !
 address-family ipv4
 exit-address-family
 !
 address-family vpnv4
  neighbor 4.4.4.4 activate
  neighbor 4.4.4.4 send-community extended
  neighbor 4.4.4.4 next-hop-self
 exit-address-family
 !
 address-family ipv4 vrf CUST
  neighbor 10.5.7.7 remote-as 65006
  neighbor 10.5.7.7 activate
  neighbor 10.5.7.7 as-override
 exit-address-family

Router6#traceroute 7.7.7.7 source 6.6.6.6
Type escape sequence to abort.
Tracing the route to 7.7.7.7
VRF info: (vrf in name/id, vrf out name/id)
  1 10.4.6.4 2 msec 3 msec 2 msec
  2 10.3.4.3 [MPLS: Labels 303/511 Exp 0] 10 msec 8 msec 7 msec
  3 10.5.7.5 [AS 65000] [MPLS: Label 511 Exp 0] 9 msec 8 msec 11 msec
  4 10.5.7.7 [AS 65000] 12 msec 12 msec *

MPLS Traffic Engineering Configuration

(more…)

Building a use case from the CCDP FLG:

Topology:

• Each site has two links to their HQ (top) via WAN (Prio) and Internet ( backup ).
• Internet and WAN connectivity goes over multipoint GRE tunnels to the sites with static NHRP mappings.
• Cost of Internet links are increased so they’re used as backup links.
• Backbone area configured over WAN and Internet

Building the LAB:

OSPF Design

Building the Backbone:

Adding the tunnel interface and NHRP mappings on the WAN Hub Router (R1):

And we have some routing on the Hubs:

• P Routers – Provider routers
  • MPLS Core
• PE Routers – Provider Edge routers
  • MPLS – IP Edge
• CE Routers – Customer Edge routers
  • IP Edge

Traceroute (R6 -> R7)

Layer 3 setup:

GNS3 LAB:

(more…)

Building a case study from the ARCH FLG book; BGP communities.

The idea is to use BGP communities to influence the routing between Autonomous Systems with the following goals in mind:

• Configure communities to tag the routes per building on each AS.
• Configure communities as no-export so the routes of AS65001.building2 and AS65002.building2 are not exported through AS65000.
  • The routes will be tagged on R6 and R9 with community 65000:99 and processed on the AS boundry.
  • The routes of AS65001.building1 and AS65002.building1 are allowed to be exported.
• Configure communities so that R7 and R8 can set their local preference on the AS65000 side.
  • The routes will be tagged on R7 will be tagged with 65000:200 resulting in a local-preference of 200.
  • The routes will be tagged on R8 will be tagged with 65000:300 resulting in a local-preference of 300.

LAB:

LAYER3:

BGP Configuration:

AS65000 :

R1# (Change the network and neighbor addresses where needed for the other routers)
router bgp 65000
 bgp log-neighbor-changes
 network 10.0.1.0 mask 255.255.255.0
 neighbor ibgp peer-group
 neighbor ibgp remote-as 65000
 neighbor ibgp next-hop-self
 neighbor ibgp send-community
 neighbor ibgp soft-reconfiguration inbound
 neighbor 10.255.65.2 peer-group ibgp
 neighbor 10.255.65.3 peer-group ibgp
 neighbor 10.255.65.4 peer-group ibgp

AS65001 :

R5# (Change the network and neighbor addresses where needed for the other routers)
router bgp 65001
 bgp log-neighbor-changes
 network 10.0.111.0 mask 255.255.255.0
 neighbor ibgp peer-group
 neighbor ibgp remote-as 65001
 neighbor ibgp next-hop-self
 neighbor ibgp send-community
 neighbor ibgp soft-reconfiguration inbound
 neighbor 10.255.1.1 remote-as 65000
 neighbor 10.255.1.1 send-community
 neighbor 10.255.66.2 peer-group ibgp

AS65002 :

R7# (Change the network and neighbor addresses where needed for the other routers)
router bgp 65002
 bgp log-neighbor-changes
 network 10.0.221.0 mask 255.255.255.0
 neighbor ibgp peer-group
 neighbor ibgp remote-as 65002
 neighbor ibgp next-hop-self
 neighbor ibgp send-community
 neighbor ibgp soft-reconfiguration inbound
 neighbor 10.255.2.1 remote-as 65000
 neighbor 10.255.2.1 send-community
 neighbor 10.255.2.1 route-map EBGP-MAP out
 neighbor 10.255.67.2 peer-group ibgp
 neighbor 10.255.67.3 peer-group ibgp

Tagging routes on R6 and R9 (no export)

R9#:
access-list 101 permit ip host 10.0.222.0 host 255.255.255.0
!
route-map TAGROUTE permit 10     
 match ip address 101                    # MATCH THE ROUTES YOU WANT TO TAG
 set community 65000:99 65002:5202       # SET COMMUNITIES 65000:99 (no export) and 65000:5202 ( site ID) 

Router bgp 65002
- snip -
neighbor ibgp route-map TAGROUTE out     # APPLY ROUTEMAP ON OUTGOING ROUTES TOWARDS R7 + R8 
- snap - 

Verify on R7 and R8:

R7#sh ip bgp 10.0.222.0
BGP routing table entry for 10.0.222.0/24, version 3
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     9
  Refresh Epoch 1
  Local, (received & used)
    10.255.67.3 from 10.255.67.3 (10.0.222.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: 65000:99 65002:5202
      rx pathid: 0, tx pathid: 0x0

Confuring communities on R7 and R8 ( Site-ID’s and Local pref community )

R7:
access-list 101 permit ip host 10.0.221.0 host 255.255.255.0
!
route-map EBGP-MAP permit 10
 match ip address 101
 set community 65000:200 65002:5101
!
route-map EBGP-MAP permit 20
!
Router bgp 65002:
neighbor 10.255.2.1 route-map EBGP-MAP out

R8:
access-list 101 permit ip host 10.0.221.0 host 255.255.255.0
!
route-map EBGP-MAP permit 10
 match ip address 101
 set community 65000:300 65002:5101
!
route-map EBGP-MAP permit 20
!
Router bgp 65002:
neighbor 10.255.3.1 route-map EBGP-MAP out

What this will accomplish is that a local pref community is send to AS65000 with resulting values of 200 for R7 and 300 for R8 for the 10.0.221.0/24 route.

Confuring the community settings on R3 and R4 ( No export and Local pref )

R3# and R4#:
ip community-list 1 permit 65000:99        # The no-export community from R6 and R9 
ip community-list 2 permit 65000:200       # The localpref community for value 200
ip community-list 3 permit 65000:300       # The localpref community for value 300
!
route-map TAG-IN permit 10
 match community 1
 set community no-export
!
route-map TAG-IN permit 20
 match community 2
 set local-preference 200
!
route-map TAG-IN permit 30
 match community 3
 set local-preference 300
!
route-map TAG-IN permit 40                  # This to allow all other routes if there were any.

router bgp 65000
 neighbor 10.255.3.2 route-map TAG-IN in

This will give R4 a higher local pref (300) for route 10.0.221.0/24 towards R8. Resulting in the following result from R3’s prespective:

R3#sh ip route 10.0.221.1
Routing entry for 10.0.221.0/24
  Known via "bgp 65000", distance 200, metric 0
  Tag 65002, type internal
  Last update from 10.255.65.4 03:51:18 ago
  Routing Descriptor Blocks:
  * 10.255.65.4, from 10.255.65.4, 03:51:18 ago        # R4 is the next hop
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65002
      MPLS label: none


R3#sh ip bgp 10.0.221.0
BGP routing table entry for 10.0.221.0/24, version 7
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     9
  Refresh Epoch 1
  65002, (received & used)
    10.255.65.4 from 10.255.65.4 (10.255.65.4)
      Origin IGP, metric 0, localpref 300, valid, internal, best
      Community: 65000:300 65002:5101
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  65002
    10.255.2.2 from 10.255.2.2 (10.255.67.1)
      Origin IGP, metric 0, localpref 200, valid, external
      Community: 65000:200 65002:5101
      rx pathid: 0, tx pathid: 0

Verifying the no-export community

If all goes well we shouldn’t see the 10.0.112.0/24 and 10.0.222.0/24 routes exported through AS65000 ( And we don’t );

R1#sh ip route
-
      10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
C        10.0.1.0/24 is directly connected, Loopback0
L        10.0.1.1/32 is directly connected, Loopback0
B        10.0.2.0/24 [200/0] via 10.255.65.2, 03:36:08
B        10.0.3.0/24 [200/0] via 10.255.65.3, 03:36:07
B        10.0.111.0/24 [200/0] via 10.255.65.2, 03:36:08
B        10.0.112.0/24 [200/0] via 10.255.65.2, 03:36:08        #AS6500 Sees the AS65001 route
B        10.0.221.0/24 [200/0] via 10.255.65.4, 03:36:07
B        10.0.222.0/24 [200/0] via 10.255.65.3, 03:36:07        #AS6500 Sees the AS65002 route
C        10.255.65.0/24 is directly connected, FastEthernet0/0
L        10.255.65.1/32 is directly connected, FastEthernet0/0

R6#sh ip route
      10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
B        10.0.1.0/24 [200/0] via 10.255.66.1, 03:37:08
B        10.0.2.0/24 [200/0] via 10.255.66.1, 03:37:08
B        10.0.3.0/24 [200/0] via 10.255.66.1, 03:36:39
B        10.0.111.0/24 [200/0] via 10.255.66.1, 00:00:03
C        10.0.112.0/24 is directly connected, Loopback0
L        10.0.112.1/32 is directly connected, Loopback0
B        10.0.221.0/24 [200/0] via 10.255.66.1, 03:36:39
C        10.255.66.0/24 is directly connected, FastEthernet0/0
L        10.255.66.2/32 is directly connected, FastEthernet0/0
                                                          #AS65001 is missing the 10.0.222.0/24 route

R9#sh ip route
      10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
B        10.0.1.0/24 [200/0] via 10.255.67.1, 03:34:29
B        10.0.2.0/24 [200/0] via 10.255.67.1, 03:34:29
B        10.0.3.0/24 [200/0] via 10.255.67.1, 03:34:29
B        10.0.111.0/24 [200/0] via 10.255.67.1, 03:34:29
B        10.0.221.0/24 [200/0] via 10.255.67.1, 03:41:11
C        10.0.222.0/24 is directly connected, Loopback0
L        10.0.222.1/32 is directly connected, Loopback0
C        10.255.67.0/24 is directly connected, FastEthernet0/0
L        10.255.67.3/32 is directly connected, FastEthernet0/0
                                                         #AS65002 is missing the 10.0.112.0/24 route

https://en.wikipedia.org/wiki/Protocol_Independent_Multicast

• PIM Sparse Mode (PIM-SM) explicitly builds unidirectional shared trees rooted at a rendezvous point (RP) per group, and optionally creates shortest-path trees per source. PIM-SM generally scales fairly well for wide-area usage.

Packetcapture when generating traffic from the Video Server (R1) to the multicast group address 224.3.2.1.

Connectivity via OSPF:

On all routers:
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/21] via 10.0.0.2, 00:14:46, FastEthernet0/0
     20.0.0.0/24 is subnetted, 1 subnets
O       20.0.0.0 [110/20] via 10.0.0.2, 00:14:46, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, FastEthernet0/0
     30.0.0.0/24 is subnetted, 1 subnets
O       30.0.0.0 [110/30] via 10.0.0.2, 00:14:46, FastEthernet0/0

Multicast configuration:

On all routers:
# Enable Multicast routing
ip multicast-routing

#Enable PIM Sparse-mode on the interfaces
R1(config)#int fa0/0
R1(config-if)#ip pim sparse-mode
R1(config)#int fa0/1
R1(config-if)#ip pim sparse-mode

#Add RP address
ip pim rp-address 1.1.1.1

(more…)

OTV: Overlay Transport Virtualization

OTV(Overlay Transport Virtualization) is a technology that provide layer2 extension capabilities between different data centers.
In its most simplest form OTV is a new DCI (Data Center Interconnect) technology that routes MAC-based information by encapsulating traffic in normal IP packets for transit.

• Transparent workload mobility
• Business resiliency
• Superior computing resource efficiencies

References:

Cisco: OTV Quick Start Guide

Cisco: NX-OS OTV Configuration Guide

Cisco: OTV Best Practices

Cisco: OTV Whitepaper

OTV Encapsulation

OTV adds a further 42 bytes on all packets traveling across the overlay network. The OTV Edge device removes the CRC and 802.1Q fields from the original Layer2 frame. It then adds an OTV Shim Header which includes this 802.1Q field (this includes the priority P-bit value) and the Overlay ID information. It also includes an external IP header for the transport network. All OTV packets have Don’t Fragment (DF) bit set to 1 in the external IP header.

(more…)

A virtual PortChannel (vPC) allows links that are physically connected to two different Cisco Nexus™ 5000 Series devices to appear as a single PortChannel to a third device. The third device can be a Cisco Nexus 2000 Series Fabric Extender or a switch, server, or any other networking device. A vPC can provide Layer 2 multipathing, which allows you to create redundancy by increasing bandwidth, enabling multiple parallel paths between nodes and load-balancing traffic where alternative paths exist.

After you enable the vPC function, you create a peer keepalive link, which sends heartbeat messages between the two vPC peer devices.

The vPC domain includes both vPC peer devices, the vPC peer keepalive link, the vPC peer link, and all the PortChannels in the vPC domain connected to the downstream device. You can have only one vPC domain ID on each device.

• vPC Quick Configuration Guide
• Design and Best practices

(more…)

HUB (R1 ):

R1: 
interface FastEthernet0/0
 ip address 192.168.1.100 255.255.255.0
 duplex full

interface Tunnel0
 ip address 10.1.1.1 255.255.255.0  #TUNNEL CONFIG
 no ip redirects
 ip mtu 1416
 ip hold-time eigrp 1 35         #EIGRP CONFIG
 no ip next-hop-self eigrp 1     #EIGRP CONFIG
 no ip split-horizon eigrp 1     #EIGRP CONFIG
 ip nhrp map multicast dynamic   #NHRP CONFIG 
 ip nhrp network-id 1            #NHRP CONFIG 
 tunnel source 192.168.1.100     #TUNNEL CONFIG
 tunnel mode gre multipoint      #TUNNEL CONFIG
!
router eigrp 1
 network 10.0.0.0
 network 172.16.0.0
 network 192.168.0.0
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1  #ROUTING TO R2-INTERNET

(more…)

Setup:

• Dual-homed BGP between AS100 and AS200
• AS100
  • HSRP 192.168.0.10 between R1 and R2
  • Router 1 HSRP Master
  • Linkstate tracking on Fa0/0
  • EIGRP as IGP
• AS200
  • HSRP 10.10.10.10 between R3 and R4
  • Router 3 as HSRP Master
  • Linkstate tracking on Fa0/0
  • OSPF for IGP

Scenario: The link between Router1 and Router3 would fail. Linkstate tracking would decrement the HSRP priority and switch masters.

When the link was restored and using default HSRP timers, the HSRP master would switch back before the BGP session was established between Router1 and Router3 (at least in GNS3).
Setting up delay timers and linkstate tracking would allow for a good recovery.

(more…)