BGP Authentication and Troubleshooting

Tasks

● Configure BGP on R01, R02, and R03 as per above topology.

● Use BGP ASN's 100, 200, and 300, respectively.

● Advertise the Loopback networks of the routers into BGP.

● R03 should peer with both R01 and R02.

● Configure BGP MD5 Authenticate in these peering with the password UNINETS.

BGP Authentication and other Configuration Commands

SW1:

R1:

R2:

R3:

BGP Authentication Methods

BGP uses TCP for transport, and because TCP already has a specification for authentication, BGP uses TCP authentication instead of a separate internal mechanism. Specifically, it uses TCP Option 19, which is the MD5 Signature Option.  Like OSPF or EIGRP, this means that if BGP authentication fails, a peering relationship will not be established. Therefore, the most basic way to verify that BGP authentication is working is to look at the show ip bgp summary output and ensure that the peers are up. 

The fact that prefixes are being received implies that the TCP session is up, but this could be further verified by viewing the BGP table, as seen below: 

Outside of simply looking at the BGP configuration, authentication can be verified on a per-neighbor basis, as seen below:

A failure in BGP authentication will trigger a syslog message: Note- It may take couple of minutes before these log messages appear.

Note that this is a different error message than if bgp authentication is simply not enabled on the peering, such as seen below: (You may have to reset the BGP neighborship to see these logs) though this is not recommended in production environment.

This is an important difference that we will see later when BGP authenticated sessions pass through either the ASA firewall or the IPS sensor, because the modifications they do to the IP header and payload will affect the TCP MD5 signature.