GNS3, IOU-images & VM Workstation

I’ve been using GNS3 when playing around with smaller topologies instead of booting up my R610 which is more or less like working next to a jet plane, but had a few issues getting it up and running on a new Win10-installation so figured I should document my steps for future reference.

Start with downloading:

You will also need the following bin-files:

  • i86bi-linux-l2-adventerprisek9-15.2d.bin
  • i86bi-linux-l3-adventerprisek9-15.4.1T.bin

Install everything as normal, follow the official GNS3-guide if there’s any questions. I started with VMware & VIX, imported the GNS3 VM, adjusted memory to at least 4GB RAM and added an extra bridge adapter so we can reach our topology from other devices on our network.

After installing GNS3 I had some strange issues that the program was unable to connect to the VM for some reason. The error-code I got was:

Error while saving settings: GNS3VM: Error while executing VMware command: vmrun has returned an error: Unable to connect to host.

Error: The specified version was not found

I found some old post recommending to downgrade the version of VMware station to 12.xx but a better fix I found was instead to edit the following file (depending on where you installed it):

C:\Program Files (x86)\VMware\VMware VIX\vixwrapper-config.txt

Edit the following line:

# latest un-versioned
ws        19  vmdb  e.x.p Workstation-14.0.0
player    19  vmdb  e.x.p Workstation-14.0.0

To:
# latest un-versioned
ws        19  vmdb  e.x.p Workstation-14.0.0
player    19  vmdb  15.0.4 Workstation-14.0.0

Restart WMware & GNS3 and you should be good to go. Import the IOU-appliances as normal, if you put the required .bin-files in the same folder it should find them automatically. Last step is to enter your license or GNS3 will refuse to start them, if you’re unsure how to get hold of this contact Cisco or do some googling.

EIGRP – Prefix filtering

Spent the day doing a bunch of different filtering techniques in EIGRP and stumbled upon something new regarding metric filtering that I haven’t seen before so felt like it was worth a post. 🙂

Lab 1 – Filtering with prefix-lists

  • Configure a prefix-list on R4 that only blocks its loopback out on Gi1.45
  • Configure a prefix-list on R1 so it doesn’t accept any updates from R4 on Gi1.146

Before we start our filtering our routing table should look something like this:

R4#sh ip route eigrp | beg Gate
Gateway of last resort is not set

150.1.0.0/32 is subnetted, 10 subnets
D 150.1.1.1 [90/130816] via 155.1.146.1, 00:49:27, GigabitEthernet1.146
D 150.1.2.2 [90/131328] via 155.1.146.1, 00:01:19, GigabitEthernet1.146
D 150.1.3.3 [90/131072] via 155.1.146.1, 00:28:38, GigabitEthernet1.146
D 150.1.5.5 [90/130816] via 155.1.45.5, 00:49:30, GigabitEthernet1.45
D 150.1.6.6 [90/130816] via 155.1.146.6, 00:49:27, GigabitEthernet1.146
D 150.1.7.7 [90/131072] via 155.1.146.6, 00:49:11, GigabitEthernet1.146
D 150.1.8.8 [90/131072] via 155.1.45.5, 00:49:30, GigabitEthernet1.45
D 150.1.9.9 [90/131328] via 155.1.146.6, 00:49:11, GigabitEthernet1.146
D 150.1.10.10 [90/131328] via 155.1.45.5, 00:49:30, GigabitEthernet1.45
155.1.0.0/16 is variably subnetted, 18 subnets, 2 masks
D 155.1.5.0/24 [90/3072] via 155.1.45.5, 00:49:30, GigabitEthernet1.45
D 155.1.7.0/24 
[90/3328] via 155.1.146.6, 00:49:11, GigabitEthernet1.146
D 155.1.8.0/24 [90/3328] via 155.1.45.5, 00:49:30, GigabitEthernet1.45
D 155.1.9.0/24 
[90/3584] via 155.1.146.6, 00:49:11, GigabitEthernet1.146
D 155.1.10.0/24 [90/3584] via 155.1.45.5, 00:49:30, GigabitEthernet1.45
D 155.1.13.0/24 
[90/3072] via 155.1.146.1, 00:49:27, GigabitEthernet1.146
D 155.1.23.0/24 
[90/3328] via 155.1.146.1, 00:28:38, GigabitEthernet1.146
D 155.1.37.0/24 
[90/3328] via 155.1.146.6, 00:28:38, GigabitEthernet1.146
[90/3328] via 155.1.146.1, 00:28:38, GigabitEthernet1.146
D 155.1.58.0/24 [90/3072] via 155.1.45.5, 00:49:30, GigabitEthernet1.45
D 155.1.67.0/24 
[90/3072] via 155.1.146.6, 00:49:27, GigabitEthernet1.146
D 155.1.79.0/24 
[90/3328] via 155.1.146.6, 00:49:11, GigabitEthernet1.146
D 155.1.108.0/24 
[90/3328] via 155.1.45.5, 00:49:30, GigabitEthernet1.45

Let’s start by creating a prefix-list that blocks our loopback and permits everything else.

ip prefix-list BLOCK_R4_LOOP deny 150.1.4.4/32
ip prefix-list BLOCK_R4_LOOP permit 0.0.0.0/0 le 32

router eigrp 100
 distribute-list prefix BLOCK_R4_LOOP out Gi1.45

R5 should no longer see the 150.1.4.4/32 over the Gi1.45 link:

R5#sh ip route 150.1.4.4
Routing entry for 150.1.4.4/32
Known via "eigrp 100", distance 90, metric 25984000, type internal
Redistributing via eigrp 100
Last update from 155.1.0.4 on Tunnel0, 00:00:06 ago
Routing Descriptor Blocks:
* 155.1.0.4, from 155.1.0.4, 00:00:06 ago, via Tunnel0
Route metric is 25984000, traffic share count is 1
Total delay is 15000 microseconds, minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1400 bytes
Loading 2/255, Hops 1

Lab 2 – Filtering with standard ACLs

  • Configure a standard ACL on R9 to filter out all routes sourced from R7 that have an odd number in the third octet

We need an access-list that only matches odd numbers in the third octet, we control this by using our wildcard-mask. In other words the first bit must always be set to 0 for the network to be accepted (even numbers).

access-list 1 permit 0.0.0.0 255.255.254.0  (only check first bit in third octet, must be 0)

router eigrp 100
 distribute-list 1 in GigabitEthernet 1.79

As we can see, the only odd-numbered network found in our routing table now is R9s own 150.1.9.9/32.

R9#sh ip route | beg Gate
Gateway of last resort is not set

150.1.0.0/32 is subnetted, 6 subnets
D 150.1.2.2 [90/131328] via 155.1.79.7, 00:12:23, GigabitEthernet1.79
D 150.1.4.4 [90/131328] via 155.1.79.7, 01:00:16, GigabitEthernet1.79
D 150.1.6.6 [90/131072] via 155.1.79.7, 01:00:16, GigabitEthernet1.79
D 150.1.8.8 [90/131840] via 155.1.79.7, 01:00:16, GigabitEthernet1.79
C 150.1.9.9 is directly connected, Loopback0
D 150.1.10.10 [90/132096] via 155.1.79.7, 01:00:16, GigabitEthernet1.79

Lab 3 – Filtering with extended ACLs

  • Shutdown R5s ethernetlink to R4
  • Use only extended ACLs to achieve the following:
    • Reroute traffic destined to R4 & R6 Loopbacks to go via R2
    • Reroute traffic destined to R1 & R2 Loopbacks to go via R3
    • Reroute traffic destined to R7 & R9 Loopbacks to go via R1

When we use extended ACLs with distribute-lists remember that the source-field represents the update-source and destination-field the network address. By only closing R5’s Gi1.45 link the routing table looks like this, most of the traffic is routed over the DMVPN-cloud:

R5#sh ip route | beg Gate
Gateway of last resort is not set

150.1.0.0/32 is subnetted, 10 subnets
D 150.1.1.1 [90/25984000] via 155.1.0.1, 00:00:09, Tunnel0
D 150.1.2.2 [90/25984000] via 155.1.0.2, 00:00:09, Tunnel0
D 150.1.3.3 [90/25984000] via 155.1.0.3, 00:00:09, Tunnel0
D 150.1.4.4 [90/25984000] via 155.1.0.4, 00:00:09, Tunnel0
C 150.1.5.5 is directly connected, Loopback0
D 150.1.6.6 [90/25984256] via 155.1.0.4, 00:00:09, Tunnel0
[90/25984256] via 155.1.0.1, 00:00:09, Tunnel0
D 150.1.7.7 [90/25984256] via 155.1.0.3, 00:00:09, Tunnel0
D 150.1.8.8 [90/130816] via 155.1.58.8, 00:22:56, GigabitEthernet1.58
D 150.1.9.9 [90/25984512] via 155.1.0.3, 00:00:09, Tunnel0
D 150.1.10.10 [90/131072] via 155.1.58.8, 00:22:56, GigabitEthernet1.58
155.1.0.0/16 is variably subnetted, 18 subnets, 2 masks
C 155.1.0.0/24 is directly connected, Tunnel0
L 155.1.0.5/32 is directly connected, Tunnel0
C 155.1.5.0/24 is directly connected, GigabitEthernet1.5
L 155.1.5.5/32 is directly connected, GigabitEthernet1.5
D 155.1.7.0/24 [90/25856512] via 155.1.0.3, 00:00:09, Tunnel0
D 155.1.8.0/24 [90/3072] via 155.1.58.8, 00:22:15, GigabitEthernet1.58
D 155.1.9.0/24 [90/25856768] via 155.1.0.3, 00:00:09, Tunnel0
D 155.1.10.0/24 [90/3328] via 155.1.58.8, 00:22:15, GigabitEthernet1.58
D 155.1.13.0/24 [90/25856256] via 155.1.0.3, 00:00:09, Tunnel0
[90/25856256] via 155.1.0.1, 00:00:09, Tunnel0
D 155.1.23.0/24 [90/25856256] via 155.1.0.3, 00:00:09, Tunnel0
[90/25856256] via 155.1.0.2, 00:00:09, Tunnel0
D 155.1.37.0/24 [90/25856256] via 155.1.0.3, 00:00:09, Tunnel0
D 155.1.45.0/24 [90/25856256] via 155.1.0.4, 00:00:09, Tunnel0
C 155.1.58.0/24 is directly connected, GigabitEthernet1.58
L 155.1.58.5/32 is directly connected, GigabitEthernet1.58
D 155.1.67.0/24 [90/25856512] via 155.1.0.4, 00:00:09, Tunnel0
[90/25856512] via 155.1.0.3, 00:00:09, Tunnel0
[90/25856512] via 155.1.0.1, 00:00:09, Tunnel0
D 155.1.79.0/24 [90/25856512] via 155.1.0.3, 00:00:09, Tunnel0
D 155.1.108.0/24 
[90/3072] via 155.1.58.8, 00:22:15, GigabitEthernet1.58
D 155.1.146.0/24 [90/25856256] via 155.1.0.4, 00:00:09, Tunnel0
[90/25856256] via 155.1.0.1, 00:00:09, Tunnel0

There might be a much easier way to do this, but the way I solved it was by blocking all possible “alternative” routes learned in the DMVPN so only the targeted router was accepted as a valid update-source. So if we start with R4 & R6 that we’re supposed to be routed towards R2, lets first create access-list that deny R1, R3 & R5 as update-sources for 150.1.4.4/32.

! R5
access-list 100 deny ip host 155.1.0.1 host 150.1.4.4
access-list 100 deny ip host 155.1.0.3 host 150.1.4.4
access-list 100 deny ip host 155.1.0.4 host 150.1.4.4
access-list 100 permit ip any any

router eigrp 100
distribute-list 100 in Tunnel0

The only way to reach 150.1.4.4 over the DMVPN should now be 155.1.0.2.

R5#sh ip route 150.1.4.4
Routing entry for 150.1.4.4/32
Known via "eigrp 100", distance 90, metric 25984768, type internal
Redistributing via eigrp 100
Last update from 155.1.0.2 on Tunnel0, 00:00:14 ago

To adjust the rest of the networks we just have do modify our ACL with more entries.

! R5
no access-list 100
! Filter for R4
access-list 100 deny ip host 155.1.0.1 host 150.1.4.4
access-list 100 deny ip host 155.1.0.3 host 150.1.4.4
access-list 100 deny ip host 155.1.0.4 host 150.1.4.4
! Filter for R6
access-list 100 deny ip host 155.1.0.1 host 150.1.6.6
access-list 100 deny ip host 155.1.0.3 host 150.1.6.6
access-list 100 deny ip host 155.1.0.4 host 150.1.6.6
! Filter for R1
access-list 100 deny ip host 155.1.0.1 host 150.1.1.1
access-list 100 deny ip host 155.1.0.2 host 150.1.1.1
access-list 100 deny ip host 155.1.0.4 host 150.1.1.1
! Filter for R2
access-list 100 deny ip host 155.1.0.1 host 150.1.2.2
access-list 100 deny ip host 155.1.0.2 host 150.1.2.2
access-list 100 deny ip host 155.1.0.4 host 150.1.2.2
! Filter for R7
access-list 100 deny ip host 155.1.0.2 host 150.1.7.7
access-list 100 deny ip host 155.1.0.3 host 150.1.7.7
access-list 100 deny ip host 155.1.0.4 host 150.1.7.7
! Filter for R9
access-list 100 deny ip host 155.1.0.2 host 150.1.9.9
access-list 100 deny ip host 155.1.0.3 host 150.1.9.9
access-list 100 deny ip host 155.1.0.4 host 150.1.9.9
! Permit rest
access-list 100 permit ip any any

Loopback prefixes for R4 & R6 should now be routed to R2, R1 & R2 to R3, R7 & R9 to R1.

R5#sh ip route | inc 150.1 
150.1.0.0/32 is subnetted, 10 subnets
D 150.1.1.1 [90/25984256] via 155.1.0.3, 00:00:16, Tunnel0
D 150.1.2.2 [90/25984256] via 155.1.0.3, 00:00:16, Tunnel0
D 150.1.3.3 [90/25984000] via 155.1.0.3, 00:02:42, Tunnel0
D 150.1.4.4 [90/25984768] via 155.1.0.2, 00:02:40, Tunnel0
C 150.1.5.5 is directly connected, Loopback0
D 150.1.6.6 [90/25984768] via 155.1.0.2, 00:00:15, Tunnel0
D 150.1.7.7 [90/25984512] via 155.1.0.1, 00:00:16, Tunnel0
D 150.1.8.8 [90/130816] via 155.1.58.8, 00:08:37, GigabitEthernet1.58
D 150.1.9.9 [90/25984768] via 155.1.0.1, 00:00:16, Tunnel0
D 150.1.10.10 [90/131072] via 155.1.58.8, 00:08:37, GigabitEthernet1.58

Lab 4 – Filtering with Offset Lists

  • Configure an offset-list on R7 so traffic to 150.1.3.3/32 is routed to R6
  • If the link to R6 is down, traffic should be rerouted directly to R3

Before we do any changes, here is how R7 sees the 150.1.3.3 network currently.

R7#sh ip eigrp topology 150.1.3.3/32
EIGRP-IPv4 Topology Entry for AS(100)/ID(150.1.7.7) for 150.1.3.3/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 130816
Descriptor Blocks:
155.1.37.3 (GigabitEthernet1.37), from 155.1.37.3, Send flag is 0x0
Composite metric is (130816/128256), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 5010 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 150.1.3.3

As R7 has a direct link to R3 with a decently low feasible distance, there’s no alternative route that matches the feasibility condition (adv. distance lower than 130816). But by making the current route less attractive we should be able to make R7 prefer the route to R6 instead as long as it’s up. First we create a simple ACL that matches our network.

access-list 1 permit host 150.1.3.3

We then offset the metric of our current route to make it less desirable.

router eigrp 100
 offset-list 1 in 10000 Gi1.37

Our routing table in R7 looks like this after the changes:

%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 155.1.37.3 (GigabitEthernet1.37) is resync: intf route configuration changed
R7#sh ip eigrp topology 150.1.3.3/32
EIGRP-IPv4 Topology Entry for AS(100)/ID(150.1.7.7) for 150.1.3.3/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 131328
Descriptor Blocks:
155.1.67.6 (GigabitEthernet1.67), from 155.1.67.6, Send flag is 0x0
Composite metric is (131328/131072), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 5030 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3
Originating router is 150.1.3.3
155.1.37.3 (GigabitEthernet1.37), from 155.1.37.3, Send flag is 0x0
Composite metric is (140816/138256), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 5400 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 150.1.3.3

R7# sh ip route 150.1.3.3
Routing entry for 150.1.3.3/32
Known via "eigrp 100", distance 90, metric 131328, type internal
Redistributing via eigrp 100
Last update from 155.1.67.6 on GigabitEthernet1.67, 00:01:19 ago
Routing Descriptor Blocks:
* 155.1.67.6, from 155.1.67.6, 00:01:19 ago, via GigabitEthernet1.67
Route metric is 131328, traffic share count is 1
Total delay is 5030 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 3

As we’re still receiving the route from R3 we have a backup if our link to R6 goes down.

Lab 5 – Filtering with administrative distance

  • Configure AD filtering on R3 so traffic towards 150.1.7.7 is sent to R1

Should be pretty easy, as you maybe know we can set AD on either route or by neighbor + route, in our case we need to do the latter.

access-list 1 permit host 150.1.7.7

router eigrp 100
 distance 255 155.1.37.7 0.0.0.0 1

R3#sh ip route 150.1.7.7 
Routing entry for 150.1.7.7/32
Known via "eigrp 100", distance 90, metric 131328, type internal
Redistributing via eigrp 100
Last update from 155.1.13.1 on GigabitEthernet1.13, 00:00:37 ago
Routing Descriptor Blocks:
* 155.1.13.1, from 155.1.13.1, 00:00:37 ago, via GigabitEthernet1.13
Route metric is 131328, traffic share count is 1
Total delay is 5030 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 3

Lab 6 – Filtering with Route maps

This lab had something new that I haven’t seen before. The requirements we’re as follows:

  • Configure on R4:
    • Loopback1 – 160.1.4.4/32, redistribute to EIGRP with tag 4
    • Loopback2 – 170.1.4.4/32, redistribute to EIGRP
  • Configure a route-filter on R2 that denies routes with tag 4
  • Configure a route-filter on R3 that denies routes with a metric between 120000 – 140000
  • Filters should not affect any other routes advertised

Let’s start with the R4, shouldn’t be anything tricky. We need two prefix-lists to match the different Loopbacks and a route-map to tag the desired route.

!! R4
interface Lo1
 ip add 160.1.4.4 255.255.255.255

interface Lo2
 ip add 170.1.4.4 255.255.255.255

ip prefix-list 160 permit 160.1.4.4/32
ip prefix-list 170 permit 170.1.4.4/32

route-map TAG permit 10
 match ip address prefix-list 160
 set tag 4
route-map TAG permit 20
 match ip address prefix-list 170

router eigrp 100
 redistribute connected route-map TAG

If we check the routes learned on R2 now 160.1.4.4/32 should be tagged.

Routing entry for 160.1.4.4/32
Known via "eigrp 100", distance 170, metric 131328
Tag 4, type external
Redistributing via eigrp 100
Last update from 155.1.23.3 on GigabitEthernet1.23, 00:02:55 ago
Routing Descriptor Blocks:
* 155.1.23.3, from 155.1.23.3, 00:02:55 ago, via GigabitEthernet1.23
Route metric is 131328, traffic share count is 1
Total delay is 5030 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 3
Route tag 4

R2#sh ip route 170.1.4.4
Routing entry for 170.1.4.4/32
Known via "eigrp 100", distance 170, metric 131328, type external
Redistributing via eigrp 100
Last update from 155.1.23.3 on GigabitEthernet1.23, 00:02:59 ago
Routing Descriptor Blocks:
* 155.1.23.3, from 155.1.23.3, 00:02:59 ago, via GigabitEthernet1.23
Route metric is 131328, traffic share count is 1
Total delay is 5030 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 3

Looks good! Now just have to do a route-map and filter our incoming routes on R2.

route-map BLOCK_TAG4 deny 10
 match tag 4
route-map BLOCK_TAG4 permit 20

router eigrp 100
 distribute-list route-map BLOCK_TAG4 in

We should now only see the 170.1.4.4 in R2.

R2#sh ip route eigrp | inc EX
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
D EX 170.1.4.4 [170/131328] via 155.1.23.3, 00:05:21, GigabitEthernet1.23

R2#sh ip route 160.1.4.4 
% Network not in table

R2#sh ip eigrp topology 160.1.4.4/32
EIGRP-IPv4 Topology Entry for AS(100)/ID(150.1.2.2)
%Entry 160.1.4.4/32 not in topology table

And the final step, filter out routes based on metric. Before configuring anything our routing table looks like this on R2:

150.1.0.0/32 is subnetted, 10 subnets
D 150.1.1.1 [90/130816] via 155.1.13.1, 00:09:51, GigabitEthernet1.13
D 150.1.2.2 [90/130816] via 155.1.23.2, 00:09:51, GigabitEthernet1.23
C 150.1.3.3 is directly connected, Loopback0
D 150.1.4.4 [90/131072] via 155.1.13.1, 00:09:51, GigabitEthernet1.13
D 150.1.5.5 [90/131328] via 155.1.13.1, 00:09:51, GigabitEthernet1.13
D 150.1.6.6 [90/131072] via 155.1.37.7, 00:09:51, GigabitEthernet1.37
[90/131072] via 155.1.13.1, 00:09:51, GigabitEthernet1.13
D 150.1.7.7 [90/130816] via 155.1.37.7, 00:09:51, GigabitEthernet1.37
D 150.1.8.8 [90/131584] via 155.1.13.1, 00:09:51, GigabitEthernet1.13
D 150.1.9.9 [90/131072] via 155.1.37.7, 00:09:51, GigabitEthernet1.37
D 150.1.10.10 [90/131840] via 155.1.13.1, 00:09:51, GigabitEthernet1.13

Matching by metric was new to me but it was pretty easy to find the command as it had to be done with a route-map in my mind. We use the match statement with metric, which has the following options:

R3(config-route-map)#match metric ?
<1-4294967295> Metric value
external match route using external protocol metric
R3(config-route-map)#match metric 120000 ?
+- deviation option to match metric in a range
<1-4294967295> Metric value

For us to match metrics between 120,000 – 140,000 we set the “average” and use deviation-option.

!! R3
route-map BLOCK_METRIC deny 10
match metric 130000 +- 10000
route-map BLOCK_METRIC permit 20

router eigrp 100
distribute-list route-map BLOCK_METRIC in

The 150.1.x.x we’re earlier routed via Gi1.13 & Gi1.37 but should now be filtered out and now take a worse route with metrics above 140k.

R3#sh ip route | inc 150.1
150.1.0.0/32 is subnetted, 10 subnets
D 150.1.1.1 [90/27264000] via 155.1.0.5, 00:04:17, Tunnel0
D 150.1.2.2 [90/27264000] via 155.1.0.5, 00:04:17, Tunnel0
C 150.1.3.3 is directly connected, Loopback0
D 150.1.4.4 [90/27264000] via 155.1.0.5, 00:04:17, Tunnel0
D 150.1.5.5 [90/27008000] via 155.1.0.5, 00:16:14, Tunnel0
D 150.1.6.6 [90/27264256] via 155.1.0.5, 00:04:17, Tunnel0
D 150.1.7.7 [90/27264512] via 155.1.0.5, 00:04:17, Tunnel0
D 150.1.8.8 [90/27008256] via 155.1.0.5, 00:16:14, Tunnel0
D 150.1.9.9 [90/27264768] via 155.1.0.5, 00:04:17, Tunnel0
D 150.1.10.10 [90/27008512] via 155.1.0.5, 00:16:14, Tunnel0

Sweet! Reading is going pretty well currently, I sort of finished “Routing on IOS, IOS XE, IOS XR”, jumping over the chapters I haven’t read anything about yet (multicast/bgp/route manipulation etc to backtrack later). Just started “Internet Routing Architectures” that seems to be focused solely on BGP, fun times! 🙂

 

EIGRP – Poisoned floating summary-routes

Another cool little lab showcasing a new/redesigned functionality that apparently was introduced in IOS 15.x  that was new to me. The lab has the following requirements:

  • Configure EIGRP Classic on R4, R5 & R8 with AS100, only enable it on the .45.0 & .58.0 segments
  • Configure loopbacks on R4 & R5 with subnet 160.1.x.x/24 (x – router id) and advertise them
  • Advertise a summary default-route from R4
  • Advertise a summary route of the two 16.0.1.x.x/24 routes without overlap on R5 to R8
  • Modify the summary route of R5 so a null0 route isn’t installed

All basic steps until the last one so no explanation needed I feel. Keeping up with writing the full config in notepad only is starting to pay of as well, improving both speed and overall knowledge of syntax. Highly recommended! 🙂

! R4

interface Lo1
 ip add 160.1.4.4 255.255.255.0

router eigrp 100
 network 155.1.45.0 0.0.0.255 
 network 160.1.4.0 0.0.0.255

interface Gi1.45
 ip summary-address eigrp 100 0.0.0.0 0.0.0.0

! R5

interface Lo1
 ip add 160.1.5.5 255.255.255.0

router eigrp 100
 network 155.1.45.0 0.0.0.255
 network 155.1.58.0 0.0.0.255
 network 160.1.5.0 0.0.0.255

interface Gi1.58
 ip summary-address eigrp 100 160.1.4.0 255.255.254.0

! R8

router eigrp 100
 network 155.1.58.0 0.0.0.255

Checking the routes in R8 confirms that we “should” have connectivity to the two loopbacks.

R8#sh ip route eigrp | beg Gate
Gateway of last resort is 155.1.58.5 to network 0.0.0.0

D* 0.0.0.0/0 [90/3328] via 155.1.58.5, 00:18:58, GigabitEthernet1.58
155.1.0.0/16 is variably subnetted, 7 subnets, 2 masks
D 155.1.45.0/24 [90/3072] via 155.1.58.5, 00:18:58, GigabitEthernet1.58
160.1.0.0/23 is subnetted, 1 subnets
D 160.1.4.0 [90/130816] via 155.1.58.5, 00:00:43, GigabitEthernet1.58

But ping is still failing to R4:

R8#ping 160.1.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 160.1.4.4, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

R8#ping 160.1.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 160.1.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/6 ms

How come? All summary-routes created in ex. EIGRP & OSPF will also add a Null0-route to avoid routing-loops! As we only have a default-route to R4 longest match will hit our null0-route instead for 160.1.4.4.

R5#sh ip route eigrp | beg Gate
Gateway of last resort is 155.1.45.4 to network 0.0.0.0

D* 0.0.0.0/0 [90/3072] via 155.1.45.4, 00:22:19, GigabitEthernet1.45
160.1.0.0/16 is variably subnetted, 3 subnets, 3 masks
D 160.1.4.0/23 is a summary, 00:04:05, Null0

R5#sh ip cef 160.1.4.0 
160.1.4.0/23
attached to Null0

So how do we fix this? As mentioned a new feature was added to EIGRP in 15.x (I think in previous versions something similar was done on the interface instead). We can adjust the AD of our summary-route, and by setting it to 255 it will be deemed invalid (poisoned) and not installed in our routing table.

! R5
router eigrp 100
 summary 160.1.4.0/23 distance 255

The summary-route is still active in a way as our router will keep suppressing the advertisements of  160.1.5.0/24 and just forward the default-route instead.

R5#sh ip route eigrp | beg Gate
Gateway of last resort is 155.1.45.4 to network 0.0.0.0

D* 0.0.0.0/0 [90/3072] via 155.1.45.4, 00:26:02, GigabitEthernet1.45

We can now reach both R4 & R5’s loopback from R8.

R8#ping 160.1.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 160.1.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/6/7 ms

R8#ping 160.1.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 160.1.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/6 ms

RIPv2 Filtering with Prefix-lists

A small lab on RIPv2 and the use of prefix-lists which had a pretty neat solution with filtering by advertising router that I hadn’t seen before.

Requirements:

  • Stop R5 from advertising the Loopback-prefixes of R6 & R7 to R8 with a prefix-list, everything else should be forwarded
  • In R5, filter out any RIP updates received from R4 over the DMVPN-cloud, other routes should be accepted over DMPVN

We enable RIPv2 on all routers with the very basic commands:

router rip
 version 2
 network 150.1.0.0
 network 155.1.0.0
 no auto-summary

Step1 should be fairly straightforward, we create a prefix-list denying the loopbacks of R6 & R7 and filter updates going out on Gi1.58 on R5.

ip prefix-list LO_FILTER deny 150.1.6.6/32
ip prefix-list LO_FILTER deny 150.1.7.7/32
ip prefix-list LO_FILTER permit 0.0.0.0/0 le 32

The “permit 0.0.0.0/0 le 32” works just like a “permit any any” in an access-list. Final step is to set which interface (Gi1.58) and in what direction it should be filtered (outgoing).

router rip
 distribute-list prefix LO_FILTER out GigabitEthernet1.58

After the invalid timer has expired the routes for R6 & R7s loopbacks should drop from R8s routing table while still getting the rest of the networks.

R8# sh ip route | beg Gate
Gateway of last resort is not set

150.1.0.0/32 is subnetted, 8 subnets
R 150.1.1.1 [120/2] via 155.1.58.5, 00:00:28, GigabitEthernet1.58
R 150.1.2.2 [120/2] via 155.1.58.5, 00:00:28, GigabitEthernet1.58
R 150.1.3.3 [120/2] via 155.1.58.5, 00:00:28, GigabitEthernet1.58
R 150.1.4.4 [120/2] via 155.1.58.5, 00:00:28, GigabitEthernet1.58
R 150.1.5.5 [120/1] via 155.1.58.5, 00:00:28, GigabitEthernet1.58
C 150.1.8.8 is directly connected, Loopback0
R 150.1.9.9 [120/4] via 155.1.58.5, 00:00:28, GigabitEthernet1.58
R 150.1.10.10 [120/1] via 155.1.108.10, 00:00:05, GigabitEthernet1.108

The next requirement is the tricky bit, here I was stuck for quite a while and I still haven’t actually managed to find any current official documentation regarding it except for this deprecated IOS 12.2 docs. First step first, as we need to filter out routes from R4 over the DMVPN and accept the rest, let’s create two (a bit strange I know but you’ll soon see why) prefix-lists:

ip prefix-list ACCEPT_ALL permit 0.0.0.0/0 le 32

ip prefix-list BLOCK_R4 deny 155.1.0.4/32
ip prefix-list BLOCK_R4 permit 0.0.0.0/0 le 32

We then use an extension within the distribute-list command in RIP thats called “gateway”, to first specify which networks we will accept (ACCEPT_ALL) filtered by gateway (BLOCK_R4). The actual command looks like this:

router rip
 distribute-list prefix ACCEPT_ALL gateway BLOCK_R4 in

We should now see every network except the ones advertised from R4 over the DMVPN-cloud (150.1.0.4):

R5#sh ip route | beg Gate
Gateway of last resort is not set

150.1.0.0/32 is subnetted, 10 subnets
R 150.1.1.1 [120/1] via 155.1.0.1, 00:00:07, Tunnel0
R 150.1.2.2 [120/1] via 155.1.0.2, 00:00:12, Tunnel0
R 150.1.3.3 [120/1] via 155.1.0.3, 00:00:06, Tunnel0
R 150.1.4.4 [120/1] via 155.1.45.4, 00:00:09, GigabitEthernet1.45
C 150.1.5.5 is directly connected, Loopback0
R 150.1.6.6 [120/2] via 155.1.0.1, 00:00:07, Tunnel0
R 150.1.7.7 [120/2] via 155.1.0.3, 00:00:06, Tunnel0
R 150.1.8.8 [120/1] via 155.1.58.8, 00:00:19, GigabitEthernet1.58
R 150.1.9.9 [120/3] via 155.1.0.3, 00:00:06, Tunnel0
R 150.1.10.10 [120/2] via 155.1.58.8, 00:00:19, GigabitEthernet1.58

R5#sh ip rip database 150.1.4.4 255.255.255.255
150.1.4.4/32
 [1] via 155.1.45.4, 00:00:20, GigabitEthernet1.45

Sweet! We’re still receiving R4’s loopback but over the physical link instead of the DMVPN.

Reliable Policy-based routing

Here’s another lab taking on how to set up reliable policy-based routing. The basic configuration is identical to a previous lab I did about policy-routing, so if you’re interested in the basics I suggest you also take a look there for an easier intro. This one ends up using some pretty nifty functions within route-maps to set up a secondary next-hop tied in with IP SLA-tracking & CDP that I haven’t seen earlier.

Lab requirements:

Basic routing:

  1. Configure a default-route on R3 towards R1s local interface (Gi1.13)
  2. Configure a default-route on R4 & R6 towards R1s local interface (Gi1.146)
  3. Configure a default-route on R5 towards R1s DMVPN-interface (Tu0)
  4. Configure static routes thru the DMVPN-cloud on R3 for R5’s Lo0, and vice versa on R5 for R3’s lo0

Policy-routing:

  1. Configure policy-routing on R1 so that traffic sourced from R4s G1.146 is routed to R3 over Gi1.13
  2. Configure policy-routing on R1 so that traffic sourced from R6s Gi1.146 is routed to R5 over DMVPN

Reliability:

  1. Configure CDP between R1 & R5 over DMVPN-cloud
  2. Configure IP SLA on R1 that confirms connection to R3 every 5 seconds
  3. Modify R1’s policy-routing so that if R1 loses ICMP reachability to R3, traffic from R4 is rerouted to R5 over the DMVPN-cloud
  4. Modify R1’s policy-routing so that if R1 loses R5 as CDP-neighbor, traffic from R6 is rerouted to R3 over the ethernet link (Gi1.13)

Let’s start with the easy stuff, the basic routing is very… basic, no explanation needed.

! Basic-1 R3

ip route 0.0.0.0 0.0.0.0 Gi1.13 155.1.13.1

! Basic-2
! R4

ip route 0.0.0.0 0.0.0.0 Gi1.146 155.1.146.1

! R6

ip route 0.0.0.0 0.0.0.0 Gi1.146 155.1.146.1

! Basic-3 R5

ip route 0.0.0.0 0.0.0.0 Tu0 155.1.0.1

! Basic-4
! R3
ip route 150.1.5.5 255.255.255.255 Tu0 155.1.0.5

! R5
ip route 150.1.3.3 255.255.255.255 Tu0 155.1.0.3

As in the previous lab, R1 has no routes so we won’t be able to pass much traffic yet.  Let’s take a look at setting up the policy-routing prerequisites so we can start testing basic functionality. First we’ll need an access-list to match the source-address of R4 & R6, then we manually set next-hop with a route-map and attach it to our incoming interface.

! Policy-routing R1

ip access-list extended R4
 permit ip host 155.1.146.4 any

ip access-list extended R6
 permit ip host 155.1.146.6 any

route-map RPR permit 10
 match ip address R4
 set ip next-hop 155.1.13.3

route-map RPR permit 20
 match ip address R6
 set ip next-hop 155.1.0.5

interface Gi1.146
 ip policy route-map RPR

We should now have basic connectivity finally, packets from R4 should be routed to R3 first whatever the destination:.

R4#ping 150.1.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/6/6 ms

R4#traceroute 150.1.5.5
Type escape sequence to abort.
Tracing the route to 150.1.5.5
VRF info: (vrf in name/id, vrf out name/id)
 1 155.1.146.1 5 msec 4 msec 4 msec
 2 155.1.13.3 5 msec 5 msec 5 msec
 3 155.1.0.5 5 msec * 5 msec

Packets from R6 should be routed to R5 first whatever the destination:

R6#ping 150.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/12/27 ms

R6#traceroute 150.1.3.3
Type escape sequence to abort.
Tracing the route to 150.1.3.3
VRF info: (vrf in name/id, vrf out name/id)
 1 155.1.146.1 5 msec 4 msec 4 msec
 2 155.1.0.5 5 msec 5 msec 5 msec
 3 155.1.0.3 5 msec * 5 msec

Everything is looking fine so far! Now to the tricky part with setting up reliability, cdp is easy though. We just enable it on both of our tunnel interfaces:

! Reliability-1 R1 & R5
cdp run
interface Tu0
 cdp enable

Next requirement was to set up IP SLA that tracks the connection between R1 & R3’s Gi1.13 every 5 seconds. We’ll do this in R1 as it will be the router doing the policy-routing later.

! Reliability-2 R1
ip sla 100
 icmp-echo 155.1.13.3 source-interface Gi1.13
 frequency 5

ip sla schedule start-time now life forever

track 1 ip sla 100 state

Let’s verify that everything’s OK this far:

R1#sh ip sla statistics 100
IPSLAs Latest Operation Statistics
IPSLA operation id: 100
 Latest RTT: 4 milliseconds
Latest operation start time: 17:00:09 UTC Wed Apr 11 2018
Latest operation return code: OK
Number of successes: 63
Number of failures: 0
Operation time to live: Forever

R1#sh track
Track 1
 IP SLA 100 state
 State is Up
 3 changes, last change 00:16:29
 Latest operation return code: OK
 Latest RTT (millisecs) 3
 Tracked by:
 Route Map 0

R5#sh cdp neighbors detail 
-------------------------
Device ID: R1
Entry address(es): 
 IP address: 155.1.0.1
Platform: cisco CSR1000V, Capabilities: Router IGMP 
Interface: Tunnel0, Port ID (outgoing port): Tunnel0
Holdtime : 138 sec

Version :
Cisco IOS Software, CSR1000V Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 15.5(3)S6, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2017 by Cisco Systems, Inc.
Compiled Mon 24-Jul-17 20:01 by mcpre

advertisement version: 2
Management address(es): 
 IP address: 155.1.0.1

Next step on how to use tracking with policy-routing had me stuck for quite a while, scrolling thru the Cisco Docs I finally found a page that had some examples of what we’re trying to do at:

Configuration Guides -> IP Routing: Protocol-Independent Configuration Guide – > PBR Support for Multiple Tracking Options

First requirement was to use our IP SLA 100 / Track 1 that’s currently verifying connection is up between R1 & R3. Our route-map currently looks like this for reference:

route-map RPR permit 10
 match ip address R4
 set ip next-hop 155.1.13.3
route-map RPR permit 20
 match ip address R6
 set ip next-hop 155.1.0.5

We’ll modify the first entry by removing the static next-hop for R4 and replace it with the command “set ip next-hop verify-availability [next-hop-address sequence track object]”. We also have to add something as a fallback next-hop if the tracker goes down, here the “set ip default” command looks like what we want to use. You can find more info here:

Configuration Guides -> IP Routing: Protocol-Independent Configuration Guide – > Policy-Based Routing Default Next-Hop Routes

“set ip default next-hop ip-address [ip-address]”- Specifies the next hop for routing packets if there is no explicit route for this destination.

Our final route-map for policy-routing R4 will look like this:

route-map RPR permit 10
 match ip address R4
 set ip-next verify availability 155.1.13.3 1 track 1
 set ip default next-hop 155.1.0.5

For R6 I had much bigger problems however. Here we were supposed to use CDP for tracking but I couldn’t manage to find any specific information about it more than that “set ip-next verify availability” has CDP-support. A quick google-search showed that it’s really basic however, we only use the actual command “set ip-next verify availability” and IOS will automatically do CDP-lookups before setting the chosen next-hop, in this case we still need the static set ip next-hop however. The final result will look something like this:

route-map RPR permit 20
 match ip address R6
 set ip next-hop 155.1.0.5
 set ip next-hop verify-availability
 set ip default next-hop 155.1.13.3

Let’s verify again:

R1#sh route-map
route-map RPR, permit, sequence 10
 Match clauses:
 ip address (access-lists): R4 
 Set clauses:
 ip next-hop verify-availability 155.1.13.3 1 track 1 [up]
 ip default next-hop 155.1.0.5
 Policy routing matches: 6 packets, 276 bytes
route-map RPR, permit, sequence 20
 Match clauses:
 ip address (access-lists): R6 
 Set clauses:
 ip next-hop 155.1.0.5
 ip next-hop verify-availability
 ip default next-hop 155.1.13.3
 Policy routing matches: 18 packets, 828 bytes

A traceroute from R4 should always take the route via R3 as long as there’s reachability between R1 & R3:

R4#traceroute 150.1.5.5
Type escape sequence to abort.
Tracing the route to 150.1.5.5
VRF info: (vrf in name/id, vrf out name/id)
 1 155.1.146.1 8 msec 5 msec 5 msec
 2 155.1.13.3 5 msec 5 msec 5 msec
 3 155.1.0.5 5 msec * 5 msec

Let’s see what happens when we take down the connection between R1 & R3:

R1#debug ip policy 
Policy routing debugging is on

R3(config)#int gi1.13
R3(config-subif)#shut

PBR Nexthop: Unregister tracking for 155.1.13.3, handle: 7F74CD6A6768
PBR Nexthop Callback invoked: 7F74F117B6C0, (155.1.13.3) tableid 0, status: 0, type: SET NEXTHOP TRACKINGmap: RPR, sequence: 10
PBR Control Plane Notification: 155.1.0.5 PBR_CP_SET_DEFAULT_NEXTHOP
Policy NextHop Inquiry: RPR seq: 10, type: SET DEFAULT NEXTHOP Nexthop: 155.1.0.5SW_OBJ_TYPE: 1E, SW_HANDLE: 7F74F1108FE8
PBR CP Notification sent: Type:SET DEFAULT NEXTHOP, 155.1.0.5SW_OBJ_TYPE: 1E, SW_HANDLE: 7F74F1108FE8

Let’s do another traceroute, the traffic should jump directly to R5 instead:

R4#traceroute 150.1.5.5
Type escape sequence to abort.
Tracing the route to 150.1.5.5
VRF info: (vrf in name/id, vrf out name/id)
 1 155.1.146.1 4 msec 4 msec 4 msec
 2 155.1.0.5 4 msec * 4 msec

Sweet! Let’s try the same for R6, all traffic should always first be redirected to R5:

R6#traceroute 150.1.3.3
Type escape sequence to abort.
Tracing the route to 150.1.3.3
VRF info: (vrf in name/id, vrf out name/id)
 1 155.1.146.1 5 msec 5 msec 4 msec
 2 155.1.0.5 5 msec 5 msec 5 msec
 3 155.1.0.3 5 msec * 5 msec

Looking good so far. Lets disable CDP on R5s Tunnel0 interface and wait out the hold-timer (180 seconds), not a very fast switchover with default timers…

! R5
interface Tu0
 no cdp enable

After a long wait R5 is no longer showed in cdp-table:

R1#sh cdp neighbors 
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
 S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone, 
 D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
R10 Gig 1 172 R I CSR1000V Gig 1
R2 Gig 1 126 R I CSR1000V Gig 1
R3 Gig 1 131 R I CSR1000V Gig 1
R6 Gig 1 132 R I CSR1000V Gig 1
R7 Gig 1 166 R I CSR1000V Gig 1
R4 Gig 1 151 R I CSR1000V Gig 1
R8 Gig 1 150 R I CSR1000V Gig 1
R9 Gig 1 158 R I CSR1000V Gig 1

A traceroute should now go directly to R3 instead (don’t forget to open the interface we previously shutdown).

R6#traceroute 150.1.3.3
Type escape sequence to abort.
Tracing the route to 150.1.3.3
VRF info: (vrf in name/id, vrf out name/id)
 1 155.1.146.1 6 msec 5 msec 3 msec
 2 155.1.0.5 5 msec 5 msec 5 msec
 3 155.1.0.3 5 msec * 5 msec

Not what we were hoping for.. Traffic is for some reason still routed over to R5 even though we have no CDP-reachability. I tried troubleshooting this forever but finally found a notation that there’s apparently a bug in the CSR-1000V routers when it comes to verify-availability & CDP tracking(!!). The config looks OK though from other examples I could find so this is how it’s “supposed” to work at least.. Fun times. 🙂

Reliable static routing with Object tracking/IP SLA

  1. Another rather basic lab regarding reliable static routing using object tracking with IP SLA, always good to refresh the fundamentals. 🙂

Goals:

    1. In R1 – Static route R4’s loopback through the DMVPN-cloud
    2. In R5 – Static route R1’s & R4’s loopbacks through the DMVPN-cloud
    3. In R4 – Make a primary static route for R1s loopback thru Gi1.146
      • Make sure the static route is only available when R1 is reachable thru Gi1.146, there’s a switch between R1 & R4 so indirect link failures will not be noticed
      • Reachability has to be checked every 5 seconds, R1 also has to respond within 2 seconds for the link to be deemed OK
    4. In R4 – Configure a backup static route for R1’s loopback thru the DMVPN-cloud, only to be used when Gi1.146 is down

For step 3 the easiest (only?) solution for step 3 should just be to set up an IP SLA sending ICMP over the G1.146 link. I couldn’t remember how the syntax looks for configuring the timers however. Trying to stay true to not cheating with checking “?” in CLI and keeping to notepad it was time to head over to the Cisco Doc. You can find IP SLA Configuration guide under:

Support > Product Support > Cisco IOS and NX-OS Software > Cisco IOS 15.4M&T > Configuration Guides > IP SLAs Configuration Guides  Configuring IP SLAs UDP Echo Operations

The values we’re looking for where frequency & timeout. Initial configuration should be something like this:

! 1-1 R1

ip route 150.1.4.4 255.255.255.255 Tu0 155.1.0.4

! 2-1 R5

ip route 150.1.1.1 255.255.255.255 Tu0 155.1.0.1
ip route 150.1.4.4 255.255.255.255 Tu0 155.1.0.4

! 3-1 R4

ip sla 1
 icmp-echo 155.1.146.1 source-ip 155.1.146.4
 frequency 5
 threshold 2000
 timeout 2000

ip sla schedule 1 life forever start-time now
track 1 ip sla 1

ip route 150.1.1.1 255.255.255.255 Gi1.146 155.1.146.1 track 1

! 4-1 R4
ip route 150.1.1.1 255.255.255.255 Tu0 150.1.0.1 2

Verification:

R4#ping 150.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/5 ms

R4#sh ip sla statistics 1
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
 Latest RTT: 4 milliseconds
Latest operation start time: 06:26:53 UTC Sat Apr 7 2018
Latest operation return code: OK
Number of successes: 65
Number of failures: 1
Operation time to live: Forever

R4#sh track
Track 1
 IP SLA 1 state
 State is Up
 2 changes, last change 00:04:08
 Latest operation return code: OK
 Latest RTT (millisecs) 5
 Tracked by:
 Static IP Routing 0

R4#sh ip route 150.1.1.1
Routing entry for 150.1.1.1/32
 Known via "static", distance 1, metric 0
 Routing Descriptor Blocks:
 * 155.1.146.1, via GigabitEthernet1.146
 Route metric is 0, traffic share count is 1

R4#sh ip static route
Codes: M - Manual static, A - AAA download, N - IP NAT, D - DHCP,
 G - GPRS, V - Crypto VPN, C - CASA, P - Channel interface processor,
 B - BootP, S - Service selection gateway
 DN - Default Network, T - Tracking object
 L - TL1, E - OER, I - iEdge
 D1 - Dot1x Vlan Network, K - MWAM Route
 PP - PPP default route, MR - MRIPv6, SS - SSLVPN
 H - IPe Host, ID - IPe Domain Broadcast
 U - User GPRS, TE - MPLS Traffic-eng, LI - LIIN
 IR - ICMP Redirect
Codes in []: A - active, N - non-active, B - BFD-tracked, D - Not Tracked, P - permanent

Static local RIB for default

T 150.1.1.1/32 [1/0] via GigabitEthernet1.146 155.1.146.1 [A]
M [2/0] via Tunnel0 155.1.0.1 [N]

Let’s see what happens if we have an indirect link failure between R4 & R1:

R4#debug track state
track state debugging enabled
R4#debug ip routing
IP routing debugging is on

R1(config)#int gi1.146
R1(config-subif)#shut

Our IP SLA timeouts and our tracker changes state to down, which in turn leads to our main static route being pulled from the routing table. As we have a floating route with an administrative distance of 2 it should instead take over:

R4#
track-sta (1) ip sla 1 state Up -> Down
RT: del 150.1.1.1 via 155.1.146.1, static metric [1/0]
RT: delete subnet route to 150.1.1.1/32
RT: updating static 150.1.1.1/32 (0x0) :
 via 155.1.0.1 Tu0 0 1048578

RT: add 150.1.1.1/32 via 155.1.0.1, static metric [2/0]
RT: updating static 150.1.1.1/32 (0x0) :
 via 155.1.0.1 Tu0 0 1048578

R4#sh ip route 150.1.1.1
Routing entry for 150.1.1.1/32
 Known via "static", distance 2, metric 0
 Routing Descriptor Blocks:
 * 155.1.0.1, via Tunnel0
 Route metric is 0, traffic share count is 1

R4#ping 150.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/6 ms

Sweet! Going to focus more on reading again for a week or two until I finish Routing TCP/IP Volume 1, the holy bible of routing books. I’ll try to stick with only doing labwork outside of my set “study hours”, unfortunately it’s just way more fun… 🙂

Policy-based routing

Just a small lab taking a closer look at how policy-based routing works.

Requirements:

  1. Configure a default-route on R3 towards R1s local interface (Gi1.13)
  2. Configure a default-route on R4 & R6 towards R1s local interface (Gi1.146)
  3. Configure a default-route on R5 towards R1s DMVPN-interface (Tu0)
  4. Configure static routes thru the DMVPN-cloud on R3 for R5’s Lo0, and vice versa on R5 for R3’s lo0
  5. Configure policy-routing on R1 so that traffic sourced from R4s G1.146 is routed to R3 over Gi1.13
  6. Configure policy-routing on R1 so that traffic sourced from R6s Gi1.146 is routed to R5 over DMVPN

Let’s start with the basic static routes first:

! 1-1 R3

ip route 0.0.0.0 0.0.0.0 Gi1.13 155.1.13.1

! 2-1 R4 & R6

ip route 0.0.0.0 0.0.0.0 Gi1.146 155.1.146.1

! 3-1 R5

ip route 0.0.0.0 0.0.0.0 Tu0 155.1.0.1

! 4-1
! R3

ip route 150.1.5.5 255.255.255.255 Tu0 155.1.0.5

! R5

ip route 150.1.3.3 255.255.255.255 Tu0 155.1.0.3

That should be all the routing we need to start with. Notice however that R1 doesn’t have a clue what to do with the packets trying to reach loopbacks and will instead timeout.

R1#sh ip route static 
Codes: L - local, 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, H - NHRP, l - LISP
 a - application route
 + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

R1#

We’ll solve this problem by using policy-based routing and manually setting next-hop ip-address depending on source address instead. First we need access-lists to separate traffic coming from R4 and R6.

ip access-list extended SRC-R4
 10 permit ip host 155.1.146.4 any
ip access-list extended SRC-R6
 10 permit ip host 155.1.146.6 any

Next step is to use a route-map to manually set the next-hop address depending on which ACL matches.

route-map PBR_LAB permit 10

 match ip address SRC-R4
 set ip next-hop 155.1.13.3
route-map PBR_LAB permit 20
 match ip address SRC-R6
 set ip next-hop 155.1.0.5

Last step is to activate policy-based routing on our incoming interface, in this case R1s Gi1.146.

interface Gi1.146
 ip policy route-map PBR_LAB

All done! To verify that traffic is routed correctly we can use traceroute.

R4#ping 150.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/6/10 ms

R4#traceroute 150.1.3.3
Type escape sequence to abort.
Tracing the route to 150.1.3.3
VRF info: (vrf in name/id, vrf out name/id)
 1 155.1.146.1 5 msec 4 msec 4 msec
 2 155.1.13.3 4 msec * 3 msec

R6#ping 150.1.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/12/27 ms

R6#traceroute 150.1.5.5
Type escape sequence to abort.
Tracing the route to 150.1.5.5
VRF info: (vrf in name/id, vrf out name/id)
 1 155.1.146.1 5 msec 5 msec 4 msec
 2 155.1.0.5 5 msec

R1#sh route-map 
route-map PBR_LAB, permit, sequence 10
 Match clauses:
 ip address (access-lists): SRC-R4 
 Set clauses:
 ip next-hop 155.1.13.3
 Policy routing matches: 20 packets, 1280 bytes
route-map PBR_LAB, permit, sequence 20
 Match clauses:
 ip address (access-lists): SRC-R6 
 Set clauses:
 ip next-hop 155.1.0.5
 Policy routing matches: 14 packets, 1004 bytes

If we however change the source-address in either R4 or R6 our access-list in R1 will no longer match, so packets will just timeout instead.

R6#ping 150.1.5.5 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.5.5, timeout is 2 seconds:
Packet sent with a source address of 150.1.6.6 
.....
Success rate is 0 percent (0/5)

For more information how to configure policy-based routing I managed to find the section in CiscoDoc at: 

Configuration Guides -> IP Routing: Protocol-Independent Configuration Guide – > Policy-based Routing

 

Current progress & random ramblings

Thinking about switching over to English instead for this & future posts. When I started this blog in the middle of 2013 I couldn’t find any Cisco/CCIE-focused blog that was written in Swedish, so my thinking was that there was a “gap to be filled”. Over the years however I actually gotten more and more traffic outside of Sweden, and just checking this last month hits from within Sweden was only about 20% of total traffic.. So instead of just being a “dead page” for most people randomly googling something, and also the fact that I don’t have to keep using horrible ‘swenglish’ in my posts which contains 99% technical words anyway – it’s starting to feel like it’s time for a change.

In the middle of february this year I decided to set a real goal of at least being done with CCIE Written and be at least around ~60% ready for the lab before the year is over. Over the years I also realized this will never happen without having a set study schedule and setting aside several hours every week for both reading and lab work after. Since then i’ve been waking up at 04.45 on weekdays and studying 2-2½h before work, on weekends I sleep a little longer but dedicate at least ~4-5h each morning.

This has been working great! In earlier attempts I always did the studying after work, and as months passed I just got too tired to retain info/kept falling asleep reading or other things got in the way. After work hours is more focused on doing labs now, it finally feels like I found a way that works for me in the long run.

A small update regarding what i’m currently reading/have read this last 1½ months & what I have planned going forward (did a full restart):

  • Fundamentals:
    • Interconnections – Bridges, Routers & Switches ✔
    • TCP/IP Illustrated – Vol. 1 ✔
  • Switching:
    • Cisco LAN Switching ✔
    • Official Cert Guide CCNP Routing & Switching – Switch 300-115 (~50%, paused until I get some switching gear to lab on)
  • Routing:
    • Routing TCP/IP – Volume 1 (Currently reading)
    • IP Routing on IOS, IOS XE, IOS XR
    • Internet Routing Architechtures
    • Troubleshooting IP Routing Protocols
    • Routing TCP/IP – Volume 2
  • IPv6
    • IPv6 Theory, Protocol & Practice
  • MPLS
    • MPLS Fundamentals
    • MPLS Enabled Applications
  • Multicast
    • CCIE Developing IP Multicast
  • QoS
    • End to End QoS Network Design
  • Final prep for Written
    • CCIE Routing & Switching – Official Certification Guide

A big problem i’ve always had is retaining information when moving on to another subject, ex going from reading details about of TCP/IP to Switching to Routing etc. Making my own flashcards has been a life saviour. I try to take at least a few minutes and go thru one set of cards on every break at work etc. A great (and free) site i’ve been using is cram.com that also have a good mobile app.

I’m also trying to set a good foundation when it comes to lab work. From reading other CCIE-blogs like lostintransit.se,  ipspace.net, rogerperkin that passed the exam, being able to write out templates & general config straight in notepad is almost a requirement to reach the speed required to finishing the actual lab exam later. So I try to stay away from the CLI until I feel like i’m done with all the steps in each lab. I’ve been using the following format in notepad after reading this great post by Nick Russo regarding passing the CCIE SP4-lab, using one document for everything will make it easy to ctrl+f and find a certain config section if you have to go back etc:

! 3-1 R4 Object Tracking

ip sla 1
 icmp-echo 150.1.146.1 source-ip 150.1.146.4
 frequency 5
 threshold 2000
 timeout 2000
ip sla schedule 1 life forever start-time now
track 1 ip sla 1
ip route 150.1.1.1 255.255.255.255 Gi1.146 155.1.146.1 track 1

! 3-2 R4 Floating route

ip route 150.1.1.1 255.255.255.255 Tu0 150.1.0.1 2

Another important thing (that i’m still terrible at using myself currently), when you’re unsure of a specific command or how to solve it, try to stay away from google and use Cisco’s official documentation instead. There’s a huge benefit in being confident knowing where to find specific material when you’re at the actual exam, remember – there is no search-field (except for ctrl+f on your current page). Unfortunately most videos going over how to use the doccd efficiently is not updated and it actually looks like Cisco recently did another revamp of the entire section (so INEs v5.1 doccd-video is also ood). The good news however is that it seems to be much faster now! 🙂

Here’s some good links i’ve found (which hopefully is reachable during the exam?):

Not really sure about which IOS they are actually running nowadays, but the difference between any 15.x version should be very small. Speaking of lab-prep i’ve actually gone all out and ordered myself an US-layout keyboard as well just to get used to the layout and type faster… 🙂

A few more tips regarding lab work, to speed things up going between different labs, on each router I created a “blank.cfg” config with only the bare minimums, ex:

hostname R1
no ip domain lookup
alias exec con conf t
alias exec sib show ip int brief
alias exec srb show run | b
alias exec sri show run int
line con 0
 exec-timeout 0 0
 logging synchronous

copy run flash:blank.cfg

I then made a small VBS-script that logs in to each router (going by open tabs in SecureCRT) and replacing current config with the blank.cfg, no more reloading!

# $language = "VBScript"
# $interface = "1.0"
dim nIndex, objCurrentTab

For nIndex = 1 to crt.GetTabCount
 Set objCurrentTab = crt.GetTab(nIndex)
 objCurrentTab.Activate
 if objCurrentTab.Session.Connected = True then
 crt.Sleep 500
 objCurrentTab.Screen.Send "end" & vbcr
 crt.Sleep 500
 objCurrentTab.Screen.Send "config replace flash:blank.cfg" & vbcr
 crt.Sleep 500
 objCurrentTab.Screen.Send "y" & vbcr
 crt.Sleep 500
 end if
 Next

The only caveat is that subinterfaces you’ve created earlier will still be visible as “deleted”, but I haven’t found any other downside.

CSR-R10# sh int desc
Interface Status Protocol Description
Gi1 up up 
Gi1.10 deleted down 
Gi1.108 deleted down 
Gi2 admin down down 
Gi3 admin down down

For loading initial configs from ex. INE’s workbook I found a great little script, you only have to select which folder you want to load from and it does the rest. Unfortunately I can’t manage to find the actual author again to give credit.. I’ll update the page when I find it. The only gotcha is that each tab in SecureCRT will have to have the same name as the config files, ex R1 for R1.txt etc.  Script looks like this:

# $language = "VBScript"
# $interface = "1.0"

Option Explicit

Dim strPath

strPath = SelectFolder( "" )
If strPath = vbNull Then
 msgbox "Cancelled"
Else
' msgbox "Selected Folder: """ & strPath & """"
End If

dim objFSO, objStartFolder, objFolder, colFiles, objFile, Xcount, nIndex, objCurrentTab 
Const ForReading = 1
Const ForWriting = 2

For nIndex = 1 to crt.GetTabCount
 Set objCurrentTab = crt.GetTab(nIndex)
 objCurrentTab.Activate
 if objCurrentTab.Session.Connected = True then
 crt.Sleep 500
 objCurrentTab.Screen.Send "!" & vbcr
 crt.Sleep 500
 objCurrentTab.Screen.Send "enable" & vbcr
 crt.Sleep 500
 objCurrentTab.Screen.Send "config t" & vbcr
 crt.Sleep 500
 objCurrentTab.Screen.Send "! " & objCurrentTab.Caption & vbcr 
 crt.Sleep 1000

Dim fso, file, str, filename, char1, char2
 Set fso = CreateObject("Scripting.FileSystemObject")
 filename = strPath & "\" & objCurrentTab.Caption & ".txt"

' Test if File is Unicode or ASCII

Set file = fso.OpenTextFile(filename)
char1 =file.read(1)
char2 =file.read(1)
file.close

if asc(char1) = 255 and asc(char2) = 254 then
 set file = fso.opentextfile(filename,,,true)
else
 set file = fso.opentextfile(filename)
end if

objCurrentTab.Screen.Send "Opening file: " & filename

'objCurrentTab.Screen.Synchronous = True

Do While file.AtEndOfStream <> True

str = file.Readline
 objCurrentTab.Screen.Send str & Chr(13)
 crt.Sleep 10
 
 Loop

'objCurrentTab.Screen.Synchronous = False

end if
 file.close
 set fso = Nothing
 Next

Function SelectFolder( myStartFolder )

Dim objFolder, objItem, objShell

On Error Resume Next
 SelectFolder = vbNull

Set objShell = CreateObject( "Shell.Application" )
 Set objFolder = objShell.BrowseForFolder( 0, "Select Folder", 0, myStartFolder )

If IsObject( objfolder ) Then SelectFolder = objFolder.Self.Path

Set objFolder = Nothing
 Set objshell = Nothing
 On Error Goto 0
End Function

“Motivation is crap, be driven”

I recommend everyone to watch this podcast with David Goggins & Joe Rogan whenever you’re starting to lose momentum, goosebumps! 🙂

Routing över NBMA – DMVPN & NHRP

En enklare labb på routing över DMVPN som jag inte hunnit läsa/labba så mycket på ännu, verkade dock rätt intressant för att få en bättre förståelse över hur NHRP används för att sätta upp tunnlar mellan spokes.

  • Konfigurera en statisk default-route i R1 & R2 genom DMVPN-molnet till R5, routen får endast vara giltig när Tunnel-interfacet är i UP-state
  • Konfigurera R5 med statiska routes till R1 & R2’s loopbacks genom DMVPN-molnet
  • Tunnel-interfacen för respektive router är: R1 155.1.0.1, R2 155.1.0.2, R5 155.1.0.5

Enklaste sättet att lösa första kravet är att ange utgående interface tillsammans med nexthop till R5, då blir routen endast giltig när nexthop är nåbar över specificerade interfacet. Anger vi bara nexthop kommer routen fortfarande vara giltig så länge det finns en alternativ väg (och då matchar vi inte längre kravet i labben).

R1(config)#ip route 0.0.0.0 0.0.0.0 Tunnel0 155.1.0.5

R2(config)#ip route 0.0.0.0 0.0.0.0 Tunnel0 155.1.0.5

R5(config)#ip route 150.1.1.1 255.255.255.255 Tunnel0 155.1.0.1
R5(config)#ip route 150.1.2.2 255.255.255.255 Tunnel0 155.1.0.2

Vi skulle även kunna krångla till det lite och använda trackers på R1 & R2 istället i stil med detta:

R1(config)#track 1 interface Tunnel0 line-protocol
R1(config)#ip route 0.0.0.0 0.0.0.0 155.1.0.5 track 1

R2(config)#track 1 interface Tunnel0 line-protocol
R2(config)#ip route 0.0.0.0 0.0.0.0 155.1.0.5 track 1

Hur som.. Alla routrar bör nu kunna pinga varandra utan problem.

R1#ping 150.1.5.5
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 150.1.5.5, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

R1#ping 150.1.2.2
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 150.1.2.2, timeout is 2 seconds:
 .!!!!
 Success rate is 80 percent (4/5), round-trip min/avg/max = 4/4/5 ms

Observera att vi tappar första paketet till R2, detta beror på att R1 måste skicka ett NHRP Resolution Request till R5 där den efterfrågar den publika ip-adressen (NBMA address) för att komma till R2/150.1.2.2. R5 svarar med R2’s publika address 169.254.100.2, R1 handskakar därefter upp en dynamisk tunnel mellan den & R2.  Vi kan verifiera detta med:

R2#
 interface Tunnel0
 ip address 155.1.0.2 255.255.255.0
 ...
  tunnel source GigabitEthernet1.100
 ...

interface GigabitEthernet1.100
 encapsulation dot1Q 100
 ip address 169.254.100.2 255.255.255.0

R1#sh ip nhrp
 155.1.0.1/32 via 155.1.0.1
 Tunnel0 created 00:00:03, expire 00:04:56
 Type: dynamic, Flags: router unique local
 NBMA address: 169.254.100.1
 (no-socket)
 155.1.0.2/32 via 155.1.0.2
  Tunnel0 created 00:00:03, expire 00:04:56
  Type: dynamic, Flags: router implicit used nhop 
  NBMA address: 169.254.100.2
 155.1.0.5/32 via 155.1.0.5
 Tunnel0 created 01:30:55, never expire
 Type: static, Flags: used
 NBMA address: 169.254.100.5

Detta fungerar lika bra även om vi endast anger DMVPN-molnet som utgående IF i R1 & R2:

R2(config)#no ip route 0.0.0.0 0.0.0.0 Tunnel0 155.1.0.5
R2(config)#ip route 0.0.0.0 0.0.0.0 Tunnel0

R1(config)#no ip route 0.0.0.0 0.0.0.0 Tunnel0 155.1.0.5
R1(config)#ip route 0.0.0.0 0.0.0.0 Tunnel0

R1#sh ip nhrp
 155.1.0.5/32 via 155.1.0.5
 Tunnel0 created 01:38:25, never expire
 Type: static, Flags: used
 NBMA address: 169.254.100.5

R1#ping 150.1.2.2
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 150.1.2.2, timeout is 2 seconds:
 .!!!!
 Success rate is 80 percent (4/5), round-trip min/avg/max = 4/4/5 ms

Vad händer dock om vi gör samma sak i vår hub/R5?

R5(config)#no ip route 150.1.1.1 255.255.255.255 Tunnel0 155.1.0.1
R5(config)#no ip route 150.1.2.2 255.255.255.255 Tunnel0 155.1.0.2
R5(config)#ip route 150.1.2.2 255.255.255.255 Tunnel0
R5(config)#ip route 150.1.1.1 255.255.255.255 Tunnel0

R1#ping 150.1.2.2
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 150.1.2.2, timeout is 2 seconds:
 .....
 Success rate is 0 percent (0/5)

Detta trots att våra tunnlar fortfarande är uppe!

R1#sh ip nhrp
 150.1.2.2/32 via 155.1.0.2
 Tunnel0 created 00:01:11, expire 00:03:49
 Type: dynamic, Flags: router
 NBMA address: 169.254.100.2
 155.1.0.2/32 via 155.1.0.2
  Tunnel0 created 00:01:10, expire 00:03:49
  Type: dynamic, Flags: router nhop 
  NBMA address: 169.254.100.2
 155.1.0.5/32 via 155.1.0.5
 Tunnel0 created 01:39:55, never expire
 Type: static, Flags: used
 NBMA address: 169.254.100.5

En debug ger lite bättre inblick vad det är som går fel:

R5#debug nhrp
 NHRP protocol debugging is on
 R5#debug ip pack
 R5#debug ip packet detail
 IP packet debugging is on (detailed)
R5#ping 150.1.1.1 rep 1
 Type escape sequence to abort.
 Sending 1, 100-byte ICMP Echos to 150.1.1.1, timeout is 2 seconds:

IP: s=155.1.0.5 (local), d=150.1.1.1, len 100, local feature
 ICMP type=8, code=0, feature skipped, Auth Proxy(16), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
 FIBipv4-packet-proc: route packet from (local) src 155.1.0.5 dst 150.1.1.1
 FIBfwd-proc: packet routed by adj to Tunnel0 150.1.1.1
 FIBipv4-packet-proc: packet routing succeeded
 IP: tableid=0, s=155.1.0.5 (local), d=150.1.1.1 (Tunnel0), routed via FIB
 IP: s=155.1.0.5 (local), d=150.1.1.1 (Tunnel0), len 100, sending
 ICMP type=8, code=0
 IP: s=155.1.0.5 (local), d=150.1.1.1 (Tunnel0), len 100, output feature
 ICMP type=8, code=0, feature skipped, TCP Adjust MSS(58), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
 NHRP: NHRP could not map 150.1.1.1 to NBMA, cache entry not found
 NHRP: MACADDR: if_in null netid-in 0 if_out Tunnel0 netid-out 1
 NHRP: Checking for delayed event NULL/150.1.1.1 on list (Tunnel0 vrf: global(0x0))
 NHRP: No delayed event node found.
 NHRP: No cache for forwarding(0)
 NHRP: Node found.
 Success rate is 0 percent (0/1)

Det är hubrouterns uppgift att hålla kolla på mappningarna mellan intern/publik nexthop och den har ingen annan att fråga än sig själv. Därför ska man alltid ange nexthop-adress när man konfigurerar rötter i hubroutern/R5. Vi kan dock lösa detta genom en workaround och göra statiska mappningar för loopback-näten i R5.

R5(config)#int tu0
R5(config-if)#ip nhrp map 150.1.1.1 169.254.100.1
R5(config-if)#ip nhrp map 150.1.2.2 169.254.100.2

R5#sh ip nhrp
 150.1.1.1/32 via 150.1.1.1
 Tunnel0 created 00:00:12, never expire
 Type: static, Flags:
 NBMA address: 169.254.100.1
 150.1.2.2/32 via 150.1.2.2
 Tunnel0 created 00:00:04, never expire
 Type: static, Flags:
 NBMA address: 169.254.100.2
 155.1.0.1/32 via 155.1.0.1
 Tunnel0 created 01:50:06, expire 00:04:24
 Type: dynamic, Flags: unique registered used nhop
 NBMA address: 169.254.100.1
 155.1.0.2/32 via 155.1.0.2
 Tunnel0 created 01:50:01, expire 00:04:28
 Type: dynamic, Flags: unique registered used nhop
 NBMA address: 169.254.100.2

R1#ping 150.1.2.2
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 150.1.2.2, timeout is 2 seconds:
 .!!!!
 Success rate is 80 percent (4/5), round-trip min/avg/max = 4/4/5 ms

R5#sh ip cef 150.1.1.1 internal
150.1.1.1/32, epoch 2, RIB[S], refcnt 6, per-destination sharing
 sources: RIB 
 feature space:
 IPRM: 0x00048000
 Broker: linked, distributed at 4th priority
 ifnums:
 Tunnel0(16): 155.1.0.1
 path list 7F324BEC8258, 3 locks, per-destination, flags 0x49 [shble, rif, hwcn]
 path 7F324C152DB0, share 1/1, type attached nexthop, for IPv4
 nexthop 155.1.0.1 Tunnel0, IP midchain out of Tunnel0, addr 155.1.0.1 7F322D228540
 output chain:
 IP midchain out of Tunnel0, addr 155.1.0.1 7F322D228540
 IP adj out of GigabitEthernet1.100, addr 169.254.100.1 7F322D228CE0

Kanske får komma tillbaka och revidera texten lite när jag har bättre koll på DMVPN sen men förhoppningsvis är det inte allt för många felaktigheter.. 🙂

Multipoint Broadcast routing & Proxy-ARP

Back to basics, en liten labb på hur proxy-arp fungerar när vi routar ut på ett multipoint (broadcast) interface med/utan proxy-arp (default alltid på i ios).

R1#sh run int gi1.146
 interface GigabitEthernet1.146
 encapsulation dot1Q 146
 ip address 155.1.146.1 255.255.255.0
 ipv6 address 2001:155:1:146::1/64

R1#sh ip int gi1.146 | inc Proxy
 Proxy ARP is enabled

Labben gick ut på följande:

  • Skapa en statisk route i R1 för R4’s Loopback med R4 som nexthop
  • Skapa en statisk route i R1 för R6’s Loopback med endast utgående interface som nexthop
  • Stängt av proxy-arp i R6 och fixa så dess loopback fortfarande är nåbar från R1

Ezpz, vi lägger in statiska rötterna till att börja med.

R1(config)#ip route 150.1.4.4 255.255.255.255 155.1.146.4
R1(config)#ip route 150.1.6.6 255.255.255.255 GigabitEthernet1.146

R1#sh ip route static | beg Gate
Gateway of last resort is not set

150.1.0.0/32 is subnetted, 3 subnets
S 150.1.4.4 [1/0] via 155.1.146.4
S 150.1.6.6 is directly connected, GigabitEthernet1.146

R1#ping 150.1.4.4 rep 1 
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 150.1.4.4, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 6/6/6 ms

R1#ping 150.1.6.6 rep 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 150.1.6.6, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 6/6/6 ms

Allt bra så långt, vad händer när vi stänger av Proxy-arp i R6?

R6(config)#int gi1.146
R6(config-subif)#no ip proxy-arp

R1#clear arp
R1#ping 155.1.6.6 rep 1 
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 155.1.6.6, timeout is 2 seconds:
.
Success rate is 0 percent (0/1)

Kikar vi närmare på debug i R1 & R6 ser vi snabbt vad det är som går på tok.

R6#debug arp
ARP packet debugging is on 

R1#debug ip packet detail 
IP packet debugging is on (detailed)
R1#debug arp
ARP packet debugging is on

R1#ping 150.1.6.6 rep 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 150.1.6.6, timeout is 2 seconds:

IP: s=155.1.146.1 (local), d=150.1.6.6, len 100, local feature
 ICMP type=8, code=0, feature skipped, Auth Proxy(16), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
FIBipv4-packet-proc: route packet from (local) src 155.1.146.1 dst 150.1.6.6
FIBfwd-proc: packet routed by adj to GigabitEthernet1.146 150.1.6.6
FIBipv4-packet-proc: packet routing succeeded
IP: tableid=0, s=155.1.146.1 (local), d=150.1.6.6 (GigabitEthernet1.146), routed via FIB
IP: s=155.1.146.1 (local), d=150.1.6.6 (GigabitEthernet1.146), len 100, sending
 ICMP type=8, code=0
IP ARP: creating incomplete entry for IP address: 150.1.6.6 interface GigabitEthernet1.146
IP ARP: sent req src 155.1.146.1 000c.2947.8992,
 dst 150.1.6.6 0000.0000.0000 GigabitEthernet1.146.
Success rate is 0 percent (0/1)

R1 broadcastar ut en ARP-request till 150.1.6.6, men då vi stängt av proxy-arp i R6 ignorerar den paketet trots att den känner till var adressen finns. Aktiverar vi proxy-arp temporärt så ser vi hur R6 svarar på arp-requesten med mac-adressen till Gi1.146.

IP ARP: rcvd req src 155.1.146.1 000c.2947.8992, dst 150.1.6.6 GigabitEthernet1.146
IP ARP: sent rep src 150.1.6.6 000c.29e8.1c2e,
 dst 155.1.146.1 000c.2947.8992 GigabitEthernet1.146

Hur löser vi då detta? En statisk arp-mappning i R1.

R1(config)#arp 150.1.6.6 000c.29e8.1c2e arpa

R1#sh arp static 
Protocol Address Age (min) Hardware Addr Type Interface
Internet 150.1.6.6 - 000c.29e8.1c2e ARPA

R1#ping 150.1.6.6 rep 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 150.1.6.6, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 6/6/6 ms

Output från debug:

IP: s=155.1.146.1 (local), d=150.1.6.6, len 100, local feature
 ICMP type=8, code=0, feature skipped, Auth Proxy(16), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
FIBipv4-packet-proc: route packet from (local) src 155.1.146.1 dst 150.1.6.6
FIBfwd-proc: packet routed by adj to GigabitEthernet1.146 150.1.6.6
FIBipv4-packet-proc: packet routing succeeded
IP: tableid=0, s=155.1.146.1 (local), d=150.1.6.6 (GigabitEthernet1.146), routed via FIB
IP: s=155.1.146.1 (local), d=150.1.6.6 (GigabitEthernet1.146), len 100, sending
 ICMP type=8, code=0
IP: s=150.1.6.6 (GigabitEthernet1.146), d=155.1.146.1, len 100, enqueue feature

Bra exempel på varför man alltid ska ange nexthop för statiska rötter (undantaget p2p-länkar), istället för att routa direkt via FIB måste den även göra ARP-uppslag på dst-adressen.