tag:blogger.com,1999:blog-72395193738652267012024-03-19T00:43:41.367-07:00Routing ProtocolsUnknownnoreply@blogger.comBlogger40125tag:blogger.com,1999:blog-7239519373865226701.post-18520686177628455972008-11-13T22:32:00.001-08:002022-08-26T01:56:36.029-07:00show ip bgp injected-paths<p><span style="font-weight: bold;">show ip bgp injected-paths</span>
To display all the injected paths in the BGP routing table, use the show ip bgp injected-paths command in EXEC mode.
</p><blockquote>show ip bgp injected-paths</blockquote><span style="font-weight: bold;">Syntax Description</span>: This command has no arguments or keywords.
<span style="font-weight: bold;">Command Modes</span> EXEC
<span style="font-weight: bold;">Examples
</span><a set="yes" linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtnivFFZKHP74izQC-XPQMP0HbNXG2y2PX53xaNlyZGFJt1x6-kQWGjOgTURPH45z_EerzXAjDEhBzvq77-x8QjRqmLxUzZ1M1NiR0ti3_VfboekfkpyGNjBRYRpSBlVx2thYhhRcDIQ/s1600-h/Image55.JPG"><img style="cursor: pointer; width: 664px; height: 394px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtnivFFZKHP74izQC-XPQMP0HbNXG2y2PX53xaNlyZGFJt1x6-kQWGjOgTURPH45z_EerzXAjDEhBzvq77-x8QjRqmLxUzZ1M1NiR0ti3_VfboekfkpyGNjBRYRpSBlVx2thYhhRcDIQ/s400/Image55.JPG" alt="" id="BLOGGER_PHOTO_ID_5264497601516376338" border="0" /></a>Unknownnoreply@blogger.comtag:blogger.com,1999:blog-7239519373865226701.post-64070952691589550532008-11-13T22:31:00.002-08:002008-11-13T22:32:17.843-08:00show ip bgp<p><span style="font-weight: bold;">show ip bgp</span><br /><br />To display entries in the Border Gateway Protocol (BGP) routing table, use the show ip bgp command in EXEC command.<br /><br />show ip bgp [network] [network-mask] [longer-prefixes] [prefix-list prefix-list-name | route-map<br />route-map-name] [shorter prefixes mask-length]<br /><br /><span style="font-weight: bold;">Syntax</span><br /></p><ol><li><span style="font-weight: bold;">network</span> (Optional) Network number, entered to display a particular network in the BGP routing table.</li><li><span style="font-weight: bold;">network-mask </span>(Optional) Displays all BGP routes matching the address and mask pair.</li><li><span style="font-weight: bold;">longer-prefixes </span>(Optional) Displays the route and more specific routes.</li><li><span style="font-weight: bold;">prefix-list | route-map </span>(Optional) Displays selected routes from a BGP routing table based on the contents of a prefix list or route map.</li><li><span style="font-weight: bold;">prefix-list-name | route-map-name </span>(Optional) The name of the route map or prefix list that is specified for the above argument.</li><li><span style="font-weight: bold;">shorter prefixes mask-length </span>(Optional) Displays learned prefixes that are longer than the maximum length but shorter than the specified mask for the prefix.</li></ol><span style="font-weight: bold;">Command Modes</span> : EXEC<br /><br />Examples: <span style="font-size: 130%;"><span style="color: rgb(0, 0, 153);">(</span><span style="font-weight: bold; color: rgb(0, 0, 153);">Please Click for Clear View</span><span style="color: rgb(0, 0, 153);">)</span></span><br /><br /><a set="yes" linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjY7tRF477VxGksimQOyLR2RUb678ObkKs50sXEZu5j_sG-DVCE_PI_BkBN71q6FhzID_havB-3AHaw6Q_5tFzsVmz1y4ffhfJJQZLK4W7dGClQEwbo0Hz4g8ZhLcwXhfFzlVg3kZqVJA/s1600-h/Image51.JPG"><img style="cursor: pointer; width: 671px; height: 274px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjY7tRF477VxGksimQOyLR2RUb678ObkKs50sXEZu5j_sG-DVCE_PI_BkBN71q6FhzID_havB-3AHaw6Q_5tFzsVmz1y4ffhfJJQZLK4W7dGClQEwbo0Hz4g8ZhLcwXhfFzlVg3kZqVJA/s320/Image51.JPG" alt="" id="BLOGGER_PHOTO_ID_5264495679930697522" border="0" /></a><br /><span style="font-weight: bold;"></span><br /><br /><a set="yes" linkindex="4" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirROU9zgymJJ9dkxXQfk0juXbHRmiGq6rfi5ThVZx_SLVBtbQJmj0QFq5GpomtpHApTBF-hMjjaKTuBPmoJjSUg34woLrt65bBiEysh9Fx4XbE5iK7FTz9U8gnQi9fFn7vkfcE2Nt2Fw/s1600-h/Image52.JPG"><img style="cursor: pointer; width: 657px; height: 688px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirROU9zgymJJ9dkxXQfk0juXbHRmiGq6rfi5ThVZx_SLVBtbQJmj0QFq5GpomtpHApTBF-hMjjaKTuBPmoJjSUg34woLrt65bBiEysh9Fx4XbE5iK7FTz9U8gnQi9fFn7vkfcE2Nt2Fw/s320/Image52.JPG" alt="" id="BLOGGER_PHOTO_ID_5264495686228922642" border="0" /></a><br /><br /><a set="yes" linkindex="5" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhFSuTFRoi_QtY7PuQ1oEMHTH42uR6mZTIwiK9-CBmx9qQjzwDhKgblCujKFrjGInnYBYzCV_ZIP0eSFvKlxb7UWTYmNG03WqQZp4K1Qj7MOFuzMNoQSU6vjSlGIGX2kT-oaD3glRC9Og/s1600-h/Image53.JPG"><img style="cursor: pointer; width: 654px; height: 926px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhFSuTFRoi_QtY7PuQ1oEMHTH42uR6mZTIwiK9-CBmx9qQjzwDhKgblCujKFrjGInnYBYzCV_ZIP0eSFvKlxb7UWTYmNG03WqQZp4K1Qj7MOFuzMNoQSU6vjSlGIGX2kT-oaD3glRC9Og/s320/Image53.JPG" alt="" id="BLOGGER_PHOTO_ID_5264495700554429586" border="0" /></a><br /><br /><a set="yes" linkindex="6" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiGuDPBONxX1XqAb-BivxEhOj193kk6J_oIkGh4PWnVy2w2SFR-vCyGLS8HZ38hO0d0u8CZqjK5rxPdqm1Z7GvLBK_W5XTwaIQBb58cXMEnFEvoTy4md-8P0vGdGn4HhtZnQalW6j8Zyg/s1600-h/Image54.JPG"><img style="cursor: pointer; width: 659px; height: 220px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiGuDPBONxX1XqAb-BivxEhOj193kk6J_oIkGh4PWnVy2w2SFR-vCyGLS8HZ38hO0d0u8CZqjK5rxPdqm1Z7GvLBK_W5XTwaIQBb58cXMEnFEvoTy4md-8P0vGdGn4HhtZnQalW6j8Zyg/s320/Image54.JPG" alt="" id="BLOGGER_PHOTO_ID_5264495709079741074" border="0" /></a><br /><br /><span style="font-weight: bold;">Related Commands</span><br /><ul><li><span style="font-weight: bold;">clear ip bgp</span> Resets a BGP connection or session.</li><li><span style="font-weight: bold;">neighbor soft-reconfiguration</span> Configures the Cisco IOS software to start storing updates.</li></ul>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-25644028346921442052008-11-13T22:31:00.001-08:002008-11-13T22:31:46.059-08:00bgp inject-map exist-map<span style="font-weight: bold;">bgp inject-map exist-map</span><br /><br />To inject a more specific route into a Border Gateway Protocol (BGP) routing table, use the bgp inject-map exist-map command in address family or router configuration mode. To disable the conditional injection of a selected route, use the no form of this command.<br /><br />bgp inject-map {inject-map-name} exist-map {exist-map-name}[copy-attributes]<br />no bgp inject-map {inject-map-name} exist-map {exist-map-name}[copy-attributes]<br /><br /><span style="font-weight: bold;">Syntax</span>: inject-map-name <br /><span style="font-weight: bold;">Description</span>: Defines the prefixes that will be created and installed to the local BGP table.<br /><br /><span style="font-weight: bold;">Syntax</span>: exist-map-name <br /><span style="font-weight: bold;">Description: </span>Specifies the prefix that the BGP speaker will track.<br /><br /><br /><span style="font-weight: bold;">Syntax</span>: copy-attributes <br /><span style="font-weight: bold;">Description: </span>(Optional) Configures the injected route to inherit the attributes of the aggregate route.<br /><br /><span style="font-weight: bold;">Defaults: </span>The BGP Conditional Route Injection feature is not enabled by default.<br /><br /><span style="font-weight: bold;">Command Modes: </span>Address family configuration, Router configuration<br /><br /><span style="font-weight: bold;">Usage Guidelines: </span><br />If the copy-attributes keyword is not specified when the bgp inject-map command is used, thecomponents will use the default attributes for locally originated routes. If the copy-attribute keyword is used, the components will inherit the same attributes as the aggregate route.<br /><br />To enable conditional route injection, the exist-map must contain both the match ip address prefix-list and match ip route-source prefix-list match clauses in the route map paragraph.<br /><br /><span style="font-weight: bold;">Examples:</span><br /><br />The following example configures the router for conditional route injection:<br /><br />(config-router)# bgp inject-map map1 exist-map map2 copy-attributes<br /><br /><span style="font-weight: bold;">Related Commands:<br /></span><ul><li><span style="font-weight: bold;">ip prefix-list </span>-> Displays information about a prefix list or prefix list entries.</li><li><span style="font-weight: bold;">neighbor remote-as </span>-> Adds an entry to the BGP or multiprotocol BGP neighbor table.</li><li><span style="font-weight: bold;">route-map (IP)</span> -> Defines the conditions for redistributing routes from one routing protocol into another, or enables policy routing.</li><li><span style="font-weight: bold;">show ip bgp </span>-> Displays entries in the BGP routing table.</li><li><span style="font-weight: bold;">show ip bgp injected-paths </span>-> Displays injected paths in the BGP routing table.</li></ul>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-12237289310790132082008-11-13T22:30:00.002-08:002008-11-13T22:31:15.570-08:00BGP Configuration Examples<p>This following configuration example configures conditional route injection for the inject-map named ORIGINATE and the exist-map named LEARNED_PATH:<br /><br /></p><blockquote>router bgp 109<br />bgp inject-map ORIGINATE exist-map LEARNED_PATH<br />!<br />route-map LEARNED_PATH permit 10<br />match ip address prefix-list ROUTE<br />match ip route-source prefix-list ROUTE_SOURCE<br />!<br />route-map ORIGINATE permit 10<br />set ip address prefix-list ORIGINATED_ROUTES<br />set community 14616:555 additive<br />!<br />ip prefix-list ROUTE permit 10.1.1.0/24<br />!<br />ip prefix-list ORIGINATED_ROUTES permit 10.1.1.0/25<br />ip prefix-list ORIGINATED_ROUTES permit 10.1.1.128/25<br />!<br />ip prefix-list ROUTE_SOURCE permit 10.2.1.1/32</blockquote>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-55029875616065419652008-11-13T22:30:00.001-08:002008-11-13T22:30:42.571-08:00BGP Troubleshooting Tips<div style="text-align: justify;">The BGP Conditional Route Injection feature is based on the injection of a more specific prefix into theBGP routing table when a less specific prefix is present. If conditional route injection is not workingproperly, check the following:<br /></div><br />If conditional route injection is configured but does not occur, check for the existence of the aggregate prefix in the BGP routing table. The existence (or not) of the tracked prefix in the BGP<br /><div style="text-align: justify;">routing table can be verified with the show ip bgp command.<br /></div><br />If the aggregate prefix exists but conditional route injection does not occur, verify that the aggregate prefix is being received from the correct neighbor and the prefix list identifying that neighbor is a /32 match.<br /><br />Verify the injection (or not) of the more specific prefix using the show ip bgp injected-paths command.<br /><br />Verify that the prefix that is being injected is not outside of the scope of the aggregate prefix.<br /><br />Ensure that the inject route map is configured with the set ip address command and not the match <span style="font-weight: bold;">ip address</span> command.<br /><br /><span style="font-weight: bold; color: rgb(0, 0, 153);">Monitoring and Maintaining BGP Conditional Route Injection</span><br /><br />To display BGP conditional advertisement information, use the following commands in EXEC mode, as needed:<br /><br />Command: Router# show ip bgp<br />Purpose: Displays entries in the BGP routing table.<br /><br />Command: Router# show ip bgp injected-paths<br />Purpose: Displays paths in the BGP routing table that were conditionally injected.<br /><br />Command: Router# show ip bgp neighbors<br />Purpose: Displays information about the TCP and BGP connections to neighbors.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-67265508512995774202008-11-13T22:29:00.000-08:002008-11-13T22:30:07.084-08:00Verifying BGP Conditional Route Injection<p>To verify that the BGP Conditional Route Injection feature is configured correctly, use the show ip bgp or show ip bgp injected-paths command.<br /><br />The following sample output is similar to the output that will be displayed when the show ip bgp<br />command is entered:<br /><br /></p><blockquote>Router# show ip bgp 172.16.0.0<br />BGP routing table entry for 172.16.0.0/8, version 13<br />Paths:(2 available, best #1, table Default-IP-Routing-Table)<br />Flag:0x200<br />Not advertised to any peer<br />Local, (injected path from 172.16.0.0/8)<br />10.0.0.2 from 10.0.0.2 (2.2.2.2)<br />Origin incomplete, localpref 100, valid, external, best<br />Community:957874231<br />200<br />10.0.0.2 from 10.0.0.2 (2.2.2.2)<br />Origin incomplete, metric 0, localpref 100, valid, external</blockquote><br />The following sample output is similar to the output that will be displayed when the show ip bgp<br />injected-routes command is entered:<br /><br /><blockquote>Router# show ip bgp injected-paths<br />BGP table version is 11, local router ID is 10.0.0.1<br />Status codes:s suppressed, d damped, h history, * valid, > best, i - internal<br />Origin codes:i - IGP, e - EGP, ? - incomplete<br /></blockquote><br /><br /><table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td align="undefined" valign="undefined"><br /></td><td align="undefined" valign="undefined">Network</td><td align="undefined" valign="undefined">Next Hop</td><td align="undefined" valign="undefined">Metric</td><td align="undefined" valign="undefined">LocPrf</td><td align="undefined" valign="undefined">Weight</td><td align="undefined" valign="undefined">Path</td></tr><tr><td align="undefined" valign="undefined">*></td><td align="undefined" valign="undefined">172.16.0.0</td><td align="undefined" valign="undefined">10.0.0.2</td><td align="undefined" valign="undefined"><br /></td><td align="undefined" valign="undefined"><br /></td><td align="undefined" valign="undefined">0</td><td align="undefined" valign="undefined">?</td></tr><tr><td align="undefined" valign="undefined">*></td><td align="undefined" valign="undefined">172.17.0.0/16</td><td align="undefined" valign="undefined">10.0.0.2</td><td align="undefined" valign="undefined"><br /></td><td align="undefined" valign="undefined"><br /></td><td align="undefined" valign="undefined">0</td><td align="undefined" valign="undefined">?</td></tr></tbody></table>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-56441293173967377492008-11-13T22:28:00.002-08:002008-11-13T22:29:27.877-08:00Configuring BGP Conditional Route Injection<div style="text-align: justify;">The BGP Conditional Route Injection feature is supported by all platforms in Cisco IOS Release 12.2(14)S that support BGP:<br /><br />• Cisco 7200 series<br />• Cisco 7400 series<br />• Cisco 7500 series<br /><br />Determining Platform Support Through Cisco Feature Navigator Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature. Cisco Feature Navigator is a web-based tool that enables you to determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.<br /><br />You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.<br /></div><br />See the following section for configuration tasks for the BGP Conditional Route Injection feature. Each task in the list is identified as either required or optional.<br /><br />• Configuring BGP Conditional Route Injection (required)<br />• Verifying BGP Conditional Route Injection (optional)<br /><br />To configure the BGP Conditional Route Injection feature, use the following commands beginning in global configuration mode:<br /><br /><table style="width: 100%; text-align: left; margin-left: 0px; margin-right: auto;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td style="width: 79px;" align="undefined" valign="undefined"><br /></td><td style="font-weight: bold; width: 324px;" align="undefined" valign="undefined">Command</td><td style="font-weight: bold; text-align: justify; width: 351px;" valign="undefined">Purpose</td></tr><tr><td style="width: 79px;" align="undefined" valign="undefined">Step 1</td><td style="width: 324px;" align="undefined" valign="undefined">Router(config)# router bgp as-number</td><td style="text-align: justify; width: 351px;" valign="undefined">Places the router in router configuration mode, and configures the router to run a BGP process.</td></tr><tr><td style="width: 79px;" align="undefined" valign="undefined">Step 2</td><td style="width: 324px;" align="undefined" valign="undefined">Router(config-router)# bgp inject-map ORIGINATE<br />exist-map LEARNED_PATH</td><td style="text-align: justify; width: 351px;" valign="undefined">Configures the inject-map named ORIGINATE and the exist-map named LEARNED_PATH for conditional route injection.</td></tr><tr><td style="width: 79px;" align="undefined" valign="undefined">Step 3</td><td style="width: 324px;" align="undefined" valign="undefined">Router(config-router)# exit</td><td style="text-align: justify; width: 351px;" valign="undefined">Exits router configuration mode, and enters global configuration mode.</td></tr><tr><td style="width: 79px;" align="undefined" valign="undefined">Step 4</td><td style="width: 324px;" align="undefined" valign="undefined">Router(config)# route-map LEARNED_PATH permit<br />sequence-number</td><td style="text-align: justify; width: 351px;" valign="undefined">Configures the route map named<br />LEARNED_PATH.</td></tr><tr><td style="width: 79px;" align="undefined" valign="undefined">Step 5</td><td style="width: 324px;" align="undefined" valign="undefined">Router(config-route-map)# match ip address prefix-list<br />ROUTE</td><td style="text-align: justify; width: 351px;" valign="undefined">Specifies the aggregate route to which a more specific route will be injected.</td></tr><tr><td style="width: 79px;" align="undefined" valign="undefined">Step 6</td><td style="width: 324px;" align="undefined" valign="undefined">Router(config-route-map# match ip route-source<br />prefix-list ROUTE_SOURCE</td><td style="text-align: justify; width: 351px;" valign="undefined">Configures the prefix list named<br />ROUTE_SOURCE to redistribute the source of the route.<br /><br />Note: The route source is the neighbor address that is configured with the neighbor remote-as command. The tracked prefix must come from this neighbor in order for conditional route injection to occur.</td></tr><tr><td style="width: 79px;" align="undefined" valign="undefined">Step 7</td><td style="width: 324px;" align="undefined" valign="undefined">Router(config-route-map)# exit</td><td style="text-align: justify; width: 351px;" valign="undefined">Exits route-map configuration mode, and enters global configuration mode.</td></tr><tr><td style="width: 79px;" align="undefined" valign="undefined">Step 8</td><td style="width: 324px;" align="undefined" valign="undefined">Router(config)# route-map ORIGINATE permit 10</td><td style="text-align: justify; width: 351px;" valign="undefined">Configures the route map named ORIGINATE.</td></tr><tr><td style="width: 79px;" align="undefined" valign="undefined">Step 9</td><td style="width: 324px;" align="undefined" valign="undefined">Router(config-route-map)# set ip address prefix-list ORIGINATED_ROUTES</td><td style="text-align: justify; width: 351px;" valign="undefined">Specifies the routes to be injected.</td></tr><tr><td style="width: 79px;" align="undefined" valign="undefined">Step 10</td><td style="width: 324px;" align="undefined" valign="undefined">Router(config-route-map)# set community community-attribute additive</td><td style="text-align: justify; width: 351px;" valign="undefined">Configures the community attribute of the injected routes.</td></tr><tr><td style="width: 79px;" align="undefined" valign="undefined">Step 11</td><td style="width: 324px;" align="undefined" valign="undefined">Router(config-route-map)# exit</td><td style="text-align: justify; width: 351px;" valign="undefined">Exits route-map configuration mode, and enters global configuration mode.</td></tr><tr><td style="width: 79px;" align="undefined" valign="undefined">Step 12</td><td style="width: 324px;" align="undefined" valign="undefined">Router(config)# ip prefix-list ROUTE permit<br />10.1.1.0/24</td><td style="text-align: justify; width: 351px;" valign="undefined">Configures the prefix list named ROUTE to permit routes from network 10.1.1.0/24.</td></tr><tr><td style="width: 79px;" align="undefined" valign="undefined">Step 13</td><td style="width: 324px;" align="undefined" valign="undefined">Router(config)# ip prefix-list ORIGINATED_ROUTES<br />permit 10.1.1.0/25</td><td style="text-align: justify; width: 351px;" valign="undefined">Configures the prefix list named<br />ORIGINATED_ROUTES to permit routes from network 10.1.1.0/25.</td></tr><tr><td style="width: 79px;" align="undefined" valign="undefined">Step 14</td><td style="width: 324px;" align="undefined" valign="undefined">Router(config)# ip prefix-list ORIGINATED_ROUTES<br />permit 10.1.1.128/25</td><td style="text-align: justify; width: 351px;" valign="undefined">Configures the prefix list named<br />ORIGINATED_ROUTES to permit routes from network 10.1.1.0/25.</td></tr><tr><td style="width: 79px;" align="undefined" valign="undefined">Step 15</td><td style="width: 324px;" align="undefined" valign="undefined">Router(config)# ip prefix-list ROUTE_SOURCE permit<br />10.2.1.1/32</td><td style="text-align: justify; width: 351px;" valign="undefined">Configures the prefix list named<br />ROUTE_SOURCE to permit routes from network 10.2.1.1/32.<br /><br />Note: The route source prefix list must be configured with a /32 mask in order for conditional route injection to occur.</td></tr><tr align="justify"><td colspan="3" rowspan="1" style="width: 79px;" valign="undefined"><span style="font-weight: bold;">Note</span>: To enable conditional route injection, the exist-map must contain both the match ip address prefix-list and match ip route-source prefix-list match clauses in the route map paragraph.</td></tr></tbody></table>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-30350186988878646242008-11-13T22:28:00.001-08:002008-11-13T22:28:47.472-08:00BGP Route Flap Dampening<div style="text-align: justify;">Route dampening (introduced in Cisco IOS version 11.0) is a mechanism to minimize the instability caused by route flapping and oscillation over the network. To accomplish this, criteria are defined to identify poorly behaved routes. A route which is flapping gets a penalty for each flap (1000). As soon as the cumulative penalty reaches a predefined "suppress−limit", the advertisement of the route will be suppressed. The penalty will be exponentially decayed based on a preconfigured "half−time". Once the penalty decreases below a predefined "reuse−limit", the route advertisement will be un−suppressed.<br /><br />Routes, external to an AS, learned via IBGP will not be dampened. This is to avoid the IBGP peers having higher penalty for routes external to the AS.<br /><br />The penalty will be decayed at a granularity of 5 seconds and the routes will be un−suppressed at a granularity of 10 seconds. The dampening information is kept until the penalty becomes less than half of "reuse−limit" , at that point the information is purged from the router.<br /><br />Initially, dampening will be off by default. This might change if there is a need to have this feature enabled by default. The following are the commands used to control route dampening:<br /><br /></div><ul style="text-align: justify;"><li>bgp dampening (will turn on dampening)</li><li>no bgp dampening (will turn off dampening)</li><li>bgp dampening <half−life−time> (will change the half−life−time)</half−life−time></li></ul><div style="text-align: justify;"><br />A command that sets all parameters at the same time is:<br /><br /></div><ul style="text-align: justify;"><li>bgp dampening <half−life−time> <reuse> <suppress> <maximum−suppress−time></maximum−suppress−time></suppress></reuse></half−life−time></li><li><half−life−time> (range is 1−45 min, current default is 15 min)</half−life−time></li><li><reuse−value> (range is 1−20000, default is 750)</reuse−value></li><li><suppress−value> (range is 1−20000, default is 2000)</suppress−value></li><li><max−suppress−time> (maximum duration a route can be suppressed, range is 1−255, default is 4 times half−life−time)<br /></max−suppress−time></li></ul><div style="text-align: justify;"><blockquote>RTB#<br />hostname RTB<br />interface Serial0<br />ip address 203.250.15.2 255.255.255.252<br />interface Serial1<br />ip address 192.208.10.6 255.255.255.252<br />router bgp 100<br />bgp dampening<br />network 203.250.15.0<br />neighbor 192.208.10.5 remote−as 300<br /><br />RTD#<br />hostname RTD<br />interface Loopback0<br />ip address 192.208.10.174 255.255.255.192<br />interface Serial0/0<br />ip address 192.208.10.5 255.255.255.252<br />router bgp 300<br />network 192.208.10.0<br />neighbor 192.208.10.6 remote−as 100</blockquote>RTB is configured for route dampening with default parameters. Assuming the EBGP link to RTD is stable, RTB's BGP table would look like this:<br /><br /><blockquote>RTB#show ip bgp<br />BGP table version is 24, local router ID is 203.250.15.2 Status codes: s<br />suppressed, d damped, h history, * valid, > best, i − internal Origin<br />codes: i − IGP, e − EGP, ? − incomplete<br /><br /><span style="font-family: courier new;"></span></blockquote><span style="font-family: Courier New,Courier,monospace;"></span></div><table style="text-align: left; width: 661px; margin-left: 0px; margin-right: 0px;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td align="undefined" valign="undefined"><br /></td><td style="width: 120px;" align="undefined" valign="undefined">Network</td><td style="width: 121px;" align="undefined" valign="undefined">Next Hop</td><td style="width: 94px;" align="undefined" valign="undefined">Metric</td><td style="width: 70px;" align="undefined" valign="undefined">LocPrf</td><td style="width: 66px;" align="undefined" valign="undefined">Weight</td><td style="width: 92px;" align="undefined" valign="undefined">Path</td></tr><tr><td align="undefined" valign="undefined">*></td><td style="width: 120px;" align="undefined" valign="undefined">192.208.10.0</td><td style="width: 121px;" align="undefined" valign="undefined">192.208.10.5</td><td style="width: 94px;" align="undefined" valign="undefined">0</td><td style="width: 70px;" align="undefined" valign="undefined"><br /></td><td style="width: 66px;" align="undefined" valign="undefined">0</td><td style="width: 92px;" align="undefined" valign="undefined">300 i</td></tr><tr><td align="undefined" valign="undefined">*></td><td style="width: 120px;" align="undefined" valign="undefined">203.250.15.0</td><td style="width: 121px;" align="undefined" valign="undefined">0.0.0.0</td><td style="width: 94px;" align="undefined" valign="undefined">0</td><td style="width: 70px;" align="undefined" valign="undefined"><br /></td><td style="width: 66px;" align="undefined" valign="undefined">32768</td><td style="width: 92px;" align="undefined" valign="undefined">i</td></tr></tbody></table><div style="text-align: justify;"><span style="font-family: Courier New,Courier,monospace;"></span><br /><span style="font-family: Courier New,Courier,monospace;"></span><span style="font-family: courier new;">In order to simulate a route flap, use clear ip bgp 192.208.10.6 on RTD. RTB's BGP table will look like this:</span><br /><span style="font-family: courier new;"></span><br />RTB#show ip bgp<br />BGP table version is 24, local router ID is 203.250.15.2 Status codes: s<br />suppressed, d damped, h history, * valid, > best, i − internal Origin<br />codes: i − IGP, e − EGP, ? − incomplete<br /><br /><span style="font-family: Courier New,Courier,monospace;"></span><br /><span style="font-family: Courier New,Courier,monospace;"></span></div><table style="text-align: left; width: 661px; margin-left: 0px; margin-right: 0px;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td align="undefined" valign="undefined"><br /></td><td style="width: 120px;" align="undefined" valign="undefined">Network</td><td style="width: 121px;" align="undefined" valign="undefined">Next Hop</td><td style="width: 94px;" align="undefined" valign="undefined">Metric</td><td style="width: 70px;" align="undefined" valign="undefined">LocPrf</td><td style="width: 66px;" align="undefined" valign="undefined">Weight</td><td style="width: 92px;" align="undefined" valign="undefined">Path</td></tr><tr><td align="undefined" valign="undefined">h</td><td style="width: 120px;" align="undefined" valign="undefined">192.208.10.0</td><td style="width: 121px;" align="undefined" valign="undefined">192.208.10.5</td><td style="width: 94px;" align="undefined" valign="undefined">0</td><td style="width: 70px;" align="undefined" valign="undefined"><br /></td><td style="width: 66px;" align="undefined" valign="undefined">0</td><td style="width: 92px;" align="undefined" valign="undefined">300 i</td></tr><tr><td align="undefined" valign="undefined">*></td><td style="width: 120px;" align="undefined" valign="undefined">203.250.15.0</td><td style="width: 121px;" align="undefined" valign="undefined">0.0.0.0</td><td style="width: 94px;" align="undefined" valign="undefined">0</td><td style="width: 70px;" align="undefined" valign="undefined"><br /></td><td style="width: 66px;" align="undefined" valign="undefined">32768</td><td style="width: 92px;" align="undefined" valign="undefined">i</td></tr></tbody></table><div style="text-align: justify;"><span style="font-family: Courier New,Courier,monospace;"></span><br /><span style="font-family: Courier New,Courier,monospace;"></span>The BGP entry for 192.208.10.0 has been put in a "history" state. Which means that we do not have a best path to the route but information about the route flapping still exists.<br /><br /><blockquote>RTB#show ip bgp 192.208.10.0<br />BGP routing table entry for 192.208.10.0 255.255.255.0, version 25<br />Paths: (1 available, no best path)<br />300 (history entry)<br />192.208.10.5 from 192.208.10.5 (192.208.10.174)<br />Origin IGP, metric 0, external<br />Dampinfo: penalty 910, flapped 1 times in 0:02:03</blockquote>The route has been given a penalty for flapping but the penalty is still below the "suppress limit" (default is 2000). The route is not yet suppressed. If the route flaps few more times we will see the following:<br /><br />RTB#show ip bgp<br />BGP table version is 32, local router ID is 203.250.15.2 Status codes:<br />s suppressed, d damped, h history, * valid, > best, i − internal Origin codes:<br />i − IGP, e − EGP, ? − incomplete<br /><span style="font-family: Courier New,Courier,monospace;"></span><br /><span style="font-family: Courier New,Courier,monospace;"></span></div><table style="text-align: left; width: 661px; margin-left: 0px; margin-right: 0px;" border="1" cellpadding="2" cellspacing="2"><tbody><tr><td align="undefined" valign="undefined"><br /></td><td style="width: 120px;" align="undefined" valign="undefined">Network</td><td style="width: 121px;" align="undefined" valign="undefined">Next Hop</td><td style="width: 94px;" align="undefined" valign="undefined">Metric</td><td style="width: 70px;" align="undefined" valign="undefined">LocPrf</td><td style="width: 66px;" align="undefined" valign="undefined">Weight</td><td style="width: 92px;" align="undefined" valign="undefined">Path</td></tr><tr><td align="undefined" valign="undefined">*d</td><td style="width: 120px;" align="undefined" valign="undefined">192.208.10.0</td><td style="width: 121px;" align="undefined" valign="undefined">192.208.10.5</td><td style="width: 94px;" align="undefined" valign="undefined">0</td><td style="width: 70px;" align="undefined" valign="undefined"><br /></td><td style="width: 66px;" align="undefined" valign="undefined">0</td><td style="width: 92px;" align="undefined" valign="undefined">300 i</td></tr><tr><td align="undefined" valign="undefined">*></td><td style="width: 120px;" align="undefined" valign="undefined">203.250.15.0</td><td style="width: 121px;" align="undefined" valign="undefined">0.0.0.0</td><td style="width: 94px;" align="undefined" valign="undefined">0</td><td style="width: 70px;" align="undefined" valign="undefined"><br /></td><td style="width: 66px;" align="undefined" valign="undefined">32768</td><td style="width: 92px;" align="undefined" valign="undefined">i</td></tr></tbody></table><div style="text-align: justify;"><span style="font-family: Courier New,Courier,monospace;"></span><br /><blockquote>RTB#show ip bgp 192.208.10.0<br />BGP routing table entry for 192.208.10.0 255.255.255.0, version 32<br />Paths: (1 available, no best path)<br />300, (suppressed due to dampening)<br />192.208.10.5 from 192.208.10.5 (192.208.10.174)<br />Origin IGP, metric 0, valid, external<br />Dampinfo: penalty 2615, flapped 3 times in 0:05:18 , reuse in 0:27:00<br /></blockquote><br />The route has been dampened (suppressed). The route will be reused when the penalty reaches the "reuse value", in our case 750 (default).The dampening information will be purged when the penalty becomes less than half of the reuse−limit, in our case (750/2=375). The following are the commands used to show and clear flap statistics information:<br /></div><ul style="text-align: justify;"><li>show ip bgp flap−statistics (displays flap statistics for all the paths)</li><li>show ip bgp−flap−statistics regexp <regexp> (displays flap statistics for all paths that match the regexp)</regexp></li><li>show ip bgp flap−statistics filter−list <list> (displays flap statistics for all paths that pass the filter)</list></li><li>show ip bgp flap−statistics A.B.C.D m.m.m.m (displays flap statistics for a single entry)</li><li>show ip bgp flap−statistics A.B.C.D m.m.m.m longer−prefixes (displays flap statistics for more specific entries)</li><li>show ip bgp neighbor [dampened−routes] | [flap−statistics] (displays flap statistics for all paths from a neighbor)</li><li>clear ip bgp flap−statistics (clears flap statistics for all routes)</li><li>clear ip bgp flap−statistics regexp <regexp> (clears flap statistics for all the paths that match the regexp)</regexp></li><li>clear ip bgp flap−statistics filter−list <list> (clears flap statistics for all the paths that pass the filter)</list></li><li>clear ip bgp flap−statistics A.B.C.D m.m.m.m (clears flap statistics for a single entry)</li><li>clear ip bgp A.B.C.D flap−statistics (clears flap statistics for all paths from a neighbor)</li></ul>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-28332341052132342282008-11-13T22:27:00.000-08:002008-11-13T22:28:00.694-08:00RR and Conventional BGP Speakers<div style="float: left; text-align: justify;"> </div><div style="text-align: justify;"> </div><div style="float: right; text-align: justify;"> <script type="text/javascript"><!-- google_ad_client = "pub-3579557091670472"; google_ad_host = "pub-1599271086004685"; /* 120x90, created 11/6/08 */ google_ad_slot = "4649236024"; google_ad_width = 120; google_ad_height = 90; //--> </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script><script> window.google_render_ad(); </script><iframe name="google_ads_frame" src="http://pagead2.googlesyndication.com/pagead/ads?client=ca-pub-3579557091670472&host=pub-1599271086004685&dt=1226644031928&lmt=1226321287&prev_slotnames=9588015226&output=html&slotname=4649236024&correlator=1226644031879&url=http%3A%2F%2Fbgpconcepts.blogspot.com%2F2008%2F11%2Frr-and-conventional-bgp-speakers.html&ea=0&ref=http%3A%2F%2Fbgpconcepts.blogspot.com%2F2008%2F11%2Fbgp-multiple-rrs-within-cluster.html&frm=0&ga_vid=310241320.1226644032&ga_sid=1226644032&ga_hid=297870794&flash=9.0.124&u_h=800&u_w=1280&u_ah=740&u_aw=1280&u_cd=32&u_tz=330&u_his=29&u_java=true&u_nplug=25&u_nmime=102&dtd=3" marginwidth="0" marginheight="0" vspace="0" hspace="0" allowtransparency="true" scrolling="no" width="120" frameborder="0" height="90"></iframe> </div><div style="text-align: justify;"> <a set="yes" linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguAcyK-pl3hyU2mHr2iW6jJ9yE0wRSaK68AIFldSNZTre3aSiQWFBipYVBzPDI-URlerH2aC5AYTHTa6xCGpl-bAjP7MjmAXDMeVyaKjR6ny0ayE5hq487n74BX1Xsc58cn8GCmCfezQ/s1600-h/Image31.JPG"><img style="cursor: pointer; width: 320px; height: 230px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguAcyK-pl3hyU2mHr2iW6jJ9yE0wRSaK68AIFldSNZTre3aSiQWFBipYVBzPDI-URlerH2aC5AYTHTa6xCGpl-bAjP7MjmAXDMeVyaKjR6ny0ayE5hq487n74BX1Xsc58cn8GCmCfezQ/s320/Image31.JPG" alt="" id="BLOGGER_PHOTO_ID_5263946125131093874" border="0" /></a><br /><br /><br />It is normal in an AS to have BGP speakers that do not understand the concept of route reflectors. We will call these routers conventional BGP speakers. The route reflector scheme will allow such conventional BGP speakers to coexist. These routers could be either members of a client group or a non−client group. This would allow easy and gradual migration from the current IBGP model to the route reflector model. One could start creating clusters by configuring a single router as RR and making other RRs and their clients normal IBGP peers. Then more clusters could be created gradually.<br /><br />In the above diagram, RTD, RTE and RTF have the concept of route reflection. RTC, RTA and RTB are what we call conventional routers and cannot be configured as RRs. Normal IBGP mesh could be done between these routers and RTD. Later on, when we are ready to upgrade, RTC could be made a RR with clients RTA and RTB. Clients do not have to understand the route reflection scheme; it is only the RRs that would have to be upgraded.<br /><br />The following is the configuration of RTD and RTC:<br /><br />RTD#<br />router bgp 100<br />neighbor 6.6.6.6 remote−as 100<br />neighbor 6.6.6.6 route−reflector−client<br />neighbor 5.5.5.5 remote−as 100<br />neighbor 5.5.5.5 route−reflector−client<br />neighbor 3.3.3.3 remote−as 100<br />neighbor 2.2.2.2 remote−as 100<br />neighbor 1.1.1.1 remote−as 100<br />neighbor 13.13.13.13 remote−as 300<br /><br />RTC#<br />router bgp 100<br />neighbor 4.4.4.4 remote−as 100<br />neighbor 2.2.2.2 remote−as 100<br />neighbor 1.1.1.1 remote−as 100<br />neighbor 14.14.14.14 remote−as 400<br /><br />When we are ready to upgrade RTC and make it a RR, we would remove the IBGP full mesh and have RTA and RTB become clients of RTC.<br /><br /><span style="font-size: 130%;"><span style="font-weight: bold;">Avoiding Looping of Routing Information</span></span><br /><span style="font-size: 130%;"><span style="font-weight: bold;"></span></span><br /><span style="font-size: 130%;"><span style="font-weight: bold;"></span></span>We have mentioned so far two attributes that are used to prevent potential information looping:<br /><br />originator−id and cluster−list. Another means of controlling loops is to put more restrictions on the set clause of out−bound route−maps.<br /><br />The set clause for out−bound route−maps does not affect routes reflected to IBGP peers.<br /><br />More restrictions are also put on nexthop−self, which is a per neighbor configuration option. When used on RRs the nexthop−self will only affect the nexthop of EBGP learned routes because the nexthop of reflected routes should not be changed.</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-2986423246307317612008-11-13T22:26:00.000-08:002008-11-13T22:27:04.555-08:00BGP Multiple RRs within a Cluster<div style="text-align: justify;"><a set="yes" linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGRGLW_g3_tAZt4DLMhBTlnKhS6CLTMgWtAR1-8r92l26cC0NA6BOPTmsbeiIF-_1dXkBkGX3Uq-_gXMNTfa7CrFKuZv1CEgUoVWpvl09TdcdKLesbZs1MqniyB28FznpWXemybNZVIA/s1600-h/Image30.JPG"><img style="cursor: pointer; width: 320px; height: 296px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGRGLW_g3_tAZt4DLMhBTlnKhS6CLTMgWtAR1-8r92l26cC0NA6BOPTmsbeiIF-_1dXkBkGX3Uq-_gXMNTfa7CrFKuZv1CEgUoVWpvl09TdcdKLesbZs1MqniyB28FznpWXemybNZVIA/s320/Image30.JPG" alt="" id="BLOGGER_PHOTO_ID_5263945439355476018" border="0" /></a><br /><br />Usually, a cluster of clients will have a single RR. In this case, the cluster will be identified by the router ID of the RR. In order to increase redundancy and avoid single points of failure, a cluster might have more than one RR. All RRs in the same cluster need to be configured with a 4 byte cluster−id so that a RR can recognize updates from RRs in the same cluster.<br /><br />A cluster−list is a sequence of cluster−ids that the route has passed. When a RR reflects a route from its clients to non−clients outside of the cluster, it will append the local cluster−id to the cluster−list. If this update has an empty cluster−list the RR will create one. Using this attribute, a RR can identify if the routing information is looped back to the same cluster due to poor configuration. If the local cluster−id is found in the cluster−list, the advertisement will be ignored.<br /><br />In the above diagram, RTD, RTE, RTF and RTH belong to one cluster with both RTD and RTH being RRs for the same cluster. Note the redundancy in that RTH has a fully meshed peering with all the RRs. In case RTD goes down, RTH will take its place. The following are the configuration of RTH, RTD, RTF and RTC:<br /><br /><blockquote>RTH#<br />router bgp 100<br />neighbor 4.4.4.4 remote−as 100<br />neighbor 5.5.5.5 remote−as 100<br />neighbor 5.5.5.5 route−reflector−client<br />neighbor 6.6.6.6 remote−as 100<br />neighbor 6.6.6.6 route−reflector−client<br />neighbor 7.7.7.7 remote−as 100<br />neighbor 3.3.3.3 remote−as 100<br />neighbor 9.9.9.9 remote−as 300<br />bgp route−reflector 10 (This is the cluster−id)<br /><br />RTD#<br />router bgp 100<br />neighbor 10.10.10.10 remote−as 100<br />neighbor 5.5.5.5 remote−as 100<br />neighbor 5.5.5.5 route−reflector−client<br />neighbor 6.6.6.6 remote−as 100<br />neighbor 6.6.6.6 route−reflector−client<br />neighbor 7.7.7.7 remote−as 100<br />neighbor 3.3.3.3 remote−as 100<br />neighbor 11.11.11.11 remote−as 400<br />bgp route−reflector 10 (This is the cluster−id)<br /><br />RTF#<br />router bgp 100<br />neighbor 10.10.10.10 remote−as 100<br />neighbor 4.4.4.4 remote−as 100<br />neighbor 13.13.13.13 remote−as 500<br /><br />RTC#<br />router bgp 100<br />neighbor 1.1.1.1 remote−as 100<br />neighbor 1.1.1.1 route−reflector−client<br />neighbor 2.2.2.2 remote−as 100<br />neighbor 2.2.2.2 route−reflector−client<br />neighbor 4.4.4.4 remote−as 100<br />neighbor 7.7.7.7 remote−as 100<br />neighbor 10.10.10.10 remote−as 100<br />neighbor 8.8.8.8 remote−as 200</blockquote>Note that we did not need the cluster command for RTC because only one RR exists in that cluster. An important thing to note, is that peer−groups were not used in the above configuration. If the clients inside a cluster do not have direct IBGP peers among one another and they exchange updates through the RR, peer−goups should not be used. If peer groups were to be configured, then a potential withdrawal to the source of a route on the RR would be sent to all clients inside the cluster and could cause problems.<br /><br />The router sub−command bgp client−to−client reflection is enabled by default on the RR. If BGP<br />client−to−client reflection were turned off on the RR and redundant BGP peering was made between the clients, then using peer groups would be alright.<br /></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-73791461672201811622008-11-13T22:25:00.000-08:002008-11-13T22:26:16.532-08:00BGP Route Reflectors<div style="text-align: justify;">Another solution for the explosion of IBGP peering within an autonomous system is Route Reflectors (RR).<br /><br />As demonstrated in the Internal BGP section, a BGP speaker will not advertise a route learned via another IBGP speaker to a third IBGP speaker. By relaxing this restriction a bit and by providing additional control, we can allow a router to advertise (reflect) IBGP learned routes to other IBGP speakers. This will reduce the number of IBGP peers within an AS.<br /><br /><br /><a set="yes" linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgatjm15OOezokHMOZPWlVXrirGRwVB1mdXAGctuEhQ-ii57DRyQ1TMu26cVZomMIum6STiJUNG-5o8rE0uOTtorqMOXA-LlKUhzMHFFyd6P3ZPq81H9PxGMoFzwWMtPV-TY4XiIZH0AQ/s1600-h/Image28.JPG"><img style="cursor: pointer; width: 320px; height: 186px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgatjm15OOezokHMOZPWlVXrirGRwVB1mdXAGctuEhQ-ii57DRyQ1TMu26cVZomMIum6STiJUNG-5o8rE0uOTtorqMOXA-LlKUhzMHFFyd6P3ZPq81H9PxGMoFzwWMtPV-TY4XiIZH0AQ/s320/Image28.JPG" alt="" id="BLOGGER_PHOTO_ID_5263942285461590514" border="0" /></a><br /><br />In normal cases, a full IBGP mesh should be maintained between RTA, RTB and RTC within AS100. By utilizing the route reflector concept, RTC could be elected as a RR and have a partial IBGP peering with RTA and RTB. Peering between RTA and RTB is not needed because RTC will be a route reflector for the updates coming from RTA and RTB.<br /><blockquote>neighbor route−reflector−client</blockquote>The router with the above command would be the RR and the neighbors pointed at would be the clients of that RR. In our example, RTC would be configured with the neighbor route−reflector−client command pointing at RTA and RTB's IP addresses. The combination of the RR and its clients is called a cluster. RTA, RTB and RTC above would form a cluster with a single RR within AS100.<br /><br />Other IBGP peers of the RR that are not clients are called non−clients.<br /><br /><a set="yes" linkindex="4" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhuU7p_4VLcuxjlS42JkaY3I60Xt_soqWZvExSuzppXR0M84iMqLQPB1yMzSVTh96x5UCqhAR9-aBdMX6FHbUWxlfsgOQU7HpL5xeOubQZY16j9-BBG2L3YddF5wPVJrahlRLWzB35SDQ/s1600-h/Image29.JPG"><img style="cursor: pointer; width: 320px; height: 305px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhuU7p_4VLcuxjlS42JkaY3I60Xt_soqWZvExSuzppXR0M84iMqLQPB1yMzSVTh96x5UCqhAR9-aBdMX6FHbUWxlfsgOQU7HpL5xeOubQZY16j9-BBG2L3YddF5wPVJrahlRLWzB35SDQ/s320/Image29.JPG" alt="" id="BLOGGER_PHOTO_ID_5263943499865172722" border="0" /></a><br />An autonomous system can have more than one route reflector; a RR would treat other RRs just like any other IBGP speaker. Other RRs could belong to the same cluster (client group) or to other clusters. In a simple configuration, the AS could be divided into multiple clusters, each RR will be configured with other RRs as non−client peers in a fully meshed topology. Clients should not peer with IBGP speakers outside their cluster.<br /><br />Consider the above diagram. RTA, RTB and RTC form a single cluster with RTC being the RR. According to RTC, RTA and RTB are clients and anything else is a non−client. Remember that clients of an RR are pointed at using the neighbor route−reflector−client command. The same RTD is the RR for its clients RTE and RTF; RTG is a RR in a third cluster. Note that RTD, RTC and RTG are fully meshed but routers within a cluster are not. When a route is received by a RR, it will do the following depending on the peer type:<br /><br /></div><ol style="text-align: justify;"><li>Route from a non−client peer: reflect to all the clients within the cluster.</li><li>Route from a client peer: reflect to all the non−client peers and also to the client peers.</li><li>Route from an EBGP peer: send the update to all client and non−client peers.</li></ol><div style="text-align: justify;"><br />The following is the relative BGP configuration of routers RTC, RTD and RTB:<br /><blockquote>RTC#<br />router bgp 100<br />neighbor 2.2.2.2 remote−as 100<br />neighbor 2.2.2.2 route−reflector−client<br />neighbor 1.1.1.1 remote−as 100<br />neighbor 1.1.1.1 route−reflector−client<br />neighbor 7.7.7.7 remote−as 100<br />neighbor 4.4.4.4 remote−as 100<br />neighbor 8.8.8.8 remote−as 200<br /><br />RTB#<br />router bgp 100<br />neighbor 3.3.3.3 remote−as 100<br />neighbor 12.12.12.12 remote−as 300<br /><br />RTD#<br />router bgp 100<br />neighbor 6.6.6.6 remote−as 100<br />neighbor 6.6.6.6 route−reflector−client<br />neighbor 5.5.5.5 remote−as 100<br />neighbor 5.5.5.5 route−reflector−client<br />neighbor 7.7.7.7 remote−as 100<br />neighbor 3.3.3.3 remote−as 100<br /></blockquote><br />As the IBGP learned routes are reflected, it is possible to have the routing information loop. The Route Reflector scheme has a few methods to avoid this:<br /><br /></div><ol style="text-align: justify;"><li>Originator−id: this is an optional, non transitive BGP attribute that is four bytes long and is created by a RR. This attribute will carry the router−id (RID) of the originator of the route in the local AS. Thus, due to poor configuration, if the routing information comes back to the originator, it will be ignored.</li><li>Cluster−list: this will be discussed in the next section.</li></ol>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-11860648440509125552008-11-13T22:24:00.002-08:002008-11-13T22:25:34.447-08:00BGP Confederation<div style="text-align: justify;">BGP confederation is implemented in order to reduce the IBGP mesh inside an AS. The trick is to divide an AS into multiple ASs and assign the whole group to a single confederation. Each AS by itself will have IBGP fully meshed and has connections to other AS's inside the confederation. Even though these ASs will have EBGP peers to ASs within the confederation, they exchange routing as if they were using IBGP; next hop, metric and local preference information are preserved. To the outside world, the confederation (the group of ASs) will look like a single AS.<br /></div>To configure a BGP confederation use the following:<br /><blockquote>bgp confederation identifier autonomous−system</blockquote>The confederation identifier will be the AS number of the confederation group. The group of ASs will look to the outside world as one AS with the AS number being the confederation identifier.<br /><br />Peering within the confederation between multiple ASs is done via the following command:<br /><blockquote>bgp confederation peers autonomous−system [autonomous−system]</blockquote>The following is an example of confederation:<br /><br /><a set="yes" linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6Ni58TXv6_ouay0XloBUXnACvfKOEOHuGbXX0il9tELWZeb_MZ91yw7qeo8e6DLGBwKyRr8WxRSlPFJZFUt6uog-uzgDYTXdNum-CwblO6_xElR1Bu7vi3BMY6dJHgcSnQDVRFkOArQ/s1600-h/Image27.JPG"><img style="cursor: pointer; width: 320px; height: 266px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6Ni58TXv6_ouay0XloBUXnACvfKOEOHuGbXX0il9tELWZeb_MZ91yw7qeo8e6DLGBwKyRr8WxRSlPFJZFUt6uog-uzgDYTXdNum-CwblO6_xElR1Bu7vi3BMY6dJHgcSnQDVRFkOArQ/s320/Image27.JPG" alt="" id="BLOGGER_PHOTO_ID_5263941720210187266" border="0" /></a><br /><br />Let us assume that you have an autonomous system 500 consisting of nine BGP speakers (other non BGP speakers exist also, but we are only interested in the BGP speakers that have EBGP connections to other ASs). If you want to make a full IBGP mesh inside AS500 then you would need nine peer connections for each router, 8 IBGP peers and one EBGP peer to external ASs.<br /><br />By using confederation we can divide AS500 into multiple ASs: AS50, AS60 and AS70. We give the AS a confederation identifier of 500. The outside world will see only one AS500. For each AS50, AS60 and AS70 we define a full mesh of IBGP peers and we define the list of confederation peers using the bgp confederation peers command.<br /><br />Let's look at a sample configuration of routers RTC, RTD and RTA. Note that RTA has no knowledge of ASs 50, 60 or 70. RTA has only knowledge of AS500.<br />RTC#<br />router bgp 50<br />bgp confederation identifier 500<br />bgp confederation peers 60 70<br />neighbor 128.213.10.1 remote−as 50 (IBGP connection within AS50)<br />neighbor 128.213.20.1 remote−as 50 (IBGP connection within AS50)<br />neighbor 129.210.11.1 remote−as 60 (BGP connection with confederation peer 60)<br />neighbor 135.212.14.1 remote−as 70 (BGP connection with confederation peer 70)<br />neighbor 5.5.5.5 remote−as 100 (EBGP connection to external AS100)<br /><br />RTD#<br />router bgp 60<br />bgp confederation identifier 500<br />bgp confederation peers 50 70<br />neighbor 129.210.30.2 remote−as 60 (IBGP connection within AS60)<br />neighbor 128.213.30.1 remote−as 50(BGP connection with confederation peer 50)<br />neighbor 135.212.14.1 remote−as 70 (BGP connection with confederation peer 70)<br />neighbor 6.6.6.6 remote−as 600 (EBGP connection to external AS600)<br /><br />RTA#<br />router bgp 100<br />neighbor 5.5.5.4 remote−as 500 (EBGP connection to confederation 500)Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-87495048862665118772008-11-13T22:24:00.001-08:002008-11-13T22:24:53.240-08:00BGP CIDR<p>CIDR and Aggregate Addresses<br /><br /><a set="yes" linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyzm1hn9sywmKKrGynKoK36h97NhQwX1N0JfK7JoFo0xXxvFg2wU_Yca7vpPE5EofrCMnpII6PluC8v-NsCZfAYLsUR2AmtgYf4YoDWOCRDq-ZdnL-eFHjpE-3eXgLaYHLOIy8KmKYOQ/s1600-h/Image26.JPG"><img style="cursor: pointer; width: 320px; height: 230px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyzm1hn9sywmKKrGynKoK36h97NhQwX1N0JfK7JoFo0xXxvFg2wU_Yca7vpPE5EofrCMnpII6PluC8v-NsCZfAYLsUR2AmtgYf4YoDWOCRDq-ZdnL-eFHjpE-3eXgLaYHLOIy8KmKYOQ/s320/Image26.JPG" alt="" id="BLOGGER_PHOTO_ID_5263929910513249650" border="0" /></a><br /></p><div style="text-align: justify;"><br />One of the main enhancements of BGP4 over BGP3 is Classless Interdomain Routing (CIDR). CIDR or supernetting is a new way of looking at IP addresses. There is no notion of classes anymore (class A, B or C).<br /><br />For example, network 192.213.0.0 which used to be an illegal class C network is now a legal supernet represented by 192.213.0.0/16 where the 16 is the number of bits in the subnet mask counting from the far left of the IP address. This is similar to 192.213.0.0 255.255.0.0.<br /><br />Aggregates are used to minimize the size of routing tables. Aggregation is the process of combining the characteristics of several different routes in such a way that a single route can be advertised. In the example below, RTB is generating network 160.10.0.0. We will configure RTC to propagate a supernet of that route 160.0.0.0 to RTA.<br /><blockquote><br />RTB#<br />router bgp 200<br />neighbor 3.3.3.1 remote−as 300<br />network 160.10.0.0<br /><br />#RTC<br />router bgp 300<br />neighbor 3.3.3.3 remote−as 200<br />neighbor 2.2.2.2 remote−as 100<br />network 170.10.0.0<br /><br />aggregate−address 160.0.0.0 255.0.0.0</blockquote>RTC will propagate the aggregate address 160.0.0.0 to RTA.<br /><br /><span style="font-weight: bold;">Aggregate Commands</span><br /><span style="font-weight: bold;"></span><br /><span style="font-weight: bold;"></span>There is a wide range of aggregate commands. It is important to understand how each one works in order to have the desired aggregation behavior.<br /><br />The first command is the one used in the previous example:<br /><blockquote>aggregate−address address mask</blockquote></div><div style="text-align: justify;">This will advertise the prefix route, and all of the more specific routes. The command aggregate−address 160.0.0.0 will propagate an additional network 160.0.0.0 but will not prevent 160.10.0.0 from being also propagated to RTA. The outcome of this is that both networks 160.0.0.0 and 160.10.0.0 have been propagated to RTA. This is what we mean by advertising the prefix and the more specific route.<br /></div><br />Please note that you can not aggregate an address if you do not have a more specific route of that address in the BGP routing table.<br /><br /><div style="text-align: justify;">For example, RTB can not generate an aggregate for 160.0.0.0 if it does not have a more specific entry of 160.0.0.0 in its BGP table. The more specific route could have been injected into the BGP table via incoming updates from other ASs, from redistributing an IGP or static into BGP or via the network command (network 160.10.0.0).<br /></div><br />In case we would like RTC to propagate network 160.0.0.0 only and NOT the more specific route then we would have to use the following:<br /><blockquote>aggregate−address address mask summary−only<br /></blockquote>This will a advertise the prefix only; all the more specific routes are suppressed.<br /><br />The command aggregate 160.0.0.0 255.0.0.0 summary−only will propagate network 160.0.0.0 and will suppress the more specific route 160.10.0.0.<br /><br /><div style="text-align: justify;">Please note that if we are aggregating a network that is injected into our BGP via the network statement (ex: network 160.10.0.0 on RTB) then the network entry is always injected into BGP updates even though we are using "the aggregate summary−only" command. The upcoming CIDR example discusses this situation.<br /></div><blockquote>aggregate−address address mask as−set<br /></blockquote>This advertises the prefix and the more specific routes but it includes as−set information in the path information of the routing updates.<br /><blockquote>aggregate 129.0.0.0 255.0.0.0 as−set<br /></blockquote>This command will be discussed in an example by itself in the following sections.<br /><br /><div style="text-align: justify;">In case we would like to suppress more specific routes when doing the aggregation we can define a route map and apply it to the aggregates. This will allow us to be selective about which more specific routes to suppress.<br /></div><blockquote>aggregate−address address−mask suppress−map map−name<br /></blockquote><div style="text-align: justify;">This advertises the prefix and the more specific routes but it suppresses advertisement according to a route−map. In the previous diagram, if we would like to aggregate 160.0.0.0 and suppress the more specific route 160.20.0.0 and allow 160.10.0.0 to be propagated, we can use the following route map:<br /></div><blockquote>route−map CHECK permit 10<br />match ip address 1<br />access−list 1 permit 160.20.0.0 0.0.255.255<br />access−list 1 deny 0.0.0.0 255.255.255.255<br /></blockquote>By definition of the suppress−map, any packets permitted by the access list would be suppressed from the updates.<br /><br />Then we apply the route−map to the aggregate statement.<br /><blockquote>RTC#<br />router bgp 300<br />neighbor 3.3.3.3 remote−as 200<br />neighbor 2.2.2.2 remote−as 100<br />neighbor 2.2.2.2 remote−as 100<br />network 170.10.0.0<br />aggregate−address 160.0.0.0 255.0.0.0 suppress−map CHECK<br /></blockquote>Another variation is the:<br /><blockquote>aggregate−address address mask attribute−map map−name<br /></blockquote><div style="text-align: justify;">This allows us to set the attributes (such as metric) when aggregates are sent out. The following route map when applied to the aggregate attribute−map command will set the origin of the aggregates to IGP.<br /></div><br /><blockquote>route−map SETMETRIC<br />set origin igp<br />aggregate−address 160.0.0.0 255.0.0.0 attribute−map SETORIGIN<br /></blockquote><span style="font-size: 130%;"><span style="font-weight: bold;">CIDR Example 1</span></span><br /><br />Request: Allow RTB to advertise the prefix 160.0.0.0 and suppress all the more specific routes.<br /><br />The problem here is that network 160.10.0.0 is local to AS200, meaning AS200 is the originator of 160.10.0.0. You cannot have RTB generate a prefix for 160.0.0.0 without generating an entry for 160.10.0.0 even if you use the aggregate summary−only command because RTB is the originator of 160.10.0.0. There are two solutions to this problem.<br /><br />The first solution is to use a static route and redistribute it into BGP. The outcome is that RTB will advertise the aggregate with an origin of incomplete (?).<br /><br /><div style="text-align: justify;"><blockquote>RTB#<br />router bgp 200<br />neighbor 3.3.3.1 remote−as 300<br />redistribute static (This will generate an update for 160.0.0.0 with the origin path as *incomplete*)<br />ip route 160.0.0.0 255.0.0.0 null0</blockquote><br /></div><br />In the second solution, in addition to the static route we add an entry for the network command. This has the same effect except that the origin of the update will be set to IGP.<br /><br /><blockquote>RTB#<br />router bgp 200<br />network 160.0.0.0 mask 255.0.0.0 (this will mark the update with origin IGP)<br />neighbor 3.3.3.1 remote−as 300<br />redistribute static<br /><br />ip route 160.0.0.0 255.0.0.0 null0</blockquote><br /><span style="font-size: 130%;"><span style="font-weight: bold;">CIDR Example 2 (as−set)</span></span><br /><br />AS−SETS are used in aggregation to reduce the size of the path information by listing the AS number only once, regardless of how many times it may have appeared in multiple paths that were aggregated. The as−set aggregate command is used in situations were aggregation of information causes loss of information regarding the path attribute. In the following example RTC is getting updates about 160.20.0.0 from RTA and updates about 160.10.0.0 from RTB. Suppose RTC wants to aggregate network 160.0.0.0/8 and send it to RTD. RTD would not know what the origin of that route is. By adding the aggregate as−set statement we force RTC to generate path information in the form of a set {}. All the path information is included in that set<br />irrespective of which path came first.<br /><br /><blockquote>RTB#<br />router bgp 200<br />network 160.10.0.0<br />neighbor 3.3.3.1 remote−as 300<br />RTA#<br />router bgp 100<br />network 160.20.0.0<br />neighbor 2.2.2.1 remote−as 300</blockquote><br /><span style="font-weight: bold;">Case 1:</span><br /><br />RTC does not have an as−set statement. RTC will send an update 160.0.0.0/8 to RTD with path information (300) as if the route has originated from AS300.<br /><br /><blockquote>RTC#<br />router bgp 300<br />neighbor 3.3.3.3 remote−as 200<br />neighbor 2.2.2.2 remote−as 100<br />neighbor 4.4.4.4 remote−as 400<br />aggregate 160.0.0.0 255.0.0.0 summary−only<br />!−− this causes RTC to send RTD updates about 160.0.0.0/8 with no indication<br />!−− that 160.0.0.0 is actually coming from two different autonomous<br />!−− systems, this may create loops if RT4 has an entry back into AS100.<br /></blockquote><br /><span style="font-weight: bold;">Case 2:<br /></span><blockquote><span style="font-weight: bold;"><br /></span>RTC#<br />router bgp 300<br />neighbor 3.3.3.3 remote−as 200<br />neighbor 2.2.2.2 remote−as 100<br />neighbor 4.4.4.4 remote−as 400<br />aggregate 160.0.0.0 255.0.0.0 summary−only<br />aggregate 160.0.0.0 255.0.0.0 as−set<br />!−− causes RTC to send RTD updates about 160.0.0.0/8 with an<br />!−− indication that 160.0.0.0 belongs to a set {100 200}.</blockquote>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-10741620400454617102008-11-13T22:23:00.002-08:002008-11-13T22:24:12.210-08:00BGP Peer Groups<a set="yes" linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhy5D5-_CpPOJFzbLLgkw3DwzQpC3FiqooD9H_6w_vgN8io55QKYGlAwWr-0Fax4nl_ADFdRRyRNmGXMdbIznJZR3fC8iyJzzAhS83nxqQ2cxo0wKHMA2VIDg77Hhyphenhyphenoh7hJURshiZ2-Uw/s1600-h/Image25.JPG"><img style="cursor: pointer; width: 320px; height: 254px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhy5D5-_CpPOJFzbLLgkw3DwzQpC3FiqooD9H_6w_vgN8io55QKYGlAwWr-0Fax4nl_ADFdRRyRNmGXMdbIznJZR3fC8iyJzzAhS83nxqQ2cxo0wKHMA2VIDg77Hhyphenhyphenoh7hJURshiZ2-Uw/s320/Image25.JPG" alt="" id="BLOGGER_PHOTO_ID_5263926946795375042" border="0" /></a><br /><br /><br />A BGP peer group, is a group of BGP neighbors with the same update policies. Update policies are usually set by route maps, distribute−lists and filter−lists, etc. Instead of defining the same policies for each separate neighbor, we define a peer group name and we assign these policies to the peer group.<br /><br />Members of the peer group inherit all of the configuration options of the peer group. Members can also be configured to override these options if these options do not affect outbound updates; you can only override options set on the inbound.<br /><br />To define a peer group use the following:<br /><blockquote>neighbor peer−group−name peer−group</blockquote>In the following example we will see how peer groups are applied to internal and external BGP neighbors.<br /><br /><blockquote>RTC#<br />router bgp 300<br />neighbor internalmap peer−group<br />neighbor internalmap remote−as 300<br />neighbor internalmap route−map SETMETRIC out<br />neighbor internalmap filter−list 1 out<br />neighbor internalmap filter−list 2 in<br />neighbor 5.5.5.2 peer−group internalmap<br />neighbor 6.6.6.2 peer−group internalmap<br />neighbor 3.3.3.2 peer−group internalmap<br />neighbor 3.3.3.2 filter−list 3 in<br /></blockquote>In the above configuration, we have defined a peer group named internalmap and we have defined some policies for that group, such as a route map SETMETRIC to set the metric to 5 and two different filter lists 1 and 2. We have applied the peer group to all internal neighbors RTE, RTF and RTG. We have defined a separate filter−list 3 for neighbor RTE, and this will override filter−list 2 inside the peer group. Note that we could only override options that affect inbound updates.<br /><br />Now, let us look at how we can use peer groups with external neighbors. In the same diagram we will configure RTC with a peer−group externalmap and we will apply it to external neighbors.<br /><blockquote>RTC#<br />router bgp 300<br />neighbor externalmap peer−group<br />neighbor externalmap route−map SETMETRIC<br />neighbor externalmap filter−list 1 out<br />neighbor externalmap filter−list 2 in<br />neighbor 2.2.2.2 remote−as 100<br />neighbor 2.2.2.2 peer−group externalmap<br />neighbor 4.4.4.2 remote−as 600<br />neighbor 4.4.4.2 peer−group externalmap<br />neighbor 1.1.1.2 remote−as 200<br />neighbor 1.1.1.2 peer−group externalmap<br />neighbor 1.1.1.2 filter−list 3 in</blockquote>Note that in the above configs we have defined the remote−as statements outside of the peer group because we have to define different external ASs. Also we did an override for the inbound updates of neighbor 1.1.1.2 by assigning filter−list 3.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-5986726549000842372008-11-13T22:23:00.001-08:002008-11-13T22:23:32.766-08:00BGP Neighbors<div style="text-align: justify;"><span style="font-weight: bold;">BGP Neighbors and Route Maps</span><br /><br /><a set="yes" linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiip4Oxk4jX8lQ2zuvSkfrNL7fBsYTAFrDgMBDD7egmjHL9-rsZIT5zcTSam69fi90Czi7aF5OXfMLfWPI3hICswidKGi9WbciG4tSxOip-yWa2L2vWNvu3nMIIFvLAiNgzcbTvMJIjuw/s1600-h/Image24.JPG"><img style="cursor: pointer; width: 320px; height: 264px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiip4Oxk4jX8lQ2zuvSkfrNL7fBsYTAFrDgMBDD7egmjHL9-rsZIT5zcTSam69fi90Czi7aF5OXfMLfWPI3hICswidKGi9WbciG4tSxOip-yWa2L2vWNvu3nMIIFvLAiNgzcbTvMJIjuw/s320/Image24.JPG" alt="" id="BLOGGER_PHOTO_ID_5263926056127502690" border="0" /></a><br /><br />The neighbor command can be used in conjunction with route maps to perform either filtering or parameter setting on incoming and outgoing updates.<br /><br />Route maps associated with the neighbor statement have no affect on incoming updates when matching based on the IP address:<br /><br />neighbor ip−address route−map route−map−name<br /><br />Assume in the above diagram we want RTC to learn from AS200 about networks that are local to AS200 and nothing else. Also, we want to set the weight on the accepted routes to 20. We can achieve this with a combination of neighbor and as−path access lists.<br /><br /><blockquote>RTC#<br />router bgp 300<br />network 170.10.0.0<br />neighbor 3.3.3.3 remote−as 200<br />neighbor 3.3.3.3 route−map stamp in<br />route−map stamp<br />match as−path 1<br />set weight 20<br />ip as−path access−list 1 permit ^200$<br /></blockquote><br />Any updates that originate from AS200 have a path information that starts with 200 and ends with 200 and will be permitted. Any other updates will be dropped.<br /><br />Assume that we want the following:<br /></div><ul style="text-align: justify;"><li>Updates originating from AS200 to be accepted with weight 20.</li><li>Updates originating from AS400 to be dropped.</li><li>Other updates to have a weight of 10.<br /></li></ul><blockquote>RTC#<br />router bgp 300<br />network 170.10.0.0<br />neighbor 3.3.3.3 remote−as 200<br />neighbor 3.3.3.3 route−map stamp in<br />route−map stamp permit 10<br />match as−path 1<br />set weight 20<br />route−map stamp permit 20<br />match as−path 2<br />set weight 10<br />ip as−path access−list 1 permit ^200$<br />ip as−path access−list 2 permit ^200 600 .*<br /></blockquote><br />The above statement will set a weight of 20 for updates that are local to AS200, and will set a weight of 10 for updates that are behind AS400 and will drop updates coming from AS400.<br /><br /><span style="font-weight: bold;">Use of set as−path prepend Command</span><br /><br />In some situations we are forced to manipulate the path information in order to manipulate the BGP decision process. The command that is used with a route map is:<br /><blockquote>set as−path prepend<as−path#><as−path#> ...</as−path#></as−path#></blockquote>Suppose in the above diagram that RTC is advertising its own network 170.10.0.0 to two different ASs:<br /><br />AS100 and AS200. When the information is propagated to AS600, the routers in AS600 will have network reachability information about 150.10.0.0 via two different routes, the first route is via AS100 with PATH (100, 300) and the second one is via AS400 with PATH (400, 200,300). Assuming that all other attributes are the same AS600 will pick the shortest path and will choose the route via AS100.<br /><br />AS300 will be getting all its traffic via AS100. If we want to influence this decision from the AS300 end we can make the PATH through AS100 look like it is longer than the PATH going through AS400. We can do this by prepending autonomous system numbers to the existing path info advertised to AS100. A common practice is to repeat our own AS number using the following:<br /><blockquote>RTC#<br />router bgp 300<br />network 170.10.0.0<br />neighbor 2.2.2.2 remote−as 100<br />neighbor 2.2.2.2 route−map SETPATH out<br />route−map SETPATH<br />set as−path prepend 300 300</blockquote>Because of the above configuration, AS600 will receive updates about 170.10.0.0 via AS100 with a PATH information of: (100, 300, 300, 300) which is longer than (400, 200, 300) received from AS100.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-443911417057272332008-11-13T22:22:00.001-08:002008-11-13T22:22:59.858-08:00BGP AS−Regular Expression<div style="text-align: justify;">A regular expression is a pattern to match against an input string. By building a regular expression we specify a string that input must match. In case of BGP we are specifying a string consisting of path information that an input should match.<br /></div><br /><div style="text-align: justify;">In the previous example we specified the string ^200$ and wanted path information coming inside updates to match it in order to perform a decision.<br /></div><br />The regular expression is composed of the following:<br /><br /><span style="font-weight: bold;">Range</span><br /><br />A range is a sequence of characters contained within left and right square brackets. ex: [abcd]<br /><br /><span style="font-weight: bold;">Atom<br /><br /></span>An atom is a single character, such as the following:<br /><br /><blockquote>. (Matches any single character)<br />^ (Matches the beginning of the input string)<br />$ (Matches the end of the input string)<br />\ (Matches the character)<br />− (Matches a comma (,), left brace ({), right brace (}), the beginning of the input string, the end of the input string, or a space.<br /></blockquote><br /><span style="font-weight: bold;">Piece<br /><br /></span>A piece is an atom followed by one of the following symbols:<br /><br /><blockquote>* (Matches 0 or more sequences of the atom)<br />+ (Matches 1 or more sequences of the atom)<br />? (Matches the atom or the null string)<br /></blockquote><br /><span style="font-weight: bold;">Branch</span><br /><br />A branch is a 0 or more concatenated pieces.<br /><br />Examples of regular expressions follow:<br /><br /><blockquote>a* (Any occurrence of the letter "a", including none)<br />a+ ( At least one occurrence of the letter "a" should be present)<br />ab?a (This matches "aa" or "aba")<br />_100_ (Via AS100)<br />^100$ (Origin AS100)<br />^100 .* (Coming from AS100)<br />^$ (Originated from this AS)<br /></blockquote><br /><span style="font-size: 130%;"><span style="font-weight: bold;">BGP Community Filtering</span><span style="font-size: 100%;"><br /><br /></span></span><a set="yes" linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtiR6xeYjq48T_hyphenhyphenOJYrG4XQ6u_zcLe7h8AMqPvE1XEQ47TxqKYMaVAmor1FpLhJH-HNFWS5nCwdcDcbe2D1k3oD-PcEKNlwBUYAw15eron_Oodjl6A2z7ARq510Cf6iABgVMh6BvfmQ/s1600-h/Image23.JPG"><img style="cursor: pointer; width: 320px; height: 232px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjtiR6xeYjq48T_hyphenhyphenOJYrG4XQ6u_zcLe7h8AMqPvE1XEQ47TxqKYMaVAmor1FpLhJH-HNFWS5nCwdcDcbe2D1k3oD-PcEKNlwBUYAw15eron_Oodjl6A2z7ARq510Cf6iABgVMh6BvfmQ/s320/Image23.JPG" alt="" id="BLOGGER_PHOTO_ID_5263922754844796402" border="0" /></a><br /><br /><div style="text-align: justify;">We would like RTB above to set the community attribute to the BGP routes it is advertising such that RTC would not propagate these routes to its external peers. The no−export community attribute is used:<br /></div><br /><blockquote>RTB#<br />router bgp 200<br />network 160.10.0.0<br />neighbor 3.3.3.1 remote−as 300<br />neighbor 3.3.3.1 send−community<br />neighbor 3.3.3.1 route−map setcommunity out<br />route−map setcommunity<br />match ip address 1<br />set community no−export<br />access−list 1 permit 0.0.0.0 255.255.255.255</blockquote><br /><div style="text-align: justify;">Note that we have used the route−map setcommunity command in order to set the community to no−export. Note also that we had to use the neighbor send−community command in order to send this attribute to RTC.<br /><br />When RTC gets the updates with the attribute no−export, it will not propagate them to its external peer RTA.<br /><br />In the example below, RTB has set the community attribute to 100 200 additive. The value 100 200 will be added to any existing community value before being sent to RTC.<br /></div><br /><blockquote>RTB#<br />router bgp 200<br />network 160.10.0.0<br />neighbor 3.3.3.1 remote−as 300<br />neighbor 3.3.3.1 send−community<br />neighbor 3.3.3.1 route−map setcommunity out<br /><br />route−map setcommunity<br />match ip address 2<br />set community 100 200 additive<br />access−list 2 permit 0.0.0.0 255.255.255.255<br /><br /></blockquote><div style="text-align: justify;">A community list is a group of communities that we use in a match clause of a route map which allows us to do filtering or setting attributes based on different lists of community numbers.<br /></div><blockquote>ip community−list community−list−number {permit|deny} community−number</blockquote>For example we can define the following route map, match−on−community:<br /><br /><blockquote>route−map match−on−community<br />match community 10 (10 is the community−list number)<br />set weight 20<br />ip community−list 10 permit 200 300<br />!−− 200 300 is the community number<br /></blockquote><div style="text-align: justify;">We can use the above in order to filter or set certain parameters like weight and metric based on the community value in certain updates. In example two above, RTB was sending updates to RTC with a community of 100 200. If RTC wants to set the weight based on those values we could do the following:<br /></div><br /><blockquote>RTC#<br />router bgp 300<br />neighbor 3.3.3.3 remote−as 200<br />neighbor 3.3.3.3 route−map check−community in<br />route−map check−community permit 10<br />match community 1<br />set weight 20<br />route−map check−community permit 20<br />match community 2 exact<br />set weight 10<br />route−map check−community permit 30<br />match community 3<br />ip community−list 1 permit 100<br />ip community−list 2 permit 200<br />ip community−list 3 permit internet</blockquote>In the above example, any route that has 100 in its community attribute will match list 1 and will have the weight set to 20. Any route that has only 200 as community will match list 2 and will have weight 20. The keyword exact states that community should consist of 200 only and nothing else. The last community list is here to make sure that other updates are not dropped. Remember that anything that does not match, will be dropped by default. The keyword internet means all routes because all routes are members of the internet community.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-12331536570294147842008-11-13T22:21:00.002-08:002008-11-13T22:22:21.959-08:00BGP FilteringSending and receiving BGP updates can be controlled by using a number of different filtering methods. BGP updates can be filtered based on route information, on path information or on communities. All methods will achieve the same results, choosing one over the other depends on the specific network configuration.<br /><br /><span style="font-weight: bold;">Route Filtering</span><br /><br /><a set="yes" linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWdBQwAKzpTcPWLta4hPraD8MZQBoc5y1BjM1iAQJbWwcPvm03UVrCwE-2SrAJM_j90ydZtX-5d28xv_wmrgEGJyINYaTcJPZjSSRP6A-IpyqJueXmUZog1j98sOA4jjVSTFfCF0QPpg/s1600-h/Image21.JPG"><img style="cursor: pointer; width: 320px; height: 249px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWdBQwAKzpTcPWLta4hPraD8MZQBoc5y1BjM1iAQJbWwcPvm03UVrCwE-2SrAJM_j90ydZtX-5d28xv_wmrgEGJyINYaTcJPZjSSRP6A-IpyqJueXmUZog1j98sOA4jjVSTFfCF0QPpg/s320/Image21.JPG" alt="" id="BLOGGER_PHOTO_ID_5263920169273052770" border="0" /></a><br /><br />In order to restrict the routing information that the router learns or advertises, you can filter BGP based on routing updates to or from a particular neighbor. In order to achieve this, an access−list is defined and applied to the updates to or from a neighbor. Use the following command in the router configuration mode:<br /><blockquote>neighbor {ip−address|peer−group−name} distribute−list access−list−number {in | out}</blockquote><br />In the following example, RTB is originating network 160.10.0.0 and sending it to RTC. If RTC wanted to stop those updates from propagating to AS100, we would have to apply an access−list to filter those updates and apply it when talking to RTA:<br /><br /><blockquote>RTC#<br />router bgp 300<br />network 170.10.0.0<br />neighbor 3.3.3.3 remote−as 200<br />neighbor 2.2.2.2 remote−as 100<br />neighbor 2.2.2.2 distribute−list 1 out<br />access−list 1 deny 160.10.0.0 0.0.255.255<br />access−list 1 permit 0.0.0.0 255.255.255.255<br />!−− filter out all routing updates about 160.10.x.x<br /></blockquote><br />Using access−lists is a bit tricky when you are dealing with supernets that might cause some conflicts.<br /><br />Assume in the above example that RTB has different subnets of 160.10.X.X and our goal is to filter updates and advertise only 160.0.0.0/8 (this notation means that we are using 8 bits of subnet mask starting from the far left of the IP address; this is equivalent to 160.0.0.0 255.0.0.0).<br /><br />The command access−list 1 permit 160.0.0.0 0.255.255.255 permits 160.0.0.0/8,160.0.0.0/9 and so on. In order to restrict the update to only 160.0.0.0/8 we have to use an extended access list of the following format:<br /><br /><span style="font-style: italic;">access−list 101 160.0.0.0 0.255.255.255 255.0.0.0 0.0.0.0. This list permits 160.0.0.0/8 only.</span><br /><br />Another type of filtering is path filtering, which is described in the next section.<br /><br /><span style="font-weight: bold;">Path Filtering</span><br /><br /><a linkindex="4" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhrM1Zf_2gylii_VFf2KhyphenhyphenEUon_zVKdGhTEK7BmYrycQqbRX418kK4LZ1jVryuL8A94M7K8YpAWJoxiFqHjscjW1sAdtyeRgD6j1bbbIl_m0XMcQH8PNY9HdIkCNjGM6S_aKvE5nwx5EQ/s1600-h/Image22.JPG"><img style="cursor: pointer; width: 320px; height: 250px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhrM1Zf_2gylii_VFf2KhyphenhyphenEUon_zVKdGhTEK7BmYrycQqbRX418kK4LZ1jVryuL8A94M7K8YpAWJoxiFqHjscjW1sAdtyeRgD6j1bbbIl_m0XMcQH8PNY9HdIkCNjGM6S_aKvE5nwx5EQ/s320/Image22.JPG" alt="" id="BLOGGER_PHOTO_ID_5263920696709255346" border="0" /></a><br /><br />You can specify an access list on both incoming and outgoing updates based on the BGP autonomous system paths information. In the above figure we can block updates about 160.10.0.0 from going to AS100 by defining an access list on RTC that prevents any updates that have originated from AS200 from being sent to AS100. To do this use the following statements.<br /><br />ip as−path access−list access−list−number {permit|deny} as−regular−expression<br />neighbor {ip−address|peer−group−name} filter−list access−list−number {in|out}<br /><br />The following example stops RTC from sending RTA updates about 160.10.0.0<br /><br /><blockquote>RTC#<br />router bgp 300<br />neighbor 3.3.3.3 remote−as 200<br />neighbor 2.2.2.2 remote−as 100<br />neighbor 2.2.2.2 filter−list 1 out<br />!−− the 1 is the access list number below<br />ip as−path access−list 1 deny ^200$<br />ip as−path access−list 1 permit .*</blockquote><br /><br />In the above example, access−list 1 states: deny any updates with path information that start with 200 (^) and end with 200 ($). The ^200$ is called a regular expression, with ^ meaning "starts with" and $ meaning "ends with". Since RTB sends updates about 160.10.0.0 with path information starting with 200 and ending with 200, this update matches the access list and will be denied.<br /><br />The .* is another regular expression with the period meaning "any character" and the * meaning "the repetition of that character". So .* is actually any path information, which is needed to permit all other updates to be sent.<br /><br />What would happen if instead of using ^200$ we have used ^200? If you have an AS400 (see figure above), updates originated by AS400 will have path information of the form (200, 400) with 200 being first and 400 being last. Those updates will match the access list ^200 because they start with 200 and will be prevented from being sent to RTA which is not the required behavior.<br /><br />A good way to check whether we have implemented the correct regular expression is to use the show ip bgp regexp regular expression> command. This shows all the paths that have matched the configured regular expression.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-24016653130772876712008-11-13T22:21:00.001-08:002008-11-13T22:21:45.747-08:00BGP Backdoor Attribute<a linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhhrkJJBIefKnSSLzTWh7rXPuYwEcmlLyX3hlCQJKVBBI_eKJhwPO8A4XtXQD0zwzaBU6P9tv_c98GeCVyBANMqFUhECHhEJNKTnFUtuhReve059Wg46yEgz6jTylG3I8m_ZXUCaZeEdw/s1600-h/Image15.JPG"><img style="cursor: pointer; width: 320px; height: 240px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhhrkJJBIefKnSSLzTWh7rXPuYwEcmlLyX3hlCQJKVBBI_eKJhwPO8A4XtXQD0zwzaBU6P9tv_c98GeCVyBANMqFUhECHhEJNKTnFUtuhReve059Wg46yEgz6jTylG3I8m_ZXUCaZeEdw/s320/Image15.JPG" alt="" id="BLOGGER_PHOTO_ID_5263752372407572850" border="0" /></a><br /><br />Consider the above diagram, RTA and RTC are running EBGP, and RTB and RTC are running EBGP. RTA and RTB are running some kind of IGP (RIP, IGRP, etc.). By definition, EBGP updates have a distance of 20 which is lower than the IGP distances. Default distance is 120 for RIP, 100 for IGRP, 90 for EIGRP and 110 for OSPF.<br /><div style="text-align: justify;"><br />RTA will receive updates about 160.10.0.0 via two routing protocols:<br /><br />EBGP with a distance of 20 and IGP with a distance higher than 20.<br /><br />By default, BGP has the following distances, but that could be changed by the distance command:<br /><blockquote><span style="font-weight: bold;">distance bgp external−distance internal−distance local−distance</span><br /></blockquote>external−distance:20<br />internal−distance:200<br />local−distance:200<br /><br />RTA will pick EBGP via RTC because of the lower distance.<br /><br />If we want RTA to learn about 160.10.0.0 via RTB (IGP), then we have two options:<br /></div><ul style="text-align: justify;"><li>Change EBGP's external distance or IGP's distance, which is not recommended.</li><li>Use BGP backdoor.<br /></li></ul>BGP backdoor makes the IGP route the preferred route.<br /><br />Use the following <span style="font-weight: bold;">network </span><span style="font-style: italic;">address </span><span style="font-weight: bold;">backdoor </span>command.<br /><br />The configured network is the network that we would like to reach via IGP. For BGP this network will be treated as a locally assigned network except it will not be advertised in BGP updates.<br /><br /><blockquote>RTA#<br />router eigrp 10<br />network 160.10.0.0<br />router bgp 100<br />neighbor 2.2.2.1 remote−as 300<br />network 160.10.0.0 backdoor<br /></blockquote><br />Network 160.10.0.0 is treated as a local entry, but is not advertised as a normal network entry.<br /><br />RTA learns 160.10.0.0 from RTB via EIGRP with distance 90, and also learns it from RTC via EBGP with distance 20. Normally EBGP is preferred, but because of the backdoor command EIGRP is preferred.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-26407969598226703452008-11-13T22:20:00.000-08:002008-11-13T22:21:03.921-08:00BGP Weight Attribute<p>BGP Weight Attribute<br /></p><div style="text-align: justify;"><br /><a set="yes" linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjYHn73euEutYBNXf6iBo8Or7jhQyyOGngOgezbEKhonq42r0zkA2u_SMWi6gSWe7JDUMH_w6MxfyT5Ej-dKS461NyayaUxgCFUwlI3l7vFS07mAk2xDJ75jGIqvGyTLwIVrOXiTbbRRQ/s1600-h/Image18.JPG"><img style="cursor: pointer; width: 320px; height: 208px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjYHn73euEutYBNXf6iBo8Or7jhQyyOGngOgezbEKhonq42r0zkA2u_SMWi6gSWe7JDUMH_w6MxfyT5Ej-dKS461NyayaUxgCFUwlI3l7vFS07mAk2xDJ75jGIqvGyTLwIVrOXiTbbRRQ/s320/Image18.JPG" alt="" id="BLOGGER_PHOTO_ID_5263756740030041058" border="0" /></a><br /><br />The weight attribute is a Cisco defined attribute. The weight is used for a best path selection process. The weight is assigned locally to the router. It is a value that only makes sense to the specific router and which is not propagated or carried through any of the route updates. A weight can be a number from 0 to 65535. Paths that the router originates have a weight of 32768 by default and other paths have a weight of zero.<br /><br />Routes with a higher weight are preferred when multiple routes exist to the same destination. Let us study the above example. RTA has learned about network 175.10.0.0 from AS4 and will propagate the update to RTC. RTB has also learned about network 175.10.0.0 from AS4 and will propagate it to RTC. RTC has now two ways for reaching 175.10.0.0 and has to decide which way to go. If on RTC we can set the weight of the updates coming from RTA to be higher than the weight of updates coming from RTB, then we will force RTC to use RTA as a next hop to reach 175.10.0.0. This is achieved by using multiple methods:<br /><br /></div><ul style="text-align: justify;"><li>Using the neighbor command: neighbor {ip−address|peer−group} weight weight.</li><li>Using AS path access−lists: ip as−path access−list access−list−number {permit|deny} as−regular−expression neighbor ip−address filter−list access−list−number weight weight.</li><li>Using route−maps.<br /></li></ul><blockquote>RTC#<br />router bgp 300<br />neighbor 1.1.1.1 remote−as 100<br />neighbor 1.1.1.1 weight 200<br /><span style="font-style: italic;">!−− route to 175.10.0.0 from RTA has 200 weight</span><br />neighbor 2.2.2.2 remote−as 200<br />neighbor 2.2.2.2 weight 100<br /><span style="font-style: italic;">!−− route to 175.10.0.0 from RTB will have 100 weight<br /><br /></span>Routes with higher weight are preferred when multiple routes exist to the same destination. RTA is preferred as the next hop.<br /><br />The same outcome can be achieved using IP as−path and filter lists.<br /><br />RTC#<br />router bgp 300<br />neighbor 1.1.1.1 remote−as 100<br />neighbor 1.1.1.1 filter−list 5 weight 200<br />neighbor 2.2.2.2 remote−as 200<br />neighbor 2.2.2.2 filter−list 6 weight 100<br />...<br />ip as−path access−list 5 permit ^100$<br /><span style="font-style: italic;">!−− this only permits path 100</span><br />ip as−path access−list 6 permit ^200$<br />...<br />The same outcome as above can be achieved by using routemaps.<br />RTC#<br />router bgp 300<br />neighbor 1.1.1.1 remote−as 100<br />neighbor 1.1.1.1 route−map setweightin in<br />neighbor 2.2.2.2 remote−as 200<br />neighbor 2.2.2.2 route−map setweightin in<br />...<br />ip as−path access−list 5 permit ^100$<br />...<br />route−map setweightin permit 10<br />match as−path 5<br />set weight 200<br /><span style="font-style: italic;">!−− anything that applies to access−list 5, such as packets from AS100, have weight 200</span><br />route−map setweightin permit 20<br />set weight 100<br /><span style="font-style: italic;">!−− anything else would have weight 100</span></blockquote>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-69048842062199227382008-11-13T22:19:00.002-08:002008-11-13T22:20:29.286-08:00BGP Community Attribute<span style="font-weight: bold;">Community Attribute</span><br /><br />The community attribute is a transitive, optional attribute in the range 0 to 4,294,967,200. The community attribute is a way to group destinations in a certain community and apply routing decisions (accept, prefer, redistribute, etc.) according to those communities.<br /><br />We can use route maps to set the community attributes. The route map set command has the following syntax:<br /><br />set community community−number [additive]<br /><br />A few predefined well known communities (community−number) are:<br /><ul><li>no−export (Do not advertise to EBGP peers)</li><li>no−advertise (Do not advertise this route to any peer)</li><li>internet (Advertise this route to the internet community, any router belongs to it)<br /></li></ul>An example of route maps where community is set is:<br /><blockquote>route−map communitymap<br />match ip address 1<br />set community no−advertise<br /></blockquote>or<br /><blockquote>route−map setcommunity<br />match as−path 1<br />set community 200 additive<br /></blockquote>If the additive keyword is not set, 200 replaces any old community that already exits; if we use the keyword additive then the 200 is added to the community. Even if we set the community attribute, this attribute is not sent to neighbors by default. In order to send the attribute to our neighbor we have to use the following:<br /><blockquote>neighbor {ip−address|peer−group−name} send−community<br /></blockquote><br />Here's an example:<br /><br /><blockquote>RTA#<br />router bgp 100<br />neighbor 3.3.3.3 remote−as 300<br />neighbor 3.3.3.3 send−community<br />neighbor 3.3.3.3 route−map setcommunity out</blockquote>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-44396226521946684972008-11-13T22:19:00.001-08:002008-11-13T22:19:39.928-08:00BGP Metric Attribute<span style="font-weight: bold;">Metric Attribute</span><br /><br /><a set="yes" linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgar-ZplMFAeGwB5W0buYgVHIgVfxIm_PMxNPn8pFHcppR8KAyhM5Ck1bZZCopvGyWw8vSaEoCeXoYCwroQ2wzR3WL2jSHqS5pS5O4P524Ripxt1WOR9zqjCsSTVgYay9JJbGY7mpt2gQ/s1600-h/Image20.JPG"><img style="cursor: pointer; width: 320px; height: 250px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgar-ZplMFAeGwB5W0buYgVHIgVfxIm_PMxNPn8pFHcppR8KAyhM5Ck1bZZCopvGyWw8vSaEoCeXoYCwroQ2wzR3WL2jSHqS5pS5O4P524Ripxt1WOR9zqjCsSTVgYay9JJbGY7mpt2gQ/s320/Image20.JPG" alt="" id="BLOGGER_PHOTO_ID_5263758133615057266" border="0" /></a><br /><br /><br />The metric attribute which is also called Multi_exit_discriminator, MED (BGP4) or Inter−As (BGP3) is a hint to external neighbors about the preferred path into an AS. This is a dynamic way to influence another AS on which way to choose in order to reach a certain route given that we have multiple entry points into that AS. A lower value of a metric is more preferred.<br /><br />Unlike local preference, metric is exchanged between ASs. A metric is carried into an AS but does not leave the AS. When an update enters the AS with a certain metric, that metric is used for decision making inside the AS. When the same update is passed on to a third AS, that metric will be set back to 0 as shown in the above diagram. The Metric default value is 0.<br /><br />Unless otherwise specified, a router will compare metrics for paths from neighbors in the same AS. In order for the router to compare metrics from neighbors coming from different ASs the special configuration command "bgp always−compare−med" should be configured on the router.<br /><br />In the above diagram, AS100 is getting information about network 180.10.0.0 via three different routers: RTC, RTD and RTB. RTC and RTD are in AS300 and RTB is in AS400.<br /><br />Assume that we have set the metric coming from RTC to 120, the metric coming from RTD to 200 and the metric coming from RTB to 50. Given that by default a router compares metrics coming from neighbors in the same AS, RTA can only compare the metric coming from RTC to the metric coming from RTD and will pick RTC as the best next hop because 120 is less than 200. When RTA gets an update from RTB with metric 50, he can not compare it to 120 because RTC and RTB are in different ASs (RTA has to choose based on some other attributes).<br /><br />In order to force RTA to compare the metrics we have to add bgp always−compare−med to RTA. This is illustrated in the configs below:<br /><br /><blockquote>RTA#<br />router bgp 100<br />neighbor 2.2.2.1 remote−as 300<br />neighbor 3.3.3.3 remote−as 300<br />neighbor 4.4.4.3 remote−as 400<br />....<br /><br />RTC#<br />router bgp 300<br />neighbor 2.2.2.2 remote−as 100<br />neighbor 2.2.2.2 route−map setmetricout out<br />neighbor 1.1.1.2 remote−as 300<br />route−map setmetricout permit 10<br />set metric 120<br /><br />RTD#<br />router bgp 300<br />neighbor 3.3.3.2 remote−as 100<br />neighbor 3.3.3.2 route−map setmetricout out<br />neighbor 1.1.1.1 remote−as 300<br />route−map setmetricout permit 10<br />set metric 200<br /><br />RTB#<br />router bgp 400<br />neighbor 4.4.4.4 remote−as 100<br />neighbor 4.4.4.4 route−map setmetricout out<br />route−map setmetricout permit 10<br />set metric 50</blockquote><br /><br />With the above configs, RTA will pick RTC as next hop, considering all other attributes are the same. In order to have RTB included in the metric comparison, we have to configure RTA as follows:<br /><br /><blockquote>RTA#<br />router bgp 100<br />neighbor 2.2.21 remote−as 300<br />neighbor 3.3.3.3 remote−as 300<br />neighbor 4.4.4.3 remote−as 400<br />bgp always−compare−med</blockquote><br /><br />In this case RTA will pick RTB as the best next hop in order to reach network 180.10.0.0.<br />Metric can also be set while redistributing routes into BGP using the default−metric number command.<br /><br />Assume in the above example that RTB is injecting a network via static into AS100 then the following configs:<br /><br /><blockquote>RTB#<br />router bgp 400<br />redistribute static<br />default−metric 50<br />ip route 180.10.0.0 255.255.0.0 null 0<br />!−− Causes RTB to send out 180.10.0.0 with a metric of 50</blockquote>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-62384003777748014212008-11-13T22:18:00.001-08:002008-11-13T22:18:57.962-08:00BGP Local Preference Attribute<span style="font-weight: bold;">Local Preference Attribute</span><br /><a set="yes" linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhov5rzc4HCKeYqN-pnD2AdTTarMatqzAnwsPeNlizLWRUbLo0tjIcWzcQ95gftVS90sFiOzJFru6VDvyd05_k53T7VsmEXVJK3z0ZS-u6wTBMz5169zPX3DJlg8PAxF6zG6JRbAEjo7Q/s1600-h/Image19.JPG"><img style="cursor: pointer; width: 320px; height: 237px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhov5rzc4HCKeYqN-pnD2AdTTarMatqzAnwsPeNlizLWRUbLo0tjIcWzcQ95gftVS90sFiOzJFru6VDvyd05_k53T7VsmEXVJK3z0ZS-u6wTBMz5169zPX3DJlg8PAxF6zG6JRbAEjo7Q/s320/Image19.JPG" alt="" id="BLOGGER_PHOTO_ID_5263755550094825666" border="0" /></a><br /><br /><br />Local preference is an indication to the AS about which path is preferred to exit the AS in order to reach a certain network. A path with a higher local preference is more preferred. The default value for local preference is 100.<br /><br />Unlike the weight attribute which is only relevant to the local router, local preference is an attribute that is exchanged among routers in the same AS.<br /><br />Local preference is set via the bgp default local−preference value> command or with route−maps as will be demonstrated in the following example:<br /><br />The bgp default local−preference command will set the local preference on the updates out of the router going to peers in the same AS. In the above diagram, AS256 is receiving updates about 170.10.0.0 from two different sides of the organization. Local preference will help us determine which way to exit AS256 in order to reach that network. Let us assume that RTD is the preferred exit point. The following configuration will set the local preference for updates coming from AS300 to 200 and those coming from AS100 to 150.<br /><br /><blockquote>RTC#<br />router bgp 256<br />neighbor 1.1.1.1 remote−as 100<br />neighbor 128.213.11.2 remote−as 256<br />bgp default local−preference 150<br /><br />RTD#<br />router bgp 256<br />neighbor 3.3.3.4 remote−as 300<br />neighbor 128.213.11.1 remote−as 256<br />bgp default local−preference 200</blockquote><br />In the above configuration RTC will set the local preference of all updates to 150. The same RTD<br />will set the local preference of all updates to 200. Since local preference is exchanged within AS256, both RTC and RTD will realize that network 170.10.0.0 has a higher local preference when coming from AS300 rather than when coming from AS100. All traffic in AS256 addressed to that network will be sent to RTD as an exit point.<br /><br />More flexibility is provided by using route maps. In the above example, all updates received by RTD will be tagged with local preference 200 when they reach RTD. This means that updates coming from AS34 will also be tagged with the local preference of 200. This might not be needed. This is why we can use route maps to specify what specific updates need to be tagged with a specific local preference as shown below:<br /><br /><blockquote>RTD#<br />router bgp 256<br />neighbor 3.3.3.4 remote−as 300<br />neighbor 3.3.3.4 route−map setlocalin in<br />neighbor 128.213.11.1 remote−as 256<br />....<br />ip as−path access−list 7 permit ^300$<br />...<br />route−map setlocalin permit 10<br />match as−path 7<br />set local−preference 400<br />route−map setlocalin permit 20<br />set local−preference 150</blockquote><br />With this configuration, any update coming from AS300 will be set with a local preference of 200. Any other updates such as those coming from AS34 will be set with a value of 150.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-7239519373865226701.post-21244200817535812522008-11-13T22:17:00.002-08:002008-11-13T22:18:22.291-08:00BGP Synchronization<a set="yes" linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEissPFWHGy2KnR7t-PzlI1-GhBd8_iHbltUYBH-QJLKDKiMl6-usT0B8EN42Zb7YDmSA65RN2IbqCWhQyIQ48ec1pO0TFRtHg8Pzl1wPgd1k5TyTnnXeWgpN5MPtiwWt6aRy1quxDM2KQ/s1600-h/Image16.JPG"><img style="cursor: pointer; width: 320px; height: 233px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEissPFWHGy2KnR7t-PzlI1-GhBd8_iHbltUYBH-QJLKDKiMl6-usT0B8EN42Zb7YDmSA65RN2IbqCWhQyIQ48ec1pO0TFRtHg8Pzl1wPgd1k5TyTnnXeWgpN5MPtiwWt6aRy1quxDM2KQ/s320/Image16.JPG" alt="" id="BLOGGER_PHOTO_ID_5263752950131251394" border="0" /></a><br /><br />Before we discuss synchronization let us look at the following scenario. RTC in AS300 is sending updates about 170.10.0.0. RTA and RTB are running IBGP, so RTB will get the update and will be able to reach 170.10.0.0 via next hop 2.2.2.1 (remember that the next hop is carried via IBGP). In order to reach the next hop, RTB will have to send the traffic to RTE.<br /><br />Assume that RTA has not redistributed network 170.10.0.0 into IGP, so at this point RTE has no idea that 170.10.0.0 even exists.<br /><br />If RTB starts advertising to AS400 that he can reach 170.10.0.0 then traffic coming from RTD to RTB with destination 170.10.0.0 will flow in and get dropped at RTE.<br /><br />Synchronization states: If your autonomous system is passing traffic from another AS to a third AS, BGP should not advertise a route before all routers in your AS have learned about the route via IGP.<br /><br />BGP will wait until IGP has propagated the route within the AS and then will advertise it to external peers. This is called synchronization.<br /><br />In the above example, RTB will wait to hear about 170.10.0.0 via IGP before it starts sending the update to RTD. We can fool RTB into thinking that IGP has propagated the information by adding a static route in RTB pointing to 170.10.0.0. Care should be taken to make sure that other routers can reach 170.10.0.0 otherwise we will have a problem reaching that network.<br /><br /><span style="font-weight: bold;">Disabling Synchronization</span><br /><br />In some cases you do not need synchronization. If you will not be passing traffic from a different autonomous system through your AS, or if all routers in your AS will be running BGP, you can disable synchronization. Disabling this feature can allow you to carry fewer routes in your IGP and allow BGP to converge more quickly.<br /><br />Disabling synchronization is not automatic, if you have all your routers in the AS running BGP and you are not running any IGP, the router has no way of knowing that, and your router will be waiting forever for an IGP update about a certain route before sending it to external peers. You have to disable synchronization manually in this case for routing to work correctly:<br /><br />router bgp 100<br />no synchronization<br /><br />(Make sure you do a <span style="font-weight: bold;">clear ip bgp</span> address to reset the session.)<br /><br /><a set="yes" linkindex="4" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiBpuxR3CXhoo3Z0xjCMhjbltA8FORseEsCmza3hBU3GDOuSC1koqq9B0gBiFXIx8xUTw7jFozfprbhiM2iHHdwr3qx_QbXXqoUcs2Ax2muXuzmz7RtGBprpkmxFNDyRuYflR_iAcA5vA/s1600-h/Image17.JPG"><img style="cursor: pointer; width: 320px; height: 230px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiBpuxR3CXhoo3Z0xjCMhjbltA8FORseEsCmza3hBU3GDOuSC1koqq9B0gBiFXIx8xUTw7jFozfprbhiM2iHHdwr3qx_QbXXqoUcs2Ax2muXuzmz7RtGBprpkmxFNDyRuYflR_iAcA5vA/s320/Image17.JPG" alt="" id="BLOGGER_PHOTO_ID_5263752950124089042" border="0" /></a><br /><br /><blockquote>RTB#<br />router bgp 100<br />network 150.10.0.0<br />neighbor 1.1.1.2 remote−as 400<br />neighbor 3.3.3.3 remote−as 100<br />no synchronization<br /><span style="color: rgb(51, 51, 255); font-style: italic;">!−− RTB puts 170.10.0.0 in its IP routing table and advertises it to</span><br /><span style="color: rgb(51, 51, 255); font-style: italic;">!−− RTD even if it does not have an IGP path to 170.10.0.0)</span><br /></blockquote>RTD#<br />router bgp 400<br />neighbor 1.1.1.1 remote−as 100<br />network 175.10.0.0<br /><br />RTA#<br />router bgp 100<br />network 150.10.0.0<br />neighbor 3.3.3.4 remote−as 100Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-7239519373865226701.post-37921999668635480622008-11-13T22:17:00.001-08:002008-11-13T22:17:41.522-08:00BGP Nexthop Attribute<p><span style="font-weight: bold;">BGP Nexthop Attribute</span><br /></p><div style="text-align: justify;"><br /></div><div style="text-align: center;"><a linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg0ICdrdqxO5n-gUgvAAGomP0l0AfNHI6hHxljJrD0diSIZTdWXMsqfUIpTZSX3-OO24kQuzyWm1PAOnOG3plFpFig8qfoSfydsv-KtWb6bbBtG4izDLBPAOIMBdCEE4V1JUYgqG5zAow/s1600-h/Image12.JPG"><img style="cursor: pointer; width: 320px; height: 210px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg0ICdrdqxO5n-gUgvAAGomP0l0AfNHI6hHxljJrD0diSIZTdWXMsqfUIpTZSX3-OO24kQuzyWm1PAOnOG3plFpFig8qfoSfydsv-KtWb6bbBtG4izDLBPAOIMBdCEE4V1JUYgqG5zAow/s320/Image12.JPG" alt="" id="BLOGGER_PHOTO_ID_5263748686021301538" border="0" /></a><br /></div><br />The BGP nexthop attribute is the next hop IP address that is going to be used to reach a certain destination.<br /><br />For EBGP, the next hop is always the IP address of the neighbor specified in the neighbor command. In the above example, RTC will advertise 170.10.0.0 to RTA with a next hop of 170.10.20.2 and RTA will advertise 150.10.0.0 to RTC with a next hop of 170.10.20.1. For IBGP, the protocol states that the next hop advertised by EBGP should be carried into IBGP. Because of that rule, RTA will advertise 170.10.0.0 to its IBGP peer RTB with a next hop of 170.10.20.2. So according to RTB, the next hop to reach 170.10.0.0 is 170.10.20.2 and not 150.10.30.1.<br /><br />You should make sure that RTB can reach 170.10.20.2 via IGP, otherwise RTB will drop packets destined to 170.10.0.0 because the next hop address would be inaccessible. For example, if RTB is running IGRP you could also run igrp on RTA network 170.10.0.0. You would want to make IGRP passive on the link to RTC so BGP is only exchanged.<br /><br /><blockquote>RTA#<br />router bgp 100<br />neighbor 170.10.20.2 remote−as 300<br />neighbor 150.10.50.1 remote−as 100<br />network 150.10.0.0<br /><br />RTB#<br />router bgp 100<br />neighbor 150.10.30.1 remote−as 100<br /><br />RTC#<br />router bgp 300<br />neighbor 170.10.20.1 remote−as 100<br />network 170.10.0.0<br /><br />*RTC will advertise 170.10.0.0 to RTA with a NextHop 170.10.20.2<br />*RTA will advertise 170.10.0.0 to RTB with a NextHop= 170.10.20.2<br />(The external NextHop via EBGP is sent via IBGP)<br /></blockquote><br /><span style="font-weight: bold;">BGP Nexthop (Multiaccess Networks)</span><br /><br /><div style="text-align: center;"><a linkindex="4" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiL6pYw3gVEZcKfy6tpNeyyYDkMY5u2ADTwL3S7rRohPMWomNQ0o9DWmJelEkU2i7ShECN0_vDGahAEC-uQxXSZ-5mBSH30Ts5MJ_9rbJmS4oXNIlaov_X1p4JT5294GBEvp3E9nimDqQ/s1600-h/Image13.JPG"><img style="cursor: pointer; width: 320px; height: 217px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiL6pYw3gVEZcKfy6tpNeyyYDkMY5u2ADTwL3S7rRohPMWomNQ0o9DWmJelEkU2i7ShECN0_vDGahAEC-uQxXSZ-5mBSH30Ts5MJ_9rbJmS4oXNIlaov_X1p4JT5294GBEvp3E9nimDqQ/s320/Image13.JPG" alt="" id="BLOGGER_PHOTO_ID_5263748699708130658" border="0" /></a><br /></div><br />The following example shows how the nexthop will behave on a multiaccess network such as ethernet.<br /><br />Assume that RTC and RTD in AS300 are running OSPF. RTC is running BGP with RTA. RTC can reach network 180.20.0.0 via 170.10.20.3. When RTC sends a BGP update to RTA regarding 180.20.0.0 it will use as next hop 170.10.20.3 and not its own IP address (170.10.20.2). This is because the network between RTA, RTC and RTD is a multiaccess network and it makes more sense for RTA to use RTD as a next hop to reach 180.20.0.0 rather than making an extra hop via RTC.<br /><br />*RTC will advertise 180.20.0.0 to RTA with a NextHop 170.10.20.3.<br /><br />If the common media to RTA, RTC and RTD was not multiaccess, but NBMA (Non Broadcast Media Access) then further complications will occur.<br /><br /><span style="font-weight: bold;">BGP Nexthop (NBMA)</span><br /><br /><div style="text-align: center;"><a linkindex="5" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgkzKpDVP-Uo1kSEqvSHs3VEEj5pM7Fqxh4ddKCeHeQ-vzVSvZ-feyC3jDPApfpQNKOR97J9RZ8mZMXzALV09GabW3Q3Wxubur_AfLB6FKhap2j12cWszsqLDwmIOEOUyRYM_WtlgJM7g/s1600-h/Image14.JPG"><img style="cursor: pointer; width: 320px; height: 201px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgkzKpDVP-Uo1kSEqvSHs3VEEj5pM7Fqxh4ddKCeHeQ-vzVSvZ-feyC3jDPApfpQNKOR97J9RZ8mZMXzALV09GabW3Q3Wxubur_AfLB6FKhap2j12cWszsqLDwmIOEOUyRYM_WtlgJM7g/s320/Image14.JPG" alt="" id="BLOGGER_PHOTO_ID_5263749534772146514" border="0" /></a><br /></div><br />If the common media as you see in the shaded area above is a frame relay or any NBMA cloud then the exact behavior will occur as if we were connected via ethernet. RTC will advertise 180.20.0.0 to RTA with a next hop of 170.10.20.3.<br /><br />The problem is that RTA does not have a direct PVC to RTD, and cannot reach the next hop. In this case routing will fail.<br /><br />In order to remedy this situation a command called NextHopself is created.<br /><br /><span style="font-weight: bold;">Nexthopself</span><br /><br />Because of certain situations with the nexthop as we saw in the previous example, a command called <span style="font-weight: bold;">next−hop−self</span> is created. The syntax is:<br /><span style="font-weight: bold;"><blockquote>neighbor {ip−address|peer−group−name} next−hop−self</blockquote></span>The next−hop−self command allows us to force BGP to use a specified IP address as the next hop rather than letting the protocol choose the next hop.<br /><br />In the previous example, the following configuration solves our problem:<br /><br /><blockquote>RTC#<br />router bgp 300<br />neighbor 170.10.20.1 remote−as 100<br />neighbor 170.10.20.1 next−hop−self<br /></blockquote><br />RTC advertises 180.20.0.0 with a NextHop = 170.10.20.2Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-7239519373865226701.post-48440994166974041782008-11-13T22:16:00.000-08:002008-11-13T22:17:05.657-08:00BGP Origin Attribute<div style="text-align: justify;">Origin Attribute<br /><br />The origin is a mandatory attribute that defines the origin of the path information. The origin attribute can assume three values:<br /><br />IGP: Network Layer Reachability Information (NLRI) is interior to the originating AS. This normally happens when we use the bgp network command or when IGP is redistributed into BGP, then the origin of the path info will be IGP. This is indicated with an "i" in the BGP table.<br /><br />EGP: NLRI is learned via EGP (Exterior Gateway Protocol). This is indicated with an "e" in the BGP table.<br /><br />INCOMPLETE: NLRI is unknown or learned via some other means. This usually occurs when we redistribute a static route into BGP and the origin of the route will be incomplete. This is indicated with an "?" in the BGP table.<br /><br /><br /><div style="text-align: center;"><a linkindex="3" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjSS8OehbpCU6KVd6EuzuKssj9ojfM8HDqywgljU9JCG5Zt12mAhNHqjt1qbqL456p0B-FhxH6W7mQtpjVkA2mM9a_SgMA1ZS-0h7CBNqhth2Jg-rmIqH4Kn8AWdzubBB6TmKXdphAVtQ/s1600-h/Image11.JPG"><img style="cursor: pointer; width: 320px; height: 248px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjSS8OehbpCU6KVd6EuzuKssj9ojfM8HDqywgljU9JCG5Zt12mAhNHqjt1qbqL456p0B-FhxH6W7mQtpjVkA2mM9a_SgMA1ZS-0h7CBNqhth2Jg-rmIqH4Kn8AWdzubBB6TmKXdphAVtQ/s320/Image11.JPG" alt="" id="BLOGGER_PHOTO_ID_5263747818815800546" border="0" /></a><br /></div><br /><br /><blockquote>RTA#<br />router bgp 100<br />neighbor 190.10.50.1 remote−as 100<br />neighbor 170.10.20.2 remote−as 300<br />network 150.10.0.0<br />redistribute static<br />ip route 190.10.0.0 255.255.0.0 null0<br /><br />RTB#<br />router bgp 100<br />neighbor 150.10.30.1 remote−as 100<br />network 190.10.50.0<br /><br />RTE#<br />router bgp 300<br />neighbor 170.10.20.1 remote−as 100<br />network 170.10.0.0<br /></blockquote><br /></div>RTA will reach 170.10.0.0 via: 300 i (which means the next AS path is 300 and the origin of the route is IGP).<br /><br />RTA will also reach 190.10.50.0 via: i (which means, the entry is in the same AS and the origin is IGP).<br /><br />RTE will reach 150.10.0.0 via: 100 i (the next AS is 100 and the origin is IGP).<br />RTE will also reach 190.10.0.0 via: 100 ? (the next AS is 100 and the origin is incomplete "?", coming from a static route).Unknownnoreply@blogger.com2