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

 

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.

 

BGP – Advanced BGP Lab, del 3

Fortsättning från tidigare inlägg om GNS3Vaults Advanced BGP-lab som finns att läsa här & här.

Path Modifications

bgp-advanced-lab

  • When R4 sends a ping to the loopback interface of R1 it should choose the path through R2. You are only allowed to make changes on R3.
  • Create another loopback interface on R1 with ip address 172.16.1.1 /24, advertise this in RIP.
  • When R4 sends a ping to the 172.16.1.1 address it should take the path through R3, you are only allowed to make changes on R4.
  • When R6 sends a ping towards the loopback interface on R11 it should go through AS300.
  • R7 should prefer the path through R11 for all external networks except for 172.16.1.1.
  • Configure AS300 so it is no longer a transit AS for AS200 to reach 172.16.1.1 in AS100. AS400 should not be influenced.

Vi har just nu full konvergens och kan pinga samtliga loopbacks i vår topologi.

1. When R4 sends a ping to the loopback interface of R1 it should choose the path through R2. You are only allowed to make changes on R3.

Tar vi en titt på R4 först kan vi se följande:

R4#sh ip bgp
BGP table version is 34, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 1.1.1.0/24 2.2.2.2 0 100 i
*> 3.3.3.3 0 100 i

Den föredrar just nu vägen via R3 för att nå R1s loopback 1.1.1.1. Då vi endast fick ändra konfigurationen på R3 för att styra om trafiken behöver vi använda oss av något Path Attribute. Varken Weight eller Local Preference kan ju hjälpa oss i detta fall då R4 ligger i ett eget AS. MED eller AS-Path Prepending däremot!

R3(config)#ip prefix-list R1-Loopback permit 1.1.1.0/24
R3(config)#route-map R1-Loopback-MED permit 10
R3(config-route-map)#match ip add prefix-list R1-Loopback
R3(config-route-map)#set as-path prepend 100 100
R3(config-route-map)#route-map R1-Loopback-MED permit 20
R3(config-route-map)#exit
R3(config)#router bgp 100
R3(config-router)#neighbor 4.4.4.4 route-map R1-Loopback-MED out

R4#sh ip bgp 1.1.1.0/24
BGP routing table entry for 1.1.1.0/24, version 35
Paths: (2 available, best #2, table Default-IP-Routing-Table)
 Advertised to update-groups:
 1 2
 100 100 100
 3.3.3.3 from 3.3.3.3 (3.3.3.3)
 Origin IGP, localpref 100, valid, external
 100
 2.2.2.2 from 2.2.2.2 (2.2.2.2)
 Origin IGP, localpref 100, valid, external, best

2Create another loopback interface on R1 with ip address 172.16.1.1 /24, advertise this in RIP. When R4 sends a ping to the 172.16.1.1 address it should take the path through R3, you are only allowed to make changes on R4.

R1(config)#int lo1
R1(config-if)#ip add 172.16.1.1 255.255.255.0
R1(config)#router rip
R1(config-router)#network 172.16.1.0

R4#sh ip bgp 172.16.1.0
BGP routing table entry for 172.16.1.0/24, version 38
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x820
 Advertised to update-groups:
 1 2
 100
 3.3.3.3 from 3.3.3.3 (3.3.3.3)
 Origin IGP, localpref 100, valid, external
 100
 2.2.2.2 from 2.2.2.2 (2.2.2.2)
 Origin IGP, localpref 100, valid, external, best

I detta fall behöver vi endast ändra BGP lokalt, och bör således använda oss av “Weight”.

R4(config)#ip prefix-list R1-Loopback2 permit 172.16.1.0/24
R4(config)#route-map R1-Loopback2-Weight permit 10
R4(config-route-map)#match ip add prefix-list R1-Loopback2
R4(config-route-map)#set weight 10
R4(config-route-map)#route-map R1-Loopback2-Weight permit 20
R4(config-route-map)#exit
R4(config)#router bgp 10
R4(config-router)#neighbor 3.3.3.3 route-map R1-Loopback2-Weight in

R4#sh ip bgp 172.16.1.0
BGP routing table entry for 172.16.1.0/24, version 39
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
 Advertised to update-groups:
 1 2
 100
 3.3.3.3 from 3.3.3.3 (3.3.3.3)
 Origin IGP, localpref 100, weight 10, valid, external, best
 100
 2.2.2.2 from 2.2.2.2 (2.2.2.2)
 Origin IGP, localpref 100, valid, external

3. When R6 sends a ping towards the loopback interface on R11 it should go through AS300.

Just nu tar R6 vägen via R7->R11.

R6#traceroute 11.11.11.11
Type escape sequence to abort.
Tracing the route to 11.11.11.11
1 192.168.67.7 24 msec 28 msec 68 msec
 2 192.168.117.11 56 msec 72 msec *

Känns som vi kan använda oss av Weight här med då local preference även hade annonserats till R7.

R6(config)#ip prefix-list R11-Loopback permit 11.11.11.0/24
R6(config)#route-map R11-Loopback-Weight permit 10
R6(config-route-map)#match ip add prefix-list R11-Loopback
R6(config-route-map)#set weight 10
R6(config-route-map)#route-map R11-Loopback-Weight permit 20
R6(config-route-map)#exit
R6(config-router)#neighbor 5.5.5.5 route-map R11-Loopback-Weight in

R6#sh ip bgp 11.11.11.0/24
BGP routing table entry for 11.11.11.0/24, version 1007
Paths: (3 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
 Advertised to update-groups:
 1 2
 300 400
 5.5.5.5 from 5.5.5.5 (5.5.5.5)
 Origin IGP, localpref 100, weight 10, valid, external, best
 400
 7.7.7.7 (metric 156160) from 7.7.7.7 (7.7.7.7)
 Origin IGP, metric 0, localpref 100, valid, internal
 300 400
 4.4.4.4 from 4.4.4.4 (4.4.4.4)
 Origin IGP, localpref 100, valid, external

4. R7 should prefer the path through R11 for all external networks except for 172.16.1.1.

Vi kan använda oss av Weight här med men själva tillvägagångssättet blir lite annorlunda nu när vi vill matcha allt utom just 172.16.1.0/24-nätet.

R7(config)#ip prefix-list R1-Loopback-R11 permit 172.16.1.0/24
R7(config)#route-map RM-Redirect-to-R11 permit 10
R7(config-route-map)#match ip address prefix-list R1-Loopback-R11
R7(config-route-map)#route-map RM-Redirect-to-R11 permit 20
R7(config-route-map)#set weight 20
R7(config-route-map)#exit
R7(config)#router bgp 200
R7(config-router)#neighbor 11.11.11.11 route-map RM-Redirect-to-R11 in

Vi sätter helt enkelt weight för alla nät som inte matchas i vår första sequence, dvs allt utom 172.16.1.0/24.

Jämför vi 172.16.1.0/24 med 1.1.1.0/24 kan vi se följande:

R7#sh ip bgp 172.16.1.0
BGP routing table entry for 172.16.1.0/24, version 12
Paths: (2 available, best #2, table Default-IP-Routing-Table)
 Advertised to update-groups:
 1
 400 300 100
 11.11.11.11 from 11.11.11.11 (11.11.11.11)
 Origin IGP, localpref 100, valid, external
 300 100
 6.6.6.6 (metric 156160) from 6.6.6.6 (6.6.6.6)
 Origin IGP, metric 0, localpref 100, valid, internal, best

R7#sh ip bgp 1.1.1.0/24
BGP routing table entry for 1.1.1.0/24, version 43
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
 Advertised to update-groups:
 2
 400 300 100
 11.11.11.11 from 11.11.11.11 (11.11.11.11)
 Origin IGP, localpref 100, weight 20, valid, external, best
 300 100
 6.6.6.6 (metric 156160) from 6.6.6.6 (6.6.6.6)
 Origin IGP, metric 0, localpref 100, valid, internal

5. Configure AS300 so it is no longer a transit AS for AS200 to reach 172.16.1.1 in AS100. AS400 should not be influenced.

Här behöver vi istället filtrera bort routing-uppdateringar för 172.16.1.0/24 i R4 & R5 mot R6. Då vi redan har en prefix-lista konfad på R4 som matchar 172.16.1.0/24-nätet återanvänder vi den istället.

R4(config)#do sh ip prefix-list
ip prefix-list R1-Loopback2: 1 entries
 seq 5 permit 172.16.1.0/24
R4(config)#route-map AS200 deny 10
R4(config-route-map)#match ip add prefix-list R1-Loopback2
R4(config-route-map)#route-map AS200 permit 20
R4(config-route-map)#exit
R4(config)#router bgp 10
R4(config-router)#neighbor 6.6.6.6 route-map AS200 out

Jag blir dock osäker på hur vi ska blockera AS200 från att lära sig om nätet via As400 istället (utan att lägga in specifik filtrering där också)?

R6#sh ip bgp 172.16.1.0/24
BGP routing table entry for 172.16.1.0/24, version 1015
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
 Advertised to update-groups:
 2
 400 300 100
 7.7.7.7 (metric 156160) from 7.7.7.7 (7.7.7.7)
 Origin IGP, metric 0, localpref 100, valid, internal, best

Som synes tar den nu istället vägen via R7 -> AS400 R11  -> R10-> AS300 R9..  Jag skulle vilja säga att vi ej har någon möjlighet att påverka vad ett annat AS  i sin tur gör med näten vi annonserar till  dem. För att lösa labben hade jag lagt in samma filter på R11 mot R7 också.

Då var vi tillslut klara med den avancerade labben, gick trots allt väldigt smärtfritt skönt nog. 🙂 MDH har släppt slutprojektet i CCNP-kursen nu så eventuella inlägg närmaste tiden kommer troligtvis handla om det.

BGP – Advanced BGP Lab, del 2

EBGP & Redistribution

  • Configure EBGP between AS-peers
  • Configure BGP authentication between R7 and R11, use password VAULT
  • Make sure all BGP neighbor relationships are working before you continue with the next steps.
  • Advertise all physical and loopback interfaces in BGP, you are not allowed to use the “network” command to achieve this.
  • Achieve full connectivity, every IP address should be pingable. Use a TCLSH script to do this.

Detta blir en fortsättning på gårdagens lab som finns att läsa här. Kom ihåg att varje BGP Speaker kräver en specifik route till respektive neighbor, en default-route räcker ej. Då vi endast annonserar Loopbacks inom IGPs/AS (förutom sub-AS10 & 20/confederation) behöver vi även sätta upp statiska routes. Glöm inte heller ebgp-multihop den här gången… 🙂

EBGP

R2

router bgp 100
 neighbor 4.4.4.4 remote-as 300
 neighbor 4.4.4.4 ebgp-multihop 255
 neighbor 4.4.4.4 update-source Loopback0
ip route 4.4.4.0 255.255.255.0 192.168.24.4

R3

router bgp 100
 neighbor 4.4.4.4 remote-as 300
 neighbor 4.4.4.4 ebgp-multihop 255
 neighbor 4.4.4.4 update-source Loopback0
ip route 4.4.4.0 255.255.255.0 192.168.34.4

R4

router bgp 10
 neighbor 2.2.2.2 remote-as 100
 neighbor 2.2.2.2 ebgp-multihop 255
 neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 ebgp-multihop 255
 neighbor 3.3.3.3 update-source Loopback0
neighbor 6.6.6.6 remote-as 200
 neighbor 6.6.6.6 ebgp-multihop 2
 neighbor 6.6.6.6 update-source Loopback0
ip route 2.2.2.0 255.255.255.0 192.168.24.2
ip route 3.3.3.0 255.255.255.0 192.168.34.3
ip route 6.6.6.0 255.255.255.0 192.168.46.6

R5

router bgp 10
 neighbor 6.6.6.6 remote-as 200
 neighbor 6.6.6.6 ebgp-multihop 2
 neighbor 6.6.6.6 update-source Loopback0
ip route 6.6.6.0 255.255.255.0 192.168.56.6

EBGP-förhållandet mellan confederation-AS #10 & #20 konfigurerade vi upp i gårdagens inlägg här.

R6

router bgp 200
 neighbor 4.4.4.4 remote-as 300
 neighbor 4.4.4.4 ebgp-multihop 2
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 5.5.5.5 remote-as 300
 neighbor 5.5.5.5 ebgp-multihop 2
 neighbor 5.5.5.5 update-source Loopback0
ip route 4.4.4.0 255.255.255.0 192.168.46.4
 ip route 5.5.5.0 255.255.255.0 192.168.56.5

R7

router bgp 200
 neighbor 11.11.11.11 remote-as 400
 neighbor 11.11.11.11 ebgp-multihop 2
 neighbor 11.11.11.11 update-source Loopback0
ip route 11.11.11.0 255.255.255.0 192.168.117.11

R9

router bgp 20
 neighbor 10.10.10.10 remote-as 400
 neighbor 10.10.10.10 ebgp-multihop 2
 neighbor 10.10.10.10 update-source Loopback0
ip route 10.10.10.0 255.255.255.0 192.168.109.10

R10

router bgp 400
 neighbor 9.9.9.9 remote-as 300
 neighbor 9.9.9.9 ebgp-multihop 2
 neighbor 9.9.9.9 update-source Loopback0
ip route 9.9.9.0 255.255.255.0 192.168.109.9

R11

router bgp 400
 neighbor 7.7.7.7 remote-as 200
 neighbor 7.7.7.7 ebgp-multihop 2
 neighbor 7.7.7.7 update-source Loopback0
ip route 7.7.7.0 255.255.255.0 192.168.117.7

Authentication

Enligt labben behöver vi sätta upp autentisering mellan R7 – R11 med lösenordet “VAULT”.

R7 
 router bgp 200
 neighbor 11.11.11.11 password VAULT

R11
 router bgp 400
 neighbor 7.7.7.7 password VAULT

Redistribution

Nästa steg är att annonsera alla fysiska interface (inkl. loopbacks) in i BGP, vi får ej använda “network”. Enklast bör väl vara att köra redistribute på connected, route-map:en är bara för att göra det lite snyggare och sätta origin till IGP istället för “unknown”.

route-map REDIST_C permit 10
 set origin igp

router bgp x
 redistribute connected route-map REDIST_C

La in ovanstående på samtliga routrar i topologin. Vilket gav följande i R1:

R1#sh ip bgp
 BGP table version is 10, local router ID is 1.1.1.1
 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
 Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
 *> 1.1.1.0/24 0.0.0.0 0 32768 i
 r>i2.2.2.0/24 2.2.2.2 0 100 0 i
 r>i3.3.3.0/24 3.3.3.3 0 100 0 i
 * i4.4.4.0/24 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i5.5.5.0/24 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i6.6.6.0/24 4.4.4.4 0 100 0 300 200 i
 * i 4.4.4.4 0 100 0 300 200 i
 * i7.7.7.0/24 4.4.4.4 0 100 0 300 200 i
 * i 4.4.4.4 0 100 0 300 200 i
 * i8.8.8.0/24 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i9.9.9.0/24 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.12.0 2.2.2.2 0 100 0 i
 *> 0.0.0.0 0 32768 i
 * i192.168.13.0 3.3.3.3 0 100 0 i
 *> 0.0.0.0 0 32768 i
 *>i192.168.24.0 2.2.2.2 0 100 0 i
 *>i192.168.34.0 3.3.3.3 0 100 0 i
 * i192.168.45.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.46.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.56.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.58.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.67.0 4.4.4.4 0 100 0 300 200 i
 * i 4.4.4.4 0 100 0 300 200 i
 * i192.168.89.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.109.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.117.0 4.4.4.4 0 100 0 300 200 i
 * i 4.4.4.4 0 100 0 300 200 i

Som synes är det endast näten inom AS100 den lägger till i routing-tabellen.. Anledningen till detta är rätt enkel, R1 har ingen route till 4.4.4.4 (next-hop). Enklaste lösningen är väl att konfigurera next-hop-self på våra border-routers istället.

R2

router bgp 100
 neighbor 1.1.1.1 next-hop-self

R3

router bgp 100
 neighbor 1.1.1.1 next-hop-self

Och så vidare, behöver göra detta på varje border-router vars neighbor saknar egna routes för loopbacks i andra AS.

TCL Verifiering

tclsh
foreach address {
1.1.1.1
2.2.2.2
3.3.3.3
4.4.4.4
5.5.5.5
6.6.6.6
7.7.7.7
8.8.8.8
9.9.9.9
10.10.10.10
11.11.11.11
} { ping $address repeat 1 }

R1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 4/4/4 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 128/128/128 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 56/56/56 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 120/120/120 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 140/140/140 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 144/144/144 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 192/192/192 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 144/144/144 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 9.9.9.9, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 216/216/216 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 252/252/252 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 324/324/324 ms

R5

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 212/212/212 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 104/104/104 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 132/132/132 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 60/60/60 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 44/44/44 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 100/100/100 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 32/32/32 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 9.9.9.9, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 100/100/100 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 100/100/100 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 184/184/184 ms

R11

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 308/308/308 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 216/216/216 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 216/216/216 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 280/280/280 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 148/148/148 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 68/68/68 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 36/36/36 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 152/152/152 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 9.9.9.9, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 80/80/80 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 56/56/56 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms

Vackert! Nu är det bara den roliga biten kvar med “path modifications” men det får allt vänta till nästa vecka då det är party ikväll. 🙂

BGP – Advanced BGP Lab, del 1

Var ett tag sedan jag konfigurerade något nu så fick lite abstinens… 😉 Tänkte göra ett försök på Renée’s “Advanced BGP-Lab” ikväll från www.gns3vault.com.

Topologin ser ut enligt följande:

bgp-advanced-lab

R1 – R2: 192.168.12.X / R1 – R3: 192.168.13.X / R3 – R4: 192.168.34.X (where X = Router number) etc..

Every router has a Loopback0 interface: X.X.X.X (where X = Router number)

  • Configure each Autonomous System (AS) with a different IGP:
    AS100: RIP
    AS300: OSPF
    AS200: EIGRP
    AS400: OSPF
  • Do not configure the IGP on the interfaces connecting to another AS. For example; R3 should not send any RIP routing updates towards R4.
  • Make sure the loopbacks are advertised in the IGP’s.
  • Configure BGP on every router, make sure you have the right IBGP and EBGP configurations. AS300 has to be configured as a confederation.
  • R1 has to be configured as a route-reflector for R2 and R3.
  • Configure on all routers that BGP updates are sourced from the Loopback0 interface.
  • Configure BGP authentication between R7 and R11, use password VAULT
  • Make sure all BGP neighbor relationships are working before you continue with the next steps.
  • Advertise all physical and loopback interfaces in BGP, you are not allowed to use the “network” command to achieve this.
  • Achieve full connectivity, every IP address should be pingable. Use a TCLSH script to do this.
  • When R4 sends a ping to the loopback interface of R1 it should choose the path through R2. You are only allowed to make changes on R3.
  • Create another loopback interface on R1 with ip address 172.16.1.1 /24, advertise this in RIP.
  • When R4 sends a ping to the 172.16.1.1 address it should take the path through R3, you are only allowed to make changes on R4.
  • When R6 sends a ping towards the loopback interface on R11 it should go through AS300.
  • R7 should prefer the path through R11 for all external networks except for 172.16.1.1.
  • Configure AS300 so it is no longer a transit AS for AS200 to reach 172.16.1.1 in AS100. AS400 should not be influenced.

Får se hur långt vi hinner idag, kommer troligtvis att bli (minst) två inlägg istället. Men låt oss börja med basics, sätta upp IGPs inom respektive AS.

IGP Routing

  • Configure each Autonomous System (AS) with a different IGP:
    AS100: RIP
    AS300: OSPF
    AS200: EIGRP
    AS400: OSPF
  • Do not configure the IGP on the interfaces connecting to another AS. For example; R3 should not send any RIP routing updates towards R4.
  • Make sure the loopbacks are advertised in the IGP’s.

Finns inte direkt något speciellt att tänka på här. Använd passive-interface default enligt best practice och kom ihåg att annonsera Loopback för respektive router.

RIP / AS100

R1
router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet1/0
 network 1.0.0.0
 network 192.168.12.0
 network 192.168.13.0
 no auto-summary

R2
 router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 network 2.0.0.0
 network 192.168.12.0
 no auto-summary

R3
 router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 network 3.0.0.0
 network 192.168.13.0
 no auto-summary

OSPF / AS300

R4
 router ospf 300
 router-id 4.4.4.4
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet2/0
 network 4.4.4.0 0.0.0.255 area 0
 network 192.168.45.0 0.0.0.255 area 0

interface Loopback0
 ip ospf network point-to-point

 R5
router ospf 300
 router-id 5.5.5.5
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet1/0
 network 5.5.5.0 0.0.0.255 area 0
 network 192.168.45.0 0.0.0.255 area 0
 network 192.168.58.0 0.0.0.255 area 0

 interface Loopback0
 ip ospf network point-to-point

 R8
 router ospf 300
 router-id 8.8.8.8
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet1/0
 network 8.8.8.0 0.0.0.255 area 0
 network 192.168.58.0 0.0.0.255 area 0
 network 192.168.89.0 0.0.0.255 area 0

 interface Loopback0
 ip ospf network point-to-point

R9
 router ospf 300
 router-id 9.9.9.9
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet1/0
 network 9.9.9.0 0.0.0.255 area 0
 network 192.168.89.0 0.0.0.255 area 0

interface Loopback0
 ip ospf network point-to-point

Anledningen till att jag lagt till “ospf network point-to-point” är för att OSPF per default annars sätter network-type till stub för Loopbacks och endast annonserar våra nät som en /32.

EIGRP / AS200

R6
 router eigrp 200
 passive-interface default
 no passive-interface FastEthernet0/0
 network 7.7.7.0 0.0.0.255
 network 192.168.67.0
 no auto-summary

R7
 router eigrp 200
 passive-interface default
 no passive-interface FastEthernet1/0
 network 6.6.6.0 0.0.0.255
 network 192.168.67.0
 no auto-summary

OSPF / AS400

R10
router ospf 400
 router-id 10.10.10.10
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 network 10.10.10.0 0.0.0.255 area 0
 network 192.168.110.0 0.0.0.255 area 0

interface Loopback0
 ip ospf network point-to-point

R11
router ospf 400
 router-id 11.11.11.11
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet1/0
 network 11.11.11.0 0.0.0.255 area 0
 network 192.168.110.0 0.0.0.255 area 0

interface Loopback0
 ip ospf network point-to-point

BGP

IBGP & Route-reflector

  • Configure BGP on every router
  • Configure on all routers that BGP updates are sourced from the Loopback0 interface.
  • R1 has to be configured as a route-reflector for R2 and R3.

Allt är relativt standard, kom ihåg att ändra update-source när vi använder Loopback-adresser för peering.

R1 – Kom ihåg route-reflector mot R2 & R3!

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 100
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 route-reflector-client
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 3.3.3.3 route-reflector-client
 no auto-summary

R2

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-source Loopback0
 no auto-summary

R3

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-source Loopback0
 no auto-summary

Blir lite tjatigt att ta med i princip identisk konfig för R6, R7, R10 & R11 så hoppar över det.

R4, R5, R8 & R9 tar vi nästa punkt då det ska konfigureras confederations istället.

Confederations

  • AS300 has to be configured as a confederation.

Vi tar och börjar med att sätta upp två confederations inom AS300, Sub-AS 10 & 20. Om du vill läsa mer om confederations har jag ett gammalt inlägg som går igenom detta relativt grundligt här.  Vanligtvis använder man privata AS-nummer för detta men tar och följer labben slaviskt nu.. 🙂

R4

router bgp 10
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 300
 bgp confederation peers 20
 neighbor 5.5.5.5 remote-as 10
 neighbor 5.5.5.5 update-source Loopback0
 no auto-summary

R5

router bgp 10
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 300
 bgp confederation peers 20
 neighbor 4.4.4.4 remote-as 10
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 8.8.8.8 remote-as 20
 neighbor 8.8.8.8 update-source Loopback0
 no auto-summary

R8

router bgp 20
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 300
 bgp confederation peers 10
 neighbor 5.5.5.5 remote-as 10
 neighbor 5.5.5.5 update-source Loopback0
 neighbor 9.9.9.9 remote-as 20
 neighbor 9.9.9.9 update-source Loopback0
 no auto-summary

R9

router bgp 20
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 300
 bgp confederation peers 10
 neighbor 8.8.8.8 remote-as 20
 neighbor 8.8.8.8 update-source Loopback0
 no auto-summary

Det var all konfig.. Men tyvärr fungerade det inte riktigt som önskat. IBGP kom upp utan problem men av någon anledning får jag ej upp någon neighbor mellan R5 <-> R8.

R5#sh ip bgp
 *Mar 1 06:30:59.486: %SYS-5-CONFIG_I: Configured from console by consolesummary
 BGP router identifier 5.5.5.5, local AS number 10
 BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
 4.4.4.4 4 10 27 27 1 0 0 00:23:08 0
 8.8.8.8 4 20 0 0 0 0 0 never Idle

En debug ip bgp events gav inte heller någon vettig information. Tillslut kom jag äntligen på vad felet var: ebgp-multihop! TTL för EBGP är ju per default satt till 1, så när paketet när R5/R8 kastas paketet istället för att vidarebefordras till Loopback. Detta var inte direkt första gången jag åkt dit på den grejjen.. 🙂

R5
 neighbor 8.8.8.8 ebgp-multihop 2
 R8
 neighbor 5.5.5.5 ebgp-multihop 2

Nu ser det bättre ut!

R8#sh ip bgp summary
 BGP router identifier 8.8.8.8, local AS number 20
 BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
 5.5.5.5 4 10 4 4 1 0 0 00:00:29 0
 9.9.9.9 4 20 15 15 1 0 0 00:11:38 0

Detta får räcka för idag, känns som inlägget blir lite väl långt annars. Fortsättning följer!