Egos and Teamwork


My practice rack is staged and ready with the initial config for scenario 13, which I plan to do tomorrow. I am so tired right now. This week has just been a little much. Up at 3am a couple of days to support a fellow engineer who was making some changes. First time, it didn’t work out, since he was under a misconception of how PBR set ip next-hop recursive worked. Nothing like being on a conf call at 4am with a fellow engineer who’s halfway across the country, and then have to tell the poor guy that the command doesn’t do what he thinks it does. Especially when I knew he didn’t believe me. :) Oh, well. We redesigned the solution to the problem and implemented it a couple of days later after a larger group of engineers had a chance to beat it up on a whiteboard.

I don’t know about you, but I much prefer to have other people sanity check me. Am I taking the right approach to solving this problem? Does anyone see a flaw in my code? Is there a different way to do solve the issue that might scale better, make better sense, be easier to document, work consistently across multiple IOS platforms, survive a failure, eliminate SPOFs, etc.? I guess at heart, all network engineers are egocentric. If you’re good at your job, you take it personally when the network goes down, your solution doesn’t work, or things just don’t go right. It’s hard not to be like that. That’s especially true the bigger the network is that you’re working on, and the more your company matters in the grand scheme of the world.

To work as a network engineer as a member of a group that functions as a team…that’s a privilege. When everyone can put their egos aside and work together to come up with the best solution, not necessarily your solution, that’s a cool place to be. You get smarter that way. As soon as you realize that someone else might be able to fix the problem better than you, and you’re willing to learn from that person, you’re a better engineer. You’re more capable. You’re more valuable to your company and to your team. Knowing your limits isn’t an admission of failure. It’s really letting your team know that you can be trusted to say you don’t know when you don’t know. That you’re not going to get yourself, and consequently them, into such a nasty problem that there’s no easy way out, just because you’re too proud to admit you’re in over your head.

I haven’t worked with too many folks who could put their egos aside. It’s hard enough to put my own ego aside. But I can say that when I’ve done it, and when others have done the same, the resulting network has been something that, as a team, we’ve been proud of.


  • Good post. I totally agree that knowing your limitations and putting ego aside results in a better team and infrastructure.

    That being said, I’m still not sure how the next-hop recursive works either. As a visual person, would you mind posting a diagram illustrating when this is useful? Thanks.

  • I will try to work up a little lab experiment to demonstrate PBR recursive next-hop and work on a diagram of the exercise. I’m visual, too. We live and die by the whiteboard and Visio at my job.

    But the short version is this. PBR “set ip next-hop” requires that the next hop be directly connected, thus the packet gets policy routed TO a specific next-hop. On the other hand, PBR “set ip next-hop recursive” allows the router to do a recursive lookup for a gateway that’s NOT directly connected, and then policy route the packet TOWARDS (as opposed to TO) that far-away gateway. The major advantage of this is that you can use CEF load balancing with PBR.

    The common misconception is that you can use “set ip next-hop recursive” to directly route to an IP that’s several hops away…as if by magic, somehow a end-to-end path is created that will hand-deliver that policy routed packet to this distant IP. In reality, whether you do a “set ip next-hop” or a “set ip next-hop recursive”, you can only forward one hop away. The PBR policy on one route doesn’t affect the forwarding decision that a downstream router is going to have to make when he gets that packet to forward.

  • Ethan – Found a great example of recursive lookups in Doyle’s TCP/IP Vol.1, 2nd.Ed., p.109. Seeing the picture and corresponding configurations made it all crystal clear. Thanks for your help.

By Ethan Banks

Ethan Banks is a podcaster and writer with a BSCS and 20+ years in enterprise IT. He's operated data centers with a special focus on infrastructure — especially networking. He's been a CNE, MCSE, CEH, CCNA, CCNP, CCSP, and CCIE R&S #20655. He's the co-founder of Packet Pushers Interactive, LLC where he creates content for humans in the hot aisle.