GP_Advanced_Routing
This appendix provides an overview of SonicWALL’s implementation of Border Gateway protocol (BGP), how BGP operates, and how to configure BGP for your network.
This appendix contains the following sections:
• Caveats
The following sections provide an overview of BGP:
BGP is a large-scale routing protocol used to communicate routing information between Autonomous Systems (ASs), which are well-defined, separately administered network domains. BGP support allows for SonicWALL security appliances to replace a traditional BGP router on the edge of a network's AS. The current SonicWALL implementation of BGP is most appropriate for "single-provider / single-homed" environments, where the network uses one ISP as their Internet provider and has a single connection to that provider. SonicWALL BGP is also capable of supporting "single-provider / multi-homed" environments, where the network uses a single ISP but has a small number of separate routes to the provider. BGP is enabled on the Network > Routing page of the SonicOS GUI and then it is fully configured through the SonicOS Command Line Interface (CLI).
BGP licensing requirements are shown in the table below.
|
Note BGP is supported on the NSA 3600 with the purchase of a SonicOS Expanded License. Licenses can be purchased on www.mysonicwall.com
Routing protocols are not just packets transmitted over a network, but comprise all the mechanisms by which individual routers, and groups of routers, discover, organize, and communicate network topologies. Routing protocols use distributed algorithms that depend on each participant following the protocol as it is specified, and are most useful when routes within a network domain dynamically change as links between network nodes change state.
Routing protocols typically interact with two databases:
• Routing Information Base (RIB) - Used to store all the route information required by the routing protocols themselves.
• Forward Information Base (FIB) - Used for actual packet forwarding.
The best routes chosen from the RIB are used to populate the FIB. Both the RIB and FIB change dynamically as routing updates are received by each routing protocol, or connectivity on the device changes.
There are two basic classes of routing protocols:
• Interior Gateway Protocols (IGPs) - Interior Gateway Protocols are routing protocols designed to communicate routes within the networks that exist inside of an AS. There are two generations of IGPs. The first generation consists of distance-vector protocols. The second generation consists of link-state protocols. The distance-vector protocols are relatively simple, but have issues when scaled to a large number of routers. The link-state protocols are more complex, but have better scaling capability. The existing distance-vector protocols are Interior Gateway Routing Protocol (IGRP), Enhanced Interior Gateway Routing Protocol (EIGRP), Routing Information Protocol (RIP), and RIPv2, an enhanced version of RIP. IGRP and EIGRP are proprietary Cisco protocols. The link-state protocols currently in use are Open Shortest Path First (OSPF) and the little-used Intermediate System to Intermediate System (IS-IS) protocol.
SonicOS supports OSPFv2 and RIPv1/v2 protocols, the two most common routing Interior Gateway Protocols, allowing our customers to use our products in their IGP networks and avoid the additional cost of a separate traditional router.
• Exterior Gateway Protocols (EGPs) - The standard, ubiquitous Exterior Gateway Protocol is BGP (BGP4, to be exact). BGP is large-scale routing protocol that communicates routing information and policy between well-defined network domains called Autonomous Systems (ASs). An Autonomous System is a separately administered network domain, independent of other Autonomous Systems. BGP is used to convey routes and route policy between Autonomous Systems. ISPs commonly use BGP to convey routes and route policy with their customers as well as with other ISPs.
Each Autonomous System has a 16-bit number assigned. Like IP addresses, an AS number may be public or private. Public AS numbers are a limited resource and are provisioned based on a number of factors. ISP customers with large networks multi-homed to two or more ISPs usually have a public AS, whereas smaller customers will be given a private AS administered by their ISP provider.
As our products evolve in support of enterprise-level requirements, some customers may want to place our products on the edge of their AS in place of a traditional BGP router.
Each Autonomous System has a 16-bit number assigned. Like IP addresses, an AS number may be public or private. Public AS numbers are a limited resource and are provisioned based on a number of factors. ISP customers with large networks multi-homed to two or more ISPs usually have a public AS, whereas smaller customers will be given a private AS administered by their ISP provider.
BGP is a very flexible and complex routing protocol. As such, BGP routers may be placed in a large variety of topology settings, such as Internet core routers, intermediary ISP routers, ISP Customer Premises Equipment (CPE), or routers in small private BGP networks. The number of BGP routes required for different topologies varies from greater than 300,000 for core routers, to 0 for ISP customers that use a single ISP and use default routing for all destinations outside of their AS. ISP customers are often required to run BGP from their edge router (the CPE) to the ISP regardless of the number of routes they receive from the ISP. This allows ISP customers to control which networks to advertise to the outside world. There's always the fear that a customer will advertise a network, or network aggregate, not owned by the customer, black-holing Internet traffic to those networks. In reality, ISP providers are careful to filter invalid advertisements from their customers (one of BGP's strengths), so this rarely happens.
There are three basic scales of BGP networks:
• Single-Provider / single-Homed - The network receives a single route (single-homed) from a single ISP (single-provider). The number of routes an ISP customer receives from its ISP depends on the nature of its AS. An ISP customer that uses only one ISP as their Internet provider, and has a single connection to that provider (single-provider / single-homed) has no need to receive any routes - all traffic destined outside of the AS will go to their ISP. These customers may still advertise some or all of their inside network to the ISP.
• Single-Provider / Multi-Homed - The network receives multiple routes (multi-homed) from a single ISP (single-provider). ISP customers that use a single ISP, but have multiple connections to their ISP may only receive the default route (0.0.0.0/0) at each ISP gateway. If an ISP connection goes down, the advertised default route sent from the connected CPE router to internal routers would be withdrawn, and Internet traffic would then flow to a CPE router that has connectivity to the ISP. The customer's inside network would also be advertised to the ISP at each CPE router gateway, allowing the ISP to use alternate paths should a particular connection to a customer go down.
• Multi-Provider / Multi-Homed - ISP customers that use more than one ISP (multi-provider / multi-homed) have one or more separate gateway routers for each ISP. In this case, the customer's AS must be a public AS, and may either be a transit or non-transit AS. A transit AS will receive and forward traffic from one ISP destined for a network reachable through another ISP (the traffic destination is not in the customer's AS). A non-transit AS should only receive traffic destined for its AS - all other traffic would be dropped. BGP routers in a transit AS would often receive a large portion (in many cases, all) of the full BGP route table from each ISP.
• Even if you are not a large network on the internet, BGP is the standard for multi-homing, load-balancing, and redundancy:
– Single-provider / single-homed – Not typically a strong candidate for BGP, but may still use it to advertise networks to the ISP. single-homed networks are not eligible for a public AS from RIRs.
– Single-provider / Multi-homed – Common to follow RFC2270 suggestion to use a single private AS (64512 to 65535) to get the benefit of BGP while preserving public ASN.
– Multi-provider / Multi-homed – Highly redundant, typically with dedicated routers to each ISP. Requires public ASN. Large memory footprint
• Route summarization makes routing scalable.
BGP uses TCP port 179 for communication. BGP is considered a path-vector protocol, containing end-to-end path descriptions for destinations. BGP neighbors can either be internal (iBGP) or external (eBGP):
• iBGP – Neighbor is in the same AS.
• eBGP – Neighbor is in a different AS.
Paths are advertised in UPDATE messages that are tagged with various path attributes. AS_PATH and NEXT_HOP are the two most important attributes that describe the path of a route in a BGP update message.
• AS_PATH: Indicates the ASs that the route is traveling from and two. In the example below, the AS_PATH is from AS 7675 to AS 12345. For internal BGP, the AS_PATH specifies the same AS for both the source and destination.
• NEXT_HOP: Indicates the IP address of the next router the path travels to. Paths advertised across AS boundaries inherit the NEXT_HOP address of the boundary router. BGP relies on interior routing protocols to reach NEXT_HOP addresses.
RFC 1771, which defines BGP, describes the operation of BGP in terms of the following state machine. The table following the diagram provides additional information on the various states.
Figure B:16 BGP Finite State Machine
|
BGP communication includes the following types of messages:
• Open – The first message between BGP peers after TCP session establishment. Contains the necessary information to establish a peering session, e.g. ASN, hold time, and capabilities such as multi-product extensions and route-refresh.
• Update – These messages contain path information, such as route announcements or withdrawals.
• Keepalive – Periodic messages to keep TCP layer up, and to advertise liveliness.
• Notification – A request to terminate the BGP session. Non-fatal notifications contain the error code “cease”. Subcodes provide further detail:
|
• Route-refresh – A request for the peer to resend its routes.
BGP update messages can include the following attributes:
|
For more information on BGP attributes, see: http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xml
• Scale - Currently, SonicOS supports from 512 to 2,048 policy-based routes (PBRs). This is not sufficient for full or even partial routing tables. The number of routes that exist in the RIB may be greater than the number installed into PBR (which is the FIB). This occurs when multiple competing routes have been received through the routing protocols. For each case in which the RIB contains competing routes to a particular network destination, only one of these routes is chosen to be installed in the FIB.
Currently, our implementation is most appropriate for the single-provider / single-homed customers. Single-provider / multi-homed installations may also be appropriate when either the default route is being received from the ISP, or a very small number of ISP-specific routes are received by the customer. The latter allows inside routers to take the optimal path to destinations outside of the AS, but still within the ISP's network domain (this is called partial-routes).
• Load balancing - There is currently no multi-path support in SonicOS or Zebos (the ‘maximum-paths’ capability). This precludes load-balancing without splitting networks.
• Loopback - There is currently no loopback interface support.
• NAT - BGP is for routing. It does not co-exist well with NAT.
• VPN updates - BGP updates over VPN are not currently working.
• Asymmetric paths - Stateful firewall will not currently handle asymmetric paths, especially not across multiple firewalls.
The following sections describe how to configure BGP Advanced Routing for SonicOS:
• Multiple Exit Discriminator (MED)
• Synchronization and Auto-Summary
• Preventing an Accidental Transit AS
• Using Multi-Homed BGP for Load Sharing
BGP transmits packets in the clear. Therefore for strong security, Dell SonicWALL recommends configuring an IPSec tunnel to use for BGP sessions. The configurations of the IPSec tunnel and of BGP are independent of each other. The IPSec tunnel is configured completely within the VPN configuration section of the SonicOS GUI, while BGP is enabled on the Network > Routing page and then configured on the SonicOS Command Line Interface. When configuring BGP over IPSec, first configure the IPSec tunnel and verify connectivity over the tunnel before configuring BGP.
The following procedure shows a sample IPSec configuration between a SonicWALL and a remote BGP peer, where the SonicWALL is configured for 192.168.168.75/24 on the X0 network and the remote peer is configured for 192.168.168.35/24 on the X0 network.
1. Navigate to the VPN > Settings page and click the Add button under the VPN Policies section. The VPN Policies window displays.
2. In the Policy Type pull-down menu, make sure that Site to Site is selected.
Note A site-to-site VPN tunnel must be used for BGP over IPSec. Tunnel interfaces will not work for BGP.
3. Select the desired Authentication Method. In this example, we are using IKE using Preshared Secret.
4. Enter a Name for the VPN policy.
5. In the IPsec Primary Gateway Name or Address field, enter the IP address of the remote peer (for this example it is 192.168.168.35).
6. In the IPsec Secondary Gateway Name or Address field, enter 0.0.0.0.
7. Enter a Shared Secret and confirm it.
8. In the Local IKE ID field, enter the IP address of the SonicWALL (for this example it is 192.168.168.75)
9. In the Peer IKE ID field, enter the IP address of the remote peer (192.168.168.35).
10. Click on the Network tab.
For the local network, select X0 IP from the Choose local network from list pull-down menu.
12. For the remote network, select the remote peer’s IP address from the Choose destination network from list pull-down menu, which is 192.168.168.35 for this example. If the remote IP address is not listed, select Create new address object to create an address object for the IP address.
13. Click on the Proposals tab. You can either use the default IPSec proposals or customize them as you see fit.
14. Click on the Advanced tab.
15. Check the Enable Keep Alive checkbox.
16. Click OK.
The VPN policy is now configured on the firewall. Now complete the corresponding IPSec configuration on the remote peer. When that is complete, return to the VPN > Settings page and check the Enable checkbox for the VPN policy to initiate the IPSec tunnel.
Use the ping diagnostic on the SonicWall to ping the BGP peer IP address and use Wireshark to ensure that the request and response are being encapsulated in ESP packets.
Note As configured in this example, routed traffic will not go through the IPSEC tunnel used for BGP. That traffic is sent and received in the clear, which is most likely the desired behavior since the goal is to secure BGP, not all the routed network traffic.
To configure BGP on a SonicWALL security appliance, perform the following tasks:
1. On the SonicOS GUI, navigate to the Network > Routing page.
2. In the Routing Mode pull-down menu, select Advanced Routing.
3. In the BGP pull-down menu, select Enabled (Configure with CLI).
After BGP has been enabled through the GUI, the specifics of the BGP configuration are performed using the SonicOS command line interface (CLI). For detailed information on how to connect to the SonicOS CLI, see the SonicOS Command-Line Interface Guide at: http://www.sonicwall.com/us/support/230_3623.html
4. Log in to the SonicOS CLI through the console interface.
5. Enter configuration mode by typing the configure command.
6. Enter the BGP CLI by typing the route ars-bgp command. You will now see the following prompt:
ZebOS version 7.7.0 IPIRouter 7/2009
ARS BGP>
7. You are now in BGP Non-Config Mode. Type ? to see a list of non-config commands.
8. Type show running-config to see the current BGP running configuration.
9. To enter BGP Configuration Mode, type the configure terminal command. Type ? to see a list of configuration commands.
10. When you have completed your configuration, type the write file command. If the unit is part of an High Availability pair or cluster, the configuration changes will be automatically conveyed to the other unit or units.
The following attributes can be used to configure the BGP path selection process.
|
The weight command assigns a weight value, per address-family, to all routes learned from a neighbor. The route with the highest weight gets preference when the same prefix is learned from more than one peer. The weight is relevant only to the local router.
The weights assigned using the set weight command override the weights assigned using this command.
When the weight is set for a peer-group, all members of the peer-group will have the same weight. The command can also be used to assign a different weight to a particular peer-group member.
The following example shows weight configuration:
router bgp 12345
neighbor 12.34.5.237 remote-as 12345
neighbor 12.34.5.237 weight 60
router bgp 12345
neighbor group1 peer-group
neighbor 12.34.5.237 peer-group group1
neighbor 67.78.9.237 peer-group group1
neighbor group1 weight 60
The Local Preference attribute is used to indicate the degree of preference for each external route in an appliance’s routing table. The Local Preference attribute is included in all update messages sent to devices in the same AS. Local Preference is not communicated to outside AS. The following figure shows a sample topology illustrating how Local Preference affects routes between neighboring ASs.
Figure B:17 BGP Local Preference topology
The following BGP configurations are entered on SNWL1 and SNWL2. The higher Local Preference on SNWL2 leads to SNWL2 being the preferred route advertised by AS 12345 (the SonicWALL AS) to outside ASs.
|
Local Preference used with Route Maps
Route Maps are similar to Access Control Lists. They consist of a series of Permit and/or Deny statements that determine how the appliance processes the routes. Route maps are applied to inbound traffic—not outbound traffic. The following diagram shows a sample topology that uses a route map to configure local preference.
Figure B:18 BGP Local Preference topology with Route Maps
The following BGP configurations are entered on SNWL1 and SNWL2.
|
The Route Map configured on SNWL2 (rmap1) is configured to apply to inbound routes from neighbor 10.1.1.1. It has two permit conditions:
• route-map rmap1 permit 10: This permit condition matches access list 100 that is configured to permit traffic from AS 8888 and set routes from AS 8888 to a Local Preference of 200.
• route-map rmap1 permit 10: This permit condition sets all other traffic that doesn’t match access list 100 (i.e. traffic coming from ASs other than 8888) to a Local Preference of 150.
AS_Path Prepending is the practice of adding additional AS numbers at the beginning of a path update. This makes the path for this route longer, and thus decreases its preference.
AS_Path Prepending can be applied on either outbound or inbound paths. AS_Path Prepending may not be honored if it is over-ruled by a neighbor.
|
This configuration leads to a route being installed to the neighbor 10.50.165.233 with the AS_Path Prepended as 12345 12345. This can be viewed by entering the show ip bgp command.
ARS BGP>show ip bgp
BGP table version is 98, local router ID is 10.50.165.228
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, l - labeled
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 12.34.5.0/24 10.50.165.233 0 0 12345 12345 12345 i
*> 7.6.7.0/24 0.0.0.0 100 32768 i
Total number of prefixes 2
Multiple Exit Discriminator (MED)
The set metric command can be used in a route map to make paths more or less preferable:
router bgp 7675
network 7.6.7.0/24
neighbor 10.50.165.233 remote-as 12345
neighbor 10.50.165.233 route-map highmetric out
!
route-map highmetric permit 10
set metric 300
The Multi Exit Discriminator (MED) is an optional attribute that can be used to influence path preference. It is non-transitive, meaning it is configured on a single appliance and not advertised to neighbors in update messages. In this section, we will consider the uses of the bgp always-compare-med and bgp deterministic-med commands.
bgp always-compare-med command
The bgp always-compare-med command allows comparison of the MED values for paths from different ASs for path selection. A path with lower MED is preferred.
As an example, consider the following routes in the BGP table and the always-compare-med command is enabled:
Route1: as-path 7675, med 300
Route2: as-path 200, med 200
Route3: as-path 7675, med 250
Route2 would be the chosen path because it has the lowest MED.
If the always-compare-med command was disabled, MED would not be considered when comparing Route1 and Route2 because they have different AS paths. MED would be compared for only Route1 and Route3.
bgp deterministic-med command
The selected route is also affected by the bgp deterministic-med command, which compares MED when choosing among routes advertised by different peers in the same autonomous system.
When the bgp deterministic-med command is enabled, routes from the same AS are grouped together, and the best routes of each group are compared. If the BGP table showed:
Route1: as-path 200, med 300, internal
Route2: as-path 400, med 200, internal
Route3: as-path 400, med 250, external
BGP would have a group of Route1 and a second group of Route2 and Route3 (the same AS).
The best of each group is compared. Route1 is the best of its group because it is the only route from AS 200.
Route1 is compared to the Route2, the best of group AS 400 (the lower MED).
Since the two routes are not from the same AS, the MED is not considered in the comparison. The external BGP route is preferred over the internal BGP route, making Route3 the best route.
A community is a group of prefixes that share some common property and can be configured with the transitive BGP community attribute. A prefix can have more than one community attribute. Routers can act on one, some or all the attributes. BGP communities can be thought of as a form of tagging. The following is an example of a BGP communities configuration.
router bgp 12345
bgp router-id 10.50.165.233
network 12.34.5.0/24
network 23.45.6.0/24
neighbor 10.50.165.228 remote-as 7675
neighbor 10.50.165.228 send-community
neighbor 10.50.165.228 route-map comm out
!
access-list 105 permit 12.34.5.0/24
access-list 110 permit 23.45.6.0/24
!
route-map comm permit 10
match ip address 105
set community 7675:300
!
route-map comm permit 20
match ip address 110
set community 7675:500
!
router bgp 7675
bgp router-id 10.50.165.228
network 7.6.7.0/24
neighbor 10.50.165.233 remote-as 12345
neighbor 10.50.165.233 route-map shape in
!
ip community-list 1 permit 7675:300
ip community-list 2 permit 7675:500
!
route-map shape permit 10
match community 1
set local preference 120
route-map shape permit 20
match community 2
set local preference 130
Synchronization and Auto-Summary
The synchronization setting controls whether the router advertises routes learned from an iBGP neighbor based on the presence of those routes in its IGP. When synchronization is enabled, BGP will only advertise routes that are reachable through OSPF or RIP (the Exterior Gateway Protocols as opposed to BGP, the Exterior Gateway Protocol). Synchronization is a common cause of BGP route advertisement problems.
The auto-summary setting controls whether or not routes are advertised classfully. Auto-summary is another common cause of BGP configuration problems
By default, auto-summary and synchronization are disabled on Zebos.
Preventing an Accidental Transit AS
As we discussed earlier, an AS peer can either be a transit peer (allowing traffic from an outside AS to another outside AS) or a non-transit peer (requiring all traffic to either originate or terminate on its AS). Transit peers will have dramatically larger routing tables. Typically, you will not want to configure a SonicWALL security appliance as a transit peer.
Figure B:19 Transit Peers vs. Non-Transit Peers
To prevent your appliance from inadvertently becoming a transit peer, you will want to configure inbound and outbound filters, such as the following:
Outbound Filters
Permit only routes originated from the local AS out:
ip as-path access-list 1 permit ^$
router bgp 12345
bgp router-id 10.50.165.233
network 12.34.5.0/24
neighbor 10.50.165.228 remote-as 7675
neighbor 10.50.165.228 filter-list 1 out
neighbor 172.1.1.2 remote-as 9999
neighbor 10.50.165.228 filter list 1 out
Permit only owned prefixes out:
ip prefix-list myPrefixes seq 5 permit 12.34.5.0/24
ip prefix-list myPrefixes seq 10 permit 23.45.6.0/24
router bgp 12345
bgp router-id 10.50.165.233
network 12.34.5.0/24
network 23.45.6.0/24
neighbor 10.50.165.228 remote-as 7675
neighbor 172.1.1.2 remote-as 9999
neighbor 10.50.165.228 prefix-list myPrefixes out
neighbor 172.1.1.2 prefix-list myPrefixes out
Inbound Filters
Drop all owned and private inbound prefixes
ip prefix-list unwantedPrefixes seq 5 deny 12.34.5.0/24 le 32
ip prefix-list unwantedPrefixes seq 10 deny 23.45.6.0/24 le 32
ip prefix-list unwantedPrefixes seq 20 deny 10.0.0.0/8 le 32
ip prefix-list unwantedPrefixes seq 21 deny 172.16.0.0/12 le 32
ip prefix-list unwantedPrefixes seq 22 deny 192.168.0.0/16 le 32
ip prefix-list unwantedPrefixes seq 30 permit 0.0.0.0/0 le 32
router bgp 12345
bgp router-id 10.50.165.233
network 12.34.5.0/24
network 23.45.6.0/24
neighbor 10.50.165.228 remote-as 7675
neighbor 172.1.1.2 remote-as 9999
neighbor 10.50.165.228 prefix-list unwantedPrefixes in
neighbor 172.1.1.2 prefix-list unwantedPrefixes in
Using Multi-Homed BGP for Load Sharing
The following topology shows an example where a SonicWALL security appliance uses a multi-homed BGP network to load share between two ISPs.
Figure B:20
Multi-Homed BGP for Load Sharing Topology
The SonicWALL security appliance is configured as follows:
router bgp 12345
bgp router-id 10.50.165.233
network 12.34.5.0/24
neighbor 10.50.165.228 remote-as 7675
neighbor 10.50.165.228 route-map ISP1 out
neighbor 172.1.1.2 remote-as 9999
neighbor 10.50.165.228 route-map ISP2 out
!
route-map ISP1 permit 10
match ip address 1
set weight 100
route-map ISP1 permit 20
match ip address 2
route-map ISP2 permit 10
match ip address 1
route-map ISP2 permit 20
match ip address 2
set weight 100
access-list 1 permit 12.34.5.0/25
access-list 2 deny 12.34.5.0/25
access-list 2 permit any
The following sections describe methods to verify a BGP configuration:
The figure below shows a basic BGP topology where a SonicWALL security appliance is configured for BGP to connect to two routers on two different ASs.
The routes in the FIB for this network can be viewed either in the SonicOS GUI or by using the CLI.
A summary of the BGP configuration can be viewed on the SonicOS GUI through the Network > Routing page by clicking the BGP Status button, located at the top of the page next to the Routing Mode pull-down menu. The BGP Status window displays the output of the show ip bgp summary and show ip bgp neighbor commands.
The BGP routes in the FIB can also be viewed on the SonicOS GUI in the Routing Policies table on the Network > Routing page.
To view the FIB routes in the CLI, perform the following commands:
SonicWALL> configure
(config[SonicWALL])> route ars-nsm
ZebOS version 7.7.0 IPIRouter 7/2009
ARS NSM>show ip route
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default
B 7.6.7.0/24 [20/0] via 10.50.165.228, X1, 05:08:31
B 199.199.0/16 [20/0] via 10.50.165.237, X1, 05:08:31
C 10.50.165.192/26 is directly connected, X1
C 127.0.0.0/8 is directly connected, lo0
C 12.34.5.0/24 is directly connected, X0
To view the RIB routes in the CLI, enter the show ip bgp command:
ARS BGP>show ip bgp
BGP table version is 98, local router ID is 10.50.165.233
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, l - labeled
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 7.6.7.0/24 10.50.165.228 0 0 7675 i
*> 12.34.5.0/24 0.0.0.0 100 32768 i
*> 199.199.0.0/16 10.50.165.228 0 0 7675 9999 i
Total number of prefixes 3
Note The last route is the path to AS9999 that was learned through AS7675.
SonicWALL BGP offers a comprehensive selection of debug commands to display log events related to BGP traffic. BGP logging can be configured on the CLI by using the debug bgp command followed by of the following keywords:
|
To disable BGP debugging, enter the “no” form of the command. For example, to disable event debugging, type the no debug events command.
BGP log messages can also be viewed on the SonicOS GUI on the Log > View page. BGP messages are displayed as part of the Advanced Routing category of log messages.
The above message indicates that an update to the outgoing RIB was denied because the router from which the update was received was not directly connected to the appliance.
To allow for BGP peers that are not directly connected, use the ebgp-multihop keyword with the neighbor command. For example:
neighbor 10.50.165.228 ebgp-multihop
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:
• IPv6 BGP is supported only on NSA platforms.
• IPv6 BGP depends on IPv6 functions and ZebOS (Zebra OS).
• MPLS/VPN and multicast are not supported in IPv6 BGP.
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.
To configure multiple ASs as shown in the above diagram, configure routers RTA, RTB, and RTC as follows:
On RTA:
router bgp 100
neighbor 129.213.1.1 remote−as 200
address-family ipv6
redistribute connected
neighbor 129.213.1.1 activate
On RTB:
router bgp 200
neighbor 129.213.1.2 remote−as 100
neighbor 175.220.1.2 remote−as 200
address-family ipv6
redistribute connected
neighbor 129.213.1.2 activate
neighbor 175.220.1.2 activate
On RTC:
router bgp 200
neighbor 175.220.212.1 remote−as 200
address-family ipv6
neighbor 175.220.212.1 activate
neighbor 175.220.212.1 activate
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.
To configure basic BGP over IPv6, configure routers R1 and R2 as follows:
On R1:
router bgp 6501
bgp router−id 1.1.1.1
neighbor 2011:11:11:11::2 remote−as 6502
address−family ipv6
neighbor 2011:11:11:11::2 activate
exit−address−family
On R2:
router bgp 6502
bgp router−id 2.2.2.2
neighbor 2011:11:11:11::1 remote−as 6501
address−family ipv6
network 1010::1/128
network 2020::1/128
neighbor 2011:11:11:11::1 activate
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:
router bgp 6501
bgp router−id 1.1.1.1
neighbor 2011:11:11:11::2 remote−as 6502
neighbor 2011:11:11:11::2 ebgp−multihop
address−family ipv6
neighbor 2011:11:11:11::2 activate
exit−address−family
On R2:
router bgp 6502
bgp router−id 2.2.2.2
neighbor 2011:11:11:11::1 remote−as 6501
neighbor 2011:11:11:11::1 ebgp−multihop
address−family ipv6
network 1010::1/128
network 2020::1/128
neighbor 2011:11:11:11::1 activate
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:
router bgp 6501
bgp router−id 1.1.1.1
neighbor 2011:11:11:11::2 remote−as 6502
address−family ipv6
redistribute connected
neighbor 2011:11:11:11::2 activate
neighbor 2011:11:11:11::2 prefix-list pref1 in
neighbor 2011:11:11:11::2 prefix-list pref2 out
exit−address−family
ipv6 prefix-list pref1 seq 10 deny 1010::1/128
ipv6 prefix-list pref1 seq 20 permit any
ipv6 prefix-list pref2 seq 10 deny 1111::1/128
ipv6 prefix-list pref2 seq 20 permit any
On R2:
router bgp 6502
bgp router−id 2.2.2.2
neighbor 2011:11:11:11::1 remote−as 6501
address−family ipv6
redistribute connected
neighbor 2011:11:11:11::1 activate
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:
R1> show bgp ipv6 unicast
On R2:
R2> show bgp ipv6 unicast
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:
router bgp 6501
bgp router−id 1.1.1.1
neighbor 2011:11:11:11::2 remote−as 6502
address−family ipv6
redistribute connected
neighbor 2011:11:11:11::2 activate
neighbor 2011:11:11:11::2 distribute-list acl1 in
neighbor 2011:11:11:11::2 distribute-list acl2 out
exit−address−family
ipv6 access-list acl1 deny 1010::1/128
ipv6 access-list acl1 permit any
ipv6 access-list acl2 deny 1111::1/128
ipv6 access-list acl2 permit any
On R2:
router bgp 6502
bgp router−id 2.2.2.2
neighbor 2011:11:11:11::1 remote−as 6501
address−family ipv6
redistribute connected
neighbor 2011:11:11:11::1 activate
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:
R1> show bgp ipv6 unicast
On R2:
R2> show bgp ipv6 unicast
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:
router bgp 6501
bgp router−id 1.1.1.1
neighbor 2011:11:11:11::2 remote−as 6502
address−family ipv6
redistribute connected
neighbor 2011:11:11:11::2 activate
neighbor 2011:11:11:11::2 route-map map1 in
neighbor 2011:11:11:11::2 route-map map2 out
exit−address−family
ipv6 access-list acl1 deny 1010::1/128
ipv6 access-list acl1 permit any
ipv6 access-list acl2 deny 1111::1/128
ipv6 access-list acl2 permit any
!
route-map map1 permit 1 match ipv6 address acl1
!
route-map map2 permit 1 match ipv6 address acl2
!
On R2:
router bgp 6502
bgp router−id 2.2.2.2
neighbor 2011:11:11:11::1 remote−as 6501
address−family ipv6
redistribute connected
neighbor 2011:11:11:11::1 activate
To check the routes on R1 and R2, use the show bgp ipv6 unicast command.
On R1:
R1> show bgp ipv6 unicast
The route on R1 should have IPv6 address 1010::1/128.
On R2:
R2> show bgp ipv6 unicast
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.
RTB advertises these routes:
• 2004::/64
• 2003::/64
• 2002::/64
RTC advertises these routes:
• 5000::/64
• 6666::6/128
• 7777::7/128
To check the routes on router RTA, use the show bgp ipv6 unicast command.
On RTA:
RTA> show bgp ipv6 unicast
BGP table version is 4, local router ID is 10.0.1.2
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal, l - labeled
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
|
To configure AS regular expressions on RTA and deny all routes originated in AS100:
router bgp 200
neighbor 10.0.1.1 remote-as 100
neighbor 10.0.1.1 update-source X2
neighbor 2004::1 remote-as 100
neighbor 2004::1 update-source X2
!
address-family ipv6
neighbor 10.0.1.1 activate
neighbor 10.0.1.1 filter-list 1 in
neighbor 2004::1 activate
exit-address-family
ip as-path access-list 1 deny ^100$
ip as-path access-list 1 permit .*
To check the routes on router RTA, use the show bgp ipv6 unicast command.
On RTA:
RTA> show bgp ipv6 unicast
BGP table version is 4, local router ID is 10.0.1.2
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal, l - labeled
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
|
Total number of prefixes 3
To modify the AS path to deny all routes learned from the AS100:
On RTA:
router bgp 200
neighbor 10.0.1.1 remote-as 100
neighbor 10.0.1.1 update-source X2
neighbor 2004::1 remote-as 100
neighbor 2004::1 update-source X2
!
address-family ipv6
neighbor 10.0.1.1 activate
neighbor 10.0.1.1 filter-list 1 in
neighbor 2004::1 activate
exit-address-family
ip as-path access-list 1 deny _100_
ip as-path access-list 1 permit .*
To check the routes on router RTA, use the show bgp ipv6 unicast command.
On RTA:
RTA> show bgp ipv6 unicast
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.
This diagram shows three ASs and the routing protocols used by the BGP routers.
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:
router bgp 100
neighbor 3001::1 remote-as 200
!
address-family ipv6
distance bgp 150 150 150
neighbor 3001::1 activate
exit-address-family
On RTB:
router bgp 200
bgp log-neighbor-changes
neighbor 1001::1 remote-as 300
neighbor 2003::1 remote-as 100
address-family ipv6
network 6666::6/128
neighbor 1001::1 activate
neighbor 2003::1 activate
exit-address-family
On RTC:
router bgp 300
neighbor 3002::1 remote-as 200
!
address-family ipv6 network 1000::/64
neighbor 3002::1 activate
exit-address-family
To check the routes on router RTA, use the show ipv6 route command.
RTA> show ipv6 route
IPv6 Routing Table
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP
Timers: Uptime
B 1000::/64 [20/0] via fe80::204:27ff:fe0c:b006, X1, 00:01:07
C 2003::/64 via ::, X1, 00:30:50
B 6666::6/128 [20/0] via fe80::204:27ff:fe0c:b006, X1, 00:01:07
C fe80::/64 via ::, X1, 00:30:53
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:
distance bgp 150 150 150
You can also use the backdoor neighbor command to set the BGP route as the preferred route. For example:
On RTA:
router bgp 100
neighbor 3001::1 remote-as 200
!
address-family ipv6
network 1000::/64
backdoor neighbor 3001::1 activate
exit-address-family
To check the routes on router RTA, use the show ipv6 route command.
RTA> show ipv6 route
IPv6 Routing Table
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP
Timers: Uptime
O 1000::/64 [110/2] via fe80::217:c5ff:feb4:57f2, X4, 00:30:53
C 2003::/64 via ::, X1, 00:31:18
B 6666::6/128 [20/0] via fe80::204:27ff:fe0c:b006, X1, 00:00:03
C fe80::/64 via ::, X1, 00:31:21
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.
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:
router bgp 100
neighbor 10.103.10.129 remote-as 100
neighbor 3001::1 remote-as 100
neighbor 3001::1 update-source X4
neighbor 5000::1 remote-as 400
neighbor 5000::1 update-source X2
!
address-family ipv6
synchronization
neighbor 10.103.10.129 activate
neighbor 3001::1 activate
neighbor 5000::1 activate
exit-address-family
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:
router bgp 100
neighbor 10.103.10.129 remote-as 100
neighbor 3001::1 remote-as 100
neighbor 3001::1 update-source X4
neighbor 5000::1 remote-as 400
neighbor 5000::1 update-source X2
!
address-family ipv6
neighbor 10.103.10.129 activate
neighbor 3001::1 activate
neighbor 5000::1 activate
exit-address-family
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.
To configure route reflection in an AS:
On RouterA:
interface Serial0/0
ipv6 address 2011:12:12:12::1/64
ipv6 ospf 10 area 0
interface Serial0/1
ipv6 address 2011:13:13:13::1/64
ipv6 ospf 10 area 0
router bgp 100
bgp router−id 1.1.1.1
no bgp default ipv4−unicast
bgp log−neighbor−changes
neighbor 2011:22:22:22::22 remote−as 100
neighbor 2011:22:22:22::22 update−source Loopback0
neighbor 2011:33:33:33::33 remote−as 100
neighbor 2011:33:33:33::33 update−source Loopback0
!
address−family ipv6
neighbor 2011:22:22:22::22 activate
neighbor 2011:22:22:22::22 route−reflector−client
neighbor 2011:33:33:33::33 activate
neighbor 2011:33:33:33::33 route−reflector−client
exit−address−family
!
ipv6 router ospf 10
router−id 1.1.1.1
On RRClient1:
interface Loopback0
ipv6 address 2011:22:22:22::22/128
ipv6 ospf 10 area 0
!
interface Loopback10
ipv6 address 1010:10:10:10::10/128
interface Serial0/0
ipv6 address 2011:12:12:12::2/64
ipv6 ospf 10 area 0
!
router bgp 100
bgp router−id 2.2.2.2
bgp log−neighbor−changes
neighbor 2011:11:11:11::11 remote−as 100
neighbor 2011:11:11:11::11 update−source Loopback0
!
address−family ipv6
neighbor 2011:11:11:11::11 activate
network 1010:10:10:10::10/128
exit−address−family
!
ipv6 router ospf 10
router−id 2.2.2.2
RRClient2:
interface Loopback0
ipv6 address 2011:33:33:33::33/128
ipv6 ospf 10 area 0
!
interface Loopback20
ipv6 address 2020:20:20:20::20/128
!
interface Serial0/0
no ip address
ipv6 address 2011:13:13:13::2/64
ipv6 ospf 10 area 0
!
router bgp 100
bgp router−id 3.3.3.3
bgp log−neighbor−changes
neighbor 2011:11:11:11::11 remote−as 100
neighbor 2011:11:11:11::11 update−source Loopback0
!
address−family ipv6
neighbor 2011:11:11:11::11 activate
network 2020:20:20:20::20/128
exit−address−family
!
ipv6 router ospf 10
router−id 3.3.3.3
log−adjacency−changes
To check the routes, use the show bgp ipv6 unicast command:
On RRClient1:
RRClient1> show bgp ipv6 unicast
You should see route 2020:20:20:20::20/128.
On RRClient2:
RRClient2> show bgp ipv6 unicast
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.
To configure the local preference of a preferred route in an AS:
On R1:
interface Loopback0
ipv6 address 1111:111:111:A::/64 eui−64
ipv6 ospf 10 area 0
interface FastEthernet0/0
ipv6 address AB01:CD1:123:A::/64 eui−64
ipv6 ospf 10 area 0
!
interface Serial0/0
ipv6 address AB01:CD1:123:C::/64 eui−64
!
interface FastEthernet0/1
ipv6 address AB01:CD1:123:B::/64 eui−64
ipv6 ospf 10 area 0
!
ipv6 router ospf 10 router−id 1.1.1.1 log−adjacency−changes
redistribute connected route−map CONNECTED
!
route−map CONNECTED permit 10
match interface Serial0/0
!
router bgp 123
bgp router−id 1.1.1.1
neighbor 2222:222:222:A:C602:3FF:FEF0:0 remote−as 123
neighbor 2222:222:222:A:C602:3FF:FEF0:0 update−source Loopback0
neighbor 3333:333:333:A:C603:3FF:FEF0:0 remote−as 123
neighbor 3333:333:333:A:C603:3FF:FEF0:0 update−source Loopback0
neighbor AB01:CD1:123:C:C604:16FF:FE98:0 remote−as 101
neighbor AB01:CD1:123:C:C604:16FF:FE98:0 ebgp−multihop 5
!
address−family ipv6
neighbor 2222:222:222:A:C602:3FF:FEF0:0 activate
neighbor 2222:222:222:A:C602:3FF:FEF0:0 next−hop−self
neighbor 3333:333:333:A:C603:3FF:FEF0:0 activate
neighbor 3333:333:333:A:C603:3FF:FEF0:0 next−hop−self
neighbor AB01:CD1:123:C:C604:16FF:FE98:0 activate exit−address−family
On R2:
interface Loopback0
ipv6 address 2222:222:222:A::/64 eui−64
ipv6 ospf 10 area 0
!
interface FastEthernet0/0
ipv6 address AB01:CD1:123:A::/64 eui−64
ipv6 ospf 10 area 0
!
interface FastEthernet0/1
ipv6 address AB01:CD1:123:D::/64 eui−64
ipv6 ospf 10 area 0
!
ipv6 router ospf 10 router−id 2.2.2.2 log−adjacency−changes
!
router bgp 123
bgp router−id 2.2.2.2
neighbor 1111:111:111:A:C601:3FF:FEF0:0 remote−as 123
neighbor 1111:111:111:A:C601:3FF:FEF0:0 update−source Loopback0
neighbor 3333:333:333:A:C603:3FF:FEF0:0 remote−as 123
neighbor 3333:333:333:A:C603:3FF:FEF0:0 update−source Loopback0
address−family ipv6
neighbor 1111:111:111:A:C601:3FF:FEF0:0 activate
neighbor 3333:333:333:A:C603:3FF:FEF0:0 activate
exit−address−family
On R3:
interface Loopback0
ipv6 address 3333:333:333:A::/64 eui−64
ipv6 ospf 10 area 0
!
interface FastEthernet0/0
ipv6 address AB01:CD1:123:B::/64 eui−64
ipv6 ospf 10 area 0
!
interface Serial0/0
ipv6 address AB01:CD1:123:E::/64 eui−64
!
interface FastEthernet0/1
ipv6 address AB01:CD1:123:D::/64 eui−64
ipv6 ospf 10 area 0
!
ipv6 router ospf 10
router−id 3.3.3.3
redistribute connected route−map CONNECTED
!
router bgp 123
no synchronization
bgp router−id 3.3.3.3
neighbor 1111:111:111:A:C601:3FF:FEF0:0 remote−as 123
neighbor 1111:111:111:A:C601:3FF:FEF0:0 update−source Loopback0
neighbor 2222:222:222:A:C602:3FF:FEF0:0 remote−as 123
neighbor 2222:222:222:A:C602:3FF:FEF0:0 update−source Loopback0
neighbor AB01:CD1:123:E:C605:16FF:FE98:0 remote−as 202
neighbor AB01:CD1:123:E:C605:16FF:FE98:0 ebgp−multihop 5
!
address−family ipv6
neighbor 1111:111:111:A:C601:3FF:FEF0:0 activate
neighbor 1111:111:111:A:C601:3FF:FEF0:0 next−hop−self
neighbor 1111:111:111:A:C601:3FF:FEF0:0 route−map LOCAL_PREF out
neighbor 2222:222:222:A:C602:3FF:FEF0:0 activate
neighbor 2222:222:222:A:C602:3FF:FEF0:0 next−hop−self
neighbor 2222:222:222:A:C602:3FF:FEF0:0 route−map LOCAL_PREF out
neighbor AB01:CD1:123:E:C605:16FF:FE98:0 activate
exit−address−family
!
ipv6 prefix−list 10 seq 5 permit BC01:BC1:10:A::/64
!
route−map LOCAL_PREF permit 10
match ipv6 address prefix−list 10
set local−preference 500
!
route−map LOCAL_PREF permit 20
!
route−map CONNECTED permit 10
match interface Serial0/0
On R4:
interface Serial0/0
ipv6 address AB01:CD1:123:C::/64 eui−64
!
interface Loopback10
ipv6 address BC01:BC1:10:A::/64 eui−64
!
interface Loopback11
ipv6 address BC02:BC1:11:A::/64 eui−64
!
interface Loopback12
ipv6 address BC03:BC1:12:A::/64 eui−64
router bgp 101
bgp router−id 4.4.4.4
neighbor AB01:CD1:123:C:C601:3FF:FEF0:0 remote−as 123
!
address−family ipv6
neighbor AB01:CD1:123:C:C601:3FF:FEF0:0 activate
network BC01:BC1:10:A::/64 network BC02:BC1:11:A::/64
network BC03:BC1:12:A::/64 exit−address−family
On R5:
interface Serial0/0
ipv6 address AB01:CD1:123:E::/64 eui−64
clock rate 2000000
!
interface Loopback10
ipv6 address BC01:BC1:10:A::/64 eui−64
!
interface Loopback11
ipv6 address BC02:BC1:11:A::/64 eui−64
!
interface Loopback12
ipv6 address BC03:BC1:12:A::/64 eui−64
!
router bgp 202
bgp router−id 5.5.5.5
neighbor AB01:CD1:123:E:C603:3FF:FEF0:0 remote−as 123
neighbor AB01:CD1:123:E:C603:3FF:FEF0:0 ebgp−multihop 5
!
address−family ipv6
neighbor AB01:CD1:123:E:C603:3FF:FEF0:0 activate
network BC01:BC1:10:A::/64
network BC02:BC1:11:A::/64
network BC03:BC1:12:A::/64
exit−address−family
To verify the route, use the show bgp ipv6 unicast command:
On R2:
R2> show bgp ipv6 unicast
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.
To configure an IPv6 BGP peer group and its update policies:
On R3:
router bgp 123
no synchronization
bgp router−id 3.3.3.3
neighbor interalmap peer-group
neighbor interalmap remote-as 123
neighbor 1111:111:111:A:C601:3FF:FEF0:0 peer-group interalmap
neighbor 2222:222:222:A:C602:3FF:FEF0:0 peer-group interalmap
neighbor AB01:CD1:123:E:C605:16FF:FE98:0 remote−as 202
neighbor AB01:CD1:123:E:C605:16FF:FE98:0 ebgp−multihop 5
!
address−family ipv6
neighbor interalmap activate
neighbor interalmap route-map 1 out
neighbor 1111:111:111:A:C601:3FF:FEF0:0 peer-group interalmap
neighbor 2222:222:222:A:C602:3FF:FEF0:0 peer-group interalmap
exit−address−family
!
ipv6 prefix−list 10 seq 5 permit BC01:BC1:10:A::/64
!
route-map 1 permit 10
match ipv6 address prefix-list 1 set tag 333
set metric 273
set local-preference 312
To verify that the correct local preference route is configured, use the show bgp ipv6 unicast command:
On R3:
R3> show bgp ipv6 unicast
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.
To configure a BGP Confederation:
R1:
router bgp 2000
bgp log-neighbor-changes
bgp confederation identifier 200
bgp confederation peers 1000
neighbor 2003::1 remote-as 1000
!
address-family ipv4
neighbor 2003::1 activate
exit-address-family
!
address-family ipv6
network 3002::/64
network 4000::/64
neighbor 2003::1 activate
exit-address-family
On R2:
router bgp 1000
bgp confederation identifier 200
neighbor 10.0.1.1 remote-as 1000
!
address-family ipv6
neighbor 10.0.1.1 activate
exit-address-family
On R3:
router bgp 1000
bgp confederation identifier 200
bgp confederation peers 2000
neighbor 10.0.1.2 remote-as 1000
neighbor 3001::1 remote-as 2000
neighbor 5000::1 remote-as 100
neighbor 5000::1 update-source X2
!
address-family ipv6
neighbor 10.0.1.2 activate
neighbor 3001::1 activate
neighbor 5000::1 activate
exit-address-family
On R5:
router bgp 100
bgp router-id 5.5.5.5
bgp log-neighbor-changes
neighbor 2002::1 remote-as 200
!
address-family ipv6
network 6666::6/128
network 7777::7/128
neighbor 2002::1 activate
exit-address-family
Verify that R1, R2, and R3 can learn this route that is advertised by R5:
6666::6/128 and 7777::7/128
Verify that R2 can learn this route from R1 even though they are not directly connected:
3002::/64 and 4000::/64
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.
ARD – Autonomous Routing Domain – A collection of networks/routers that have a common administrative routing policy.
AS - Autonomous System – An ARD that has been assigned an identifying number, typically running BGP4 at its border router(s).
BGP4: - Border Gateway Protocol 4: The most prevalent EGP.
CIDR – Classless inter-domain routing, enables efficient route advertisement through route aggregation.
CPE – Customer Premise Equipment - The equipment at the edge of a customer's network used to interface with the ISP.
EGP - Exterior Gateway Protocol – Any protocol (in practice, BGP4) used to communicate routing information between Autonomous Systems.
Full-Routes - The entire global BGP route table.
FIB - Forwarding Information Base – Our existing route table, used to find the egress interface and next hop when forwarding packets.
Looking Glass* - A Looking Glass (LG) server is a read-only view of routers of organizations running the LG servers. Typically, publicly accessible looking glass servers are run by ISPs or NOCs.
Multi-Homed - An ISP customer that has multiple connections to one or more ISPs.
Multi-Provider - An ISP customer that uses multiple ISPs to connect to the Internet.
NSM – Network Services Module - The ZebOS component that centralizes the interface to the FIB and RIB. The separate routing protocol daemons interface with the NSM for all RIB updates. NSM alone updates the FIB with best-route information from the RIB.
Partial Routes - A subset of the full BGP route table, usually specific to destinations that are part of an ISP's domain.
RIB - Route Information Base – A run-time database owned by the NSM, and used to store all route information gathered and used by the routing protocols.