Why mp bgp

Address families include:. The available address families will depend on the platform. Smaller platforms may only have IPv4 and IPv6. Large service-provider platforms will have many address-family options. This makes it a great choice for service providers. The same mechanism can be reused and new match criteria added to address similar filtering for other BGP address families for example, IPv6 unicast.

After a flow route is installed in the inetflow. If there is a match, the VPN can start using the flow routes to filter and rate-limit packet traffic. Received flow routes are installed into the flow routing table instance-name. VPN flow routes are supported for the default instance only. Flow routes configured for VPNs with family inet-vpn are not automatically validated, so the no-validate statement is not supported at the [edit protocols bgp group group-name family inet-vpn] hierarchy level.

No validation is needed if the flow routes are configured locally between devices in a single AS. A policy that allows the advertisement of flow routes specified by a route-filter. Only the flow routes covered by the This policy does not affect unicast routes.

Recommended For the flow specification algorithm, configure the standard-based term order. In the default term ordering algorithm, as specified in the flowspec RFC draft Version 6, a term with less specific matching conditions is always evaluated before a term with more specific matching conditions. This causes the term with more specific matching conditions to never be evaluated. Version 7 of RFC made a revision to the algorithm so that the more specific matching conditions are evaluated before the less specific matching conditions.

For backward compatibility, the default behavior is not altered in Junos OS, even though the newer algorithm makes more sense. To use the newer algorithm, include the term-order standard statement in the configuration. This statement is supported in Junos OS Release From configuration mode, confirm your configuration by entering the show routing-options command.

From configuration mode, confirm your configuration by entering the show protocols , show policy-options , and show routing-options commands. Application of a route limit might result in unpredictable dynamic route protocol behavior. For example, once the limit is reached and routes are being rejected, BGP does not necessarily attempt to reinstall the rejected routes after the number of routes drops below the limit.

BGP sessions might need to be cleared to resolve this issue. Set an upper limit for the number of prefixes installed in inetflow.

Set a threshold value of 50 percent, where when routes are installed, a warning is logged in the system log. Configuring a prefix limit for a specific neighbor provides more predictable control over which peer can advertise how many flow routes.

After the session is brought down, the session reestablishes in a short time unless you include the idle-timeout statement. From configuration mode, confirm your configuration by entering the show protocols command. From operational mode, run the show bgp neighbor Look for inet-flow in the output. Look at the flow routes. The sample output shows a flow route learned from BGP and a statically configured flow route.

For locally configured flow routes configured at the [edit routing-options flow] hierarchy level , the routes are installed by the flow protocol. Therefore, you can display the flow routes by specifying the table, as in show route table inetflow.

Or, you can display all locally configured flow routes across multiple routing instances by running the show route protocol flow command. You can display the flow routes by specifying the table or by running show route protocol bgp , which displays all BGP routes flow and non-flow.

From operational mode, run the show route table inetflow. A flow route represents a term of a firewall filter. When you configure a flow route, you specify the match conditions and the actions. In the match attributes, you can match a source address, a destination address, and other qualifiers such as the port and the protocol.

For a single flow route that contains multiple match conditions, all the match conditions are encapsulated in the prefix field of the route. When you issue the show route command on a flow route, the prefix field of the route is displayed with all of the match conditions. If the matching conditions contain both a source and a destination, the asterisk is replaced with the address. The term-order numbers indicate the sequence of the terms flow routes being evaluated in the firewall filter.

The show route extensive command displays the actions for each term route. From operational mode, run the show route flow validation detail command. If you configure a limit on the number of flow routes installed, as described in Limiting the Number of Flow Routes Installed in a Routing Table , view the system log message when the threshold is reached.

If you configure a limit on the number of flow routes installed, as described in Limiting the Number of Prefixes Received on a BGP Peering Session , view the system log message when the threshold is reached. From operational mode, run the show log message command. This example shows how to configure IPv6 flow specification for traffic filtering.

BGP flow specification can be used to automate inter-domain and intra-domain coordination of traffic filtering rules in order to mitigate denial-of-service attacks. Configure a routing policy that exports routes such as static routes, direct routes, or IGP routes from the routing table into BGP. Flow specification provides protection against denial-of-service attacks and restricts bad traffic that consumes the bandwidth and stops it near the source.

Figure 7 shows the sample topology. Router R1 and Router R2 belong to different autonomous systems. IPv6 flow specification is configured on Router R2. All incoming traffic is filtered based on the flow specification conditions, and the traffic is treated differently depending on the specified action. Repeat this procedure for Router R1 after modifying the appropriate interface names, addresses, and other parameters.

Configure a static route and a next hop. Thus a route is added to the routing table to verify the feature in this example. Configure a discard action to discard packets that match the specified match conditions. Configure an accept action to accept packets that match the specified match conditions. From operational mode, run the show route table inet6flow. From operational mode, run the show bgp summary command on Router R1 and R2. Verify that the inet6. From operational mode, run the show route flow validation command on Router R1.

The output displays the flow routes in the inet6. Display the number of packets that are discarded and accepted based on the specified flow specification routes. Junos OS advertises redirect to IP flow specification action using the extended community by default. This feature is required to support service chaining in virtual service control gateway vSCG.

Redirect to IP action allows to divert matching flow specification traffic to a globally reachable address that could be connected to a filtering device that can filter the DDoS traffic and send the clean traffic to the egress device.

For example, define a policy p1 to set, add, or delete a community reidirip and an extended community to redirect traffic to IP address Configure the legacy flow specification redirect to IP feature using the nexthop attribute.

You cannot configure policies to redirect traffic to an IP address using BGP extended community and the legacy redirect to next hop IP address together. Configure legacy flow specification redirect to IP specified in the internet draft draft-ietf-idr-flowspec-redirect-ip Define a policy to set, add, or delete the BGP community using the legacy flow specification next hop attribute redirect to IP action.

Help us improve your experience. Let us know what you think. Do you have time for a two-minute survey? Maybe Later. Multiprotocol BGP.

Note: If you change the address family specified in the [edit protocols bgp family] hierarchy level, all current BGP sessions on the routing device are dropped and then reestablished. Limiting the Number of Prefixes Received on a BGP Peer Session You can limit the number of prefixes received on a BGP peer session, and log rate-limited messages when the number of injected prefixes exceeds a set limit.

Note: Alternatively, you can configure a limit to the number of prefixes that can be received as opposed to accepted on a BGP peer session.

To configure BGP routing table groups, include the rib-group statement: rib-group group-name ; For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement. Allowing Labeled and Unlabeled Routes You can allow both labeled and unlabeled routes to be exchanged in a single session.

To allow both labeled and unlabeled routes to be exchanged, include the rib statement: rib inet. Requirements No special configuration beyond device initialization is required before you configure this example. Configuration CLI Quick Configuration Configuring Device R1 CLI Quick Configuration To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Configure the routing policy. Results From configuration mode, confirm your configuration by entering the show interfaces , show policy-options , show protocols , and show routing-options commands. Verification Confirm that the configuration is working properly.

Action From operational mode, enter the show bgp neighbor command. Meaning The various occurrences of inet6-unicast in the output shows that BGP is enabled to carry IPv6 unicast routes.

Action From operational mode, enter the show route protocol bgp inet6. Note: You cannot configure this feature for the inet6 unicast, inet6 multicast, or inet6 labeled-unicast address families because BGP already has the capability to advertise these address families over an IPv6 BGP session. See Also local-ipv4-address. Requirements This example uses the following hardware and software components: Three routers with dual stacking capability Junos OS Release Configure dual stacking on all devices.

Overview Beginning with Release The next-hop information is the next-hop address information of the next router on the path to the destination. The next-hop address must be of the same address family as the NLRI.

To satisfy this requirement, the route distinguisher field of the next-hop is set to all zeros. Label: 24 bits Carries one or more labels in a stack, although a BGP update has only one label. Example shows the command that identifies which labels are assigned to the particular VPN routes, and Example shows the command to determine whether the PE-router is exchanging VPN-IPv4 address information with a neighbor.

The configuration of BGP requires several steps, and various configuration commands. The default behavior when a BGP session is configured on a Cisco router is to activate the session to carry IPv4 unicast prefixes. Example shows the syntax of this command.

The address-family is synonymous with the routing context. The BGP process with no address-family specified is the default address-family where any sessions are configured that either are not associated with a VRF or are used to carry IPv4 routes from the global routing table.

The configuration of the BGP sessions that carry IPv4 routes from the global routing table is exactly the same as the standard BGP configuration, with the exception that the session needs to be activated. The neighbor command controls the activation of the session, as shown in Example In Example , notice that the VPNv4 address-family configuration needs only one command. The configuration of the vpnv4 address-family also adds a further command to the BGP configuration.

This command is neighbor x. This command is added by default and is necessary because it instructs BGP to advertise the extended community attribute discussed earlier in this chapter. Example provides the syntax of this command. The default behavior is to send only the extended community attribute. If the network design requires the standard community attribute to be attached to VPN routes, change the default configuration using the command neighbor Again, you achieve this using the address-family configuration under the BGP process, using the ipv4 option of the address-family command used in Example The first step of the BGP decision process is to group all relevant routes so they can be compared.

Before the PE-router can select routes, it has to know which VPN routes exist and which of these routes should be comparable with each other by the BGP selection process. A site can be a member of multiple VPNs. However, a site can associate with only one VRF. These tables prevent information from being forwarded outside a VPN, and they also prevent packets that are outside a VPN from being forwarded to a device within the VPN. VPN routing information is distributed as follows:.

Typically the list of route target community extended values is set from an export list of route targets associated with the virtual routing and forwarding VRF instance from which the route was learned. An import list of route target extended communities is associated with each VRF. The import list defines route target extended community attributes that a route must have in order for the route to be imported into the VRF.

A provider edge PE device binds a label to each customer prefix learned from a customer edge CE device and includes the label in the network reachability information for the prefix that it advertises to other PE devices. When a PE device forwards a packet received from a CE device across the provider network, it labels the packet with the label learned from the destination PE device.

When the destination PE device receives the labeled packet, it pops the label and uses it to direct the packet to the correct CE device. Label forwarding across the provider backbone is based on either dynamic label switching or traffic engineered paths. A customer data packet carries two levels of labels when traversing the backbone:. The second label indicates how that PE device should forward the packet to the CE device.

The IP prefix is a member of the IPv4 address family. It uniquely identifies the customer address, even if the customer site is using globally nonunique unregistered private IP addresses. BGP communication occurs at two levels:. A given site can be a member of multiple VPNs. The as-number argument indicates the number of an autonomous system that identifies the device to other BGP devices and tags the routing information passed along.

The range is 0 to Private autonomous system numbers that can be used in internal networks are to The ip-address argument specifies the IP address of the neighbor. The peer-group-name argument specifies the name of a BGP peer group. The as-number argument specifies the autonomous system to which the neighbor belongs. Enters address family configuration mode for configuring routing sessions, such as BGP, that use standard VPNv4 address prefixes.

The optional unicast keyword specifies VPNv4 unicast address prefixes. You can enter a show ip bgp neighbor command to verify that the neighbors are up and running.

If this command is not successful, enter a debug ip bgp ip-address events command, where ip-address is the IP address of the neighbor. Private autonomous system numbers that can be used in internal networks range from to