Category: Cisco Cert

Packet header graphic representation

I was surfing the Internet in search of some good drawing representing packet header and I come across five excellent diagrams large enough ( 1050px wide ) to use digital but also for printing. The person behind these excellent drawings is Matt Baxter, but his site (fatpipe.org) is not accessible anymore. I found these documents on the Internet and I thought to add them here together.

You will find a link at the bottom of this post where you can download them all together.

Disclaimer: These drawings are not mine and I don’t claim any rights on them. My thanks and all copyrights go to Matt Baxter.
Matt, if you come across this blog and you find sharing to be inappropriate, please contact me.

IPv4 Header

IPv4 Header

IPv6 Header

IPv6 Header

TCP Header

TCP Header

UDP Header

UDP Heater

ICMP Header

ICMP Header

Download all drawings here:

Packet header representation

 

Selective BGP Dampening and parameters tuning

Some time ago, I wrote about BGP Dampening and how this feature can improve the stability of the network. A lot happened since then and during my experience with different service providers I have seen that BGP dampening can help in the same measure at it can harm your network. An endless discussion can be started on this topic, but this is not what I want to do here.

One thing that I did learn is that fine tuning of any feature can help a lot in some cases making the difference between stable network and a total disaster. In regard to BGP dampening, I have the following scenario. Imagine that you would like to use BGP dampening, but only for some networks, which are proven to be more stable than others. I will base my example on the following scenario:

Task

Router 1 in the above scenario has three networks that are advertised into BGP:
L0 – 1.1.1.0 /24
L1 – 11.11.11.0 /24
L2 – 111.111.111.0 /24
Imagine this are being remote networks and that 11.11.11.0 /24 is very unstable. To simulate an unstable network that triggers BGP, shut / no shut multiple times.

On Router 2, we want to use the BGP Dampening feature, but only for this network. We know already that we can do something like:

conf t
router bgp 200
bgp dampening

This will enable the BGP dampening feature. We can even fine tune some parameters like:

conf t
router bgp 200
bgp dampening 15 750 5000 30

In this way we increase the limit at which a route will be dampened (5000) and decrease the maximum dampening time to 30 minutes. Unfortunately this parameters are applied globally and all routes (stable and unstable) will play by this rules.

Solution

Going back to the idea of this post, use of selective BGP Dampening, we can configure Router 2 like this:

conf t
access-list 11 permit 11.11.11.0 0.0.0.255
!
route-map DAM permit 10
match ip address 11
set dampening 15 750 2000 60
!
route-map DAM deny 1000

What we just did is to match the unstable prefix in an ACL. Use the ACL in a route-map with permit policy. Mandatory set the dampening parameters. They can be the same as original values, but if you don’t set anything here, you will meet the following error when trying to apply the BGP dampening.

%BGP-3-BADROUTEMAP: Bad parameters in the route-map DAM applied for Dampening

At the end we have a deny policy in the same route-map to avoid matching any other prefixes. We can not apply it to BGP:

conf t
router bgp 200
bgp dampening route-map DAM

We want to check that BGP Dampening feature is activated:

R2#sh ip bgp dampening parameters
 dampening 15 750 2000 60 (route-map DAM 10)
  Half-life time      : 15 mins       Decay Time       : 2320 secs
  Max suppress penalty: 12000         Max suppress time: 60 mins
  Suppress penalty    :  2000         Reuse penalty    : 750

By the way, if you check the output immediately after applying the BGP dampening feature, you might see the following error:

% dampening reconfiguration in progress for IPv4 Unicast

Verification

Let us see if there are any flaps on going:

R2#sh ip bgp dampening flap-statistics 
 
R2#

Now we can shut / no shut L1 interface on R1 to create an instability of this network. After doing so couple of times we can see that the BGP dampening is active:

R2#sh ip bgp dampening flap-statistics | b Net
   Network          From            Flaps Duration Reuse    Path
 h 11.11.11.0/24    10.1.12.1       1     00:00:22          100

If we continue to play with shut / no shut, soon we will see that 11.11.11.0 /24 is marked as dampened:

R2#sh ip bgp dampening dampened-paths | b Net
   Network          From             Reuse    Path
*d 11.11.11.0/24    10.1.12.1        00:06:29 100 i

Now I want to prove that the same BGP dampening policies does NOT apply to other networks like 111.111.111.0 /24. I will try to play the same shut / no shut game with L2 on R1. After 5 minutes of this game I can see the following:

R2#sh ip bgp dampening dampened-paths | b Net
   Network          From             Reuse    Path
*d 11.11.11.0/24    10.1.12.1        00:02:09 100 i
 
R2#sh ip bgp dampening flap-statistics | b Net
   Network          From            Flaps Duration Reuse    Path
*d 11.11.11.0/24    10.1.12.1       3     00:07:51 00:01:49 100 
 
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.1.23.3                0             0 300 i
*d 11.11.11.0/24    10.1.12.1                0             0 100 i
*> 111.111.111.0/24 10.1.12.1                0             0 100 i

You can see that 111.111.111.0 /24 does not appear in any dampening report.

I tried this in multiple scenarios and every time I got the expected result. If you test this and get different results, please let me know in comments and we can discuss.


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!

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.