Physical to logical topology clarification


Just started with BGP labs, but whilst doing labs looking at the logical topolgies and trying to figure out how do I solve physcial to logical topology.


Looking at the neighbor realtionship between R5 and R7 why does R5 forms the neighbor realtionship with the peer and not  it just confuses me and I'm lost.

Can someone please help me clarify this is there a way to look between physical and logical topology and make sense.





  • As Martinl suggested, either one will work.  You just have to make sure that the address the TCP session is being sourced from matches what is configured in your neighbor statement.  By default, packets will be sourced by the outbound interface address unless told otherwise.

    You can either check your unicast routing first and see which interface the router will use to route to the remote neighbor when forming the BGP neighborship (use their outbound interface addresses in your neighbor statements), or you can tell the routers which address to use in the negotiation.

    For example:


    neigh remote 75

    neigh update-source gi1/0.58


    neigh remote 75

    neigh update-source gi1/0.7


    R5 is going to use in the TCP negotiations per the update-source command (so we need R7 to have as the neighbor statement).

    R7 is going to use in the TCP negotiations per the update-source command (so we need R5 to have as the  neighbor statement).


    Again, the update-source command is not required, but it is insuring we know which address it will use regardless of the unicast routing (the update-source interface must be in the up/up state in order to be used).  This will allow the routers to use whatever interface they want to in order to get to the remote neighbor, but the TCP session will be sourced from the same address every time (resulting in the neighbor statement being correct at the other end every time leading to the neighborship coming up).


    Hope this helps.

  • It is becasuse the metric via the R4 path instead of the DMVPN cloud has a lower total delay in EIGRP, which causes IGP to route via R6->R4->R5. For this reason it will use the GigabitEthernet1.67 interface.

    But it depends on the prefix in this case, for the DMVPN prefix it will use R3 because of lower metric, the other prefixes will use the R6 path. The metric is lower because the DMVPN prefix is connected on all spokes so the link between R4-R5 will not be used in this case. 

    It does not depend on the physical topology, but only the logical where the IGP metric wil detemine the path and interface. 

Sign In or Register to comment.