Question about BGP Configuration LAB- Establishing iBGP Peerings

Obviously this is a no-brainer to establish iBGP peering ... but the question I have regards why the INE solution selects certain ip addresses over others.  A router will have multiple paths to another router ... and yet there does not seem to be any consistency as to why it chooses one interface over another.

Does it really matter which interface I select to establish the peering?  Just want to make sure I am not missing something here.

Case in point ... R6 peers with R3 through R7.  I was thinking lower RTO.  Yet R7 peers with R1 though R6 .. higher RTO.  I only mentiin RTO because the EIGRP metrics are equal .. so I don't know what the tie-breaker is.

R6#show ip eigrp neigh
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
2   155.1.67.7               Fa0/0.67          12 00:28:59    2   200  0  6
1   155.1.146.4             Fa0/0.146         11 00:29:03    1   200  0  11
0   155.1.146.1             Fa0/0.146         11 00:29:07  816  4896  0  17

 

R7#show ip eigrp neigh
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   155.1.37.3              Fa0/0.37          13 00:26:48    3   200  0  19
0   155.1.67.6              Fa0/0.67          11 00:26:50 1596  5000  0  12

Comments

  • Thanks for the quick reply.

    I actually found a thread mentioning using the IP route table just after posting ... that worked for accurately determining the paths for R1-R4. 

    However, it didn't work for R5.  Based on the route table, R5 should peer with R7 through R4->R6.  The INE solution has the router going through the DMVPN tunnel from R3->R7.

    So I will take you advice and check the CEF table entries next.

  • Thanks Martin.  I overlooked the obvious with referencing the actual route table.  That appears to work for peering R1,R2,R3, and R4.  However, starting with R5 .. specifically with wihich interface to peer with R7 ... the route table npr the CEF table does not match what is recommended in the INE solution.

     

    Router 7 interfaces

    R7#show ip int br
    Interface                  IP-Address      OK? Method Status                Protocol
    FastEthernet0/0.7          155.1.7.7       YES NVRAM  up                    up     
    FastEthernet0/0.37         155.1.37.7      YES NVRAM  up                    up     
    FastEthernet0/0.67         155.1.67.7      YES NVRAM  up                    up     
    Loopback0                  150.1.7.7       YES NVRAM  up                    up


    Router 5 CEF table

    R5#show ip cef      
    Prefix               Next Hop             Interface
    155.1.7.0/24         155.1.45.4           FastEthernet0/0.45
    155.1.37.0/24        155.1.45.4           FastEthernet0/0.45
    155.1.67.0/24        155.1.45.4           FastEthernet0/0.45

     

    Based on this information R5 should learn about R7 from R4->R6->R7 (Gi1.67)

    Instead it peers with 155.1.37.7 ... which would be learned from its DMVPN client R3.

    Just trying ot figure out what the pattern is ???

     

  • <!DOCTYPE html>




    The usual guides to choose the peering address/interface are

     

    * ebgp: use direct connected interface for peering, but if you have alternate paths to the ebgp peer then use a loopback.

    * ibgp:  use a loopback.

     

    When you use a loopback for peering, you let the IGP routing protocol choose the bestpath between the loopbacks.

     

     

    --

    Paulo Roque


     


     

     

    Em Dom 19 abr. 2015, às 15:05, sclements escreveu:

    Obviously this is a no-brainer to establish iBGP peering ... but the question I have regards why the INE solution selects certain ip addresses over others.  A router will have multiple paths to another router ... and yet there does not seem to be any consistency as to why it chooses one interface over another.

    Does it really matter which interface I select to establish the peering?  Just want to make sure I am not missing something here.

    Case in point ... R6 peers with R3 through R7.  I was thinking lower RTO.  Yet R7 peers with R1 though R6 .. higher RTO.  I only mentiin RTO because the EIGRP metrics are equal .. so I don't know what the tie-breaker is.

    R6#show ip eigrp neigh
    EIGRP-IPv4 Neighbors for AS(100)
    H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                                (sec)         (ms)       Cnt Num
    2   155.1.67.7               Fa0/0.67          12 00:28:59    2   200  0  6
    1   155.1.146.4             Fa0/0.146         11 00:29:03    1   200  0  11
    0   155.1.146.1             Fa0/0.146         11 00:29:07  816  4896  0  17


    R7#show ip eigrp neigh
    EIGRP-IPv4 Neighbors for AS(100)
    H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                                (sec)         (ms)       Cnt Num
    1   155.1.37.3              Fa0/0.37          13 00:26:48    3   200  0  19
    0   155.1.67.6              Fa0/0.67          11 00:26:50 1596  5000  0  12

     

     

     



    INE - The Industry Leader in CCIE Preparation


     


    Subscription information may be found at:


     



  • I agree with martin, CEF table ultimately decides the path towards the
    destination as specified in the bgp neighbor statement

     

     

    Regards

  • Does that mean that the INE workbook solution is wrong for the first lab - Establishing iBGP Peerings?  R5 does not use the CEF table to peer with R7.  The CEF table takes it via R4-R6-R7.

    router bgp 100
    network 150.1.5.5 mask 255.255.255.255
    neighbor 155.1.0.1 remote-as 100
    neighbor 155.1.0.2 remote-as 100
    neighbor 155.1.0.3 remote-as 100
    neighbor 155.1.0.4 remote-as 100
    neighbor 155.1.37.7 remote-as 100   <-  R5 peers via R3 to R7
    neighbor 155.1.58.8 remote-as 100
    neighbor 155.1.146.6 remote-as 100

     

Sign In or Register to comment.