Receiving and Sending RT-MEM-NLRI Routing Updates

RT-MEM-NLRI routing updates are processed in the following sequence:

1. During the initial RT-MEM-NLRI route exchange that takes place when a session with a peer is being brought up, BGP sends an End-of-RIB marker for RT-MEM-AFI-SAFI that signals it has finished advertising route-target membership information.
2. Remote peers interpret the End-of-RIB marker for RT-MEM-AFI-SAFI to mean that the BGP speaker has advertised all of its route target-memberships. If the BGP speaker does not receive an End-of-RIB marker for RT-MEM-AFI-SAFI from a remote BGP peer in the context of the route-target address family, by default the local BGP speaker waits for 60 seconds before timing out.
3. The BGP speaker then starts advertising its VPN routes. The routes are passed through the outbound route-target membership filters for that peer.
4. When a BGP speaker receives a RT-MEM-NLRI update message, it re-evaluates the advertisement status of VPN routes that match the corresponding route target in the peer's Adj-RIBS-Out table. This can result in an incremental update that advertises or withdraws some routes for the VPN.

You can use the bgp wait-on-end-of-rib command to specify how long BGP waits for the End-ofRIB marker from route-target peers.

When the route-refresh capability has been negotiated for the route-target address family. BGP handles route-refresh messages for the RT-MEM-AFI-SAFI by resending all RT-MEM-NLRI routes to the remote peer

You can use the neighbor maximum-prefix command to specify the maximum number of prefixes that the speaker can receive from a BGP peer.

Route-target filtering generally follows the standard BGP rules for route advertisement to determine when to advertise RT-MEM-NLRI prefixes that have been received from BGP peers. Table 61 lists the destinations that the prefixes are advertised to based on their source. In this table, client-to-client reflection is enabled and the source and destination peers are not the same.

Table 61: Route-Target Filtering Advertisement Rules for Routes Received from Peers

Advertising to IBGP clients varies from the standard advertisement rules in terms of path attribute modifications. When locally originated RT-MEM-NLRI routes are advertised to IBGP route reflector clients, BGP does the following:

• Sets the originator ID as the router ID of the advertising router.
• Sets the next hop as the local address of the session.

This behavior is useful when the route reflector does not advertise the Default-RT-MEM-NLRI route.

When locally originated RT-MEM-NLRI routes are advertised to IBGP route reflector nonclients, the route from the client is advertised to the nonclient peer when the best path route is advertised by a nonclient but an alternative route from a client exists. This behavior signals the client’s interest in the route target routes that were not selected as the best path.

You cannot filter RT-MEM-NLRI routes with inbound policies or outbound policies, because policy items cannot currently match a RT-MEM-NLRI prefix (origin AS number:route target). However, you can filter route-target filtering routes with policies that include items that match on other BGP attributes, such as the extended community attached to the route-target filtering route.

bgp wait-on-end-of-rib

• Use to configure how long BGP waits to receive End-of-RIB markers from route-target address family peers.
• The wait interval applies to all route-target address family peers.
• This command takes effect immediately.
• Example

  host1(config-router)#address-family route-target signaling

  host1(config-router-af)#bgp wait-on-end-of-rib 360

• Use the no version to restore the default wait interval, 60 seconds.
• See bgp wait-on-end-of-rib.

neighbor maximum-prefix

• Use to control how many prefixes can be received from a neighbor.
• If you specify a BGP peer group by using the peerGroupName argument, all the members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.
• By default, BGP checks the maximum prefix limit only against accepted routes. You can specify the strict keyword to force BGP to check the maximum prefix against all received routes. The accepted and received routes will likely differ when you have configured inbound soft reconfiguration and route filters for incoming traffic.
• This command takes effect immediately. To prevent a peer from continually flapping, when it goes to state idle because the maximum number of prefixes has been reached, the peer stays in state idle until you use the clear ip bgp command to issue a hard clear.
• Example

  host1(config-router)#address-family route-target signaling

  host1(config-router-af)#neighbor maximum-prefix 10.1.2.3 100

• Use the no version to remove the maximum number of prefixes.
• See neighbor maximum-prefix.

Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice.