cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Bookmark
|
Subscribe
|
435
Views
2
Helpful
10
Replies

L3 switch VRFs with firewall help!

Sargon007
Level 1
Level 1

Hi Everyone,

I am currently labbing up what should be a simple set up. Basically just testing how to integrate a firewall with a L3 switch with the first hop being the SVI. Many posts describe this how you can set up VRFs on the switch, attach a sub interface to it that connects to the firewall, and on the firewall each sub interface can now be in a zone. My topology is as follows:

Sargon007_0-1745791275718.png

From VRF client I should be able to ping to VRF server through the switch and firewall. The palo is set up and working, I can see hits on the rules and captures confirm that it's passing traffic as I can see both outbound and inbound traffic(from the IP-ID). Routes and rules are in place and I know that's not the problem. I know the issue is somewhere on the switch, but I don't know where or if I did not configure this correctly. Basically return traffic is getting dropped by the switch before it even reaches the server/client.

Sargon007_1-1745791557303.png

 

Here is the config:

ip vrf client
!
ip vrf phones
!
ip vrf server
!
!
!
no ip domain-lookup
ip cef
no ipv6 cef
!
!
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
! 
!
!         
!
!
!
!
!
!
!
!
!
!
interface Ethernet0/0
 description firewall
 no switchport
 no ip address
 duplex auto
!
interface Ethernet0/0.2
 encapsulation dot1Q 2
 ip vrf forwarding server
 ip address 10.8.20.2 255.255.255.0
!
interface Ethernet0/0.3
 encapsulation dot1Q 3
 ip vrf forwarding client
 ip address 10.8.30.2 255.255.255.0
!
interface Ethernet0/1
 switchport access vlan 2
!
interface Ethernet0/2
 switchport access vlan 3
!
interface Ethernet0/3
 switchport access vlan 4
!
interface Ethernet1/0
!
interface Ethernet1/1
!
interface Ethernet1/2
!
interface Ethernet1/3
!
interface Vlan1
 no ip address
 shutdown 
!
interface Vlan2
 ip vrf forwarding server
 ip address 10.0.2.1 255.255.255.0
!
interface Vlan3
 ip vrf forwarding client
 ip address 10.0.3.1 255.255.255.0
!
interface Vlan4
 ip vrf forwarding phones
 ip address 10.0.4.1 255.255.255.0
!
router ospf 10 vrf client
 network 10.0.3.0 0.0.0.255 area 0
 network 10.0.4.0 0.0.0.255 area 0
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip route vrf client 0.0.0.0 0.0.0.0 10.8.30.1
ip route vrf server 0.0.0.0 0.0.0.0 10.8.20.1

It's been a while since I looked at cisco so very possible it's just not configured correctly.

 

1 Accepted Solution

Accepted Solutions

For such basic labs with standard features I use CML in most cases as the setup can be done quicker and the basic feature set is pretty solid and usually works fine.

I have various router and switch platforms at hand which I typically use for more complex labs with advanced features or if I doubt the befavior of the CML lab. Of course I also use my hardware in case I need to check some platform specific bahavior.

Tests of your setup have been done with the IOSvL2 node type for the switch.

View solution in original post

10 Replies 10

You need RD for each vrf

Vrf not be UP without RD

MHM

Joseph W. Doherty
Hall of Fame
Hall of Fame

I believe I see some possible issues, which I'll get into a few hours from now.

As to whether you need RDs, I recall (?) they are not needed when using VLAN VRFs (aka VRF-Lite).

More on RD need . . .

Personally, I recalled not needing to use RDs with VRF-Lite, but that was years ago.  However, when I saw this reply:

You need RD for each vrf

Vrf not be UP without RD

I thought perhaps my memory is incorrect (which does happen), or there's some reason why this instance requires it, or perhaps it's just now required.

When I made my initial reply, a very quick search found whether RDs are needed with VRF-Lite, isn't a new question, and there were mixed answers to this question.  I.e. which generally were:  no it's not required or yes it is.

I referenced one instance of this question and the answers it generated, in my initial reply.

Later, I spent an hour or so, searching and reviewing this question, and basically found, again, it's not required VRF-Lite, or it is required, or (another answer), some platforms require it, even though it really isn't required.  (As I understand the purpose of the RD, I didn't see a technical need for RDs with VLAN/VRF-Lite, but possibly could see it being required to set a quasi standard for when you do need it with MPLS/BGP VRFs.

Lastly, someone in another thread, suggested posing a question to any AI for a good answer.  I tried it, for that thread, and found, indeed, the AI answers were good, at least IMO.

So, I posed the question:  "does vrf lite need rd" to two AIs, and received similar answers, and one of them is:

VRF Lite does not inherently require a Route Distinguisher (RD) for its operation. In VRF Lite configurations, the routing tables are already isolated, which means that routes from different VRFs do not conflict without the need for RDs.
 

However, some network devices or software versions may still require an RD to be configured, even if it is not functionally necessary. This is often due to the specific implementation or requirements of the networking equipment being used. Therefore, while RDs are not a fundamental requirement for VRF Lite, it's important to check the documentation for your specific hardware and software to determine if an RD is needed in your configuration.

From my research, I would say that AI answer is also good.

I was going to suggest trying RDs, but in the meantime, @Jens Albrecht tried it in CML, and it worked fine without, and @Sargon007 tried it on a router, and also found it worked fine.

So, looks like, at least, it's not always required, but perhaps some platforms will require it (although, it probably is actually ignored).

I use VRF-Lite for many years now on various Cisco router and switch platforms and never had to configure RDs using the typical LAN protocols including OSPF routing.

Things start to change as soon as you want/need to use BGP for the routing between VRFs because BGP requires RDs for its loop prevention. If you try to configure BGP for a VRF that does not have a RD you get error messages.

So in case of this scenario it was clear that RDs are not needed.

Joseph W. Doherty
Hall of Fame
Hall of Fame

Other than a potential issue in not using RDs (I'll reply more on that later), I don't see anything obviously wrong for your server VRF.

Your client VRF OSPF includes a phones VRF network?  Otherwise no obvious issues.

Your phones VRF appears to be isolated.

You believe your FW config is correct, but you're sure it knows of, and correctly routes to, and permit traffic for, the VLAN subnets?

Sorry the phones VRF and OSPF process are not part of this config they are just there. Can be a bit confusing now that I think of it. I swapped out the switch for a regular router and then everything seems to work. I think there was something wrong with that image.

Jens Albrecht
Level 1
Level 1

First of all, this setup uses VRF-lite and therefore RDs are definitely not needed.

As Joseph mentioned the OSPF process does not make sense, especially trying to use a network from a different VRF.
However, these minor issues do not affect the server VRF and I also do not see any config problems with this VRF.

Hence I quickly labbed it up and as expected I have full connectivity end-to-end without any issues, meaning the ping from the server to resources behind the firewall (simply used a router here) is successful.

What is the output of the "show vrf" and "show ip route vrf server" commands on your switch?

Just want to add that I used exactly your config for my switch.
So if your output of the above mentioned show commands looks fine, then you probably need to go back and check your FW.

Sorry the phones VRF and OSPF process are not part of this config they are just there. Can be a bit confusing now that I think of it. I swapped out the switch for a regular router and then everything seems to work.  I suspect there is something wrong with that switch image, how did you lab it up? Physical?

For such basic labs with standard features I use CML in most cases as the setup can be done quicker and the basic feature set is pretty solid and usually works fine.

I have various router and switch platforms at hand which I typically use for more complex labs with advanced features or if I doubt the befavior of the CML lab. Of course I also use my hardware in case I need to check some platform specific bahavior.

Tests of your setup have been done with the IOSvL2 node type for the switch.