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:

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

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…)

• Unicast:  One-to-one.
• Multicast: One-to-many.
• Anycast: One-to-closest.

• Link-local scope address:  layer2 domain
• Unique / Site-local scope address: Organization
• Global scope address: Internet

(more…)

Setup:

• R1 functions as the internet.
• R2 is the first location with Public IP 1.1.1.2/30
• R3 is the second location with Public IP 1.1.2.2/30

There must be a GRE tunnel configured between R2 and R3 so that OSPF can be used between them. In the example we will use a tunnel with and without IPsec.

Configuration without IPsec:

ROUTER 2:

R2:

# WAN ADDRESS
interface FastEthernet0/0
 ip address 1.1.1.2 255.255.255.0
 duplex auto
 speed auto
!

# TUNNEL ADDRESS
interface Tunnel0
 ip address 10.10.10.1 255.255.255.252
 tunnel source 1.1.1.2
 tunnel destination 1.1.2.2
!

# LAN ADDRESS
interface Loopback0
 ip address 192.168.10.1 255.255.255.0
!

# OSPF CONFIG
router ospf 1
 log-adjacency-changes
 network 10.10.10.0 0.0.0.3 area 0
 network 192.168.10.0 0.0.0.255 area 0
!

# DEFAULT ROUTE (TRAFFIC TOWARDS R3)
ip route 0.0.0.0 0.0.0.0 1.1.1.1

(more…)

SNMP – Simple network management protocol

• Manager – Monitoring device
• Agent – Devices being monitored
• MIB – management information Base
• UDP port 161
• Uses GETs and SETs
• SNMP Traps
  • Agent informs the manager.
• SNMPv1 and 2c have community strings.
• SNMPv3 has encryption and authentication.
  • auth – Group using the AuthNoPriv Security Level
    • Authentication: yes
    • Privacy ( encryption ): no
  • noauth – Group using the noAuthNoPriv Security Level
    • Authentication: no
    • Privacy ( encryption ): no
  • Priv – Group using the AuthPriv Security Level
    • Authentication: yes
    • Privacy ( encryption ): yes
• If no read view is defined , all objects can be read.
• If no write view is defined , no objects can be written.
• If no notify view is defined , group members are not sent notifications.

(more…)

LAB III ( DMVPN, MGRE, NHRP, EIGRP)

• Point-to-multipoint layer 3 overlay VPN
• Logical hub and spoke topology
• Direct spoke to spoke is support

DMVPN uses a combination of:

• Multipoint GRE tunnels (mGRE)
• Next Hop Resolution Protocol ( NHRP )
• IPsec Crypto Profiles
• Routing

(more…)

• Virtual Private Network
  • Route exchange privacy
  • Path determination for packets
  • Data Security
    • IPSec IP security
  • Collection of standized protocols that provide
    • Confidentiality
    • Integrity
    • Authentication
    • Anti-Reply

(more…)

• Transition technique designed to allow native IPv6 hosts to access IPv4-only content.
  • (Translation technique not a tunneling technique).
• Primarily used to allow v6 hosts to initiate connections to IPv4 content.
  • Mechanisms do exist to allow the reverse.
• Stateful and stateless versions.
  • stateful can use any prefix
  • stateless has restriction on prefix

NAT64 and DNS64 co-existance.

1. IPv6 host sends AAAA DNS Query
2. DNS64 server tries AAAA lookup and fails
3. DNS64 server successfully resolves IPv4 address
4. DNS64 server generates AAAA DNS response of <IPv6 prefix:IPv4 adress> and sends it back to the client.

(more…)

• point-to-point tunnels
• MCT ( manually configured tunnel )
• GRE ( Generic Routing Encapsulation )

• Virtual point-to-point between two IPv4 routers
• IPv6 iGP routing protocols can run over these virtual links.

(more…)