VRF route-map

 This lab I will use the following topology:

 

R1 to R4 are all SP routers where R1, R3 and R4 are PE routers and R2 is P router. R5 and R6 are CE routers running EIGRP as PE-to-CE routing protocol.

R5 and R6 belong to the same VRF name RED with both configured with RT100:100 as import and export communities.

So first let’s look on R1 VRF RED routing table:

R1#sh ip route vrf RED   Routing Table: RED Codes: 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   Gateway of last resort is 10.1.16.6 to network 0.0.0.0        10.0.0.0/24 is subnetted, 2 subnets C       10.1.16.0 is directly connected, FastEthernet1/1 B       10.1.34.0 [200/0] via 3.3.3.3, 00:00:02 B    192.168.53.0/24 [200/156160] via 3.3.3.3, 00:00:02 B    192.168.52.0/24 [200/156160] via 3.3.3.3, 00:00:02 B    192.168.51.0/24 [200/156160] via 3.3.3.3, 00:00:02 S*   0.0.0.0/0 [1/0] via 10.1.16.6

 

We can see that R1 is learning subnets 192.168.51.0/24, 192.168.52.0/24 and 192.168.53.0/24 from R3, which in turn learns those from R5.

R1 uses RT 100:100 to import and export routes from VRF RED:

R1# sh running-config | s ip vrf RED ip vrf RED  rd 1:100  route-target export 100:100  route-target import 100:100

 

Now I have configured the following route-map on R3:

ip prefix-list PL_NET51 permit 192.168.51.0/24 ! ip prefix-list PL_NET52 permit 192.168.52.0/24 ! ip prefix-list PL_NET53 permit 192.168.53.0/24 ! route-map RM_VRF_RED_EXPORT permit 10   match ip address prefix-list PL_NET51   set extcommunity rt 100:51  exit   route-map RM_VRF_RED_EXPORT permit 20   match ip address prefix-list PL_NET52   set extcommunity rt 100:52 additive  exit   ip vrf RED   export map RM_VRF_RED_EXPORT

 

Clearing the BGP peering on R2 and let’s have a look on R1 VRF RED routing table:

R1#sh ip route vrf RED   Routing Table: RED Codes: 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   Gateway of last resort is 10.1.16.6 to network 0.0.0.0        10.0.0.0/24 is subnetted, 2 subnets C       10.1.16.0 is directly connected, FastEthernet1/1 B       10.1.34.0 [200/0] via 3.3.3.3, 00:00:05 B    192.168.53.0/24 [200/156160] via 3.3.3.3, 00:00:05 B    192.168.52.0/24 [200/156160] via 3.3.3.3, 00:00:05 B    192.168.51.0/24 [200/156160] via 4.4.4.4, 00:00:05 S*   0.0.0.0/0 [1/0] via 10.1.16.6

 

Ok, subnet 192.168.51.0/24 wasn’t learned from R3 due to changing in the extended community, note that I didn’t add the additive option so the extended community has changed for this subnet and R1 isn’t importing it.

Subnet 192.168.52.0/24 was learned as its holds both extended communities:

R1# show ip bgp vpnv4 vrf RED 192.168.52.0/24 bestpath BGP routing table entry for 1:100:192.168.52.0/24, version 97 Paths: (2 available, best #2, table RED)   Not advertised to any peer   Local, imported path from 3:100:192.168.52.0/24     3.3.3.3 (metric 3) from 2.2.2.2 (2.2.2.2)       Origin incomplete, metric 156160, localpref 100, valid, internal, best       Extended Community: RT:100:52 RT:100:100 Cost:pre-bestpath:128:156160         0x8800:32768:0 0x8801:100:130560 0x8802:65281:25600 0x8803:65281:1500       Originator: 3.3.3.3, Cluster list: 2.2.2.2       mpls labels in/out nolabel/24

 

Subnet 192.168.53.0/24 is also learned via R3 although it’s not matched to any statement in the route-map.

As with access lists, there must be a default action for the route map to take in the event that a route or packet passes through every statement without a match. An implicit deny exists at the end of every route map. Routes that pass through a redistribution route map without a match are not redistributed, and packets that pass through a policy route map without a match are sent to the normal routing process.  

[CCIE Professional Development Routing TCPIP Volume I ch 14 lev1 sec 2]

The route-map doesn’t make any change to this subnet so it bound to the route-target import/export extended communities.

 

 

 

 

 

 

Fortigate diagnose debug flow

How can I verify that traffic is being accepted by (or hitting) a security policy?

You can use the diagnose debug flow command to show packet flow through the FortiGate unit. As packets are received you can view debug messages to show how the FortiGate unit processes them. The following command sequence displays packet flow for packets with IP address 10.10.20.30.

The command output shows what happens after one packet is received:

• a new session is allocated,

• a route is found for the packet,

• its source NAT IP and port number are selected,

• It is matched with a policy (in this case policy ID 5),

• Source is performed and the packet is forwarded.

diagnose debug enable  diagnose debug flow show console enable show trace messages on console  diagnose debug flow filter add 10.10.20.30  diagnose debug flow trace start 100

We can use the following filters:

Option	Description
addr	IP address
clear	Clear filter
daddr	Destination IP address
dport	Destination port
negate	Inverse filter
port	Port
proto	Protocol number
saddr	Source IP address
sport	Source port
vd	index of virtual domain

 

The number after the trace start indicates how many lines to show in the console output.

The way EIGRP calculate metric

Here is the following topology:

All routers are configured in EIGRP AS1, R1 is advertising subnet 192.168.11.0/24 while R4 is advertising subnet 192.168.41.0/24.

Let’s examine R1 routing table:

R1#sh ip route Codes: 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 Gateway of last resort is not set      1.0.0.0/32 is subnetted, 1 subnets C       1.1.1.1 is directly connected, Loopback0 C    192.168.11.0/24 is directly connected, Loopback1 D    192.168.41.0/24 [90/158720] via 10.1.13.3, 00:00:17, FastEthernet0/1                      [90/158720] via 10.1.12.2, 00:00:17, FastEthernet0/0      10.0.0.0/24 is subnetted, 4 subnets C       10.1.13.0 is directly connected, FastEthernet0/1 C       10.1.12.0 is directly connected, FastEthernet0/0 D       10.1.24.0 [90/30720] via 10.1.12.2, 00:00:17, FastEthernet0/0 D       10.1.34.0 [90/30720] via 10.1.13.3, 00:00:19, FastEthernet0/1

And EIGRP topology:

R1#sh ip eigrp topology IP-EIGRP Topology Table for AS(1)/ID(1.1.1.1) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,        r - reply Status, s - sia Status P 10.1.13.0/24, 1 successors, FD is 28160         via Connected, FastEthernet0/1 P 10.1.12.0/24, 1 successors, FD is 28160         via Connected, FastEthernet0/0 P 10.1.24.0/24, 1 successors, FD is 30720         via 10.1.12.2 (30720/28160), FastEthernet0/0 P 10.1.34.0/24, 1 successors, FD is 30720         via 10.1.13.3 (30720/28160), FastEthernet0/1 P 192.168.41.0/24, 2 successors, FD is 158720         via 10.1.12.2 (158720/156160), FastEthernet0/0         via 10.1.13.3 (158720/156160), FastEthernet0/1 P 192.168.11.0/24, 1 successors, FD is 128256         via Connected, Loopback1

We can see that R1 is learning subnet 192.168.41.0/24 from both R2 and R3 with the same metric, note that two numbers are displayed here: 435200 and 409600, the first is FD and the second is RD.

Here is an explanation taken from Cisco CCNP ROUTE 642-902 Official Certification Guide:

Feasible Distance (FD): Integer metric for the route, from the local router’s perspective, used by the local router to choose the best route for that prefix.

Reported Distance (RD): Integer metric for the route, from the neighboring router’s perspective (the neighbor that told the local router about the route). Used by the local router when converging to new routes.

As you may recall the formula used by EIGRP to calculate the metric is using the least bandwidth and cumulative delay of the link. But which link exactly does it means?

Let’s try to change the delay on R3 Fa0/0 and see what happens:

R3#configure terminal Enter configuration commands, one per line.  End with CNTL/Z. R3(config)#interface fastEthernet 0/0 R3(config-if)#delay 5000 R3(config-if)#end R3# R3#clear ip eigrp neighbors

And now let’s look again on R1:

R1# show ip route Codes: 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 Gateway of last resort is not set      1.0.0.0/32 is subnetted, 1 subnets C       1.1.1.1 is directly connected, Loopback0 C    192.168.11.0/24 is directly connected, Loopback1 D    192.168.41.0/24 [90/158720] via 10.1.13.3, 00:00:29, FastEthernet0/1                      [90/158720] via 10.1.12.2, 00:00:29, FastEthernet0/0      10.0.0.0/24 is subnetted, 4 subnets C       10.1.13.0 is directly connected, FastEthernet0/1 C       10.1.12.0 is directly connected, FastEthernet0/0 D       10.1.24.0 [90/30720] via 10.1.12.2, 00:00:36, FastEthernet0/0 D       10.1.34.0 [90/30720] via 10.1.13.3, 00:00:36, FastEthernet0/1 R1#show ip eigrp topology IP-EIGRP Topology Table for AS(1)/ID(1.1.1.1) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,        r - reply Status, s - sia Status P 10.1.13.0/24, 1 successors, FD is 28160         via Connected, FastEthernet0/1 P 10.1.12.0/24, 1 successors, FD is 28160         via Connected, FastEthernet0/0 P 10.1.24.0/24, 1 successors, FD is 30720         via 10.1.12.2 (30720/28160), FastEthernet0/0 P 10.1.34.0/24, 1 successors, FD is 30720         via 10.1.13.3 (30720/28160), FastEthernet0/1 P 192.168.41.0/24, 2 successors, FD is 158720         via 10.1.12.2 (158720/156160), FastEthernet0/0         via 10.1.13.3 (158720/156160), FastEthernet0/1 P 192.168.11.0/24, 1 successors, FD is 128256         via Connected, Loopback1

As you can see nothing changed! R1 is still learning subnet 192.168.41.0/24 from R2 and R3 with the same metric.

That’s because R1 is calculating the metric to this subnet in the following manner:

      1.       Least bandwidth on the link, in our topology the bandwidth is the same for all interfaces

      2.       Cumulative delay of the link

The link in this case is composed from link 13 + link 34 toward R4 subnet (upstream), so R1 is calculating the delay on the interfaces toward R4, using R1 Fa0/1 and R3 Fa0/1, as cumulative delay in the formula!

The blue dots indicate the interfaces which R1 used in his formula to calculate the delay toward R4:

Even configuring delay on R4 Fa0/1 won’t change the metric calculation for R1.

The only way to change the metric for this link will be on R1 Fa0/1 or R3 Fa0/1 interfaces.

R1 is looking on the link toward the advertising router, from his perspective, upstream.

Configuring bandwidth is the same beside the fact that the least bandwidth is taken into calculation and not in cumulative way as delay.