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.

BGP MED

BGP MED is an optional non-transitive attribute meaning its not propagated throughout the whole internet but just to adjacent AS. The word "optional" means that this is not necessarily by default sent with the BGP updates. The purpose of MED is to influence how other autonomous systems enter your AS to reach a certain prefix. If the other attributes are set to default, MED will be the attribute used for path selection however, if Weight or Local preference is configured on the adjacent AS router, then MED will not be selected. The lower the MED the more preferred the path will be.

Acronym for Multi Exit Discriminator and otherwise known as "Metric" in the BGP table.
The lower the MED the more preferred.
It is an optional non-transitive attribute.
Can dictate how other AS enter your AS.

Configure R4 so that it will advertise a MED value of 30 to R3 and 20 to R2. Afterwards,
tweak the route map to set a MED of 10 for network 144.144.144.144/32 in R4 towards R3. The end
result should have traffic from AS123 to 4.4.4.4/32 and 44.44.44.44/32 take R2 but traffic for
144.144.144.144/32 should take R3. At the start BGP has been established on all routers.

To start lets configure 2 route maps and set the MED as required.

R4(config)#access-list 20 permit any
R4(config)#access-list 30 permit any
R4(config)#route-map R2SETMED20 permit 10
R4(config-route-map)#match ip address 20
R4(config-route-map)#set metric 20
R4(config-route-map)#route-map R3SETMED30 permit 10
R4(config-route-map)#match ip address 30         
R4(config-route-map)#set metric 30

Access-list matches all routes. Now, lets apply the route map to the neighbors.

R4(config-router)#neighbor 24.24.24.2 route-map R2SETMED20 out
R4(config-router)#neighbor 34.34.34.3 route-map R3SETMED30 out

Its in the "out" direction because R4 is the one advertising the routes. Let's check what R2 and R3 see in their BGP table.

R2#sh ip bgp
BGP table version is 31, local router ID is 24.24.24.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

  Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       24.24.24.4              20             0 4 i
*> 44.44.44.44/32   24.24.24.4              20             0 4 i
*> 144.144.144.144/32
                   24.24.24.4              20             0 4 i

R3#sh ip bgp
BGP table version is 10, local router ID is 34.34.34.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

  Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       34.34.34.4              30             0 4 i
*> 44.44.44.44/32   34.34.34.4              30             0 4 i
*> 144.144.144.144/32
                   34.34.34.4              30             0 4 i

Ok, its clear that the Metric now is changed to 20 and 30 for R2 and R3 respectively. Let's see how R1 sees the routes.

R1#sh ip bgp
BGP table version is 34, local router ID is 13.13.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
             r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

  Network          Next Hop            Metric LocPrf Weight Path
*>i4.4.4.4/32       24.24.24.4              20    100      0 4 i
* i                 34.34.34.4              30    100      0 4 i
*>i44.44.44.44/32   24.24.24.4              20    100      0 4 i
* i                 34.34.34.4              30    100      0 4 i
*>i144.144.144.144/32
                   24.24.24.4              20    100      0 4 i
* i                 34.34.34.4              30    100      0 4 i

R1 sees two paths, but notice that the paths with ">" are with those with lower MED. Therefore it is going to take those paths. Now, lets configure R4 so that the path R1 will take to 144.144.144.144/32 in R4 will be through R3 then clear the BGP session after.

R4(config)#access-list 33 permit 144.144.144.144 0.0.0.0
R4(config)#route-map R3SETMED30 permit 10
R4(config-route-map)#match ip address 33
R4(config-route-map)#set metric 10
R4(config-route-map)#route-map R3SETMED30 permit 20
R4(config-route-map)#match ip address 30
R4(config-route-map)#set metric 30
R4#clear ip bgp *

Now, lets see the outputs.

R2#sh ip bgp | beg Network
  Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       24.24.24.4              20             0 4 i
*> 44.44.44.44/32   24.24.24.4              20             0 4 i
*> 144.144.144.144/32
                   24.24.24.4              20             0 4 i

R3#sh ip bgp | beg Network
  Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       34.34.34.4              30             0 4 i
*> 44.44.44.44/32   34.34.34.4              30             0 4 i
*> 144.144.144.144/32
                    34.34.34.4              10             0 4 i

R1#sh ip bgp | beg Network
  Network          Next Hop            Metric LocPrf Weight Path
* i4.4.4.4/32       34.34.34.4              30    100      0 4 i
*>i                 24.24.24.4              20    100      0 4 i
* i44.44.44.44/32   34.34.34.4              30    100      0 4 i
*>i                 24.24.24.4              20    100      0 4 i
*>i144.144.144.144/32
                    34.34.34.4              10    100      0 4 i
* i                 24.24.24.4              20    100      0 4 i

We can see a change in R3 that shows a MED of 10 for 144.144.144.144/32, while R1 shows the same and will now take R3 to reach the subnet.

JNCIA-ER Finally

After the whole year of inconsistent reading and studying, I passed the JNCIA-ER exam today with a good grade. I just focused on my studies last month and I found the exam easy because its similar to the principles in CCNA. I will finally get back to focus on the CCDA/CCDP track again while preparing for my CCIE Written exam early next year. JNCIS-ER exam will be taken on the last week of November.

I have updated my certification logos at the right hand side of the blog which now contains the JNCIA-ER logo. Hopefully I will see the CCDA and CCDP logo before this year ends. Next year, I hope to see the CCIE logo displayed there. These logos serve to remind me what I have accomplished and what should I be accomplishing. How nice would it be to see 5 CCIE logos there and even 1 JNCIE logo. Call me a certification monkey but I am more like a certification chimpanzee. :)

Juniper Configuration on the Mini Labs?

I have been busy with my preparation for my Juniper JNCIA-ER exam tomorrow thats why I haven't been able to do any technical posts here. I often read an ebook and do Juniper emulator using "Olive" even at work. Doing Juniper configuration is pretty much like doing the CCNA but learning a different command language. Remember, any networking lessons and principles that applies to Cisco is pretty much the same with Juniper provided that its not vendor specific.

Something crossed my mind while I was doing the Juniper preparation. I have read many networking blogs but I haven't found anything that posts both Cisco and Juniper configs. My idea is to include one Juniper router on the Mini Labs and post Juniper basic configs here just for my reference and for those who read this blog. It's a good way to learn Juniper configs while mastering the Cisco IOS. I am not talking about very advanced Juniper configs. I rarely come across with a Juniper router here in the global network I support so including a Juniper router in the mini labs will really help with Juniper exposure.

What can you say about this? Would this be a good idea? After all, I am looking for some aspects that will make this blog different from the rest and this one I think will make it a unique one. Will this defeat the purpose of this blog? Let me know your thoughts.

For the time being, I have booked my Juniper JNCIS-ER exam on the last week of November so I have ample time to prepare (I have been reading from time to time about Juniper few months before.) My CCDA is underway too and my ARCH exam will be taken on December hopefully.

Focused Mini Labs or Mock Labs???

I can't recall where I read it but I read some posts on which is better Focused Mini Labs or Mock Labs. I can't really say one is better than the other because in my opinion, these two should be equally useful for the CCIE lab exam preparation. I believe that a person preparing for the CCIE should focus first on the mini labs and understand the topics as clearly as possible and the mock lab a few months before the exam. What I am doing in this blog is doing the labs from the basic to the possibly more advanced topics. If you notice, I rarely jump from one topic to another but instead I focus more on one routing protocol/ subject at a time and divide it into smaller topics ( I wonder when I will finish blogging about BGP :) )

To tell you the truth, I don't have Mock Labs yet from those famous CCIE training vendors for two reasons, first I don't have money to purchase one for the moment (too bad for me ;) ) secondly I don't want to get tempted to get into the Mock Labs without first completing the mini labs I am doing. Gives me the study focus I need but its just me. There are people who the mock labs first and do mini labs later, its okay we have our own unique ways of doing things ;).

Currently, I am doing Kocharian labs but the labs I post here in my blog aren't copied from there or any source. I create my own topology for my own personal understanding and explanation. I can truly say I have understood something if I can explain it clearly and that is one purpose of this blog.