10: Deploying BGP

IBGP and EBGP

If the two peers are in the same AS, the session is an IBGP session. Otherwise, the session is an EBGP session. The distinction affects things such as the path selection.

EBGP sessions are usually established using the IP addresses of the physical interfaces over which the session is established. This prevents remote ASs needing to maintain any routing information about the inside of the other AS. It also ensures that all traffic exchanged within the session goes over the link by which the session was established.

IBGP sessions are usually established between loopback addresses. Another IGP is used to maintain the sessions regardless of the physical topology between the routers.

IBGP Route Propagation

IBGP peers send routes that they have learned from EBGP peers. To prevent loops, IBGP peers do not send routes that they have learned from other IBGP peers. To ensure that all routers maintain consistent BGP routing information, a full mesh of IBGP routers is required.

Using route reflectors or confederations can reduce or alleviate the full mesh requirement.

By default, only active BGP routes are advertised. IBGP advertises routes learned from EBGP. EBGP advertises routes learned from either EBGP or IBGP. IBGP does not advertise any routes learned from IBGP (as above, to prevent loops).

IBGP Next-Hop Propagation

By default, BGP does not change the next hop attribute for routes received from EBGP peers. IBGP will only install routes which have a reachable next hop. Therefore, for routes to propagate successfully into IBGP, either the router’s IGP must provide a route to the EBGP peer’s interface with the remote EBGP peer (by installing it with the passive option), or the next hop must be rewritten with the next-hop self routing policy action.

Configuring BGP

routing-options {
    router-id ...;
    autonomous-system ...;
}

protocols {
    bgp {
        group int-... {
            type internal;
            local-address ...;
            neighbor ...;
        }
        group ext-... {
            type external;
            peer-AS ...;
            neighbour ...;
        }
    }
}

The ASN can also be configured in a BGP group, to allow the router to peer with routers in other ASNs when merging networks.

The session type does not have to be defined. Junos infers from the peer-AS whether the session should be internal or external.

Changing the Next Hop

Routes redistributed into IBGP should have a next hop set to the loopback IP address of the router, because this local IP address is advertised into the IGP. Do not use the accept action in this policy statement, as it would cause the router to accept all routes and advertise them to all its IBGP peers.

poilcy-options {
    policy-statement next-hop-self-policy {
        term alter-next-hop {
            then {
                next-hop self;
            }
        }
    }
}
protocols {
    bgp {
        group int-... {
            type internal;
            local-address ...;
            export next-hop-self-policy;
            neighbor ...;
        }
        group ext-... {
            type external;
            peer-AS ...;
            neighbour ...;
        }
    }
}

Advertising the Aggregate Route

routing-options {
    aggregate {
        route ...;
    }
}

policy-options {
    policy-statement advertise-aggregate {
        term match-aggregate {
            from {
                protocol aggregate;
                route-filter ... exact;
            }
            then accept;
        }
    }
}

protocols {
    bgp {
        group ext-... {
            type external;
            export advertise-aggregate;
            peer-AS ...;
            neighbor ...;
        }
    }
}

Applying Policy to BGP

Routing policy can be applied at the protocol, group, and neighbour levels in the configuration hierarchy. Only the policy in the most specific level will be applied. Policies will only be inherited from less specific levels if one is not configured in the more specific levels.

An import policy affects routes that are learned from BGP and entered into the local routing table (RIB).

Export policies affect routes from the local routing table (RIB) which are advertised by BGP. An export policy cannot, by default, advertise a route which is locally inactive. This can be changed with the advertise-inactive configuration option. Export policies do not change the routes installed in the local routing table; they only change the exported version of the route.

Monitoring BGP

show bgp summary shows the number of groups, peers and downed peers, and a list of peers. show bgp peer shows much more detailed information about each peer.

show bgp group lists groups including group type, AS, export policies, and peers.

Routes learned from BGP may be displayed with show route protocol bgp. To see routes received by BGP before import policy processing has ocurred, show route receive-protocol bgp ... may be used, specifying the neighbour RID.

The show route advertising-protocol bgp ... command shows routes advertised to a specific BGP neighbour.