BGP Community

Discussion in 'Networking' started by sunnyvikash, Feb 24, 2013.

  1. sunnyvikash

    sunnyvikash Junior Member

    Joined:
    Feb 24, 2013
    Messages:
    1
    Likes Received:
    0
    Hi all,
    I am new to this forum. I want to know what the does Rule of sunchronization exactly says in BGP ?
     
  2. m1ldslide1

    m1ldslide1 Platinum Member

    Joined:
    Feb 20, 2006
    Messages:
    2,322
    Likes Received:
    0
    Basically that an iBGP speaker won't advertise a prefix to an iBGP peer unless it is also in the routing table via IGP. This is something I know for exam-taking purposes, but I don't think you will see it in real life. Recent versions of IOS have it disabled by default. Does anyone know of a scenario where you would actually want to enable it??
     
  3. Gryz

    Gryz Golden Member

    Joined:
    Aug 28, 2010
    Messages:
    1,139
    Likes Received:
    4
    Synchronization is that a BGP-speaker will not advertise an iBGP learned route to an eBGP-neighbor, before it has learned that same route via the IGP. (BGP never advertises iBGP-learned routes to iBGP-neighbors (unless it's a route-reflector)).

    You want to enable synchronization when you run BGP only on the outer routers in your AS, and when you do not run BGP on the inner routers in your network. (Implying that those "inner routers" are (or can be) transit-routers)).

    The idea was once that you would redistribute all BGP routes into your IGP.
    Example: AS1 - eBGP speaker 1A - eBGP speaker 2A (in AS2) - IGP-only router 2B (in AS2) - eBGP speaker 2C (in AS2) - eBGP speaker 3A (in AS3) - AS3.

    We are AS2.
    We have 3 routers. 2A and 2C speak iBGP. 2B does not run BGP.

    Suppose someone wants to send a packet from AS1 to AS3. Via AS2.
    The packet will go from AS1 to 1A -> 2A -> 2B -> 2C -> 3A -> AS3.
    All the BGP speakers will know the route to the enddestination in AS3.
    But router 2B does not. Because it doesn't speak BGP.
    So if we don't do anything, 2B will drop the packet.

    There are 2 solutions.
    1) Make 2B a BGP-speaker. This is current common practice nowadays. We configure 2B to speak iBGP with 2A and 2C. I've only seen this since I looked at BGP (which was in 1994).
    or 2) Make 2A and 2C redistribute their eBGP routes into the IGP.
    This was the initial idea of BGP. Many years ago. (20+).

    A problem happened when BGP would learn a route before the IGP would learn the route. Suppose 2C advertises a prefix from AS3 to 2A. Can 2A advertise it immediately to 1A ? Suppose the IGP is slow, and 2B has not learned the prefix yet. That means 2A will actually advertise a blackhole. Remember that in those everybody was still running RIP and IGRP.
    The solution was: 2A needs to wait until it has learned the prefix from AS3 via the IGP. Only then it knows that 2B knows the route too. And then it can advertise the prefix to 1A. This is called synchronization.

    Old stuff.
    But if you work with BGP, you should at least understand how and why it works. Even if you don't use it. It is similar to the reason why your area-0 in OSPF needs to be contiguous. Or why you L2-backbone in IS-IS needs to be contiguous.
     
    #4 Gryz, Feb 28, 2013
    Last edited: Feb 28, 2013
  4. dtiernan77

    dtiernan77 Junior Member

    Joined:
    Jul 18, 2015
    Messages:
    1
    Likes Received:
    0
    Question:

    I am going through a learning curve with VRF-Lite and my topology consist of CE-PE-PE-CE.

    Each CE has 2 VRF-Lite instances (gold / silver) each have a RD defined for each VRF Instance.

    My question is, when each CE establishes a BGP session and sends the BGP update message, should it contain the extended community information of the RD (2 of them) that are configured on each CE device?