Hi, imagine this simple case: -------------------------- route { t_on_branch("1"); t_on_failure("2"); xlog("We are in 'route'"); t_relay("1.1.1.1"); } branch_route[1] { xlog("We are in 'branch_route[1]'"); # do something.... } failure_route[2] { xlog("We are in 'failure_route[2]'"); append_branch(); t_relay("2.2.2.2"); } --------------------------- In case an error occurs when forwarding the request to 1.1.1.1 this would be the screen log output: We are in 'route' We are in 'branch_route[1]' We are in 'failure_route[2]' We are in 'branch_route[1]' This is: branch_route[1] will also be runned **again** after the failure route since it was loaded in the first forward attemp. I really don't know if this is intuitive or not. The only way to "dissable" branch_route[1] in the failure route is by adding: ------------------- failure_route[2] { t_on_branch("2"); # <--- Dissable t_on_branch("1") xlog("We are in 'failure_route[2]'"); append_branch(); t_relay("2.2.2.2"); } branch_route[2] { xlog("We are in 'branch_route[2]'"); # Nothing to do here. # This route is neccesary to dissable t_on_branch("1") } ------------------ This would show: We are in 'route' We are in 'branch_route[1]' We are in 'failure_route[2]' We are in 'branch_route[2]' What about if "t_on_branch" wouldn't remain loaded after a failure route or serial forking? wouldn't be more intuitive to re-enable it explicitely when required?