Soft Reconfiguration Inbound

This morning I set up an eBGP session between routers with a switch in the middle configured for SPAN. The SPAN session sent the output to my laptop for Wireshark analysis.

Of course, I would need prefixes in BGP to have something to observe. I took inspiration from Free Range Routing’s sharpd feature and wrote a Python script to configure static routes so they can be redistributed into BGP. The script asks the user for an IPv4 prefix and configures a static route for every /32 within the prefix using the next hop of NULL0. Disclaimer! I have no idea what I’m doing with Python or any other programming language, so the code is lousy. The script is available at I used input prefix to configure 4094 static routes on R1. I have tested the script with prefixes as large as /16.

Initial Router Configurations:


router bgp 65001

bgp log-neighbor-changes

            redistribute static

            neighbor remote-as 65002


            router bgp 65002

            bgp router-id

            bgp log-neighbor-changes

            neighbor remote-as 65001

I then configured R2 for BGP soft-reconfiguration inbound while observing traffic in Wireshark. It turns out that enabling this feature triggers a route refresh to be requested. The packet selected in the screenshot is just after enabling soft reconfiguration on R2. Until seeing this result I’d never considered that enabling this feature would put packets on the wire or cause the peer to have to resend everything it’s already sent. If I ever have the opportunity, I’d like to retry this test with DFZ sized tables to see if I can spot any measurable impact or resource utilization while resending the full feed.

R2 requesting a route refresh when soft reconfiguration was enabled
The first BGP update packet being resent by R1

Leave Comment

Your email address will not be published. Required fields are marked *