Networks Horizon

share

Wednesday 22 February 2012

Continue....
Border Gateway Protocol 
BGP-version 4- Part 2


BGP Split Horizon


Routes learned from eBGP neighborhip on ingress router will never be advertised to another iBGP peer in the same AS.


This rule is BGPs loop prevention method in iBGP. Rule is enabled by default assuming that there is a full mess between all the BGP running Routers within an AS. So to prevent any loop in full BGP mess, this rule is kept enabled.


It is also unreal to have BGP neighborship from ingress BGP router with all BGP running routers in an AS(or ISP environment) or you can say ONE-to-ALL relationship is not recommended when number of bgp routers are in thousands which will increase processre overload and config overhead. 


In this case also, Route Reflector came to the picture. Neighbor relationship is established with RRs(backup and primary). RR as the name suggest RRs reflect the route learned from one bgp router to another bgp client or non-client routers. We will discuss Route Reflector concept in detail in coming sessions.


BGP Attributes


BGP path attributes describe the values that belong to the the routes sent in a BGP UPDATE message. All attributes contained in an UPDATE message apply to all routes specified by the NLRI field of the UPDATE.


Well Known
Attributes those are supported by all BGP running routers and processes.
  • Mandatory: Attributes those are supported by all BGP running processes and also must be in all BGP update message. For example: ORIGIN. AS-PATH, NEXT HOP
  • Discretionary:Attributes those are supported by all BGP running processes and administrator decides whether to include them in BGP update message or not. For example: LOCAL PREFERENCE, ATOMIC AGGREGATE
Optional
 Some BGP processes on different routers/devices may not support these attributes.
  • Transitive: These attributes traverse autonomous systems other than its own. For example: AGGREGATER, COMMUNITY.
  • Non-Transitive: These attributes remain in autonomous system where they are generated from. For example : MED, Originator_ID, CLUSTOR_LIST.
Note: Why BGP WEIGHT attribute does not fall under any path attribute category?


eBGP (Non-directly connected) neighbors


By the rule, eBGP neighbor-ship should be directly connected. To overrule this rule, neighbor "ebgp-multihop" command is used.


In other words, to accept and attempt BGP connections to the external peers residing on networks that are not directly connected, we need to use either 'neighbor ebgp-multihop ' or 'neighbor ttl-security ' command. These two commands are interchangable. We can use another command 'neighbor disable-connected-check' to accomplish the same task if the BGP neighbor is one-hop away.


Router1(config_router)# neighbor 5.5.5.5 ebgp-multihop 2
Above command means eBGP neighbor is 2 hops away.


Difference between "ebgp-multihop" and "ttl-security" command


This is additional   lightweight security mechanism  in BGP to protect BGP peering sessions from CPU utilization-based attacks. These types of attacks are typically brute force Denial of Service (DoS) attacks that attempt to disable the network by flooding the network with IP packets that contain forged source and destination IP addresses in the packet headers.



iN SUMMARY, Where ebg-multihop depends on routers to drop it as the ttl is decremented to 0, TTL Security expects a minimum value. 


neighbor ebgp-multihop <ttl value>   
As already said TTL value for packet will be set here and decreaments as it passes hop by hop.


neighbor ttl-security hops <number of hops>


Clearly specifies how many hops away the ebgp neighbor is.
In this case routers set initial TTL to 255 and will not accept packets with TTL value of lest than 255-<hops>


In this example


If "neighbor 10.1.1.1 ttl-security hops 2" is set.

example sets the hop count to 2 because the hop-count argument is set to 2 and BGP will accept only IP packets with a TTL count in the header that is equal to or greater than 253 (253 or 254). If a packet is received with any other TTL value in the IP packet header, the packet will be silently discarded.


If we are using Router1(config_router)# neighbor 5.5.5.5 ebgp-multihop 2 command, TTL value will be taken as 2 and 1 only but hop count is still 2. This given an opportunity to hacker to reduce TTL value to a significant number and sent fake IP packets to cause high CPU utilization.


So this way ttl-security helps reduce the opportunity for an attacker to be successful, due to perhaps not knowing how many hops are required between the attacker and the BGP speaker. 



When this feature is enabled, BGP will establish or maintain a session only if the TTL value in the IP packet header is equal to or greater than the expected TTL value configured for the peering session. This feature only verifies the number of hops that separate the two BGP peers. The BGP peering session can still expire if keepalive packets are not received. If a packet is received with a TTL count that is less than expected number, the packet is silently discarded and no Internet Control Message Protocol (ICMP) message is generated. 


Command "neighbor disable-connected-check"


This option (disable-connected-check) does not increment TTL but relies on the fact that the routers ARE directly connected only peering between loopbacks is used. The difference between this and ebgp-multihop is that in the latter one we can tune TTL value allowing multiple transit routers between the two BGP peers. In the former option (disable-connected-check), the routers must be directly connected (1 hop since TTL=1).








                                              Please read BGP-version 4- Part 3 for more information.

No comments:

Post a Comment