We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is Why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • [geot exclude_region="No Trial" ] Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career![/geot]
  • Full Access to our 541 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

 

303 New Members signed up the last 30 days!

 
satisfaction-guaranteed

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags:


Notable Replies

  1. Well Done man. I was reading the same topic on the TCP/IP Vol II but the topology used there was quite confusing. Here you used a simple topology and explained to concept of it in a nice and clean way.

  2. Dear Rene,

    Nice explanation. I am bit confused about the use of the command bgp confederation identifier 2

    Should we use this command only to that router (R2) connecting to EBGP peers-R1 (the External Autonomous System, in this case 1 )?

    Or should we use the command also in the routers connecting to Sub-AS (inside the IBGP)?

    I saw you have used the command in all Routers. But do we need to use in all the sub-as routers? I am bit confused. Your help is highly appreciated.

    Thanks

  3. Dear Ahammad,

    You have to configure this on all routers within the sub-AS otherwise they won't consider themselves part of the confederation. They will be able to establish BGP peerings but they'll consider other routers in the confederation as regular "external" or "internal" neighbors. They will also drop routes when they see a confederation path in it.

    I tested this, here is the output of some show commands when I removed "bgp confederation identifier 2" on R3, R4 and R5:

    R3#show ip bgp 11.11.11.11
    BGP routing table entry for 11.11.11.11/32, version 19
    Paths: (1 available, best #1, table default)
    Flag: 0x820
      Advertised to update-groups: (Pending Update Generation)
         3         
      Refresh Epoch 1
      (24) 1
        192.168.12.1 (metric 2) from 2.2.2.2 (2.2.2.2)
          Origin IGP, metric 0, localpref 100, valid, external, best
          rx pathid: 0, tx pathid: 0x0

    R4#show ip bgp 11.11.11.11
    BGP routing table entry for 11.11.11.11/32, version 20
    Paths: (1 available, best #1, table default)
      Advertised to update-groups:
         1         
      Refresh Epoch 1
      1
        192.168.12.1 (metric 2) from 2.2.2.2 (2.2.2.2)
          Origin IGP, metric 0, localpref 100, valid, internal, best
          rx pathid: 0, tx pathid: 0x0

    R5#show ip bgp 11.11.11.11
    BGP routing table entry for 11.11.11.11/32, version 25
    Paths: (2 available, best #2, table default)
      Advertised to update-groups:
         1         
      Refresh Epoch 1
      24 1
        192.168.12.1 (metric 3) from 4.4.4.4 (4.4.4.4)
          Origin IGP, metric 0, localpref 100, valid, external
          rx pathid: 0, tx pathid: 0
      Refresh Epoch 1
      (24) 1
        192.168.12.1 (metric 3) from 3.3.3.3 (3.3.3.3)
          Origin IGP, metric 0, localpref 100, valid, internal, best
          rx pathid: 0, tx pathid: 0x0

    Here's one of the errors I noticed:

    R4#
    %BGP-6-ASPATH: Invalid AS path 35 (24) received from 5.5.5.5: Confederation AS-path found in the middle

    Hope this helps.

    Rene

  4. andrew says:

    Hi Kandhla,
    Yes, you can absolutely use the next-help-self option with iBGP. In fact, in some circumstances you might HAVE to. For example, let's say you have a router (R1) with an external BGP relationship with an ISP, and your highly available site has been given two separate circuits from that ISP. To ensure that R1's BGP neighborship with the ISP is also highly available, you have configured R1 to use the ISP's router's loopback address (you would also have to use the ebgp-multihop option for this). To do this you would create static routes on R1 to get to the ISP's loopback through both of your circuits.

    Now, suppose that R1 also has an iBGP relationship with other routers you have inside your company (say, R2 and R3). What would happen to all the routes that R1 would learn from the ISP, when it shares them with R2 and R3? The answer is that the routes would not appear in the routing table, and the reason is the next-hop attribute associated with the routes.

    In order for BGP to consider a route valid, the very first thing it checks for is the reachability of the next-hop address. From the perspective of R2 and R3, they have no idea how to get to the loopback of the ISP's BGP router. The best way to fix this would be to do what you said--turn on the "next-hop-self" option for R1.

    --Andrew

Continue the discussion forum.networklessons.com

12 more replies

Participants