OSPF – Path Selection with Non-Backbone Transit Areas

Pretty much done with EIGRP labs for now and started with OSPF instead where I found a really interesting lab regarding using non-backbone areas as transit. The traffic really didn’t behave the way I “thought” it should based on what i’ve read earlier, the lab looked like this:

Requirements

  • Disable the link between R3 & R7 and make sure traffic in area 2 still can reach the rest of the network
  • Modify SPF calculations so that R4 can’t be used for transit traffic in area 1 to area 0, don’t use cost
  • Traffic from R9 should route via R1 to reach R8

By disabling the link between R3 – R7 traffic in area 2 will be separated from the rest of the network as traffic isn’t allowed to pass via another non-backbone area. We can verify this in R7 as it shouldn’t consider R6 an ABR.

R7#sh ip ospf border-routers

OSPF Router with ID (150.1.7.7) (Process ID 1)

Base Topology (MTID 0)

Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route

Checking the OSPF database we still see R3’s LSAs until they age out, but no summary-routes (LSA Type 3) are advertised from R6.

R7#sh ip ospf database

OSPF Router with ID (150.1.7.7) (Process ID 1)

Router Link States (Area 2)

Link ID ADV Router Age Seq# Checksum Link count
150.1.3.3 150.1.3.3 262 0x80000002 0x002840 1
150.1.6.6 150.1.6.6 182 0x80000003 0x0073AA 1
150.1.7.7 150.1.7.7 181 0x80000005 0x00DD03 5
150.1.9.9 150.1.9.9 254 0x80000002 0x008AF8 3

Net Link States (Area 2)

Link ID ADV Router Age Seq# Checksum
155.1.67.6 150.1.6.6 182 0x80000001 0x00C5A1
155.1.79.9 150.1.9.9 255 0x80000001 0x003517

Summary Net Link States (Area 2)

Link ID ADV Router Age Seq# Checksum
150.1.1.1 150.1.3.3 269 0x80000001 0x00B973
150.1.2.2 150.1.3.3 269 0x80000001 0x00A486
150.1.3.3 150.1.3.3 319 0x80000001 0x0028D8
150.1.4.4 150.1.3.3 269 0x80000001 0x0051C0
150.1.5.5 150.1.3.3 279 0x80000001 0x0032DE
150.1.6.6 150.1.3.3 253 0x80000002 0x002FDC
150.1.8.8 150.1.3.3 248 0x80000001 0x00FC0D
150.1.10.10 150.1.3.3 244 0x80000001 0x00DC28
155.1.0.1 150.1.3.3 269 0x80000001 0x0079B0
155.1.0.2 150.1.3.3 269 0x80000001 0x006FB9
155.1.0.3 150.1.3.3 309 0x80000001 0x00FD02
155.1.0.4 150.1.3.3 269 0x80000001 0x0032DF
155.1.0.5 150.1.3.3 279 0x80000001 0x001EF3
155.1.5.0 150.1.3.3 279 0x80000001 0x0023ED
155.1.8.0 150.1.3.3 248 0x80000001 0x000C01
155.1.10.0 150.1.3.3 244 0x80000001 0x00FF0A
155.1.13.0 150.1.3.3 319 0x80000001 0x00965E
155.1.23.0 150.1.3.3 319 0x80000001 0x0028C2
155.1.45.0 150.1.3.3 279 0x80000001 0x00697F
155.1.58.0 150.1.3.3 279 0x80000001 0x00D902
155.1.108.0 150.1.3.3 248 0x80000001 0x00BBEC
155.1.146.0 150.1.3.3 269 0x80000001 0x00186A

We solve this by setting up a virtual link between R6 & R1, remember we’re not supposed to send area 2’s traffic to R4.

! R6

router ospf 1
 area 1 virtual-link 150.1.1.1

! R1

router ospf 1
 area 1 virtual-link 150.1.6.6

R6 will now have a virtual connection to area 0 and can now act as an ABR to area 2.

R6#sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
150.1.1.1 0 FULL/ - - 155.1.146.1 OSPF_VL0
150.1.1.1 1 FULL/DROTHER 00:00:35 155.1.146.1 GigabitEthernet1.146
150.1.4.4 1 FULL/BDR 00:00:37 155.1.146.4 GigabitEthernet1.146
150.1.7.7 1 FULL/BDR 00:00:31 155.1.67.7 GigabitEthernet1.67

R6#sh ip ospf interface 
OSPF_VL0 is up, line protocol is up 
Internet Address 155.1.146.6/24, Area 0, Attached via Not Attached
Process ID 1, Router ID 150.1.6.6, Network Type VIRTUAL_LINK, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Configured as demand circuit
Run as demand circuit
DoNotAge LSA allowed
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:08
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Can not be protected by per-prefix Loop-Free FastReroute
Can not be used for per-prefix Loop-Free FastReroute repair paths
Index 1/1/4, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1 
Adjacent with neighbor 150.1.1.1 (Hello suppressed)
Suppress hello for 1 neighbor(s)
R6#sh ip ospf database self-originate

OSPF Router with ID (150.1.6.6) (Process ID 1)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count
150.1.6.6 150.1.6.6 739 0x80000003 0x00F126 1

Summary Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum
150.1.6.6 150.1.6.6 739 0x80000002 0x00BF34
150.1.7.7 150.1.6.6 739 0x80000002 0x00B43C
150.1.9.9 150.1.6.6 739 0x80000002 0x009457
155.1.7.0 150.1.6.6 739 0x80000002 0x00B939
155.1.9.0 150.1.6.6 739 0x80000002 0x00AD42
155.1.37.0 150.1.6.6 739 0x80000002 0x006E66
155.1.67.0 150.1.6.6 739 0x80000002 0x00199E
155.1.79.0 150.1.6.6 739 0x80000002 0x009E0C
155.1.146.0 150.1.6.6 739 0x80000002 0x00B0B7

R7 now see’s R6 as an ABR which in turn will send summary-LSAs for the rest of the network.

R7#sh ip ospf border-routers

OSPF Router with ID (150.1.7.7) (Process ID 1)

Base Topology (MTID 0)

Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route

i 150.1.6.6 [1] via 155.1.67.6, GigabitEthernet1.67, ABR, Area 2, SPF 6

R7#sh ip ospf database | beg Summary
Summary Net Link States (Area 2)

Link ID ADV Router Age Seq# Checksum
150.1.1.1 150.1.3.3 814 0x80000001 0x00B973
150.1.1.1 150.1.6.6 311 0x80000001 0x0035C8
150.1.2.2 150.1.3.3 814 0x80000001 0x00A486
150.1.2.2 150.1.6.6 306 0x80000002 0x005CB1
150.1.3.3 150.1.3.3 864 0x80000001 0x0028D8
150.1.3.3 150.1.6.6 306 0x80000002 0x0047C4
150.1.4.4 150.1.3.3 814 0x80000001 0x0051C0
150.1.4.4 150.1.6.6 306 0x80000002 0x00F303
150.1.5.5 150.1.3.3 824 0x80000001 0x0032D
....

R7#sh ip route 150.1.8.8
Routing entry for 150.1.8.8/32
Known via "ospf 1", distance 110, metric 5, type inter area
Last update from 155.1.67.6 on GigabitEthernet1.67, 00:06:17 ago
Routing Descriptor Blocks:
* 155.1.67.6, from 150.1.6.6, 00:06:17 ago, via GigabitEthernet1.67
Route metric is 5, traffic share count is 1

Even if we enable R3’s link to R7 now the traffic will still prefer the route via R6 as it has a lower metric to R8, indifferent to the fact that a virtual-link is needed to traverse that area.

R7#sh ip ospf database summary 150.1.8.8

OSPF Router with ID (150.1.7.7) (Process ID 1)

Summary Net Link States (Area 2)

LS age: 976
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 150.1.8.8 (summary Network Number)
Advertising Router: 150.1.3.3
LS Seq Number: 80000001
Checksum: 0xFC0D
Length: 28
Network Mask: /32
MTID: 0 Metric: 1002

LS age: 493
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 150.1.8.8 (summary Network Number)
Advertising Router: 150.1.6.6
LS Seq Number: 80000001
Checksum: 0xB538
Length: 28
Network Mask: /32
MTID: 0 Metric: 4

By checking the metric you may already have realized how the traffic is currently flowing to R8 which was a surprise to myself. By setting up a virtual-link between R6 & R1 I thought that the transit traffic from area 2 would also route that way. But no, not at all!

R7#traceroute 150.1.8.8 numeric 
Type escape sequence to abort.
Tracing the route to 150.1.8.8
VRF info: (vrf in name/id, vrf out name/id)
1 155.1.67.6 7 msec 3 msec 4 msec
2 155.1.146.4 5 msec 5 msec 5 msec
3 155.1.45.5 6 msec 6 msec 6 msec
4 155.1.58.8 6 msec * 6 msec

How come? Let’s dive in to R6’s database.

R6#sh ip ospf database summary 150.1.8.8

OSPF Router with ID (150.1.6.6) (Process ID 1)

Summary Net Link States (Area 0)

LS age: 484 (DoNotAge)
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 150.1.8.8 (summary Network Number)
Advertising Router: 150.1.5.5
LS Seq Number: 80000001
Checksum: 0xAE43
Length: 28
Network Mask: /32
MTID: 0 Metric: 2

So R5 is the ABR originating the summary-LSA with a metric of 2, so what is R6’s preferred path to R5?

R6# sh ip ospf database router 150.1.5.5

OSPF Router with ID (150.1.6.6) (Process ID 1)

Router Link States (Area 0)

LS age: 501 (DoNotAge)
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 150.1.5.5
Advertising Router: 150.1.5.5
LS Seq Number: 80000004
Checksum: 0x56B2
Length: 108
Area Border Router
Number of Links: 7

Link connected to: a Stub Network
(Link ID) Network/subnet number: 150.1.5.5
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1

Link connected to: a Transit Network
(Link ID) Designated Router address: 155.1.45.5
(Link Data) Router Interface address: 155.1.45.5
Number of MTID metrics: 0
TOS 0 Metrics: 1

 Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 150.1.4.4
(Link Data) Router Interface address: 155.1.0.5
Number of MTID metrics: 0
TOS 0 Metrics: 1000

Traffic is going directly from R6 to R4 even though that it isn’t R6s virtual-link to area 0! This functionality is further explained in RFC 2328 section 16.3, examining transit area’s summary-LSAs.

16.3.  Examining transit areas' summary-LSAs

        This step is only performed by area border routers attached to
        one or more non-backbone areas that are capable of carrying
        transit traffic (i.e., "transit areas", or those areas whose
        TransitCapability parameter has been set to TRUE in Step 2 of
        the Dijkstra algorithm (see Section 16.1).

        The purpose of the calculation below is to examine the transit
        areas to see whether they provide any better (shorter) paths
        than the paths previously calculated in Sections 16.1 and 16.2.
        Any paths found that are better than or equal to previously
        discovered paths are installed in the routing table.

Apparently the parameter TransitCapability is on by default in all cisco-routers, which results in R6 preferring the route via R4 as it has lower metric even though the route is passing a non-backbone area. This functionality can be disabled however and that is also how we solve the labs requirement that traffic has to pass via R1.

! R6

router ospf 1
no capability transit

R6’s metric to R8 is updated to reflect the new path via R1:

R6#sh ip route 150.1.8.8
Routing entry for 150.1.8.8/32
Known via "ospf 1", distance 110, metric 1003, type inter area
Last update from 155.1.146.1 on GigabitEthernet1.146, 00:00:25 ago
Routing Descriptor Blocks:
* 155.1.146.1, from 150.1.5.5, 00:00:25 ago, via GigabitEthernet1.146
Route metric is 1003, traffic share count is 1

R6#traceroute 150.1.8.8
Type escape sequence to abort.
Tracing the route to 150.1.8.8
VRF info: (vrf in name/id, vrf out name/id)
1 155.1.146.1 5 msec 4 msec 4 msec
2 155.1.146.4 5 msec 5 msec 5 msec
3 155.1.45.5 7 msec 6 msec 7 msec
4 155.1.58.8 7 msec * 7 msec

Very interesting! Even though it’s uses may be very specific and not commonly used in the “real world” it feels like it certainly can be something that they throw at you at the CCIE-exam.

 

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 Classic & Named mode – Leak-maps

Back from my vacation in Greece! Took a break from everything network-related to recharge but now i’m all set to keep crunching both labs & books. Currently fighting my way thru “IP Routing on IOS, IOS XE and IOS XR – An essential guide to understanding & implementing IP Routing Protocols” (2.1k pages – yikes… ). Trying to get back into the groove with an easier lab on EIGRP Leak-maps down below:

Requirements:

  • Configure Classic mode on R4 & R5 with AS100 and enable over both ethernet + DMVPN
  • Configure Named mode on R1, R3, R6 & R7 with AS200 and enable over 155.1.0.0/16
  • Configure loopbacks on R4 and redistribute to EIGRP
    • Lo40 -4.0.0.4/24
    • Lo41 – 4.0.1.4/24
  • Configure loopbacks on R6 and redistribute to EIGRP
    • Lo60 – 6.0.0.6/24
    • Lo61 – 6.0.1.6/24
  • Configure default summary-routes on R4 & R6  to be advertised instead of Loopbacks
  • Configure a leak-map on R4 for traffic to Lo40 to be routed via DMVPN
  • Configure a leak-map on R6 for traffic to Lo60 to be routed via R3 from R1
  • If the DMVPN is down, traffic should still be rerouted on the backup-path

Let’s start with the easy part and configure EIGRP, Loopbacks and redistribution:

!! General

! R4 & R5

router eigrp 100
 network 155.1.0.0 0.0.255.255
 network 150.0.0.0 0.0.0.255

! R1, R3, R6, R7

router eigrp MULTI-AF
 address-family ipv4 auto 200
  network 155.1.0.0 0.0.255.255

!! Loopbacks
! R4

int Lo40
 ip add 4.0.0.4 255.255.255.0
int Lo41
 ip add 4.0.1.4 255.255.255.0

router eigrp 100
 redistribute connected

! R6

int Lo60
 ip add 6.0.0.6 255.255.255.0
int Lo61
 ip add 6.0.1.6 255.255.255.0

router eigrp MULTI-AF
 address-family ipv4 auto 200
  topology base 
   redistribute connected

We should now have the baseline working.

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

4.0.0.0/24 is subnetted, 2 subnets
D EX 4.0.0.0 [170/130816] via 155.1.45.4, 00:18:52, GigabitEthernet1.45
D EX 4.0.1.0 [170/130816] via 155.1.45.4, 00:18:52, GigabitEthernet1.45
150.1.0.0/32 is subnetted, 2 subnets
D EX 150.1.4.4 [170/130816] via 155.1.45.4, 00:18:52, GigabitEthernet1.45

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

6.0.0.0/24 is subnetted, 2 subnets
D EX 6.0.0.0 [170/10880] via 155.1.146.6, 00:14:51, GigabitEthernet1.146
D EX 6.0.1.0 [170/10880] via 155.1.146.6, 00:14:51, GigabitEthernet1.146
150.1.0.0/32 is subnetted, 2 subnets
D EX 150.1.6.6 [170/10880] via 155.1.146.6, 00:14:51, GigabitEthernet1.146
155.1.0.0/16 is variably subnetted, 10 subnets, 2 masks
D 155.1.7.0/24 
[90/20480] via 155.1.146.6, 00:15:53, GigabitEthernet1.146
[90/20480] via 155.1.13.3, 00:15:53, GigabitEthernet1.13
D 155.1.37.0/24 
[90/15360] via 155.1.13.3, 00:15:53, GigabitEthernet1.13
D 155.1.67.0/24 
[90/15360] via 155.1.146.6, 00:15:53, GigabitEthernet1.146
D 155.1.79.0/24 
[90/20480] via 155.1.146.6, 00:15:53, GigabitEthernet1.146
[90/20480] via 155.1.13.3, 00:15:53, GigabitEthernet1.13

Let’s add our summary-routes to R4 & R6:

!! Summary default-route

! R4
int Gi1.45
 ip summary-address eigrp 100 0.0.0.0 0.0.0.0
int Tu0
 ip summary-address eigrp 100 0.0.0.0 0.0.0.0

! R6
router eigrp MULTI-AF
 address-family ipv4 auto 200
  af-interface Gi1.67
   summary-address 0.0.0.0 0.0.0.0
  af-interface Gi1.146
   summary-address 0.0.0.0 0.0.0.0

As we’re doing summarization our loopbacks advertisements will be suppressed and replaced with an internal 0.0.0.0/0 route:

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

D* 0.0.0.0/0 [90/10880] via 155.1.146.6, 00:01:30, GigabitEthernet1.146
155.1.0.0/16 is variably subnetted, 10 subnets, 2 masks
D 155.1.7.0/24 [90/20480] via 155.1.13.3, 00:01:30, GigabitEthernet1.13
D 155.1.37.0/24 
[90/15360] via 155.1.13.3, 00:01:30, GigabitEthernet1.13
D 155.1.67.0/24 
[90/20480] via 155.1.13.3, 00:01:30, GigabitEthernet1.13
D 155.1.79.0/24 
[90/20480] via 155.1.13.3, 00:01:30, GigabitEthernet1.13

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:00:20, GigabitEthernet1.45

Next step is to use a leak-map so traffic going to R4s loopback is routed via DMVPN-cloud instead of the ethernet-segment. This will be easily solved by advertising that specific route out on our Tu0-interface together with our default-route. Longest-match makes routers prefer our specific-route instead of the default to get to 4.0.0.4. To implement this we use a “leak-map”, I found it in the official DOC here & here.

!! Leak-map

! R4
ip prefix-list LOOP permit 4.0.0.4/24

route-map LEAK permit 10
 match ip add prefix-list LOOP

int Tu0
 ip summary-address eigrp 100 0.0.0.0 0.0.0.0 leak-map LEAK

Neighbors will do a graceful-restart and then the results should be visible in R5:

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:07:01, GigabitEthernet1.45
4.0.0.0/24 is subnetted, 1 subnets
D EX 4.0.0.0 [170/25984000] via 155.1.0.4, 00:00:05, Tunnel0

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

If we close our Tunnel-interface traffic will still be routed over the default-route to Gi1.45.

! R4
int Tu0
 shut

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:09:36, GigabitEthernet1.45

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

Sweet! Now we just have to do the same thing in R6, by leaking our route on the Gi1.67-interface R1 will prefer the route to R3 over going directly to R6 for reaching 6.0.0.0/24.

!! Leak-map

! R6
ip prefix-list LOOP permit 6.0.0.6/24

route-map LEAK permit 10
 match ip add prefix-list LOOP

router eigrp MULTI-AF
 address-family ipv4 auto 200
  af-interface gi1.67
   summary-address 0.0.0.0 0.0.0.0 leak-map LEAK

Let’s check R1 again:

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

D* 0.0.0.0/0 [90/10880] via 155.1.146.6, 00:11:33, GigabitEthernet1.146
6.0.0.0/24 is subnetted, 1 subnets
D EX 6.0.0.0 [170/21120] via 155.1.13.3, 00:00:20, GigabitEthernet1.13
155.1.0.0/16 is variably subnetted, 10 subnets, 2 masks
D 155.1.7.0/24 [90/20480] via 155.1.13.3, 00:11:33, GigabitEthernet1.13
D 155.1.37.0/24 
[90/15360] via 155.1.13.3, 00:11:33, GigabitEthernet1.13
D 155.1.67.0/24 
[90/20480] via 155.1.13.3, 00:11:33, GigabitEthernet1.13
D 155.1.79.0/24 
[90/20480] via 155.1.13.3, 00:11:33, GigabitEthernet1.13

All is good! I’m really starting to like EIGRP’s named mode the more I use it, the classic feels so clunky now. Until next time… 🙂

RIPv2 Conditional default-routes

A few examples of advertising a default-route within RIPv2 using different techniques, some was a bit tricky to figure out. The requirements were as follows (three separate labs):

  1. From R6 – Advertise a default-route via RIP only outbound on Vl146, you are not allowed to use any access/prefix-lists
  2. From R4 – Advertise a default-route via RIP as long as R4 has a route to R9s loopback
  3. From R1 – Advertise a default-route via RIP as long as R1 has reachability to R7s LAN-interface 155.1.7.7, otherwise withdraw route

First lab – Advertise by outbound interface

Advertising a default-route on a specific interface without filtering by accesss/prefix-list we could instead use a route-map.

! R6

route-map FILTER permit 10
 set interface Gi1.146

router rip
 default-information originate route-map FILTER

Big difference from ex. OSPF is that RIP doesn’t require the route to be in it’s actual routing-table to advertise it, which in turn leads to a routing loop in our topology. R6 advertise the route to R1 & R4, R1 will in turn advertise it to R7 who will forward it to R6. R6 will accept the route as it dosen’t have a default-route in it’s table and advertise that.

R6#sh ip rip database 0.0.0.0 0.0.0.0
0.0.0.0/0
 [4] via 155.1.67.7, 00:00:07, GigabitEthernet1.67

R6#sh ip rip database 0.0.0.0 0.0.0.0
0.0.0.0/0
 [8] via 155.1.67.7, 00:00:00, GigabitEthernet1.67

R1#sh ip route | beg Gate
Gateway of last resort is 155.1.146.6 to network 0.0.0.0

R* 0.0.0.0/0 [120/13] via 155.1.146.6, 00:00:02, GigabitEthernet1.146

This can be solved in many ways, I chose to insert a dummy default-route to null0, but you could also use filtering etc.

! R6

ip route 0.0.0.0 0.0.0.0 null0

R6 will now ignore the default-route advertisement from R7 and not propagate it any further.

R6#sh ip rip database 0.0.0.0 0.0.0.0
0.0.0.0/0 redistributed
 [1] via 0.0.0.0,

R8#sh ip rip database 
0.0.0.0/0 auto-summary
0.0.0.0/0
 [3] via 155.1.58.5, 00:00:09, GigabitEthernet1.58

Second lab – Conditional default-route

This lab requires us to originate a default-route from R4 as long as it has a route to R9s loopback0, the final solution looked like this for me:

! R4

ip prefix-list R9 permit 150.1.9.9/32

route-map R9_TRACKING permit 10
 match ip address prefix-list R9

ip route 0.0.0.0 0.0.0.0 null0

router rip
 default-information originate route-map R9_TRACKING

The logic is that as long as our route-map matches the prefix-list of R9s loopback it will advertise the default-route, and we add a static route to avoid routing loops via the DMVPN-hub R5 (no split-horizon). Let’s verify to be sure.

R5#sh ip route | inc 0.0.0.0
Gateway of last resort is 155.1.45.4 to network 0.0.0.0
R* 0.0.0.0/0 [120/1] via 155.1.45.4, 00:00:05, GigabitEthernet1.45

If we shut R9s loopback the default-route should time out eventually.

! R9

int Lo0
 shut

R4#sh ip route 150.1.9.9
% Subnet not in table

R5#sh ip route 0.0.0.0 
% Network not in table

Third lab – IP SLA & default-route

This lab requires us to advertise a default-route as long as R1 has reachability to R7s LAN-interface 155.1.7.7, otherwise withdraw route. So obviously we’re looking at setting up IP SLA to start with.

! R1

ip sla 1
 icmp-echo 155.1.7.7
 frequency 5

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

R1#sh track 1
Track 1
 IP SLA 1 state
 State is Up

I couldn’t figure out how to use our tracker in RIP however, eventually I found a pretty neat solution that might not be the prettiest, but it does the trick. First we create a “dummy-route” together with our tracker.

! R1
ip route 169.254.254.1 255.255.255.255 null0 track 1

Next step we borrow from our second lab, we create a prefix-list matching our dummy-route together with a route-map that we then use as a condition for our default-route advertising.

! R1

ip prefix-list DUMMY_FILTER permit 169.254.254.1/32
route-map DUMMY permit 10
 match ip address prefix-list DUMMY_FILTER

router rip
 default-information originate route-map DUMMY

The logic is, when our tracker (testing icmp-reachability to 155.1.7.7) goes down, our dummy static route will be removed from the routing table. This will in turn make rip stop advertising (or rather poison-reverse) the default as our route-map no longer has any match. Let’s try it!

! R7

interface Gi1.7
 shut

! R1

R1#debug ip rip
RIP protocol debugging is on
R1#
%TRACK-6-STATE: 1 ip sla 1 state Up -> Down
R1#
RIP: sending v2 flash update to 224.0.0.9 via Loopback0 (150.1.1.1)
RIP: build flash update entries
 0.0.0.0/0 via 0.0.0.0, metric 16, tag 0
 155.1.7.0/24 via 0.0.0.0, metric 16, tag 0

As our tracker goes down, R1 poisons the default-route and it will eventually timeout in our other routers.

R2#sh ip route 0.0.0.0 
% Network not in table

Fun stuff, even RIP can be pretty tricky even though it’s such a basic protocol compared to the rest. 🙂

RIPv2 Filtering with Prefix-lists

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

Requirements:

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

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

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

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

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

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

router rip
 distribute-list prefix LO_FILTER out GigabitEthernet1.58

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

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

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

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

ip prefix-list ACCEPT_ALL permit 0.0.0.0/0 le 32

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

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

router rip
 distribute-list prefix ACCEPT_ALL gateway BLOCK_R4 in

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

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

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

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

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

Reliable Policy-based routing

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

Lab requirements:

Basic routing:

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

Policy-routing:

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

Reliability:

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

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

! Basic-1 R3

ip route 0.0.0.0 0.0.0.0 Gi1.13 155.1.13.1

! Basic-2
! R4

ip route 0.0.0.0 0.0.0.0 Gi1.146 155.1.146.1

! R6

ip route 0.0.0.0 0.0.0.0 Gi1.146 155.1.146.1

! Basic-3 R5

ip route 0.0.0.0 0.0.0.0 Tu0 155.1.0.1

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

! R5
ip route 150.1.3.3 255.255.255.255 Tu0 155.1.0.3

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

! Policy-routing R1

ip access-list extended R4
 permit ip host 155.1.146.4 any

ip access-list extended R6
 permit ip host 155.1.146.6 any

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

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

interface Gi1.146
 ip policy route-map RPR

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

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

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

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

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

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

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

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

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

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

ip sla schedule start-time now life forever

track 1 ip sla 100 state

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Let’s verify again:

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

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

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

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

R1#debug ip policy 
Policy routing debugging is on

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

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

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

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

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

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

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

! R5
interface Tu0
 no cdp enable

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

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

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

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

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

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

Reliable static routing with Object tracking/IP SLA

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

Goals:

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

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

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

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

! 1-1 R1

ip route 150.1.4.4 255.255.255.255 Tu0 155.1.0.4

! 2-1 R5

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

! 3-1 R4

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

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

ip route 150.1.1.1 255.255.255.255 Gi1.146 155.1.146.1 track 1

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

Verification:

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

R4#sh ip sla statistics 1
IPSLAs Latest Operation Statistics

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

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

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

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

Static local RIB for default

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

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

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

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

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

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

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

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

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

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

Policy-based routing

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

Requirements:

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

Let’s start with the basic static routes first:

! 1-1 R3

ip route 0.0.0.0 0.0.0.0 Gi1.13 155.1.13.1

! 2-1 R4 & R6

ip route 0.0.0.0 0.0.0.0 Gi1.146 155.1.146.1

! 3-1 R5

ip route 0.0.0.0 0.0.0.0 Tu0 155.1.0.1

! 4-1
! R3

ip route 150.1.5.5 255.255.255.255 Tu0 155.1.0.5

! R5

ip route 150.1.3.3 255.255.255.255 Tu0 155.1.0.3

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

R1#sh ip route static 
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
 a - application route
 + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

R1#

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

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

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

route-map PBR_LAB permit 10

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

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

interface Gi1.146
 ip policy route-map PBR_LAB

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

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

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

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

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

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

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

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

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

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

 

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.

 

VRF-Lite & BGP

Tänkte skriva ett kortare inlägg om ett rätt intressant problem jag stötte på tidigare vilket löstes med hjälp av VRF-Lite och lite trixande med BGP. Topologin som önskades var enligt följande:

lightvrf

Länken mot ISP-1 önskades vara primär pga bättre serviceavtal & bandbredd samtidigt som länken till ISP-2 endast skulle användas som backup. Både ISP-1 & 2 genererar en default-route samt annonserar varsitt 10.x.0.0/23-nät. Det fanns även önskemål att AS #666 skulle agera transit mellan ISP-1 & 2.

lightvrfigp

Som IGP användes EIGRP inom AS #666 samt mellan R1 – ISP-1 och OSPF mellan R3 – ISP-2 där respektive länknät redistributas. Detta är egentligen helt onödigt men användes för att göra uppgiften lite mer komplicerad bara. 🙂

Problematiken var dock att ISP-1 & ISP-2 består av en och samma router! Den fysiska topologin ser nämligen ut enligt följande:

lightvrftopologi

Med andra ord behöver vi dela upp R1 till två virtuella routrar med separata routing tables & bgp-adjacencys. Detta löser vi med hjälp av VRF-Lite! 🙂

Låt oss ta och kika lite närmare på konfigen för respektive router.

R2

interface Serial1/0
 ip address 12.0.0.2 255.255.255.252
 description Primary uplink to ISP-1
 no shut
interface Loopback3
 description For testing
 ip address 172.32.0.1 255.255.255.0
 no shut
interface Loopback4
 description For testing
 ip address 172.32.1.1 255.255.255.0
 no shut

interface FastEthernet0/0
 description to MLS1
 ip address 172.16.11.11 255.255.255.0
 ip hello-interval eigrp 101 2
 ip hold-time eigrp 101 6
 ip authentication mode eigrp 1 md5
 ip authentication key-chain eigrp 1 s3cr3t
 ip summary-address eigrp 101 172.32.0.0 255.255.254.0 5
 duplex full
 speed 100
 no shut

IGP-konfig

Då vi endast vill redistributa in länknätet mellan R1 & ISP-1 till EIGRP 101 använde jag en en route-map, passade även på att tagga route’sen om vi skulle behöva utföra någon filtrering senare.

!Internal IGP-routing
router eigrp 101
 redistribute eigrp 666 route-map EIGRP666-EIGRP101
 passive-interface default
 no passive-interface FastEthernet0/1
 network 172.16.0.0
 network 172.32.0.0 0.0.0.255
 network 172.32.1.0 0.0.0.255
 no auto-summary
 eigrp router-id 172.16.99.11

ip prefix-list EIGRP666-EIGRP101 seq 5 permit 12.0.0.0/30

route-map EIGRP666-EIGRP101 permit 10
 match ip address prefix-list EIGRP666-EIGRP101
 set metric 100000 100 255 1 1500
 set tag 1666

route-map EIGRP666-EIGRP101 deny 20

!External IGP routing ISP-1
router eigrp 666
 passive-interface default
 no passive-interface Serial1/0
 network 12.0.0.0 0.0.0.3
 no auto-summary

BGP

Inga konstigheter här, peer-groups för lite mer “kompakt” konfig.

router bgp 666
 no synchronization
 bgp log-neighbor-changes
 network 172.16.0.0
 network 172.32.0.0 mask 255.255.254.0
 redistribute eigrp 666

 neighbor 12.0.0.1 remote-as 65001
 neighbor 12.0.0.1 description ISP-1

 neighbor IBGP peer-group
 neighbor IBGP remote-as 666
 neighbor IBGP next-hop-self
 neigbhor IBGP password s3cr3t

 neighbor 172.16.11.1 peer-group IBGP
 neighbor 172.16.11.1 description MLS1
 neighbor 172.16.13.3 peer-group IBGP
 neighbor 172.16.13.3 description MLS2
 neighbor 172.16.33.33 peer-group IBGP
 neighbor 172.16.33.33 description R3
 no auto-summary

Konfigen är mer eller mindre identisk för R3.

Default-route

Som nämndes tidigare önskades företaget att vi använda denna länk som primär, både ISP-1 & 2 genererade varsin default-route. Att ändra local pref för samtliga routes vi lär oss från ISP-1 hade inte varit något hit då det även skulle påverka trafik vi är transit för. Tänkte istället använda en route-map som sätter en högre local pref endast för default-routen. Vi behöver även se till så att vi ej annonserar default-routen vidare utanför vårat AS.

R2

router bgp 666
 neighbor 12.0.0.1 prefix-list DEFAULT-ROUTE-BLOCK out
 neighbor 12.0.0.1 route-map ISP1-routes in

ip prefix-list DEFAULT-ROUTE-BLOCK seq 5 deny 0.0.0.0/0
ip prefix-list DEFAULT-ROUTE-BLOCK seq 10 permit 0.0.0.0/0 le 32

ip prefix-list default-route seq 5 permit 0.0.0.0/0

route-map ISP1-routes permit 10
 match ip address prefix-list default-route
 set local-preference 150

route-map ISP1-routes permit 20

R3

router bgp 666
 neighbor 13.0.0.1 prefix-list DEFAULT-ROUTE-BLOCK out
 neighbor 13.0.0.1 route-map ISP2-routes in

ip prefix-list DEFAULT-ROUTE-BLOCK seq 5 deny 0.0.0.0/0
ip prefix-list DEFAULT-ROUTE-BLOCK seq 10 permit 0.0.0.0/0 le 32

ip prefix-list default-route seq 5 permit 0.0.0.0/0

route-map ISP2-routes permit 10
 match ip address prefix-list default-route
 set local-preference 110

route-map ISP2-routes permit 20

Vilket ger följande resultat:

R3#sh ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 4
Paths: (2 available, best #1, table Default-IP-Routing-Table)
 Not advertised to any peer
 65001
  172.16.11.11 (metric 30720) from 172.16.11.11 (172.32.1.1)
   Origin IGP, metric 0, localpref 150, valid, internal, best
 65002
  13.0.0.1 from 13.0.0.1 (2.2.2.2)
   Origin IGP, metric 0, localpref 100, valid, external

VRF-Lite / R1

Nu över till det lite roligare. 🙂 VRF:er har vi ju redan konfat i flera tidigare inlägg, så detta är väl inte direkt något nytt men själva användningsområdet  är något jag aldrig stött på tidigare.

interface Loopback1
 ip vrf forwarding ISP-1
 ip address 10.1.0.1 255.255.255.0

interface Loopback2
 ip vrf forwarding ISP-1
 ip address 10.1.1.1 255.255.255.0

interface Loopback3
 ip vrf forwarding ISP-2
 ip address 10.2.0.1 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0

interface Loopback4
 ip vrf forwarding ISP-2
 ip address 10.2.1.1 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0

interface Loopback5
 ip vrf forwarding Shared
 ip address 1.1.1.1 255.255.255.255

interface Loopback6
 ip vrf forwarding Shared
 ip address 2.2.2.2 255.255.255.255

interface Loopback11
description Management - RID
ip address 11.11.11.11 255.255.255.255

interface Serial0/0/0
 description ISP-1 to CustomerA-R1
 ip vrf forwarding ISP-1
 ip address 12.0.0.1 255.255.255.252
 ip summary-address eigrp 666 10.1.0.0 255.255.254.0 5

interface Serial0/0/1
 description ISP-2 to CustomerA-R3
 ip vrf forwarding ISP-2
 ip address 13.0.0.1 255.255.255.252
 ip ospf 1 area 666

Vi konfar först upp några VRF-instanser, shared simulerar i detta fallet externa routes/internet. La även till en export-map för att endast exportera 1.1.1.1/32 och 2.2.2.2/32 från Shared till ISP-1 & ISP-2 vrf:erna.

ip vrf ISP-1
 rd 65000:1
 route-target export 65000:1
 route-target import 65000:1

ip vrf ISP-2
 rd 65000:2
 route-target export 65000:2
 route-target import 65000:2

ip vrf Shared
 rd 65000:3
 export map ISP-Loopback-Inject
 route-target export 65000:3
 route-target import 65000:3
 route-target import 65000:1
 route-target import 65000:2

route-map ISP-Loopback-Inject permit 10
 match ip address prefix-list ISP-1
 set extcommunity rt 65000:1 additive

route-map ISP-Loopback-Inject permit 20
 match ip address prefix-list ISP-2
 set extcommunity rt 65000:2 additive

route-map ISP-Loopback-Inject deny 30

IGP

Då vi använder oss av vrf:er måste vi även justera våra IGP-instanser precis som tidigare.

router eigrp 666
 passive-interface default
 no passive-interface Serial0/0/0
 no auto-summary

 address-family ipv4 vrf ISP-1
  network 10.1.0.0 0.0.0.255
  network 10.1.1.0 0.0.0.255
  network 12.0.0.0 0.0.0.3
  no auto-summary
  autonomous-system 666
  exit-address-family
 eigrp router-id 1.1.1.1

router ospf 1 vrf ISP-2
 router-id 2.2.2.2
 log-adjacency-changes
 area 0 range 10.2.0.0 255.255.254.0
 passive-interface default
 no passive-interface Serial0/0/1

BGP

Här stöter vi på ett litet problem då vi endast kan ha en aktiv BGP-instans, dvs skriver vi “router bgp 65001” kan vi ej konfa upp “router bgp 65002” för ISP-2 efteråt.

BGP har ju dock som bekant en hel del roliga funktioner vi kan använda oss av, och i detta fall kan vi lösa problemet med hjälp av “local-as“, “no-prepend” & “replace-as“. Klicka på respektive för mer info, Lostintransit.se har även en läsvärd artikel om detta här!

router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 no auto-summary

 address-family ipv4 vrf Shared
  redistribute connected
  no synchronization
  exit-address-family

 address-family ipv4 vrf ISP-2
  neighbor 13.0.0.2 remote-as 666
  neighbor 13.0.0.2 local-as 65002 no-prepend replace-as
  neighbor 13.0.0.2 activate
  neighbor 13.0.0.2 default-originate
  no synchronization
  bgp router-id 2.2.2.2
  network 10.2.0.0 mask 255.255.255.0
  network 10.2.1.0 mask 255.255.255.0
  aggregate-address 10.2.0.0 255.255.254.0 summary-only
  exit-address-family

 address-family ipv4 vrf ISP-1
  neighbor 12.0.0.2 remote-as 666
  neighbor 12.0.0.2 local-as 65001 no-prepend replace-as
  neighbor 12.0.0.2 activate
  neighbor 12.0.0.2 default-originate
  no synchronization
  bgp router-id 1.1.1.1
  network 10.1.0.0 mask 255.255.255.0
  network 10.1.1.0 mask 255.255.255.0
  aggregate-address 10.1.0.0 255.255.254.0 summary-only
  exit-address-family

Vilket ger följande resultat:

R1#sh ip bgp neighbors 12.0.0.1
 BGP neighbor is 12.0.0.1, remote AS 65001, external link
 BGP version 4, remote router ID 1.1.1.1
 BGP state = Established, up for 00:45:25
 Last read 00:00:16, last write 00:00:31, hold time is 180, keepalive interval is 60 seconds

R3#sh ip bgp neighbors 13.0.0.1
 BGP neighbor is 13.0.0.1, remote AS 65002, external link
 BGP version 4, remote router ID 2.2.2.2
 BGP state = Established, up for 00:46:18
 Last read 00:00:05, last write 00:00:21, hold time is 180, keepalive interval is 60 seconds

R2#sh ip bgp vpnv4 vrf ISP-1
 BGP table version is 60, 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
 Route Distinguisher: 65000:1 (default for vrf ISP-1) VRF Router ID 1.1.1.1
 *> 1.1.1.1/32 0.0.0.0 0 32768 ?
 *> 2.2.2.2/32 12.0.0.2 0 666 65002 ?
 s> 10.1.0.0/24 0.0.0.0 0 32768 i
 r> 10.1.0.0/23 0.0.0.0 32768 i
 s> 10.1.1.0/24 0.0.0.0 0 32768 i
 *> 10.2.0.0/23 12.0.0.2 0 666 65002 i
 *> 13.37.0.0/16 0.0.0.0 0 32768 ?
 *> 172.16.0.0 12.0.0.2 28416 0 666 i
 *> 172.32.0.0/23 12.0.0.2 128256 0 666 i

R2#sh ip bgp vpnv4 vrf ISP-1
 BGP table version is 60, 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
 Route Distinguisher: 65000:1 (default for vrf ISP-1) VRF Router ID 1.1.1.1
 *> 1.1.1.1/32 0.0.0.0 0 32768 ?
 *> 2.2.2.2/32 12.0.0.2 0 666 65002 ?
 s> 10.1.0.0/24 0.0.0.0 0 32768 i
 r> 10.1.0.0/23 0.0.0.0 32768 i
 s> 10.1.1.0/24 0.0.0.0 0 32768 i
 *> 10.2.0.0/23 12.0.0.2 0 666 65002 i
 *> 13.37.0.0/16 0.0.0.0 0 32768 ?
 *> 172.16.0.0 12.0.0.2 28416 0 666 i
 *> 172.32.0.0/23 12.0.0.2 128256 0 666 i

Vi kan även verifiera att vår transit fungerar som önskat, ISP-1 har följande information för 2.2.2.2/32 som ligger på samma router men under ISP-2s VRF.

R2#sh ip bgp vpnv4 vrf ISP-1 2.2.2.2/32
 BGP routing table entry for 65000:1:2.2.2.2/32, version 50
 Paths: (1 available, best #1, table ISP-1)
 Not advertised to any peer
 666 65002
 12.0.0.2 from 12.0.0.2 (172.16.99.11)
 Origin incomplete, localpref 100, valid, external, best
 Extended Community: RT:65000:1
 mpls labels in/out 31/nolabel

Vackert! VRF-Lite ger oss ett enkelt sätt att segmentera upp en router om vi exempelvis måste separera två avdelningar från varandra som ansluter till en och samma router. Fler läsvärda artiklar om detta finns här:

http://packetlife.net/blog/2009/apr/30/intro-vrf-lite/

Inter-VRF routing using VRF-lite