Q: 
By default, IOS sends BGP messages to EBGP neighbors with an IP time-to-live (TTL) of 1. (This can be adjusted with ebgp-multihop attached to the desired neighbor or peer group under BGP configuration.) 

Sending BGP messages with a TTL of one requires that the peer be directly connected, 

or the packets will expire in transit. Likewise, a BGP router will only accept incoming BGP messages with a TTL of 1 (or whatever value is specified by ebgp-multihop), which can help mitigate spoofing attacks. 
However, there is an inherent vulnerability to this approach: it is trivial for a remote attacker to 

adjust the TTL of sent packets so that they appear to originating from a directly-connected peer. 
By spoofing legitimate-looking packets toward a BGP router at high volume, a denial of service (DoS) attack may 

be accomplished,please refer to network picture as attachment_1. 
How to avoid the attack described above? 

Solution

A: 
A very simple solution to this, as discussed in RFC 3682, is to invert the direction in which the TTL is counted. The maximum value of the 8-bit TTL field in an IP packet is 255; instead of accepting only packets with a TTL set to 1, 

we can accept only packets with a TTL of 255 to ensure the originator really is exactly one hop away. This is accomplished on IOS with the TTL security feature, by appending ttl-security hops <count> to the BGP peer statement, please refer to the network picture as 

attachment_2. 
Only BGP messages with an IP TTL greater than or equal to 255 minus the specified hop 

count will be accepted. TTL security and EBGP multihop are mutually exclusive; ebgp-multihop is no longer needed when TTL security is in use. 

thanks for sharing ...............

By default, IOS sends BGP messages to EBGP neighbors with an IP time-to-live (TTL) of 1. (This can be adjusted with ebgp-multihop attached to the desired neighbor or peer group under BGP configuration.) 

the above question was very meaningful..

add more case study

nice writing