IPv6 BGP

IPv6 Border Gateway protocol (BGP) communicates IPv6 routing information between Autonomous Systems (ASs). A Dell SonicWALL security appliance with IPv6 BGP support can replace a traditional BGP router on the edge of a network's AS.

IPv6 BGP is enabled on the Network > Routing page, but must be configured on the SonicOS Command Line Interface (CLI).

The following restrictions apply to SonicOS 6.2:

Topics:

Configuring Multiple Autonomous Systems

If an Autonomous System (AS) has multiple BGP routers, the AS can serve as a transit service for other ASs. When BGP runs between routers in different ASs, it uses exterior BGP (eBGP). When BGP runs between routers in the same AS, it uses interior BGP (iBGP).

In the following diagram, AS 200 is a transit AS for AS 100 and AS 300.

Figure 59. Autonomous System with multiple BGP routers configuration

To configure multiple ASs as shown in the above diagram, configure routers RTA, RTB, and RTC as follows:

On RTA:

On RTB:

On RTC:

Configuring Basic BGP over IPv6

A IPv6 BGP peer router can be configured to carry either IPv4 or IPv6 route information over either an IPv6 address family or an IPv4 address family.

Figure 60. Basic BGP over IPv6 configuration

To configure basic BGP over IPv6, configure routers R1 and R2 as follows:

On R1:

On R2:

Configuring EBGP Multihop

EBGP Multihop enables you to establish a neighbor connection between two external peers that are not directly connected. Multihop is available only for eBGP and is not available in for iBGP. When the firewall has an external neighbor that does not have a direct connection, you can use the ebgp−multihop command to establish a neighbor connection.

To configure EBGP Multihop, configure routers R1 and R2 as follows:

On R1:

On R2:

Configuring IPv6 BGP Outbound Route Filter

IPv6 BGP Outbound Route Filter (ORF) can be used to minimize the number of BGP updates sent between peer routers by filtering out unwanted routing updates at the source.

To configure IPv6 BGP Outbound Route Filter (ORF), configure routers R1 and R2 as follows:

On R1:

On R2:

To check the routes on R1 and R2, use the show bgp ipv6 unicast command.

The route on R1 should have IPv6 address 1010::1/128.

The route on R2 should have IPv6 address 1111::1/128.

On R1:

On R2:

Configuring IPv6 BGP Distribute List

IPv6 BGP Distribute List can be used to minimize the number of BGP updates sent between peer routers by filtering out unwanted routing updates at the source.

To configure IPv6 BGP Distribute List, configure routers R1 and R2 as follows:

On R1:

On R2:

To check the routes on R1 and R2, use the show bgp ipv6 unicast command.

The route on R1 should have IPv6 address 1010::1/128.

The route on R2 should have IPv6 address 1111::1/128.

On R1:

On R2:

IPv6 BGP Route-Map

IPv6 BGP Route-Map can be used to minimize the number of BGP updates sent between peer routers by filtering out unwanted routing updates at the source.

To configure IPv6 BGP Route-Map, configure routers R1 and R2 as follows:

On R1:

On R2:

To check the routes on R1 and R2, use the show bgp ipv6 unicast command.

On R1:

The route on R1 should have IPv6 address 1010::1/128.

On R2:

The route on R2 should have IPv6 address 1111::1/128.

Configuring an AS Regular Expression

You can configure regular expressions that can be matched and used to deny or allow addresses from an AS.

Figure 61. Autonomous System regular expression configuration

RTB advertises these routes:

RTC advertises these routes:

To check the routes on router RTA, use the show bgp ipv6 unicast command.

On RTA:

To configure AS regular expressions on RTA and deny all routes originated in AS100:

To check the routes on router RTA, use the show bgp ipv6 unicast command.

On RTA:

To modify the AS path to deny all routes learned from the AS100:

On RTA:

To check the routes on router RTA, use the show bgp ipv6 unicast command.

On RTA:

EBGP Route Selection

Routes are selected based on the administrative distance of the routing protocol running on that route. Routing protocols with lower administrative distances are given priority over routing protocols with higher administrative distances. EBGP has an administrative distance of 20. OSPF has an administrative distance of 110.

Figure 62 shows three ASs and the routing protocols used by the BGP routers.

Figure 62. Autonomous systems EBGP route selection configuration

The RTC router in AS300 advertises route 1000::/64 to both AS100 and to AS200.

The route from RTC (AS300) to RTA (AS100) runs OSPF.

The route from RTC (AS300) to RTB (AS200) runs eBGP.

The route from RTA (AS100) to RTB (AS200) runs eBGP.

RTA (AS100) receives updates about route 1000::/64 from both OSPF and eBGP. The route learned from eBGP is selected and added to RTA’s routing table, because the administrative distance of eBGP is less than the administrative distance of OSPF.

On RTA:

On RTB:

On RTC:

To check the routes on router RTA, use the show ipv6 route command.

Since RTC is directly connected to RTA, the route from OSPF is actually a better route than the route learned by BGP. To ensure that the route between RTA and RTC is selected for the routing table, you can use the distance command to change the default administrative distance of the BGP route to a higher administrative distance than the OSPF route. For example:

You can also use the backdoor neighbor command to set the BGP route as the preferred route. For example:

On RTA:

To check the routes on router RTA, use the show ipv6 route command.

IPv6 BGP Synchronization

IPv6 BGP Synchronization keeps all BGP routers updated with the IPv6 addresses of all available routes and networks.

In BGP Synchronization, if an AS (AS100) passes traffic from another AS (AS300) to a third AS (AS400), BGP does not advertise that route until all the routers in AS100 have learned that route from the IGP. In this case, the IGP is iBGP. AS100 must wait until iBGP has propagated that route to all routers within AS100. Then, eBGP advertises the route to external ASs.

In this example, after RTB learns address 6666::6/128 via iBGP. it then advertises the address to RTD.

Figure 63. IPv6 BGP synchronization example

NOTE: You can make RTB think that IGP has already propagated the route information by adding a static route to 6666::6/128 on RTB and making sure that the other routers can reach 6666::6/128.

In this example, RTC (AS2) advertises address 6666::6/128 to RTA (AS100). In AS100, RTA and RTB are running iBGP, so RTB learns address 6666::6/128 and is able to reach it via next hop 5.5.5.5 (RTC). Next hop is carried via iBGP. However, to reach the next hop (RTC), RTB must send traffic through RTE, but RTE does not know IP address 6666::6/128.

If RTB advertises 6666::6/128 to RTD (AS400), traffic that tries to reach 6666::6/128 from RTD must pass through RTB and RTE in AS100. However, since RTE has not learned 6666::6/128, all packets will be dropped at RTE.

To configure BGP Synchronization on RTB in AS100:

On RTB:

You can disable synchronization if you do not pass traffic from one AS to another AS through an intermediate AS. You can also disable synchronization if all routers in the intermediate AS run BGP. Disabling synchronization lets you to carry fewer routes in your IGP and allows BGP to converge more quickly.

To disable BGP Synchronization on RTB in AS100:

On RTB:

BGP Route Reflection

By default, all iBGP routers in an AS must be in a full mesh configuration. Each router must be configured as a peer to every other router.

With route reflection, all iBGP routers do not need to be fully meshed. Route reflection eliminates the need for each iBGP router to communicate with every other iBGP router in the AS. An iBGP router can be designated as a route reflector and can pass iBGP learned routes to multiple iBGP clients.

When a router is configured as a route reflector, it acts as a single point where all the other iBGP routers can get the iBGP learned routes. The route reflector acts like a server, rather than a peer, for every other router in the AS. All the other IBGP routers become route reflector clients. A router is a route reflector as long as it has at least one route reflector client.

Figure 64. BGP route reflection configuration

To configure route reflection in an AS:

On RouterA:

On RRClient1:

RRClient2:

To check the routes, use the show bgp ipv6 unicast command:

On RRClient1:

You should see route 2020:20:20:20::20/128.

On RRClient2:

You should see route 1010:10:10:10::10/128.

IPv6 BGP Local Preference

The local preference designates a route to a certain network as the preferred exit route to that network from the AS. The route with a highest local preference is the preferred route. The default value of the local preference is 100, but this can be changed using the set local-preference command.

Figure 65. IPv6 BGP local preference configuration

To configure the local preference of a preferred route in an AS:

On R1:

On R2:

On R3:

On R4:

On R5:

To verify the route, use the show bgp ipv6 unicast command:

On R2:

Before the local preference is configured, R2 has R1 as its next hop for all learned IPv6 addresses. After configuring the local preference on R3 to 500, R2 has a different preferred exit route for prefix BC01:BC1:10:A::/64. R2 can now reach prefix BC01:BC1:10:A::/64 through the exit path of R3, which is now designated as the local preference.

BGP Peer Group Update Policies

A BGP peer group is a group of BGP neighbors that share the same update policies. Update policies are typically set by route maps, distribution lists, and filter lists.

When you define a peer group and add neighbors to it, all of the update policies that you assign to that peer group apply to all of the neighbors in that peer group. You do not need to define a policy for each neighbor.

Members of a peer group inherit all of the configuration settings of that peer group. You can configure certain members to override the update policies, but only if those policies are set for inbound traffic. You cannot configure members to override group policies if the policies apply to outbound traffic.

Figure 66. BGP peer group update policy configuration

To configure an IPv6 BGP peer group and its update policies:

On R3:

To verify that the correct local preference route is configured, use the show bgp ipv6 unicast command:

On R3:

Verify that IPv6 address BC01:BC1:10:A::/64 passes from AS100 to R1 and R2, and that the metric and local preference are set to the corresponding route-map settings.

BGP Confederation

You can divide a single AS into multiple ASs, and then assign these multiple ASs to a single confederation of ASs. The implementation of a BGP confederation reduces the iBGP mesh size of the AS, and the confederation can still advertise as a single AS to external peers.

Each individual AS within a confederation runs fully meshed iBGP, and each individual AS within the confederation also runs eBGP connections to the other ASs inside the confederation. These eBGP peers within the confederation exchange routing information as if they used iBGP. In this way, the confederation preserves next hop, metric, and local preference information. To the outside world, the confederation appears to be a single AS.

Figure 67. BGP confederation configuration

To configure a BGP Confederation:

R1:

On R2:

On R3:

On R5:

Verify that R1, R2, and R3 can learn this route that is advertised by R5:

Verify that R2 can learn this route from R1 even though they are not directly connected:

NOTE: The IPv6 BGP configuration data and the IPv6 BGP routes are dumped into a Terminate and Stay Resident (TSR) file.

NOTE: IPv6 BGP uses the ZebOS debug interface. The default setting for all debug switches is closed. Entering the CLI debug command on the console opens the debug switch.