To reduce the impact of lab testing bits and pieces, I decided to refresh my home network. The requirement I set myself is to reduce some of my family’s frustration when things go sideways, as it inevitably happens when trying out something new. Thus the point of the exercise is not just to refresh my memory or learn something new, but to create a clear separation between the home and the ‘lab’ networks.

The core of the domestic network will still be the same core switch and servers. But, any failures on the lab side should not affect the home network’s connection to the internet. Or as my kids would put it, the ‘WiFi’ must not go down. To my shame, and despite my many admonitions, our spawn persists in calling an internet connection “WiFi”.

In summary, my home network consists of a Ruckus ICX 7250 layer-3 capable switch. Not as polished as a Cisco but it’s an affordable second-hand switch with 48 POE ports and 8x 10GE SFP+ ports. The bulk of the compute and storage element is provided by two HPE DL380 servers, one gen8 (LFF with raid SAS storage) and the other gen9. I later added vSAN using Intel NVMe and 8TB SAS disks. It’s an organically grown mess, but it works and runs the latest version of vSphere 7 very well. Both servers are connected with 2x10GE (LACP LAG) for vSAN and VMs and 2x2GE for management.

Our FTTP terminates on a Palo Alto VM-50, and this is where vSAN and vMotion shine as this virtual firewall can move between the two ESXi hosts without missing a beat.

Initial setup and problem

At first, each VLAN was individually connected to the firewall, which worked great until the firewall went down (only for a software upgrade of course) and I could no longer connect to vCenter from my home network.

My solution was to introduce a Layer-3 link between the switch and the firewall. This made the switch the default gateway for the home network and I could then bring up a vlan interface on the switch to restore access to the management subnet if the firewall was unavailable. Routing between the switch and the firewall was static, which worked well enough, issues were only sporadic after all.

But then a DNS server on my network died and I figured I could do better, by removing lab/dev elements from the home network and giving myself direct access to that rather than traversing the firewall.

Current redesign

I had already used VRF-lite to configure the p2p routed link between the switch and the firewall for the home network. Doubling this for a work VRF was a simple progression while also ensuring that local traffic between work (access, server and management) subnets could flow freely without traversing the firewall. This should avoid management reachability issues for me the next time I upgrade the firewall. Additionally, I’ll be the only user connecting this way and there will be no direct wireless exposure of this VRF, limiting exposure of vSphere via potentially compromised clients on the home network.

I’m still undecided about which is harder to teach regarding cyber security, clients or family members…

Static or dynamic routing?

Moving subnets around becomes easier with dynamic routing protocols. This is what I needed to do and I figured it would be a good Palo Alto routing refresher. While the Ruckus switch supports RIP and OSPF, I went with OSPF as I figured it to be more relevant. Does anyone still use RIP these days? Please don’t answer that; there are too many things in tech that just won’t die…

OSPF

As I set out to add a second VRF to the switch and configure OSPF on it I found a couple of things that one should be aware of:

vSphere

• When adding a new Distributed Port Group (DPG) on a vSwitch with a LAG uplink, ensure the advanced settings are changed to reflect this. This is obvious when initially configuring vSphere, but is easy to forget. So if you find that the switch doesn’t see an OSPF neighbor and the firewall does (stuck in init mode), check the settings of the DPG…

Ruckus

• Simple straightforward configuration from the CLI, but there is no way to see or configure anything OSPF from the web interface.
• With no need to filter advertised prefixes I didn’t check or test for prefix filtering. In fact I used area 0 (0.0.0.0) for all three routing instances.
  • Switch: Enabled OSPF on vrf LAN
  • Switch: Enabled OSPF on vrf WORK
  • Firewall: Enabled OSPF on the default virtual router
  • Set vlan ports to ospf-passive to include them in OSPF rather than redistribute connected.
    • This reduces network chatter, as no neighbor advertisements take place on passive ports.

Palo Alto

• Only advertise a default route. As I’m using the backbone area (0.0.0.0) I can’t use a stub area for the switch, which would make it easier to advertise only a default route.
  • The solution is to use Redistribution Profiles. But, as there’s no comprehensive prefix-list with prefix length matching, one can’t match a default-route as follows:
    • 0.0.0.0/0 le 0
  • Instead, the 0.0.0.0/0 redist needs to be preceded (by priority) by a ‘no-redist’ object containing:

128.0.0.0/1
64.0.0.0/2
32.0.0.0/3
16.0.0.0/4
8.0.0.0/5
4.0.0.0/6
2.0.0.0/7
1.0.0.0/8

The second requirement for filtering redistributed prefixes on Palo Alto is to add both Export Rules under the virtual router OSPF configuration. It took me some time to figure out that creating the Redistribution Profiles does nothing; applying them to the routing process does. It makes absolute sense once you notice.

OSPF Ruckus configuration

The following is the OSPF configuration of the Ruckus, including floating statics for the default routes (belts and braces):

vrf LAN
 rd 65000:100
 ip router-id 192.168.100.1
 address-family ipv4
 ip route 0.0.0.0/0 192.168.199.0 15 distance 254 name fw01
 exit-address-family
exit-vrf
!
vrf WORK
 rd 65000:101
 ip router-id 192.168.101.1
 address-family ipv4
 ip route 0.0.0.0/0 192.168.199.2 15 distance 254 name fw01
 exit-address-family
exit-vrf
!
router ospf vrf WORK
area 0.0.0.0
!
router ospf vrf LAN
area 0.0.0.0
!
interface loopback 1
 vrf forwarding WORK
 ip address 192.168.199.253 255.255.255.255 ospf-passive
 ip ospf area 0.0.0.0
 ip ospf active
!
interface ve 100
 port-name LAN
 vrf forwarding LAN
 ip address 192.168.100.1 255.255.255.0
 ip ospf area 0.0.0.0
 ip ospf passive
!
interface ve 101
 port-name WORK-user-VLAN
 vrf forwarding WORK
 ip address 192.168.101.1 255.255.255.0 ospf-passive
 ip ospf area 0.0.0.0
 ip ospf passive
!
interface ve 198
 port-name WORK-Uplink-to-FW
 vrf forwarding WORK
 ip address 192.168.199.3 255.255.255.254
 ip ospf area 0.0.0.0
 ip ospf active
 ip ospf network point-to-point
!
interface ve 199
 port-name Uplink-to-FW
 vrf forwarding LAN
 ip address 192.168.199.1 255.255.255.254
 ip ospf area 0.0.0.0
 ip ospf active
 ip ospf network point-to-point
!
interface ve 400
 port-name Servers
 vrf forwarding WORK
 ip address 192.168.104.1 255.255.255.0 ospf-passive
 ip ospf area 0.0.0.0
 ip ospf passive
!
interface ve 700
 port-name Management
 vrf forwarding WORK
 ip address 192.168.107.1 255.255.255.0 ospf-passive
 ip ospf area 0.0.0.0
 ip ospf passive

Checking OSPF

Once the Palo Alto and both VRFs on the switch were configured and the vSphere Distributed Port Group issue was resolved both neighborships came up:

I left a couple of floating statics in place on the firewall, they’re shown below with metric 255.

But as can be seen from the forwarding table, the OSPF learned prefixes are preferred:

And this is what things look like on the Ruckus:

SSH@sw01#sh ip ospf vrf LAN neighbor
Number of Neighbors is 1, in FULL state 1

Port Address Pri State Neigh Address Neigh ID Ev Opt Cnt
v199 192.168.199.1 1 FULL/OTHER 192.168.199.0 192.168.199.0 5 66 0

SSH@sw01#sh ip ospf vrf WORK neighbor
Number of Neighbors is 1, in FULL state 1

Port Address Pri State Neigh Address Neigh ID Ev Opt Cnt
v198 192.168.199.3 1 FULL/OTHER 192.168.199.2 192.168.199.0 5 66 0

SSH@sw01#sh ip route vrf LAN
Total number of IP routes: 9
Type Codes - B:BGP D:Connected O:OSPF R:RIP S:Static; Cost - Dist/Metric
BGP Codes - i:iBGP e:eBGP
OSPF Codes - i:Inter Area 1:External Type 1 2:External Type 2
Destination Gateway Port Cost Type Uptime
1 0.0.0.0/0 192.168.199.0 ve 199 110/2 O2 5d4h
2 192.168.100.0/24 DIRECT ve 100 0/0 D 13d4h
3 192.168.101.0/24 192.168.199.0 ve 199 110/12 O 2m40s
4 192.168.104.0/24 192.168.199.0 ve 199 110/12 O 2m40s
5 192.168.107.0/24 192.168.199.0 ve 199 110/12 O 2m40s
6 192.168.199.0/31 DIRECT ve 199 0/0 D 13d4h
7 192.168.199.2/31 192.168.199.0 ve 199 110/11 O 5d4h
8 192.168.199.253/32 192.168.199.0 ve 199 110/12 O 2m40s
9 192.168.199.254/32 192.168.199.0 ve 199 110/11 O 5d4h

SSH@sw01#sh ip route vrf WORK
Total number of IP routes: 9
Type Codes - B:BGP D:Connected O:OSPF R:RIP S:Static; Cost - Dist/Metric
BGP Codes - i:iBGP e:eBGP
OSPF Codes - i:Inter Area 1:External Type 1 2:External Type 2
Destination Gateway Port Cost Type Uptime
1 0.0.0.0/0 192.168.199.2 ve 198 110/2 O2 2m50s
2 192.168.100.0/24 192.168.199.2 ve 198 110/12 O 2m50s
3 192.168.101.0/24 DIRECT ve 101 0/0 D 4d21h
4 192.168.104.0/24 DIRECT ve 400 0/0 D 5d4h
5 192.168.107.0/24 DIRECT ve 700 0/0 D 5d3h
6 192.168.199.0/31 192.168.199.2 ve 198 110/11 O 2m50s
7 192.168.199.2/31 DIRECT ve 198 0/0 D 6d22h
8 192.168.199.253/32 DIRECT loopback 1 0/0 D 5d21h
9 192.168.199.254/32 192.168.199.2 ve 198 110/11 O 2m50s

Summary

Though I am now violating a stated requirement by advertising connected prefixes between the two VRFs, I’m not that bothered by this. The firewall filters traffic between the VRFs and matching my requirement would have meant creating two stub area networks, adding complexity. While possible, for my home network the current setup will do just fine.

Equally, any prefixes which do not need internet connectivity are simply not added to the OSPF process and thus remain unknown outside the VRF. And prefixes which need more security like the DMZ, guest WiFi and IoT remain directly connected to the firewall.

Conclusion

All in all, deploying OSPF between Palo Alto and a Ruckus ICX 7250 proved to be an easy and successful exercise and no licenses were required on either device to support dynamic layer-3 routing. Both devices were at their latest available firmware.

• Palo Alto: 11.0.0
• Ruckus ICX 7250: 8.0.90j

SSH@sw01>sh ver
  Copyright (c) Ruckus Networks, Inc. All rights reserved.
    UNIT 1: compiled on Jan  5 2021 at 21:08:45 labeled as SPR08090j
      (33554432 bytes) from Primary SPR08090j.bin (UFI)
        SW: Version 08.0.90jT213
      Compressed Primary Boot Code size = 786944, Version:10.1.18T215 (spz10118)
       Compiled on Mon Jul 13 09:53:15 2020

  HW: Stackable ICX7250-48-HPOE
==========================================================================
UNIT 1: SL 1: ICX7250-48P POE 48-port Management Module
      Serial  #:DUK3849N0JS
      Software Package: ICX7250_L3_SOFT_PACKAGE   (LID: fwmINJOpFlu)
      Current License: l3-prem-8X10G
      P-ASIC  0: type B344, rev 01  Chip BCM56344_A0
==========================================================================
UNIT 1: SL 2: ICX7250-SFP-Plus 8-port 80G Module
==========================================================================
 1000 MHz ARM processor ARMv7 88 MHz bus
 8192 KB boot flash memory
 2048 MB code flash memory
 2048 MB DRAM
STACKID 1  system uptime is 13 day(s) 7 hour(s) 45 minute(s) 46 second(s)

Tags: OSPF,Palo Alto,Ruckus
Categories: Networking, Work
1 Comment »