Some time ago I published article about BGP local preference attribute. Today I’d like to show you how to configure BGP MED attribute.
What is it for?
The multi-exit discriminator MED determines an optimal route for incoming traffic of an AS. When a BGP device obtains multiple routes to the same destination but with different next hops from EBGP peers, the BGP device selects the route with the smallest MED value as the optimal route. Simply saying, configuring MED attribute, we would like to show the next hop for traffic coming from EBGP peer. The MED attribute is exchanged only between two neighboring ASs. The AS that receives the MED attribute does not advertise it to any other ASs.
Let’s look at typical scenario for MED attribute configuration:
Why might we want to assign multiple IP addresses to the same interface? The following are the most common scenarios:
- hosts in the network segment use IP addresses on different networks
- there are not enough host addresses on a logical network segment, suppose a /24 address space and 300 hosts
How to configure multiple IP addresses on Huawei devices?
Let’s configure a pair of routers connected via a Gigabit Ethernet link and use four different logical networks.
[labnarioR1]int gi 0/0/0 [labnarioR1-GigabitEthernet0/0/0]ip add 192.168.12.1 255.255.255.0 [labnarioR1-GigabitEthernet0/0/0]ip add 10.0.12.1 255.255.255.0 sub [labnarioR1-GigabitEthernet0/0/0]ip add 10.0.22.1 255.255.255.0 sub [labnarioR1-GigabitEthernet0/0/0]ip add 10.0.32.1 255.255.255.0 sub
Some time ago we talked about a basic configuration of BGP/MPLS VPNs. Let’s go on with hub&spoke networking today. Such solution can be adopted to control the mutual access of users, when an access control device is set. In this case no direct route exists between spoke sites. A spoke site advertises routes to a hub site and then the hub site advertises the routes to other spoke sites. Thus, communication between spoke sites is controlled by hub site.
Let’s look at our topology:
We have to remember that traffic policy consists of 3 parts:
In brief, to configure a traffic policy:
- define traffic class
- define action to be applied to the traffic class
- associate traffic classifiers and behaviors
- apply the traffic policy to an interface.
Let’s start from ACL.
We have possibility to configure many rules in an ACL. If the ACL is specified in if-match clause, then a packet is matched against multiple rules. If the packet matches a rule in the ACL, then it stops checking against the next rules.
- In a case of DENY action in the ACL, the matched packet is denied, regardless of what traffic behavior defines.
- When PERMIT action is defined in the ACL, then traffic behavior is applied to the matched packet.
The first what a device has to do is to check if the ACL exists. If it does, the device matches packets against rules, according to the rule ID. We can configure rule IDs manually or they are automatically allocated. In case of automatically allocated rules, there is a certain space between two rule IDs. The size of the space depends on ACL step. By default it is 5 but we can change it by command. In this manner, we can add a rule before the first rule or between rules. ACL rules are displayed in ascending order of rule IDs, not in the order of configuration.
ACL rules can be arranged in two modes: configuration and auto.
In the configuration mode (default mode), we decide which rule should be first, which second and so on and so forth. In this mode, the device matches rules in ascending order of rule IDs. Anytime we can configure an additional rule with smaller rule ID. In such case, later configured rule may be matched earlier. We make such a decision, not the system.
In the auto mode, unlike in the configuration mode, the system automatically allocates rule IDs. We don’t have possibility to specify rule ID. The most precise rule is placed at the beginning of ACL.
When can we use it?