[Contents] [Prev] [Next] [Index] [Report an Error]

Preventing Routing Loops

Routing loops can occur when routes learned from a peer are later advertised back to that peer. Normally such routing loops are prevented by the AS path attribute. However, the AS path cannot prevent routing loops in a network configuration with the following characteristics:

BGP is running between CE and PE routers.
You use a single AS number for all customer sites, and have issued the neighbor as-override command for the PE routers.
A CE router is dual-homed to two or more PE routers.

The site-of-origin extended community attribute enables BGP to filter out such routes to prevent routing loops in this network. You can use the set extcommunity command to specify a site of origin and then use the match extcommunity command and an outbound route map to filter routes; for more information, see Extended Community Lists in the JUNOSe IP Services Configuration Guide.

Alternatively, you can use the neighbor site-of-origin command alone to achieve the same effect in such a network configuration. Consider the network shown in Figure 96, which enables PE 3 to advertise back to CE 1 routes that it learned from PE 1 that originated with CE 1. In a typical network configuration, CE 1 rejects these routes because it determines from the AS path that a routing loop exists. In this particular network, the neighbor as-override command prevents this method of detection.

Figure 96: Network with Potential Routing Loops

Image g013217.gif

The following commands are relevant to the illustrated network:



host1:pe1(config)#ip vrf yourvpn 

host1:pe1(config-vrf)#rd 200:1 

host1:pe1(config-vrf)#route-target both 200:11 

...
host1:pe1(config)#router bgp 200 

host1:pe1(config-router)#address-family ipv4
unicast vrf yourvpn 

host1:pe1(config-router)#neighbor 10.5.4.22
remote-as 100 

host1:pe1(config-router)#neighbor 10.5.4.22
as-override 

...

Now, suppose instead you assign a unique site of origin to each CE router in the network and configure the BGP session on each PE router with the site of origin. The result of the following (partial) configuration is shown in Figure 97.



host1:pe1(config)#ip vrf yourvpn 

host1:pe1(config-vrf)#rd 200:1 

host1:pe1(config-vrf)#route-target both 200:11 

...
host1:pe1(config)#router bgp 200 

host1:pe1(config-router)#address-family ipv4
unicast vrf yourvpn 

host1:pe1(config-router)#neighbor 10.5.4.22
remote-as 100 

host1:pe1(config-router)#neighbor 10.5.4.22
as-override 

host1:pe1(config-router)#neighbor 10.5.4.22
site-of-origin 200:21 

...

Figure 97: Preventing Potential Routing Loops in the Network

Image g013218.gif

neighbor site-of-origin

Use to set a site of origin that is included in the extended community list for routes received from the specified peer.
If you use this command to configure a site of origin for routes from a peer, then routes advertised to that peer that contain this site of origin are filtered out and not advertised. This behavior is followed regardless of whether the neighbor send-community extended command has been issued for the peer.
The configured site of origin does not override the site of origin if it is already present in the extended community list of a route.
If you specify a BGP peer group by using the peer-group-name argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override the characteristic for a specific member of the peer group.
The site of origin is applied to all routes that are received or advertised to all after you issue the command. The session is not bounced.
To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Examplehost1(config-router)#neighbor 10.25.32.4 site-of-origin 200:21
Use the no version to remove the site of origin for routes received from the peer.
See neighbor site-of-origin.

[Contents] [Prev] [Next] [Index] [Report an Error]