07-29-2009 08:52 AM
In reading documentation, the KB, and these forums I see lots of conflicting, and outdated information regarding what can, and cannot be done with ECMP. I'd like to get some clarification on a few points.
I have an SSG 550 running ScreenOS 6.2r2. It separates two large segments of our network. I have two interfaces in the "Trust" zone, and two more in a custom zone called "Core." Both zones use trust-vr. All four interfaces are in route mode, configured with a /30 subnet mask, and participate in OSPF area 0. There is no NAT of any kind between these zones.
I have ECMP enabled, and my routing table looks good:
intfw01-> get route ip 10.10.130.31
Dest for 10.10.130.31
trust-vr : => 10.10.130.0/24 (id=158) via 10.9.0.77 (vr: trust-vr)
Interface ethernet0/1 , metric 3
trust-vr : => 10.10.130.0/24 (id=2402) via 10.9.0.33 (vr: trust-vr)
Interface ethernet1/1 , metric 3
It is my understanding that the firewall will loadbalance between the routes on a per-session basis, meaning that a particular session will choose one of the routes and use it for the duration of that session. That is all good and well, but the destination also has multiple, equal, paths to the firewall. Using the output above, what happens when the firewall chooses route id=158 (ethernet0/1) for sending packets to 10.10.130.31, but replies are arriving via both ethernet1/1 and ethernet0/1?
I can't find any information on this type of asymmetric behavior. Everything seems to be working in my configuration, but I'm worried since I see so much conflicting information.
Can some one please give some insight on how a multihomed Netscreen firewall with ECMP handles packets being asymmetrically routed TO it once a session has already been established.
Jacob Wilkins CISSP, CISA
07-29-2009 10:05 AM
The situation discussed in that thread doesn't have much in common with my configuration. I have no NAT, and I'm using OSPF to propogate routes.
I've found these, but they are void of discussion:
07-29-2009 10:08 AM
The firewall will run reverse route look-up for the return packet to verify if you are receiving it on the same interface of the first packet. Depending on your configuration the return packet could be dropped.
To be in the safe side there are two options:
1. Disable reverse route lookup via CLI "unset flow reverse-route clear-text"
2. NAT outgoing traffic so you will always receive the return traffic in the same interface.
07-29-2009 10:44 AM
I've found this KB talking about unset flow reverse-route clear-text:
The scenerio in the KB shows a firewall with three routes on the same interface.
I'm not sure if the description of the feature provided in that KB is accurate, but it differes from how you describe it.
The KB indicates that the setting will alter route selection behavior during session creation. All the routers on my network have OSPF enabled point-to-point links. If a SYN packet were to arrives on eth0/1, there would be nothing wrong with the SYN-ACK being sent out eth1/1, the upstream host wouldn't be able to tell the difference.
NAT is not an option in this configuration.
07-30-2009 09:43 AM
The setup used in that KB is different that you scenario but "unset flow reverse-route clear-text" should help you to avoid issues for the return packet.
"...After enabling this command the firewall will not do a reverse route lookup. Rather it uses the mac-cache entry (entry is made with the first packet of the session) to forward the reverse packet i.e syn-ack to the same gateway from where the SYN packet had arrived initially."
07-30-2009 11:55 AM
Since I'm point-to-point routed, it doesn't matter which gateway gets the packet. That is the point of equal cost multi-path.
My question has to do with how the firewall behaves when traffic is being routed TO it asymmetrically. A topology change 5 hops away from the firewall could cause traffic that had been routed to eth0/1 to land on eth1/1. If the firewall can't figure out that traffic belonging to a single session can arrive on multiple interfaces, then what is the point of ECMP?
Maybe it will help if we talk about this in terms of a specific scenario.
Lets say that the Cisco 4506 that is plugged into eth0/1 gets disconnected from half of its other uplinks, but is still connected to my SSG. The Cisco's OSPF neighbor table will get updated, and it will stop advertising routes to networks to which it is no longer connected. Hosts on the other side of it will now see a single route to the SSG.
In router-land, everyone is happy. No connections would be dropped, OSPF would reconverg in a matter of seconds, and very few people would even notice.
What happens on the firewall to all the sessions that were using the now non-existent route?
I have the following flow commands set:
set flow tcp-rst-invalid-session
set flow tcp-syn-check
unset flow tcp-syn-bit-check
My hope is that the SSG would be able to reconcile the routing change without invalidating the session. But, if it could not, then based on my current config wouldn't it send an RST to both ends of the connection, effectively forcing a disconnect?
Question 1: Does it invalidate the session or not?
Question 2: If I "unset flow tcp-syn-check," will I now be able to support situations in which traffic is being asymmetrically routed through the firewall? Couldn't that result in a single TCP connection creating 4 sessions in my configuration? (Remember, I'm dual cross-connected, two links in, two links out.)
Question 3: Can someone give me a detailed description of the differences between "tcp-syn-check" and "tcp-syn-bit-check"?
Jacob Wilkins CISSP, CISA