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 github.com/routingloopnet/Static-Route-Generator. I used input prefix 10.0.0.0/20 to configure 4094 static routes on R1. I have tested the script with prefixes as large as /16.

Initial Router Configurations:

RoutingLoop_R1:

router bgp 65001

bgp log-neighbor-changes

            redistribute static

            neighbor 172.16.0.2 remote-as 65002

RoutingLoop_R2:

            router bgp 65002

            bgp router-id 172.16.0.2

            bgp log-neighbor-changes

            neighbor 172.16.0.1 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.