Author: Calin

Calin is a network engineer, with more than 20 years of experience in designing, installing, troubleshooting, and maintaining large enterprise WAN and LAN networks.

BGP Conditional Advertisement

BGP Conditional Advertisement – it let the impression of a very complex task. Actually you will find it very easy to implement once you understand it.

In simple words I would say  that BGP conditional advertisement it’s a feature that let you advertise a prefix to one of your neighbors if mandatory condition is satisfied. To implement this feature you must configure at least two of the following three maps:

– Advertise-map -> this contains the selected prefixes which will be advertised if the mandatory condition is satisfied
– Exist-map -> condition to be satisfied (e.g. advertise the prefixes in the “advertise-map” only if the prefixes in this condition exist)
– Non-exist-map -> condition to be satisfied (e.g. advertise the prefixes in the “advertise-map” only if the prefixes in this condition doesn’t exist)

Let’s take an example. We have the following topology:

We have here a simple topology, with eBGP peering between R1 – R2 and R2 – R3. Each router has a Loopback interface with the following IP addresses:

R1 – L0 – 1.1.1.1 /24
R2 -L0 – 2.2.2.2 /24
R3 – L0 – 3.3.3.3 /24

These interfaces are advertised into BGP and they have full reachability:

R2#sh ip bgp sum | b Nei
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.12.1      4   100       5       4        0    0    0 00:01:27        1
10.10.23.3      4   300       2       2        0    0    0 00:00:24        0
 
R2#sh ip bgp | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.10.12.1               0             0 100 i
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
*> 3.3.3.0/24       10.10.23.3               0             0 300 i
 
R2#sh ip route bgp
     1.0.0.0/24 is subnetted, 1 subnets
B       1.1.1.0 [20/0] via 10.10.12.1, 00:04:02
     3.0.0.0/24 is subnetted, 1 subnets
B       3.3.3.0 [20/0] via 10.10.23.3, 00:04:02

Task

An easy task would ask you to solve something like if 1.1.1.0 /24 is NOT in the BGP table of R2, then R2 should advertise its 2.2.2.0 /24 to R3.

Solution

Let’s analyze this request a little bit. The prefix to be advertised or not, depending of the satisfaction of the condition, is 2.2.2.0 /24. According to what I said before about the necessary “maps” for BGP conditional advertisement, this prefix will go into the “advertise-map”. R2 is the only router you need to configure to accomplish this task.

conf t
access-list 2 permit 2.2.2.0 0.0.0.255
route-map ADVERTISE permit 10
match ip address 2

OK, we have the advertisement map. What about the condition? The task request that 2.2.2.0 /24 should be advertised if 1.1.1.0 / 24 does NOT exist in the BGP table of R2. Using logical deduction we can say that “non-exist-map” is what we need to configure.

conf t
access-list 1 permit 1.1.1.1 0.0.0.255
route-map NOT-EXIST permit 10
match ip address 1

Let’s add everything together in BGP:

conf t
router bgp 200
neighbor 10.10.23.3 advertise-map ADVERTISE non-exist-map NOT-EXIST

Verification

On R2 check the BGP table:

R2#sh ip bgp | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.10.12.1               0             0 100 i
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
*> 3.3.3.0/24       10.10.23.3               0             0 300 i

We have the 1.1.1.0 /24 prefix in the BGP table. According to our task, 2.2.2.0 /24 should be advertised if 1.1.1.0 /24 does NOT EXIST. By analogy, if 1.1.1.0 /24 EXIST, the 2.2.2.0 /24 should NOT be advertised. You see? It’s just a tricky words game.

R2#sh ip bgp neigh 10.10.23.3 adv | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.10.12.1               0             0 100 i
 
Total number of prefixes 1

We advertise only one network. The 2.2.2.0 /24 is not advertised to R3:

R3#sh ip bgp | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       10.10.23.2                             0 200 100 i
*> 3.3.3.0/24       0.0.0.0                  0         32768 i

To check that the conditional advertisement really works, stop R1 from announcing 1.1.1.0 /24 in BGP. You can just shutdown the interface.
Check if the L0 of R1 is in the routing table / BGP table of R2:

R2#sh ip bgp | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
*> 3.3.3.0/24       10.10.23.3               0             0 300 i

1.1.1.0 /24 is not in the BGP table of R2, then 2.2.2.0 /24 should be advertised to R3:

R2#sh ip bgp neigh 10.10.23.3 adv | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
 
Total number of prefixes 1

On R3:

R3#sh ip bgp | b Net
   Network          Next Hop            Metric LocPrf Weight Path
*> 2.2.2.0/24       10.10.23.2               0             0 200 i
*> 3.3.3.0/24       0.0.0.0                  0         32768 i

Remember that usually in the exams, the tasks related to BGP Conditional Advertisement are more word tricks than complex. As an example, base on the above topology, resolve the following:
– If 1.1.1.0 /24 and 2.2.2.0 /24 are both in the BGP table of R2, both prefixes should be advertised to R3
– If 1.1.1.0 /24 is not in the BGP table of R2, then 2.2.2.0 /24 should not be advertised to R3
– If 1.1.1.0 /24 and 2.2.2.0 /24 are not in the BGP table of R2, then none of them should be advertised to R3

If you don’t understand the trick, let me know and I will explain.


Free Streaming CCNA Voice Bootcamp from INE

I got today a newsletter from INE announcing a freebie. You have it below. Enjoy!

Free Streaming of our NEW
CCNA Voice Bootcamp Course!

FOR A LIMITED TIME until March 31st, 2012, get FREE streaming
of the NEW CCNA Voice Bootcamp Course with CCIEx2 #14073
Mark Snow when you become a member with INE!
Registration today for free!

The CCNA Voice class is an ultimate all-in-one solution for engineers pursuing the Cisco Certified Network Associate Voice (CCNA Voice) certification. This Video-on-Demand course includes over 25 hours of instructor-led content that will fully prepare you for the latest Cisco 640-461 ICOMM v8 certification exam. Please note that per Cisco CCNA Voice certification requirements, you need to have already met the pre-requisite of having a valid regular CCNA (Routing & Switching) status. View this course on your desktop computer, iPhone®, iPad® or other .mov video file format compatible devices. Learn more »

Click Here to register for your free account with INE to receive your FREE access to the ALL NEW CCNA Voice Bootcamp Course!

Cisco NX-OS Malformed IP Packet Denial of Service Vulnerability

Summary

Cisco NX-OS Software is affected by a denial of service (DoS) vulnerability that could cause Cisco Nexus 1000v, 5000, and 7000 Series Switches that are running affected versions of Cisco NX-OS Software to reload when the IP stack processes a malformed IP packet.

Vulnerable Products

Cisco Nexus 1000v, 5000, and 7000 Series Switches that are running affected versions of Cisco NX-OS Software are affected by this vulnerability. The vulnerability is in the operating system’s IP stack; therefore, any feature that makes use of the services that are offered by the IP stack to process IP packets is affected.

Cisco NX-OS Software versions prior to the First Fixed Release version are affected. Refer to the Software Versions and Fixes section for details regarding fixed versions.

To determine the version of Cisco NX-OS Software that is running on a Cisco Nexus switch, administrators can log in to the device and issue the show version command to display the system banner.

Products Confirmed Not Vulnerable

Cisco NX-OS Software for products other than the Cisco Nexus 1000v, 5000, and 7000 Series Switches is not affected by this vulnerability. In particular, the following products that run Cisco NX-OS Software are not affected:

Cisco Nexus 2000 Series Switches
Cisco Nexus 3000 Series Switches
Cisco Nexus 4000 Series Switches
Unified Computing System (UCS)
Cisco MDS 9000 Series Multilayer Switches

No other Cisco products are currently known to be affected by this vulnerability.

This advisory is available at the following link:

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120215-nxos

CCIE home rack – Ubuntu persistent net rules

In one of my last posts, I was writing about my CCIE home rack which has one server that runs Ubuntu + Ethernet Quad cards + Cisco switches. Before connecting the cables between server and Cisco switches, I had one problem that was driving me crazy.

I have three Ethernet Quad cards connected in 3 PCI slots in my server. The issue is that sometimes (quite often) the port numbers were changing during the reboot of my client. To give you and example, an ethernet port that was  eth1 during one server boot could change to eth2 next time. For twelve ports you can imagine what mess this creates after almost each server reboot. When this was happening, the ports were not matched correctly in Dynamips and from it would result in a lot of connectivity problems.

I will try to explain in a few word why this is happening. With Udev and modular network drivers, the network interface numbering is not persistent across reboots by default, because the drivers are loaded in parallel and, thus, in random order. For example, on a computer having two network cards made by Intel and Realtek, the network card manufactured by Intel may become eth0 and the Realtek card becomes eth1. In some cases, after a reboot the cards get renumbered the other way around. To avoid this, create Udev rules that assign stable names to network cards based on their MAC addresses or bus positions.

My solution is based on MAC addresses. I’m not saying that’s the best, but it works for me and I hope it will help you as well. Before editing the file for persistent Udev rules, we have to gather some information.

First I needed to check what cards I have in my server:

root@athos:/etc/udev/rules.d# lspci | grep Ethernet
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
04:00.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 05)
04:01.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 05)
04:02.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 05)
04:03.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 05)
05:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
05:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
05:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
05:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
06:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
06:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
06:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
06:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)

So, I have my onboard Realtek card, then one Intel quad card and then two D-Link DFE-570TX quad cards. The Intel card I got it from a friend and the D-Link I bought over eBay. I must say that Ethernet quad cards tend to be a little bit too expensive, but I’ve found 2 brands over eBay that were cheaper, around 25 Eur / piece. One brand is the D-Link and the other one is from Sun. There are some arguments to choose D-Link over Sun on the INE Online Community discussion. You should check that discussion as it has a lot of good tips and tricks. All cards are supported natively in Ubuntu.

Next, I had to collect the MAC addresses of all Ethernet cards.

root@athos:/etc/udev/rules.d# grep -H . /sys/class/net/*/address | grep eth
/sys/class/net/eth0/address:00:25:22:53:57:40
/sys/class/net/eth10/address:00:80:c8:ca:d8:7e
/sys/class/net/eth11/address:00:80:c8:ca:d8:7f
/sys/class/net/eth12/address:00:80:c8:ca:d8:80
/sys/class/net/eth1/address:00:e0:b6:06:a6:3b
/sys/class/net/eth2/address:00:e0:b6:06:a6:3a
/sys/class/net/eth3/address:00:e0:b6:06:a6:39
/sys/class/net/eth4/address:00:e0:b6:06:a6:38
/sys/class/net/eth5/address:00:80:c8:ca:bb:59
/sys/class/net/eth6/address:00:80:c8:ca:bb:5a
/sys/class/net/eth7/address:00:80:c8:ca:bb:5b
/sys/class/net/eth8/address:00:80:c8:ca:bb:5c
/sys/class/net/eth9/address:00:80:c8:ca:d8:7d

On the last step I had to edit the file in charge for Udev persistent rules for network cards. In Ubuntu, this file is under:

/etc/udev/rules.d/70-persistent-net.rules

I already had a sample file, so I just modified it so match my own rules. My file looks like this:

# This file maintains persistent names for network interfaces.
# See udev(7) for syntax.
#
# Entries are automatically added by the 75-persistent-net-generator.rules
# file; however you are also free to add your own entries.
#
### File generated by cc ####
### Count start from top card left side with eth1 ####
### # eth4  # eth3  # eth2  # eth1 ###
### # eth8  # eth7  # eth6  # eth5 ###
### # eth12 # eth11 # eth10 # eth9 ###
 
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:25:22:53:57:40", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
 
# PCI device 0x1011:0x0019 (tulip)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:80:c8:ca:d8:80", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth12"
 
# PCI device 0x1011:0x0019 (tulip)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:80:c8:ca:d8:7f", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth11"
 
# PCI device 0x1011:0x0019 (tulip)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:80:c8:ca:d8:7e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth10"
 
# PCI device 0x1011:0x0019 (tulip)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:80:c8:ca:d8:7d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth9"
 
# PCI device 0x1011:0x0019 (tulip)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:80:c8:ca:bb:5c", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth8"
 
# PCI device 0x1011:0x0019 (tulip)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:80:c8:ca:bb:5b", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth7"
 
# PCI device 0x1011:0x0019 (tulip)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:80:c8:ca:bb:5a", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth6"
 
# PCI device 0x1011:0x0019 (tulip)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:80:c8:ca:bb:59", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5"
 
# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:b6:06:a6:38", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"
 
# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:b6:06:a6:39", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"
 
# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:b6:06:a6:3a", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
 
# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:b6:06:a6:3b", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

I did some remarks for myself on the top file, just to know in future how the ports are arranged. Save this file and you’re good to go.

Please remember, don’t just copy / paste the output from this file. I mean you can do it, but change at least the ATTR{address} and NAME. I don’t know what other attributes (ATTR{dev_id}==”0x0″, ATTR{type}==”1″) are doing. They were in the original file and I just copy/paste them. Everything is working and for me that is enough for me.

Good luck and let me know if you have any problems implementing the above solution.