EIGRP – Prefix filtering

9 juni, 2018 Jonas CollénCCIE

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

BGP – Lab, Configuring a Transit AS/ISP

26 juli, 2013 Jonas CollénBGP

Tänkte göra ett försök att sätta upp Jeremys Transit AS-lab från hans CCIP BGP-serie. Labben är uppbyggd enligt följande:

topology transit lab
scenario transit lab

requirements transit lab 1

requirements transit lab 2

Min lösning

Grundkonfig

!ISP1 Basic conf
inte s0/0
ip add 17.9.1.1 255.255.255.252
no shut
description To R2
clock rate 256000
int s0/1
ip add 17.9.1.5 255.255.255.252
no shut
description To R2
clock rate 256000
int lo0
ip add 11.11.11.11 255.255.255.255
no shut

!ISP2 Basic conf
inte s0/0
ip add 180.1.5.1 255.255.255.252
no shut
description To R1
clock rate 256000
int s0/1
ip add 180.1.5.5 255.255.255.252
no shut
description To R1
clock rate 256000
int lo0
ip add 22.22.22.22 255.255.255.255
no shut

!R1 Basic conf
int s0/0
ip add 17.9.1.2 255.255.255.252
no shut
description To ISP1
int s0/1
ip add 17.9.1.6 255.255.255.252
no shut
description To ISP1
int s0/2
ip add 10.1.1.5 255.255.255.252
no shut
clock rate 256000
description To R2
int s0/3
ip add 10.1.1.1 255.255.255.252
no shut
clock rate 256000
description To R3
int lo0
ip add 1.1.1.1 255.255.255.255

!R2 Basic conf
int s0/0
ip add 180.1.5.2 255.255.255.252
no shut
description To ISP2
int s0/1
ip add 180.1.5.6 255.255.255.252
no shut
description To ISP2
int s0/2
ip add 10.1.1.6 255.255.255.252
no shut
description To R1
int s0/3
ip add 10.1.1.9 255.255.255.252
no shut
clock rate 256000
description To R4
int lo0
ip add 2.2.2.2 255.255.255.255

!R3 Basic conf
int s0/0
ip add 150.1.0.1 255.255.255.252
no shut
description To Cust1
clock rate 256000
int s0/1
ip add 10.1.1.13 255.255.255.252
no shut
clock rate 256000
description To R4
int s0/3
ip add 10.1.1.2 255.255.255.252
no shut
description To R1
int lo0
ip add 3.3.3.3 255.255.255.255

!R4 Basic conf
int s0/0
ip add 10.1.1.10 255.255.255.252
no shut
description To R2
int s0/1
ip add 10.1.1.14 255.255.255.252
no shut
description To R3
int lo0
ip add 4.4.4.4 255.255.255.255
no shut
!Cust1 Basic conf
int s0/0
ip add 150.1.0.2 255.255.255.252
no shut
description To R3
int lo0
ip add 150.1.1.1 255.255.255.0

Configure IGP

Configure network-statements as specific as possible
Only advertise between internal routers
Use a hello-timer of 1 second / dead-timer of 3 seconds

Enligt uppgiften skulle vi använda oss av OSPF. Känns inte som något är nytt här så skriver bara ner den konfig jag skriver. Kom ihåg att vi sätter hello/deadtimers per interface! Glöm inte passive-interface default.

!R1
router ospf 1
passive-interface default
no passive-interface s0/2
no passive-interface s0/3
router-id 1.1.1.1
network 1.1.1.1 0.0.0.0 area 0
network 17.9.1.2 0.0.0.0 area 0
network 17.9.1.6 0.0.0.0 area 0
network 10.1.1.5 0.0.0.0 area 0
network 10.1.1.1 0.0.0.0 area 0
int s0/2
ip ospf hello-interval 1
ip ospf dead-interval 3
int s0/3
ip ospf hello-interval 1
ip ospf dead-interval 3

!R2
router ospf 1
passive-interface default
no passive-interface s0/2
no passive-interface s0/3
router-id 2.2.2.2
network 2.2.2.2 0.0.0.0 area 0
network 180.1.5.2 0.0.0.0 area 0
network 180.1.5.6 0.0.0.0 area 0
network 10.1.1.6 0.0.0.0 area 0
network 10.1.1.9 0.0.0.0 area 0
int s0/2
ip ospf hello-interval 1
ip ospf dead-interval 3
int s0/3
ip ospf hello-interval 1
ip ospf dead-interval 3

!R3
router ospf 1
passive-interface default
no passive-interface s0/3
no passive-interface s0/1
router-id 3.3.3.3
network 3.3.3.3 0.0.0.0 area 0
network 150.1.0.1 0.0.0.0 area 0
network 10.1.1.2 0.0.0.0 area 0
network 10.1.1.13 0.0.0.0 area 0
int s0/1
ip ospf hello-interval 1
ip ospf dead-interval 3
int s0/3
ip ospf hello-interval 1
ip ospf dead-interval 3

!R4
router ospf 1
passive-interface default
no passive-interface s0/0
no passive-interface s0/1
router-id 4.4.4.4
network 4.4.4.4 0.0.0.0 area 0
network 10.1.1.14 0.0.0.0 area 0
network 10.1.1.10 0.0.0.0 area 0
int s0/0
ip ospf hello-interval 1
ip ospf dead-interval 3
int s0/1
ip ospf hello-interval 1
ip ospf dead-interval 3

Kom ihåg att verifiera så att alla nät är nåbara redan nu innan det börjar bli lite mer avancerat. 🙂

Full-mesh IGP

Peers should fail over based on IGP if any internal links fail
Set logical descriptions in BGP
Disable BGP synchronization

Steg 1 har vi redan löst delvis genom att konfigurera Loopbacks på R1-R4 som vi annonserar via OSPF. När vi sätter upp iBGP-relations nu så behöver vi endast använda loopback-adresserna istället för de fysiska länknäten. Kom ihåg att även ändra update-source (om du inte vet varför, se tidigare inlägg om iBGP transit-area)!

Steg 2 fixar vi genom descriptions per neighbor-statement, och BGP synchronization är avslaget per default i den IOS jag använder (v12.4(15)T13) (no synchronization).

!R1 iBGP
router bgp 500
neighbor 2.2.2.2 remote-as 500
neighbor 2.2.2.2 description iBGP to R2
neighbor 2.2.2.2 update-source Lo0
neighbor 3.3.3.3 remote-as 500
neighbor 3.3.3.3 description iBGP to R3
neighbor 3.3.3.3 update-source Lo0
neighbor 4.4.4.4 remote-as 500
neighbor 4.4.4.4 description iBGP to R4
no synchronization

!R2
router bgp 500
neighbor 1.1.1.1 remote-as 500
neighbor 1.1.1.1 description iBGP to R1
neighbor 1.1.1.1 update-source Lo0
neighbor 3.3.3.3 remote-as 500
neighbor 3.3.3.3 description iBGP to R3
neighbor 3.3.3.3 update-source Lo0
neighbor 4.4.4.4 remote-as 500
neighbor 4.4.4.4 description iBGP to R4
neighbor 4.4.4.4 update-source Lo0
no synchronization

!R3
router bgp 500
neighbor 1.1.1.1 remote-as 500
neighbor 1.1.1.1 description iBGP to R1
neighbor 1.1.1.1 update-source Lo0
neighbor 2.2.2.2 remote-as 500
neighbor 2.2.2.2 description iBGP to R2
neighbor 2.2.2.2 update-source Lo0
neighbor 4.4.4.4 remote-as 500
neighbor 4.4.4.4 description iBGP to R4
neighbor 2.2.2.2 update-source Lo0
no synchronization

!R4
router bgp 500
neighbor 1.1.1.1 remote-as 500
neighbor 1.1.1.1 description iBGP to R1
neighbor 1.1.1.1 update-source Lo0
neighbor 2.2.2.2 remote-as 500
neighbor 2.2.2.2 description iBGP to R2
neighbor 2.2.2.2 update-source Lo0
neighbor 3.3.3.3 remote-as 500
neighbor 3.3.3.3 description iBGP to R3
neighbor 3.3.3.3 update-source Lo0
no synchronization

En sh ip bgp summary visar att vi är på rätt spår. 🙂

R1#sh ip bgp summary 
BGP router identifier 1.1.1.1, local AS number 500
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 500 6 7 1 0 0 00:03:47 0
3.3.3.3 4 500 4 5 1 0 0 00:01:55 0
4.4.4.4 4 500 4 4 1 0 0 00:00:12 0

Configure eBGP-peers between NL Fast & ISP1-2 and Customer

On redudant links, peers using loopback and provide loadbalancing
Configure authentication
Set logical descriptions for neighbors

Steg 1 skiljer sig inte jättemycket från vad vi nyss gjorde när vi satte upp iBGP-mesh. Som du förhoppningsvis kommer ihåg tillåter BGP endast en öppen session mot en neighbor, för redundanta länkar bör vi således använda Loopback-interface för att inte vara låsta till någon specifik länk. Kom ihåg att ändra update-source!

Lastbalansering skapar vi enklast via två statiska routes som båda pekar på ISP1/2s loopback-adress och vice-versa.

Autentisering har jag inte skrivit någon post om ännu men det är extremt enkelt att sätta upp i BPG som du kommer se nedan.

!R1 eBGP

ip route 11.11.11.11 255.255.255.255 17.9.1.1
ip route 11.11.11.11 255.255.255.255 17.9.1.5

router bgp 500
neighbor 11.11.11.11 remote-as 200
neighbor 11.11.11.11 description ISP1
neighbor 11.11.11.11 password cisco
neighbor 11.11.11.11 update-source lo0

!ISP1

ip route 1.1.1.1 255.255.255.255 17.9.1.2
ip route 1.1.1.1 255.255.255.255 17.9.1.6

router bgp 200
neighbor 1.1.1.1 remote-as 500
neighbor 1.1.1.1 description ISP1
neighbor 1.1.1.1 password cisco
neighbor 1.1.1.1 update-source Lo0

!R2

ip route 22.22.22.22 255.255.255.255 180.1.5.1
ip route 22.22.22.22 255.255.255.255 180.1.5.5

router bgp 500
neighbor 22.22.22.22 remote-as 300
neighbor 22.22.22.22 description ISP1
neighbor 22.22.22.22 password cisco
neighbor 22.22.22.22 update-source lo0
neighbor 22.22.22.22 ebgp-multihop 2

!ISP2

ip route 2.2.2.2 255.255.255.255 180.1.5.2
ip route 2.2.2.2 255.255.255.255 180.1.5.6

router bgp 300
neighbor 2.2.2.2 remote-as 500
neighbor 2.2.2.2 description ISP1
neighbor 2.2.2.2 password cisco
neighbor 2.2.2.2 update-source Lo0

Här fastande jag dock ett tag, av någon anledning fick jag inte upp någon adjacency? Varken debug ip bgp all eller wireshark gav några hintar om vad felet kunde tänkas vara. En show ip bgp summary visade endast att neighbor x.x.x.x var fast i “idle”. Tillslut kom jag dock på vad det var, gör du? Försök att finna lösningen själv!

facit i vit text (markera för svar): eBGP-multihop! TTL sätts som bekant till 1 för eBGP-relationsships, när vi använder Loopbacks behöver vi därför modifera detta via neighbor x.x.x.x ebgp-multihop 2. Har en tidigare post dedikerad om just detta om detta koncept är nytt för dig och finns att läsa här.

Announce networks in BGP appropriately

ISP1 & 2 should use filtered redistribution to announce their networks. Only networks located on the loopback-interfaces of ISP1&2 should enter the BGP-table
The Cust1-router should advertise its network using the network-statement
R1 & R2 should advertise the WAN-link subnet (currently 150.1.0.0/30) as 150.1.0.0/24

Här är det nog lika bra vi bryter ner det i mindre delar. Vi börjar med filtered redistribution!

Verkar som att det saknades i topologin jeremy skapade, men ISP1 ska tydligen ha mer än det loopback-nätet vi använder för att sätta upp eBGP. Jag skapade därför 5 nät på respektive router:

!R1
int lo1
ip add 200.10.0.1 255.255.255.0
int lo2
ip add 200.10.1.1 255.255.255.0
int lo3
ip add 200.10.2.1 255.255.255.0
int lo4
ip add 200.10.3.1 255.255.255.0
int lo5
ip add 200.10.4.1 255.255.255.0

!R2
int lo1
ip add 200.20.0.1 255.255.255.0
int lo2
ip add 200.20.1.1 255.255.255.0
int lo3
ip add 200.20.2.1 255.255.255.0
int lo4
ip add 200.20.3.1 255.255.255.0
int lo5
ip add 200.20.4.1 255.255.255.0

Vi hade enkelt kunnat lösa detta genom att använda network-statements för Loopback-näten, men i detta fall så önskas filtrering. Finns säkert många olika lösningar på detta men såhär tänkte jag:

Vi skapar först en prefix-lista:

!ISP1
 ip prefix-list LOOPBACKS seq 5 permit 200.10.0.0/24
 ip prefix-list LOOPBACKS seq 10 permit 200.10.1.0/24
 ip prefix-list LOOPBACKS seq 15 permit 200.10.2.0/24
 ip prefix-list LOOPBACKS seq 20 permit 200.10.3.0/24
 ip prefix-list LOOPBACKS seq 25 permit 200.10.4.0/24

 !ISP2
 ip prefix-list LOOPBACKS seq 5 permit 200.20.0.0/24
 ip prefix-list LOOPBACKS seq 10 permit 200.20.1.0/24
 ip prefix-list LOOPBACKS seq 15 permit 200.20.2.0/24
 ip prefix-list LOOPBACKS seq 20 permit 200.20.3.0/24
 ip prefix-list LOOPBACKS seq 25 permit 200.20.4.0/24

Sedan en route-map som endast tillåter nät som matchar vår prefix-lista, passar även på att sätta origin till igp när vi ändå är igång:

!ISP1 & 2
route-map LOOPBACK_FILTER permit 10
match ip address prefix-list LOOPBACKS
set origin igp

Och vi använder sedan route-mapen som filter när vi aktiverar redistribution av nät som är “Connected”:

!ISP1 & 2
router bgp 200 / 300
redistribute connected route-map LOOPBACK_FILTER

Det borde fixa biffen! En debug visar att vi är på rätt spår:

*Mar 1 02:18:30.707: BGP: Applying map to find origin for 200.10.4.0/24
*Mar 1 02:18:30.735: BGP: Applying map to find origin for 200.10.0.0/24
*Mar 1 02:18:30.739: BGP: Applying map to find origin for 200.10.1.0/24
*Mar 1 02:18:30.743: BGP: Applying map to find origin for 200.10.2.0/24
*Mar 1 02:18:30.747: BGP: Applying map to find origin for 200.10.3.0/24

Och en sh ip bgp på R4 visar att allt fungerar som det ska!

Next up var :

The Cust1-router should advertise its network using the network-statement

Denna router har just nu endast grundkonfig så vi får fixa allt grundläggande också! Då vi ej har en redundant lina behöver vi ej “krångla” med loopbacks/ebgp multihop. Observera också att kunden använder ett Privat-AS, vilket kan jämföras med privata ip-adresser, och bör således aldrig annonseras ut till internet(ISP1/2).

!R3
 router bgp 500
 neighbor 150.1.0.2 remote-as 64512
 neighbor 150.1.0.2 description Cust1
 neighbor 150.1.0.2 password cisco

!Cust1 (private AS)
 router bgp 64512
 no synchronization
 network 150.1.1.0 mask 255.255.255.0
 neighbor 150.1.0.1 remote-as 500
 neighbor 150.1.0.1 description NLFastISP
 neighbor 150.1.0.1 password cisco

Ser bra ut! Observera dock att vi just nu skickar med det privata as-numret till ISP:en.

Detta är inget som nämns i CCNP-boken så fick ta och googla lite, skönt nog var det väldigt enkelt att fixa!

!R1
router bgp 500
neighbor 11.11.11.11 remove-private-as

!R2
router bgp 500
neighbor 22.22.22.22 remote-private-as

R1 & R2 should advertise the WAN-link subnet (currently 150.1.0.0/30) as 150.1.0.0/24

Enklast tycker jag borde vara att göra enligt följande:

!R3
ip route 150.1.0.0 255.255.255.0 null0
router bgp 500
network 150.1.0.0 mask 255.255.255.0

Svårare än så behöver det nog inte vara..

Woho!! 🙂

Verify

Verify that all expected neighbors have formed – check!
Verify that all expected routes appear – check!
ISP1 & 2 should be able to ping: Cust1 routes & NL FastISP WAN-link

ISP1#ping 150.1.0.1 source lo0
Success rate is 0 percent (0/5)
ISP1#ping 150.1.1.1 source lo0
Success rate is 0 percent (0/5)

Crap.. 🙂 Let the troubleshooting begin!

En traceroute visar att vi fastnar i R3:

ISP1#traceroute 150.1.0.2
Type escape sequence to abort.
Tracing the route to 150.1.0.2
1 17.9.1.6 36 msec
 17.9.1.2 48 msec
 17.9.1.6 72 msec
 2 10.1.1.2 8 msec 40 msec 124 msec
 3 * * *

Om du varit väldigt uppmärksam på skärmdumparna jag visat under labben här så kanske du redan upptäckt ett stort problem. Om vi kollar en skärmdump från R4 exempelvis:

Endast 150.1.0.0/24 & 150.1.1.0/24 har valts till “best”-route och har därför inte lagt in i routing table! Det är även därför vi inte kan se ISP2’s routes i ISP1’s table.

Problemet är helt enkelt att routrarna EJ har en route för den next-hop adressen som annonseras (förutom R1<->ISP1 och R2<->ISP2 tack vare sina statiska routes)!

Jag löste det enligt följande:

!R1
access-list 1 permit 11.11.11.11 0.0.0.0 
route-map LOOP_REDIST permit 10
match ip address 1
router ospf 1
redistribute static subnets route-map LOOP_REDIST

!R2
access-list 1 permit 22.22.22.22 0.0.0.0 
route-map LOOP_REDIST permit 10
match ip address 1
router ospf 1
redistribute static subnets route-map LOOP_REDIST

Let’s watch the magic happen! 🙂

Och från ISP:

Vackert!

Vi bör dock se till att Customer1 får en default-route, vi vill ju inte hålla på och annonsera våra interna nät dit. Detta löser vi enklast genom följande:

!R3
router bgp 500
#neighbor 150.1.0.2 default-originate

Detta skickar en default-route till Cust1 via BGP! Enkelt. 🙂

Vi kan nu pinga som önskat!

ISP1#ping 150.1.1.1 source lo1
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/63/92 ms

ISP2#ping 150.1.1.1 source lo1
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/83/140 ms

Finally! Ytterligare något man skulle kunna fixa till är att blockera ISP1 från att lära sig ISP2’s routes via vårat AS och vice versa, då detta gör oss till en transit-area även för dem – något vi absolut inte vill! Men klockan börjar bli väldigt sent och jag ska upp tidigt och jobba imorgon så tar och avslutar här. Problemet hade vi hur som enkelt löst genom route-maps, och endast tillåtit de nät vi specificerar att annonseras ut till AS200 & 300.

BGP – Route Redistribution & Filtering

23 juli, 2013 Jonas CollénBGP

bgp AS-path

Här kommer ett enkelt exempel på hur vi utför redistribution & filtrering in till BGP (som egentligen inte skiljer sig något från de övriga protokollen som vi redan labbat med). Låt oss säga att vi vill redistributa näten 200.0.2.0/24 & 200.0.3.0/24 från R5 in till BGP.

Vi skapar först en access-lista (eller prefix-list):

access-list 1 permit 200.0.2.0
access-list 1 permit 200.0.3.0

Sedan en route-map:

route-map FILTER permit 10
match ip address 1

Vi går sedan in under BGP-processen och aktiverar redistribute men filtrerar med hjälp av vår route-map.

router bgp 100
redistribute connected route-map FILTER

Easy peasy.. Vi kan nu se förändringen i exempelvis R7:

R7#sh ip bgp
BGP table version is 15, local router ID is 192.168.0.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
* 5.5.5.0/24 172.16.76.6 0 200 500 100 i
*> 172.16.47.4 0 500 100 i
*> 6.6.6.0/24 172.16.76.6 0 0 200 i
* 172.16.47.4 0 500 200 i
*> 192.168.0.0 0.0.0.0 0 32768 i
* 200.0.2.0 172.16.76.6 0 200 500 100 ?
*> 172.16.47.4 0 500 100 ?
* 200.0.3.0 172.16.76.6 0 200 500 100 ?
*> 172.16.47.4 0 500 100 ?
R7#sh ip route | beg Gat
Gateway of last resort is not set
5.0.0.0/24 is subnetted, 1 subnets
B 5.5.5.0 [20/0] via 172.16.47.4, 00:20:19
 6.0.0.0/24 is subnetted, 1 subnets
B 6.6.6.0 [20/0] via 172.16.76.6, 00:19:48
B 200.0.2.0/24 [20/0] via 172.16.47.4, 00:06:16
 172.16.0.0/24 is subnetted, 2 subnets
C 172.16.47.0 is directly connected, FastEthernet0/0
C 172.16.76.0 is directly connected, FastEthernet0/1
B 200.0.3.0/24 [20/0] via 172.16.47.4, 00:06:16
C 192.168.0.0/24 is directly connected, Loopback0

Road to .. NetDevOps?

Posting nerdy stuff about networking since 2013

Etikett: route filtering