In the field of IP routing, the practice of using null routes (A.K.A. “Black-Hole Routes”) has always had a place. Null routes are often used for DOS mitigation, loop prevention, routing stability, and route summarization. One must always be careful, though, as null routes can have unexpected effects…
A few nights ago a I ran into a very unique problem when using null routes to summarize the RFC1918 address space at the WAN edge of a customer’s datacenter.
Background
This datacenter is built upon Cisco’s Virtualized Multiservice Data Center (VMDC) which consists of three separate virtual device contexts on the Nexus 7000:
Edge: WAN and Internet edge transport routing
Core: IGP core routing, MPLS switching, and MPBGP route reflector, much like a MPLS service provider core
Aggregation: provider edge service networks and firewalling
The Edge context has multiple VRFs for multiple external services: WAN, Internet, Extranet, etc (WAN and Internet shown). The Aggregation context has multiple VRFs for your different tenants and will export their routes with a unique extended community (route-target) so their routes can be selectively imported into other VRFs on both the local [virtual] switch and other PE switches.
The problem I was trying to solve that night was that the entire organizational routing table (400+ routes) was being pulled into and duplicated on every VRF in both the Edge and Aggregation switches (20 or so VRFs total). The vast majority of those routes fell into the RFC1918 space. I couldn’t aggregate everything into a default route as I had separate VRFs in the edge for internet and WAN access (Agg VRFs would import a default route from the Internet VRF, and some public and private routes from WAN); so the goal was to aggregate all private routes at the WAN VRF into the three private summary routes: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.
My WAN VRF was learning it’s routes via OSPF from the edge routers and injecting them into BGP (which then exported them and sent them down to AGG). My first attempt at summarization involved adding the three RFC1918 routes as null routes to the WAN VRF and injecting (redistributing) them into BGP. I then filtered my OSPF to BGP redistribution by using prefix lists and route-map deny statements to filter out specific private routes (ie: “permit 10.0.0.0/8 ge 9” matches all routes within 10.0.0.0/8 that are more specific than the /8, but doesn’t match the /8 itself). This had the effect of stripping out all private routes more specific than the summaries, but left public routes alone.
It also had the effect of blackholing ALL of my private addressed traffic….
I found out why during the second attempt, and we will walk through the steps that led me there in the lab.
Lab
In the lab we have three routers: WAN_Router, Edge_Router, and Tenant_Router.
WAN_Router and Tenant_Router are very simple, they have some loopbacks that are being injected into OSPF and they are peering with the Edge VRFs via OSPF.
The Edge_Router is where our focus lies. It has two VRFs (one to peer with each of the other routers) and is performing VRF-Lite route sharing between those VRFs.
WAN_Router
WAN_Router#sh run
Building configuration...
Current configuration : 1505 bytes
!
!
hostname WAN_Router
!
!
interface Loopback1
ip address 10.1.0.1 255.255.0.0
!
interface Loopback2
ip address 10.2.0.1 255.255.0.0
!
interface Loopback3
ip address 10.3.0.1 255.255.0.0
!
interface Loopback4
ip address 10.4.0.1 255.255.0.0
!
interface Loopback5
ip address 10.5.0.1 255.255.0.0
!
interface Loopback6
ip address 10.6.0.1 255.255.0.0
!
interface Loopback7
ip address 10.7.0.1 255.255.0.0
!
interface Loopback8
ip address 10.8.0.1 255.255.0.0
!
interface Loopback50
ip address 50.50.50.50 255.255.255.255
!
!
!
interface FastEthernet0/0
ip address 172.16.0.1 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
!
!
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
!
!
end
Edge_Router
Edge_Router#sh run
Building configuration...
Current configuration : 1917 bytes
!
!
hostname Edge_Router
!
!
!
ip vrf Agg_VRF
rd 172.255.255.255:2
route-target export 172.255.255.255:2
route-target import 172.255.255.255:1
!
ip vrf Edge_WAN_VRF
rd 172.255.255.255:1
route-target export 172.255.255.255:1
route-target import 172.255.255.255:2
!
!
!
!
interface Loopback1
ip address 172.255.255.255 255.255.255.255
!
interface FastEthernet0/0
ip vrf forwarding Edge_WAN_VRF
ip address 172.16.0.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet0/1
ip vrf forwarding Agg_VRF
ip address 172.16.0.5 255.255.255.252
duplex auto
speed auto
!
!
!
router ospf 1 vrf Edge_WAN_VRF
log-adjacency-changes
redistribute bgp 65000 subnets
network 0.0.0.0 255.255.255.255 area 0
!
router ospf 2 vrf Agg_VRF
log-adjacency-changes
redistribute bgp 65000 subnets
network 0.0.0.0 255.255.255.255 area 0
!
!
!
router bgp 65000
no bgp default ipv4-unicast
bgp log-neighbor-changes
!
address-family ipv4 vrf Edge_WAN_VRF
redistribute ospf 1 vrf Edge_WAN_VRF
no synchronization
exit-address-family
!
address-family ipv4 vrf Agg_VRF
redistribute ospf 2 vrf Agg_VRF
no synchronization
exit-address-family
!
!
end
Tenant_Router
Tenant_Router#sh run
Building configuration...
Current configuration : 1123 bytes
!
!
hostname Tenant
!
!
interface Loopback1
ip address 192.168.1.1 255.255.255.255
!
!
!
interface FastEthernet0/0
ip address 172.16.0.6 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
!
!
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
!
!
end
If we look at the routing tables on the WAN_Router and Tenant_Router, we can see that their routes are being fully redistributed to each other by the Edge_Router. Nothing is being pruned or summarized. We can also see that they are able to ping each other with no problems.
WAN_Router#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
50.0.0.0/32 is subnetted, 1 subnets
C 50.50.50.50 is directly connected, Loopback50
172.16.0.0/30 is subnetted, 2 subnets
O E2 172.16.0.4 [110/1] via 172.16.0.2, 02:17:59, FastEthernet0/0
C 172.16.0.0 is directly connected, FastEthernet0/0
10.0.0.0/16 is subnetted, 8 subnets
C 10.8.0.0 is directly connected, Loopback8
C 10.2.0.0 is directly connected, Loopback2
C 10.3.0.0 is directly connected, Loopback3
C 10.1.0.0 is directly connected, Loopback1
C 10.6.0.0 is directly connected, Loopback6
C 10.7.0.0 is directly connected, Loopback7
C 10.4.0.0 is directly connected, Loopback4
C 10.5.0.0 is directly connected, Loopback5
192.168.1.0/32 is subnetted, 1 subnets
O E2 192.168.1.1 [110/2] via 172.16.0.2, 02:18:00, FastEthernet0/0
WAN_Router#
WAN_Router#
WAN_Router#
WAN_Router#
WAN_Router#ping 192.168.1.1 source loop 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/36/52 ms
WAN_Router#
Tenant_Router#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
50.0.0.0/32 is subnetted, 1 subnets
O E2 50.50.50.50 [110/2] via 172.16.0.5, 00:01:31, FastEthernet0/0
172.16.0.0/30 is subnetted, 2 subnets
C 172.16.0.4 is directly connected, FastEthernet0/0
O E2 172.16.0.0 [110/1] via 172.16.0.5, 02:45:32, FastEthernet0/0
10.0.0.0/32 is subnetted, 8 subnets
O E2 10.8.0.1 [110/2] via 172.16.0.5, 02:45:32, FastEthernet0/0
O E2 10.3.0.1 [110/2] via 172.16.0.5, 02:45:32, FastEthernet0/0
O E2 10.2.0.1 [110/2] via 172.16.0.5, 02:45:32, FastEthernet0/0
O E2 10.1.0.1 [110/2] via 172.16.0.5, 02:45:32, FastEthernet0/0
O E2 10.7.0.1 [110/2] via 172.16.0.5, 02:45:32, FastEthernet0/0
O E2 10.6.0.1 [110/2] via 172.16.0.5, 02:45:32, FastEthernet0/0
O E2 10.5.0.1 [110/2] via 172.16.0.5, 02:45:32, FastEthernet0/0
O E2 10.4.0.1 [110/2] via 172.16.0.5, 02:45:32, FastEthernet0/0
192.168.1.0/32 is subnetted, 1 subnets
C 192.168.1.1 is directly connected, Loopback1
Tenant_Router#
Tenant_Router#
Tenant_Router#
Tenant_Router#
Tenant_Router#ping 10.1.0.1 source loop 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.0.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/41/48 ms
Tenant_Router#
Also, notice the routes in the different VRFs on the Edge_Router. Specifically, notice how the routes that are shared between VRFs (which show up as BGP routes) show you the originating VRF and the next hop of that originating VRF.
Edge_Router#sh ip route vrf Edge_WAN_VRF
Routing Table: Edge_WAN_VRF
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
50.0.0.0/32 is subnetted, 1 subnets
O 50.50.50.50 [110/2] via 172.16.0.1, 00:02:36, FastEthernet0/0
172.16.0.0/30 is subnetted, 2 subnets
B 172.16.0.4 is directly connected, 03:08:43, FastEthernet0/1
C 172.16.0.0 is directly connected, FastEthernet0/0
10.0.0.0/32 is subnetted, 8 subnets
O 10.8.0.1 [110/2] via 172.16.0.1, 03:15:51, FastEthernet0/0
O 10.3.0.1 [110/2] via 172.16.0.1, 03:15:51, FastEthernet0/0
O 10.2.0.1 [110/2] via 172.16.0.1, 03:15:51, FastEthernet0/0
O 10.1.0.1 [110/2] via 172.16.0.1, 03:15:51, FastEthernet0/0
O 10.7.0.1 [110/2] via 172.16.0.1, 03:15:51, FastEthernet0/0
O 10.6.0.1 [110/2] via 172.16.0.1, 03:15:51, FastEthernet0/0
O 10.5.0.1 [110/2] via 172.16.0.1, 03:15:51, FastEthernet0/0
O 10.4.0.1 [110/2] via 172.16.0.1, 03:15:52, FastEthernet0/0
192.168.1.0/32 is subnetted, 1 subnets
B 192.168.1.1 [20/2] via 172.16.0.6 (Agg_VRF), 03:08:44, FastEthernet0/1
Edge_Router#
Edge_Router#
Edge_Router#
Edge_Router#
Edge_Router#sh ip route vrf Agg_VRF
Routing Table: Agg_VRF
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
50.0.0.0/32 is subnetted, 1 subnets
B 50.50.50.50 [20/2] via 172.16.0.1 (Edge_WAN_VRF), 00:02:37, FastEthernet0/0
172.16.0.0/30 is subnetted, 2 subnets
C 172.16.0.4 is directly connected, FastEthernet0/1
B 172.16.0.0 is directly connected, 03:09:17, FastEthernet0/0
10.0.0.0/32 is subnetted, 8 subnets
B 10.8.0.1 [20/2] via 172.16.0.1 (Edge_WAN_VRF), 03:09:17, FastEthernet0/0
B 10.3.0.1 [20/2] via 172.16.0.1 (Edge_WAN_VRF), 03:09:17, FastEthernet0/0
B 10.2.0.1 [20/2] via 172.16.0.1 (Edge_WAN_VRF), 03:09:17, FastEthernet0/0
B 10.1.0.1 [20/2] via 172.16.0.1 (Edge_WAN_VRF), 03:09:17, FastEthernet0/0
B 10.7.0.1 [20/2] via 172.16.0.1 (Edge_WAN_VRF), 03:09:18, FastEthernet0/0
B 10.6.0.1 [20/2] via 172.16.0.1 (Edge_WAN_VRF), 03:09:20, FastEthernet0/0
B 10.5.0.1 [20/2] via 172.16.0.1 (Edge_WAN_VRF), 03:09:20, FastEthernet0/0
B 10.4.0.1 [20/2] via 172.16.0.1 (Edge_WAN_VRF), 03:09:20, FastEthernet0/0
192.168.1.0/32 is subnetted, 1 subnets
O 192.168.1.1 [110/2] via 172.16.0.6, 03:12:39, FastEthernet0/1
Edge_Router#
Edge_Router#
Edge_Router#
Edge_Router#
Now, say we want to summarize all the 10.X.X.X routes into a single summary route on the Edge_WAN_VRF before exporting them to the Agg_VRF, but we want to leave the public addresses (50.50.50.50/32 in this case) alone. We can add a static null route for 10.0.0.0/8 and redistribute that into BGP, then prune the specific routes with a route-map deny statement and a prefix list. See highlighted lines below.
*Note: If you are thinking “use BGP aggregate-address with summary-only”, you would be right, except that BGP will only suppress the specific routes when it sends them to a neighbor, not when it exports them. This is because it doesn’t suppress specific routes in it’s BGP table, it simply adds a hidden null route and advertises that instead of the specific ones.
Edge_Router#sh run | be router bgp 65000
router bgp 65000
no bgp default ipv4-unicast
bgp log-neighbor-changes
!
address-family ipv4 vrf Edge_WAN_VRF
redistribute static
redistribute ospf 1 vrf Edge_WAN_VRF route-map OSPF>BGP
no synchronization
exit-address-family
!
address-family ipv4 vrf Agg_VRF
redistribute ospf 2 vrf Agg_VRF
no synchronization
exit-address-family
!
ip forward-protocol nd
ip route vrf Edge_WAN_VRF 10.0.0.0 255.0.0.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
ip prefix-list PFX_OSPF>BGP seq 5 permit 10.0.0.0/8 ge 9
!
!
!
!
route-map OSPF>BGP deny 10
match ip address prefix-list PFX_OSPF>BGP
!
route-map OSPF>BGP permit 20
!
!
!
end
We should now expect to see the 50.50.50.50/32 public route and only the summarized 10.0.0.0/8 route imported into the Agg_VRF. And look the the next hops shown for the originating VRF…
Edge_Router#
Edge_Router#sh ip route vrf Agg_VRF
Routing Table: Agg_VRF
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
50.0.0.0/32 is subnetted, 1 subnets
B 50.50.50.50 [20/2] via 172.16.0.1 (Edge_WAN_VRF), 00:29:35, FastEthernet0/0
172.16.0.0/30 is subnetted, 2 subnets
C 172.16.0.4 is directly connected, FastEthernet0/1
B 172.16.0.0 is directly connected, 04:06:13, FastEthernet0/0
B 10.0.0.0/8 is directly connected, 00:20:04, Null0
192.168.1.0/32 is subnetted, 1 subnets
O 192.168.1.1 [110/2] via 172.16.0.6, 04:09:31, FastEthernet0/1
Edge_Router#
Edge_Router#
And when we try to ping one of the 10.X.X.X loopbacks on the WAN_Router from the Tenant_Router, we receive ICMP unreachables.
Tenant#
Tenant#
Tenant#ping 10.1.0.1 source loop 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.0.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
UUUUU
Success rate is 0 percent (0/5)
Tenant#
Tenant#
Explanation
This is because when the Agg_VRF receives a packet from the Tenant_Router that is destined for the 10.X.X.X network, it immediately makes the forwarding decision and passes it to the next hop (instead of passing the packet to the Edge_WAN_VRF to be re-evaluated against the Edge_WAN_VRF routing table, which has more specific routes to the destination).
Solution
The solution I used to get around this summarization problem is to originate a summary route from my WAN_Router along with all the specific routes (we can use a static null on the WAN_Router because the packets get evaluated against the full routing table from the get-go since the router doesn’t advertise it’s routes with VRF-Lite or MPBGP). Then remove the static null routes and static to BGP redistribution on the Edge_Router.
*Note
Since the next hop for a 10.X.X.X address from Agg will hop directly to the WAN router, alot of the traffic may now hairpin through the inside interface of the WAN router and back down to the 7k.
Add these config lines
WAN_Router#
WAN_Router#sh run | be router ospf
router ospf 1
log-adjacency-changes
redistribute static subnets
network 0.0.0.0 255.255.255.255 area 0
!
ip forward-protocol nd
ip route 10.0.0.0 255.0.0.0 Null0
no ip http server
no ip http secure-server
!
!
!
end
And remove these config lines
Edge_Router#
Edge_Router#sh run | be router bgp
router bgp 65000
no bgp default ipv4-unicast
bgp log-neighbor-changes
!
address-family ipv4 vrf Edge_WAN_VRF
redistribute static
redistribute ospf 1 vrf Edge_WAN_VRF route-map OSPF>BGP
no synchronization
exit-address-family
!
address-family ipv4 vrf Agg_VRF
redistribute ospf 2 vrf Agg_VRF
no synchronization
exit-address-family
!
ip forward-protocol nd
ip route vrf Edge_WAN_VRF 10.0.0.0 255.0.0.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
ip prefix-list PFX_OSPF>BGP seq 5 permit 10.0.0.0/8 ge 9
!
!
!
!
route-map OSPF>BGP deny 10
match ip address prefix-list PFX_OSPF>BGP
!
route-map OSPF>BGP permit 20
!
!
!
end
Now we see that the Agg_VRF routing table still has the 10.0.0.0/8 route, but it’s next hop is appropriate (instead of showing as “directly connected”).
Edge_Router#
Edge_Router#sh ip route vrf Agg_VRF
Routing Table: Agg_VRF
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
50.0.0.0/32 is subnetted, 1 subnets
B 50.50.50.50
[20/2] via 172.16.0.1 (Edge_WAN_VRF), 01:03:51, FastEthernet0/0
172.16.0.0/30 is subnetted, 2 subnets
C 172.16.0.4 is directly connected, FastEthernet0/1
B 172.16.0.0 is directly connected, 04:40:29, FastEthernet0/0
B 10.0.0.0/8 [20/20] via 172.16.0.1 (Edge_WAN_VRF), 00:10:48, FastEthernet0/0
192.168.1.0/32 is subnetted, 1 subnets
O 192.168.1.1 [110/2] via 172.16.0.6, 04:43:47, FastEthernet0/1
Edge_Router#
Edge_Router#
Now we are able to ping from the Tenant_Router to the WAN_Router with just the summarized route and not a bunch of specific ones.
Tenant#
Tenant#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
50.0.0.0/32 is subnetted, 1 subnets
O E2 50.50.50.50 [110/2] via 172.16.0.5, 01:07:59, FastEthernet0/0
172.16.0.0/30 is subnetted, 2 subnets
C 172.16.0.4 is directly connected, FastEthernet0/0
O E2 172.16.0.0 [110/1] via 172.16.0.5, 04:44:53, FastEthernet0/0
O E2 10.0.0.0/8 [110/20] via 172.16.0.5, 00:14:56, FastEthernet0/0
192.168.1.0/32 is subnetted, 1 subnets
C 192.168.1.1 is directly connected, Loopback1
Tenant#
Tenant#
Tenant#
Tenant#
Tenant#
Tenant#
Tenant#ping 10.1.0.1 source loop 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.0.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/36/52 ms
Tenant#
Tenant#
Conclusion
When multiple VRFs are sharing routes [whether it be on the local router via VRF-Lite, or through MPLS (since MPLS is really just VRF-Lite tunnelled through the default VRFs)], the comparison of the destination IP address against the routing table only occurs once (by the PE VRF closest to the source). This routing decision is made at that point and is forwarded out to the next hop. If that next hop is a summary null route, then the traffic gets blackholed (even if the VRF that originally advertised the summary route has more specific routes for the destination in it’s routing table, but is just not exporting them).
*Note: This lab was created in a GNS3 environment (available here), but the behaviour of the routing was first noticed and verified on production Nexus 7000 equipment.
I have hit the same problem and I can see that configuring the summary route on the WAN router will solve the problem. But I also see that “alot of the traffic may now hairpin to the WAN router and back down to the 7k” which seems to be a bit unfortunate. If you did find an alternate solution for the summary to be applied on the 7K then please let me know.