Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Jon, I had noticed your absence, and your relatively recent return. Very glad to see you back!
I suspect PfR hasn't had a lot of uptake. If that's true, suspect it's because you need multiple "edge" paths, with an interior and exterior. When you first look at it, it also seems very complex but once you begin to understand it, it's really not all the complex. Unfortunately there's yet a Doyle book on the subject.
Why VSS can work against you, in L3, is because it's very feature hides better L3 paths.
Ideally VSS should have connections from each VSS member to all other devices. But in my experience, often they don't, especially for L3. For example, you might have a single "east" and "west" connection, each on a different VSS member. From one L3 device out, optimal path might be to the VSS member with the "east" connection, but the next L3 device sees the VSS pair as a single device. So, perhaps it sends its traffic to the "west" VSS member. Now that VSS member will redirect the traffic to its VSS mate (basically we're back to your concern about suboptimal traffic flows, on eBGP egress routers, in this post).
This situation can also arise in failure modes. Suppose a VSS member has a line card failure. From an L3 perspective, an adjoining L3 device won't know not to avoid sending some of its traffic to that device in lieu of sending it directly to the VSS member with the remaining egress path.
Cross traffic in a VSS pair is something you want to avoid because often the bandwidth is limited (often just a dual 10g pair is being used - consider a pair of 3750Xs or 3850s often have more bandwidth for a dual stack) and if there's congestion on the VSL link, you cannot define custom QoS prioritization for it. (Unlikely, but consider losing a 6900 line card [80 Gbps] whose egress now needs to be redirected to its VSS mate across the 20g[?] VSL.)
Another issue with VSS, a pair of L3 devices has a (very slightly) higher MTBF. This because separate L3 devices don't share the single point of failure, the VSS OS. (NB: the difference in MTBF for dual L3 vs. VSS is sort of akin to the difference between VSS vs. a single chassis with redundancy for everything [except, of course, the chassis itself].)
Yet another issue with VSS, a VSS member will always use their own local egress path; to avoid using the VSL. With L3, I could make the local device's egress and it's peer egress equal cost (or if EIGRP use unequal cost) to take advantage of the peer's egress bandwidth.
The above isn't an indictment against VSS. But I've found some engineers think VSS is a huge improvement vs. a fully redundant chassis or better than dual L3 in all aspects.
