No Updates, Yet!!!

I have no time to write a technical blog as of now as I am currently in transition moving from my current company to a new one. I have to do all the necessary stuff needed for this move. Currently I am reading CCIE Routing and Switching Exam Certification Guide, 4th Edition as preparation for my CCIE written mid this year. I don't have much lab time yet but I do have time reading the concepts I have studied when I took my CCNP. My target is Written this year and probably late this year or early to mid next year for my lab attempt. Will be posting something technical here probably 2 weeks from now.

Study Tip: Gathering Configurations

I am fond of checking Cisco website and other blogs. Whenever I come across a configuration I am interested whether its something familiar or unfamiliar, I copy that config, save it on a notepad. Though I might not understand some of the configuration files I gather, I find time researching what those config lines mean, try it in Dynamips and read more about it.

If you work doing network configuration changes, doing configs line by line will really get in your nerves. One best practice is to prepare yourself a template config per technology or per setup and save this in a notepad. Network configs in an enterprise environment usually have standard format so this will really save time and you can use time reviewing the config you prepared using the template. In the future the configs you have gathered will surely come in handy.

New Year, New Challenges

It's been a month since I last posted something and 2 months since I posted something technical. I have been on break from studying since the holiday season started and I am again picking up the momentum on my studies. I am determined to finish my Multicast studies but it seems just reading theories won't satisfy me. Though I am still aiming for my written doing the mini labs sure does help when it comes to understading the topic more.

Before the New Year started, I landed a new job with a multinational banking firm. This will be a new challenge for me because its a new network environment, new setup, new people, everything is new. To be familiar with the network environment takes a few months of study and support. I am pretty excited with that new position and I am sure I will learn and experience more.

As for this blog, it really helps writing something here for my studies. Blogging keeps me on focus and keeps me motivated to study more. I noticed that when I don't blog my motivation for my CCIE diminishes. So for the regular readers ( I don't know if there are even any :)) expect technical posts here regularly. I will be sharing what I have learned from my current environment and the new environment I will be in by February.

Busy with CCIE Written Preparation

I haven't been able to post lately since I am busy with theory and will be back on the labs once I finish my written exam. For the meantime, I will be posting some notes from time to time. I have several books to read and need to finish them and make sure the theory sinks in. My plan is to take my written exam first quarter next year. I can feel the Christmas season in the air and this chilly air makes me wanna sleep and not study :). For all those of you who celebrate Christmas, happy tidings to you and enjoy your holidays.

IGMP Version 2

IGMP Version 2 was developed as a solution for the first version's weaknesses. One of which was the inability to detect if there are still hosts which are still members of a multicast group. It will take 3 minutes before the router knows that there are no more members in version 1. The enhancements in Version 2 is shown below.

Group-Specific Query messages – enables the router to do a query operation on specific multicast groups

Leave Group messages – hosts sends a Leave message to the router that they are leaving the multicast group.

Querier election process – can elect the router that will do that query without relying on multicast routing protocols.

Maximum Response Time field - permits the Query Router to specify the maximum Query-Response time. This field
permits the tuning of the Query-Response process to control response burstiness and to fine-tune leave latencies.

The first 2 enhancements above, really helps in saving bandwidth. What happens is, if a host leaves the multicast group, it sends a Leave message. When the router receives this Leave message, it will send out a Group Specific query to that group of which the Leave message indicated and within 10 secs (default) if no host replies a Membership Report the router removes the entry in its IGMP membership table. The router doesn't have to wait 3 minutes like in Version 1.

Below is the Message types.

IGMP Version 2 Message Types

Membership Query (Type code = 0x11)

Two Subtypes:
       General Query – operates the same way like in the
       Group-Specific Query - enables the router to do a query operation on specific multicast groups.

Version 1 Membership Report (Type code = 0x12) - This is for backwards compatibility with version 1.

Version 2 Membership Report (Type code = 0x16)

Leave Group (Type code = 0x17)

Now let’s try this in the lab. I have set up the lab like before using Ubuntu and MINT. To start off, let's configure the router the same way in the IGMP Version 1 post. The command "ip multicast-routing" should be configured under global config mode. Commands "ip igmp version 2" and "ip pim sparse-dense-mode" should be configured on the FastEthernet interface. Let’s see the screenshots on Wireshark. Firstly I have generated the traffic in MINT for the Ubuntu VM to join multicast group 239.10.10.10 port 4321.


The screenshot above shows the Membership report which has a Type code of 0x16. Since in the lab that I made, there are no valid multicast sources, the host immediately sends a Leave message.

We see that the host sends the leave message to a multicast group 224.0.0.2 which means “all routers” in the local subnet. Its clear that they Type code is 0x17. Right below the Leave group message, immediately the router sends a Group Specific Query to check if there are still hosts who are still members on the same multicast group. Also it sends a General Query. Check the screenshots below to spot the difference.


Group Specific Query


General Query


The similarities between both is the Type Code which is 0x11. General Queries send it out to a well known multicast group 224.0.0.1 which is all hosts in the segment. Group Specific queries shows that it sends to the group address. In the Multicast address field, General Queries will have 0.0.0.0 which Group Specific will have the group address.

Finally let’s see the router debug output.

Router>
*Nov 18 15:41:32.759: IGMP(0): Received v2 Report on FastEthernet0/0 from 192.168.59.128 for 239.10.10.10
*Nov 18 15:41:32.759: IGMP(0): Received Group record for group 239.10.10.10, mode 2 from 192.168.59.128 for 0 sources
*Nov 18 15:41:32.763: IGMP(0): WAVL Insert group: 239.10.10.10 interface: FastEthernet0/0Successful
*Nov 18 15:41:32.763: IGMP(0): Switching to EXCLUDE mode for 239.10.10.10 on FastEthernet0/0
*Nov 18 15:41:32.763: IGMP(0): Updating EXCLUDE group timer for 239.10.10.10
*Nov 18 15:41:32.767: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.10.10.10) by 0
*Nov 18 15:41:33.975: IGMP(0): Received Leave from 192.168.59.128 (FastEthernet0/0) for 239.10.10.10
*Nov 18 15:41:33.975: IGMP(0): Received Group record for group 239.10.10.10, mode 3 from 192.168.59.128 for 0 sources
*Nov 18 15:41:33.979: IGMP(0): Lower expiration timer to 2000 msec for 239.10.10.10 on FastEthernet0/0
*Nov 18 15:41:33.979: IGMP(0): Send v2 Query on FastEthernet0/0 for group 239.10.10.10
*Nov 18 15:41:34.979: IGMP(0): Send v2 Query on FastEthernet0/0 for group 239.10.10.10
*Nov 18 15:41:35.979: IGMP(0): Switching to INCLUDE mode for 239.10.10.10 on FastEthernet0/0
*Nov 18 15:41:35.979: IGMP(0): MRT delete FastEthernet0/0 for (*,239.10.10.10) by 0

Why did the router send 2 Group Specific Queries on the debug above? The router in this case used a “Last Member Query Interval” in the range of 10 -1 second in between the Group Specific queries. What it did in our case, was to send on Group Specific query and wait for 1 second and then sends another so by the 2nd time it sent the queries and there is no reply, we see now that it did remove the group from its MRT as the last line of the debug indicated. It should take around 3 seconds as shown above for the router to stop sending traffic for a group if there are no more members. Should there were other hosts in the same multicast group 239.10.10.10 the router will continue forwarding traffic.

Study Tip: Audio Recordings

I take 2 trains and the company bus going to work each day so I spend around 1.5 to 2 hours travel from my house to my work vice-versa. It's really a waste of time just standing there and looking at the scenery which I have been looking at everyday for almost 2 years. I need to study and make most of my time even when traveling, so what I did is record some of my Cisco notes in audio and convert it to mp3. With my cheap Creative Zen Stone mp3 player, I am able to review even in the train and I am amazed how effective this is for core knowledge. I'll bet if you do this you will even laugh listening at your own voice. An audio class from a reputable vendor is also a great way to study if you don't have time to record your own notes. Listening to audio notes will become one of my daily habits.

IGMP Version 1

This protocol's version might be old but its very important how to learn the differences between IGMP V1, V2 and V3. It's important to start learning about how the protocol evolved into what it is now. Learning IGMP V1 will give us a foundational knowledge of what IGMP does and how it functions.

What is IGMP?

IGMP is used for hosts who wish to join a multicast address/group, to inform their nearest 
multicast router on which group they wish to be a member of.

Used by routers to maintain a table of multicast group membership per interface. Multicast 
group membership is active on an interface, if the router receives a Membership 
Report from that interface.

It is only needed on IPV4 networks as IPV6 has a different way to handle multicast.

In this entry, I will focus on how the router forms the multicast membership table and what are the most commonly used multicast addresses used to discover multicast members. I will also do some debugs to check how IGMP Version 1 removes a multicast address from the IGMP membership table. The simple diagram is shown below, instructions on how I set up MINT, Wireshark and Ubuntu can be found on the previous blog entry.

Scenario: Ubuntu VM wishes to receive multicast traffic from 239.10.10.10, 239.20.20.20 and 
239.30.30.30. Observe through Wireshark and debug commands how IGMP Version 1 works.

First thing is to configure the router to make multicast work.

R0(config)#ip multicast-routing
R0(config)#int fa0/0
R0(config-if)#ip pim sparse-dense-mode
R0(config-if)#ip igmp version 1

Router#sh ip igmp interface
FastEthernet0/0 is up, line protocol is up
 Internet address is 192.168.18.10/24
 IGMP is enabled on interface
  Current IGMP host version is 1
  Current IGMP router version is 1
 IGMP query interval is 60 seconds
 Inbound IGMP access group is not set
 IGMP activity: 6 joins, 4 leaves
 Multicast routing is enabled on interface
 Multicast TTL threshold is 0
 Multicast designated router (DR) is 192.168.18.10 (this system)
 IGMP querying router is 192.168.18.10 (this system)
 Multicast groups joined by this system (number of users):
     224.0.1.40(1)

These commands are needed to make multicast operate on the router. PIM sparse-dense mode will be discussed on the other entries. I doubt if any aspiring CCIE candidates who already took their CCNP will know nothing about PIM.:)

Then, Wireshark should already be ready to sniff packets on the VMware interface towards Ubuntu VM. From Ubuntu VM Terminal, generate the commands below for the virtual machine to receive traffic for multicast groups 239.10.10.10, 239.20.20.20 and 239.30.30.30. There are no real multicast sources though so don't expect a continous multicast traffic flow. This commands on MINT will only send Membership Report to the router informing that this host is interested joining these 3 multicast groups.

pete@pete-desktop:~/mint-1.2$ mint -r 239.10.10.10 -p 4321
pete@pete-desktop:~/mint-1.2$ mint -r 239.20.20.20 -p 4321
pete@pete-desktop:~/mint-1.2$ mint -r 239.20.20.20 -p 4321

I filtered the output on Wireshark to only show igmp packets and the first 3 outputs are shown below in the red box. My Ubuntu VM's ip address is 192.168.18.129. Click on the picture below to enlarge...


We can see the lines numbered 2, 4 and 7 with the red box that the Info part specifies a V1 Membership Report. Let's see how the router sees the debug.

*Oct 30 13:39:35.783: IGMP(0): Received v1 Report on FastEthernet0/0 from 192.168.18.129 for 239.10.10.10
*Oct 30 13:39:35.783: IGMP(0): Received Group record for group 239.10.10.10, mode 2 from 192.168.18.129 for 0 sources
*Oct 30 13:39:35.787: IGMP(0): WAVL Insert group: 239.10.10.10 interface: FastEthernet0/0Successful
*Oct 30 13:39:35.787: IGMP(0): Switching to EXCLUDE mode for 239.10.10.10 on FastEthernet0/0
*Oct 30 13:39:35.787: IGMP(0): Updating EXCLUDE group timer for 239.10.10.10
*Oct 30 13:39:35.791: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.10.10.10) by 0
*Oct 30 13:39:41.083: IGMP(0): Received v1 Report on FastEthernet0/0 from 192.168.18.129 for 239.20.20.20
*Oct 30 13:39:41.087: IGMP(0): Received Group record for group 239.20.20.20, mode 2 from 192.168.18.129 for 0 sources
*Oct 30 13:39:41.087: IGMP(0): WAVL Insert group: 239.20.20.20 interface: FastEthernet0/0Successful
*Oct 30 13:39:41.087: IGMP(0): Switching to EXCLUDE mode for 239.20.20.20 on FastEthernet0/0
*Oct 30 13:39:41.091: IGMP(0): Updating EXCLUDE group timer for 239.20.20.20
*Oct 30 13:39:41.091: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.20.20.20) by 0
*Oct 30 13:39:42.275: IGMP(0): Received v1 Report on FastEthernet0/0 from 192.168.18.129 for 239.20.20.20
*Oct 30 13:39:42.275: IGMP(0): Received Group record for group 239.20.20.20, mode 2 from 192.168.18.129 for 0 sources
*Oct 30 13:39:42.279: IGMP(0): Updating EXCLUDE group timer for 239.20.20.20
*Oct 30 13:39:42.279: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.20.20.20) by 0
*Oct 30 13:39:44.651: IGMP(0): Received v1 Report on FastEthernet0/0 from 192.168.18.129 for 239.30.30.30
*Oct 30 13:39:44.651: IGMP(0): Received Group record for group 239.30.30.30, mode 2 from 192.168.18.129 for 0 sources
*Oct 30 13:39:44.655: IGMP(0): WAVL Insert group: 239.30.30.30 interface: FastEthernet0/0Successful
*Oct 30 13:39:44.655: IGMP(0): Switching to EXCLUDE mode for 239.30.30.30 on FastEthernet0/0
*Oct 30 13:39:44.655: IGMP(0): Updating EXCLUDE group timer for 239.30.30.30
*Oct 30 13:39:44.655: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.30.30.30) by 0

We can see there the statements "MRT Add/Update FastEthernet0/0" which means it mapped the specific multicast address to the MRT (multicast routing table) for a specific interface. This will be also added to the IGMP membership. Lets check the MROUTE and IGMP memberships.

Router#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
     L - Local, P - Pruned, R - RP-bit set, F - Register flag,
     T - SPT-bit set, J - Join SPT, M - MSDP created entry,
     X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
     U - URD, I - Received Source Specific Host Report,
     Z - Multicast Tunnel, z - MDT-data group sender,
     Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.250), 00:00:44/00:02:15, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
  FastEthernet0/0, Forward/Sparse-Dense, 00:00:44/00:00:00

(*, 239.10.10.10), 00:00:08/00:02:51, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
  FastEthernet0/0, Forward/Sparse-Dense, 00:00:08/00:00:00 ######### Added to MRT

(*, 224.0.1.40), 00:00:49/00:02:52, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
  FastEthernet0/0, Forward/Sparse-Dense, 00:00:49/00:00:00

Router#sh ip igmp member
Flags: A  - aggregate, T - tracked
  L  - Local, S - static, V - virtual, R - Reported through v3
  I - v3lite, U - Urd, M - SSM (S,G) channel
  1,2,3 - The version of IGMP the group is in
Channel/Group-Flags:
  / - Filtering entry (Exclude mode (S,G), Include mode (*,G))
Reporter:
   - last reporter if group is not explicitly tracked
/      -  reporter in include mode,  reporter in exclude

Channel/Group                  Reporter        Uptime   Exp.  Flags  Interface
*,239.255.255.250              192.168.18.1    00:03:32 02:59 1A     Fa0/0
*,239.20.20.20                 192.168.18.129  00:02:38 00:22 1A     Fa0/0
*,239.10.10.10                 192.168.18.129  00:02:43 00:16 1A     Fa0/0
*,239.30.30.30                 192.168.18.129  00:02:34 00:25 1A     Fa0/0
*,224.0.1.40                   192.168.18.10   00:03:34 02:50 1LA    Fa0/0

What are these other groups here? We are these for? Check the Wireshark screenshot above for the blue and green boxes. 239.255.255.250 is used by SSDP (Simple Service Discovery Protocol) used for Universal Plug and Play and from the output above its REPORTER is my Host OS which is Windows (192.168.18.1). 224.0.1.40 is a well known IANA assigned address for RP discovery while its counter part 224.0.1.39 is for RP announcement. This is reported by the router itself.

Multicast Routers use the IANA allocated Multicast address 224.0.0.1 for Membership Queries.
This multicast address is  reserved for all hosts in the LAN segment.

Leave Group

What happens when a host no longer wants to receive multicast traffic? How does the router know that there are no more interested hosts for that multicast group. For version 1, IGMP by default does Membership query every 60 seconds. It sends the multicast to 224.0.0.1 which means all host in the subnet. If by 3 tries which would be 180 secs or 3 mins and there are no Membership Report for a certain address, the router removes the entry from the IGMP membership table. Let's again generate traffic for 239.10.10.10 in MINT and lets see after 3 mins what the router does if there are no more Membership Reports.

pete@pete-desktop:~/mint-1.2$ mint -r 239.20.20.20 -p 4321

Router#debug ip igmp 239.10.10.10
IGMP debugging is on
Router#
*Oct 30 13:53:33.727: IGMP(0): Received v1 Report on FastEthernet0/0 from 192.168.18.129 for 239.10.10.10
*Oct 30 13:53:33.731: IGMP(0): Received Group record for group 239.10.10.10, mode 2 from 192.168.18.129 for 0 sources
*Oct 30 13:53:33.731: IGMP(0): WAVL Insert group: 239.10.10.10 interface: FastEthernet0/0Successful
*Oct 30 13:53:33.731: IGMP(0): Switching to EXCLUDE mode for 239.10.10.10 on FastEthernet0/0
*Oct 30 13:53:33.735: IGMP(0): Updating EXCLUDE group timer for 239.10.10.10
*Oct 30 13:53:33.735: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.10.10.10) by 0
*Oct 30 13:54:09.335: IGMP(0): Send v1 general Query on FastEthernet0/0
*Oct 30 13:54:14.815: IGMP(0): Report has illegal group address 224.0.0.251
*Oct 30 13:55:09.335: IGMP(0): Send v1 general Query on FastEthernet0/0
*Oct 30 13:55:14.095: IGMP(0): Report has illegal group address 224.0.0.251
Router#sh ip igmp member
Flags: A  - aggregate, T - tracked
L  - Local, S - static, V - virtual, R - Reported through v3
I - v3lite, U - Urd, M - SSM (S,G) channel
1,2,3 - The version of IGMP the group is in
Channel/Group-Flags:
/ - Filtering entry (Exclude mode (S,G), Include mode (*,G))
Reporter:
 - last reporter if group is not explicitly tracked
/      -  reporter in include mode,  reporter in exclude

Channel/Group                  Reporter        Uptime   Exp.  Flags  Interface
*,239.255.255.250              192.168.18.1    00:17:14 02:13 1A     Fa0/0
*,239.10.10.10                 192.168.18.129  00:02:27 00:32 1A     Fa0/0
*,224.0.1.40                   192.168.18.10   00:17:16 02:08 1LA    Fa0/0
Router#
*Oct 30 13:56:09.335: IGMP(0): Send v1 general Query on FastEthernet0/0
*Oct 30 13:56:15.155: IGMP(0): Report has illegal group address 224.0.0.251
*Oct 30 13:56:34.335: IGMP(0): Switching to INCLUDE mode for 239.10.10.10 on FastEthernet0/0
*Oct 30 13:56:34.335: IGMP(0): MRT delete FastEthernet0/0 for (*,239.10.10.10) by 0

The one highlighted in red is timestamped 13:53:33.735 when the router added 239.10.10.10 in the IGMP membership and when it did not receive a Membership report it removed the entry in its IGMP Membership timestamped 13:56:34.335, thats almost exactly 3 minutes! The command "show ip igmp membership" shows above that in 00:32 secs the multicast group will be removed from the IGMP Membership if it doesn't hear a Membership Report. If there was a real multicast source in this lab, R0 would have been wasting bandwidth for 3 minutes sending multicast traffic out of Fa0/0 with no receivers. IGMP version 1 doesn't have mechanism for hosts to inform the router that they are leaving the group. The host "quietly leaves" the multicast group. This lead to the development of IGMP V2.

Multicast Lab Preparation

My idea of studying the CCIE topics includes sniffing the packets using Wireshark and study the contents of the packet. This I think, is a good way to understand how a protocol works and what components/ fields make up a packet of a certain protocol. I also will continue making use of VMware to host operating systems to be used for my studies of Multicast, QoS and other topics. Here I will show I set up my Guest OS and install the Multicast Traffic Generator I will be using.

Requirements:

VMware Server Installer
MINT software for Linux (Multicast Application)
GNS3
Ubuntu image
Wireshark

Steps:

1. Install VMware software. After installation, create a new virtual machine. For steps, on how to create a virtual machine in VMware click here. Use the Ubuntu ISO image downloaded as the ISO for the virtual CD drive in the virtual machine. This would automatically boot the live cd. It will display a menu and choose "Try Ubuntu without any change to your computer." Screenshot from Ubuntu site seen below.



2. Let the Live CD run and when it fully boots up and shows the desktop, click Install Icon as seen below.


3. Once Ubuntu is done installing on your VMware, run it and it should be ready to be used the first time. Make sure the virtual NIC is set to NAT or Bridge. If this is set to bridge, your internet router should lease an ip addresses to this virtual NIC and would be on the same subnet as your real NIC connected to your internet router.

4. Check if you can browse the internet using Firefox on your Ubuntu VM. Download the MINT from http://mc-mint.sourceforge.net/. Download the latest version 1.2.

5. Ubuntu might need an update to install or compile *.tar files so we would need to update and install those updates. Execute the commands below on the Applications -> Accessories ->Terminal, just make sure you have internet connectivity on your Ubuntu VM.

sudo apt-get update

sudo apt-get install build-essential

6. Now its time to install MINT. Copy the downloaded mint to your /home/username directory. Unzip the file using commands below.

gzip -d mint-1.2.tar.gz

tar -xvf mint-1.2.tar

7. Go to the new mint directory created and execute the command "make" to compile.

8. If you want to install it to /usr/local/bin execute "make install". Open the README file for more details on how to install and run MINT by going to the directory ./mint and execute "more README".

9. Integrate your Ubuntu VM to your GNS by dragging a cloud as seen below(Click on the image to enlarge). Click on the cloud and Choose the VMware NIC and click add. Connect your GNS3 routers ethernet interface to the cloud and then configure the interface with same subnet IP as your VMware interface. Mine defaulted to 192.168.18.0/24. Check your Ubuntu ip address by executing "ifconfig" on the terminal and then ping it from the router to test connectivity. This should be ready for the exercises I will do in my studies.


10. Download Wireshark, on your host Operating System, (I assume its Windows) then install it. It should be ready to sniff any traffic on the VMware virtual NIC's.

Now, I am ready to start my mini labs for Multicasting. :)

Multicast Studies Loading

Its been a while since I posted something here. I have finished my BGP studies but will get back on that again after I have finished the other topics. Now I am into Multicasting and currently reading the book Developing IP Multicast Networks. The book might be a little old but the author is good at explaning what Multicast is and the other topics. I haven't even finished half of the book and yet the information it shares really helps. I have also setup VMware in my laptop and setup Ubuntu as a Guest Operating System on where I will run a multicast software to send and receive multicast traffic. Installed Wireshark for packet sniffing so I can see what's going on, on a multicast packet. I will post the instructions how I set up the lab I will be using and integrate it with Dynamips/GNS3. I am excited in this study because Multicast is one areas I have little to no experience with. I rarely encounter Multicast in the production networks in my present and previous jobs. This is one of weaknesses but the book I'm reading will greatly help me overcome this weakness.

BGP Attributes Categories

A quick copy-and-paste summary on BGP attribute categorization.

WELL-KNOWN, MANDATORY

AS-path: A list of the Autonomous Systems (AS) numbers that a route passes through to reach the destination. As the update passes through an AS the AS number is inserted at the beginning of the list. The AS-path attribute has a reverse-order list of AS passed through to get to the destination.

Next-hop: The next-hop address that is used to reach the destination.

Origin: Indicates how BGP learned a particular route. There are three possible types -- IGP (route is internal to the AS), EGP (learned via EBGP), or Incomplete (origin unknown or learned in a different way).


WELL-KNOWN, DISCRETIONARY

Local Preference: Defines the preferred exit point from the local AS for a specific route.

Atomic Aggregate: Set if a router advertises an aggregate causes path attribute information to be lost.


OPTIONAL, TRANSITIVE

Aggregator: Specifies the router ID and AS of the router that originated an aggregate prefix. Used in conjunction with the atomic aggregate attribute.

Community: Used to group routes that share common properties so that policies can be applied at the group level.


OPTIONAL, NON-TRANSITIVE

Multi-exit-discriminator (MED): Indicates the preferred path into an AS to external neighbors when multiple paths exist.


A list of path attributes is contained in BGP update messages. The attribute is variable length and consists of three fields: Attribute type consisting of a 1-byte attribute flags field and a 1-byte attribute code field, Attribute length field that is 1 or 2 bytes, and a variable length attribute value field. The attribute type codes used by Cisco are: 1-origin, 2-AS-path, 3-Next-hop, 4-MED, 5-Local preference, 6-Atomic aggregate, 7-aggregator, 8-community, 9-originator-ID, and 10-cluster list.