If you have passed your CCIE Lab exam and used any of IPexpert’s training products including Self-study Material, Video on Demand, Audio on Demand, Rack Rental, or even one of our free vLecture’s and you don’t see your name on the list we want to hear from you! It doesn’t matter if you purchased the material from us or borrowed it from a friend just let us know what you thought about the material be visiting http://www.ipexpert.com/products/review or email CCIE@ipexpert.com with your Name and CCIE# and we will send you a free shirt seen below that will have your name and CCIE# in the list of Top Guns!

Print Friendly

To examine Network LSA, we will focus on area 0 and the connection between R1 and R2. As mentioned in the description of the network, this is a shared Ethernet segment, with R1 as the DR. Before we continue, let’s just quickly confirm the facts.

R1:

R1#show ipv6 ospf interface brief
Interface    PID   Area            Intf ID    Cost  State Nbrs F/C
Fa0/0        1     0               4          1     DR    1/1
Lo0          1     0               11         1     LOOP  0/0

R2:

R2#show ipv6 ospf neighbor

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
5.5.5.5           1   FULL/  -        00:00:31    10              Serial0/2/0
1.1.1.1         255   FULL/DR         00:00:33    4               GigabitEthernet0/0
6.6.6.6           1   FULL/  -        00:01:55    6               Serial0/1/0

Since R1 is the DR, it should also be the router to generate Type 2002 (Network) LSA and represent this shared network to the rest of the world. Let’s take a look. We will look into the database as seen by R5.

R5:

R5#show ipv6 ospf database network

            OSPFv3 Router with ID (5.5.5.5) (Process ID 1)

                Net Link States (Area 0)

  LS age: 1476
  Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
  LS Type: Network Links
  Link State ID: 4 (Interface ID of Designated Router)
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000007
  Checksum: 0x25C9
  Length: 32
        Attached Router: 1.1.1.1
        Attached Router: 2.2.2.2

From the output highlighted red We can indeed see that Type 2002 LSA with ID “4″ has been originated by R1. Highlighted green are the attached routers. We can see that no IPv6 prefixes are mentioned here. The reason for this is the same as it was with Type 2001. In order to optimize SPF calculations, prefixes are not carried in Type 2002, but instead in Type 2009 (Intra-Area-Prefix) LSA. Let’s take a look at that.

R5:

R5#show ipv6 ospf database prefix adv-router 1.1.1.1

            OSPFv3 Router with ID (5.5.5.5) (Process ID 1)

                Intra Area Prefix Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1755
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 0
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000009
  Checksum: 0x6420
  Length: 52
  Referenced LSA Type: 2001
  Referenced Link State ID: 0
  Referenced Advertising Router: 1.1.1.1
  Number of Prefixes: 1
  Prefix Address: 2001:DB8::1
  Prefix Length: 128, Options: LA, Metric: 0

  Routing Bit Set on this LSA
  LS age: 1755
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 4096
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000007
  Checksum: 0x8129
  Length: 44
  Referenced LSA Type: 2002
  Referenced Link State ID: 4
  Referenced Advertising Router: 1.1.1.1
  Number of Prefixes: 1
  Prefix Address: 2001:DB8:12::
  Prefix Length: 64, Options: None, Metric: 0

In the above output, again from R5, red highlight shows LSA originated by R1 that references LSA Type 2002, originated by R1 with the ID “4″. Prefixes associated with this LSA are shown with cyan highlight.

There is one important thing to notice with Type 2002 LSA in OSPFv3. The prefix for the shared segment is advertised only by the designated router and not by any other attached routers. See output from R5 below.

R5:

R5#show ipv6 ospf database prefix adv-router 1.1.1.1

            OSPFv3 Router with ID (5.5.5.5) (Process ID 1)

                Intra Area Prefix Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1034
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 0
  Advertising Router: 1.1.1.1
  LS Seq Number: 8000000A
  Checksum: 0x6221
  Length: 52
  Referenced LSA Type: 2001
  Referenced Link State ID: 0
  Referenced Advertising Router: 1.1.1.1
  Number of Prefixes: 1
  Prefix Address: 2001:DB8::1
  Prefix Length: 128, Options: LA, Metric: 0

  Routing Bit Set on this LSA
  LS age: 1034
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 4096
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000008
  Checksum: 0x7F2A
  Length: 44
  Referenced LSA Type: 2002
  Referenced Link State ID: 4
  Referenced Advertising Router: 1.1.1.1
  Number of Prefixes: 1
  Prefix Address: 2001:DB8:12::
  Prefix Length: 64, Options: None, Metric: 0

R5#show ipv6 ospf database prefix adv-router 2.2.2.2

            OSPFv3 Router with ID (5.5.5.5) (Process ID 1)

                Intra Area Prefix Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1125
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 0
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000013
  Checksum: 0xC90E
  Length: 64
  Referenced LSA Type: 2001
  Referenced Link State ID: 0
  Referenced Advertising Router: 2.2.2.2
  Number of Prefixes: 2
  Prefix Address: 2001:DB8::2
  Prefix Length: 128, Options: LA, Metric: 0
  Prefix Address: 2001:DB8:25::
  Prefix Length: 64, Options: None, Metric: 64

If we check the routing table for 2001:db8:12::/64 on R5, we get the correct metric of 65:

R5:

R5#show ipv6 route 2001:db8:12::/64
Routing entry for 2001:DB8:12::/64
  Known via "ospf 1", distance 110, metric 65, type intra area
  Route count is 1/1, share count 0
  Routing paths:
    FE80::218:19FF:FEF3:42B0, Serial0/2/0
      Last updated 05:18:41 ago

The reason for the correct metric calculation is information contained in Router LSA, which includes a reference to the shared link, with the correct metric, advertised by R2. Take a look:

R5:

R5#show ipv6 ospf database router adv-router 2.2.2.2

            OSPFv3 Router with ID (5.5.5.5) (Process ID 1)

                Router Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1293
  Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
  LS Type: Router Links
  Link State ID: 0
  Advertising Router: 2.2.2.2
  LS Seq Number: 8000001E
  Checksum: 0xABA9
  Length: 56
  Area Border Router
  AS Boundary Router
  Number of Links: 2

    Link connected to: another Router (point-to-point)
      Link Metric: 64
      Local Interface ID: 8
      Neighbor Interface ID: 10
      Neighbor Router ID: 5.5.5.5

    Link connected to: a Transit Network
      Link Metric: 1
      Local Interface ID: 2
      Neighbor (DR) Interface ID: 4
      Neighbor (DR) Router ID: 1.1.1.1

This concludes the intra-area related posts in this series. Next time, we’ll explore how routers exchange the information between areas. In other words, we’ll take a look at Inter-Area-Prefix LSA>

Happy studies!

–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List

Print Friendly

The Test Network

The test network we’ll work on is shown on the diagram below. We will be using this same network throughout this series.

We can see on the diagram that routers R1, R2 and R5 are backbone (area 0) routers, with R2 and R5 being ABRs, too. R2 is connected to R6 over Frame Relay interface in NSSA area 26 and R5 is connected to R4 in area 45 over a point-to-point serial interface. Routers R4 and R6 are also ASBRs. All routers are statically configured with OSPF Router-ID in the R.R.R.R format, where R is the router number (R1′s Router ID will be 1.1.1.1).

Here are the relevant configurations for all the routers.

R1:

interface Loopback0
 ipv6 address 2001:DB8::1/128
 ipv6 ospf 1 area 0
!
interface FastEthernet0/0
 ipv6 address 2001:DB8:12::1/64
 ipv6 ospf priority 255
 ipv6 ospf 1 area 0
!
ipv6 router ospf 1
 router-id 1.1.1.1
!

R2:

interface Loopback0
 ipv6 address 2001:DB8::2/128
 ipv6 ospf 1 area 0
!
interface GigabitEthernet0/0
 ipv6 address 2001:DB8:12::2/64
 ipv6 ospf priority 0
 ipv6 ospf 1 area 0
!
interface Serial0/1/0
 encapsulation frame-relay
 ipv6 address FE80::2 link-local
 ipv6 address 2001:DB8:26::2/64
 ipv6 ospf network point-to-multipoint
 ipv6 ospf 1 area 26
 frame-relay map ipv6 2001:DB8:26::6 206
 frame-relay map ipv6 2001:DB8:26::2 206
 frame-relay map ipv6 FE80::6 206 broadcast
 no frame-relay inverse-arp
!
interface Serial0/2/0
 ipv6 address 2001:DB8:25::2/64
 ipv6 ospf 1 area 0
!
ipv6 router ospf 1
 router-id 2.2.2.2
 area 26 nssa default-information-originate
!

R4:

interface Loopback0
 ipv6 address 2001:DB8::4/128
 ipv6 ospf 1 area 45
!
interface Loopback4
 ipv6 address 2001:DB8:4::4/64
!
interface Serial0/1/0
 ipv6 address 2001:DB8:45::4/64
 ipv6 ospf 1 area 45
!
ipv6 router ospf 1
 router-id 4.4.4.4
 redistribute connected route-map CON-to-OSPF
!
route-map CON-to-OSPF permit 10
 match interface Loopback4
!

R5:

interface Loopback0
 ipv6 address 2001:DB8::5/128
 ipv6 ospf 1 area 0
!
interface Serial0/0/0
 ipv6 address 2001:DB8:45::5/64
 ipv6 ospf 1 area 45
!
interface Serial0/2/0
 ipv6 address 2001:DB8:25::5/64
 ipv6 ospf 1 area 0
!

R6:

interface Loopback0
 ipv6 address 2001:DB8::6/128
 ipv6 ospf 1 area 26
!
interface Loopback6
 ipv6 address 2001:DB8:6::6/64
!
interface Serial0/1/0
 encapsulation frame-relay
 ipv6 address FE80::6 link-local
 ipv6 address 2001:DB8:26::6/64
 ipv6 ospf network point-to-multipoint
 ipv6 ospf 1 area 26
 frame-relay map ipv6 2001:DB8:26::2 602
 frame-relay map ipv6 2001:DB8:26::6 602
 frame-relay map ipv6 FE80::2 602 broadcast
 no frame-relay inverse-arp
!
ipv6 router ospf 1
 router-id 6.6.6.6
 area 26 nssa
 redistribute connected route-map CON-to-OSPF
!
route-map CON-to-OSPF permit 10
 match interface Loopback6
!

We’ll quickly run the verification script to ensure that everything in our network is reachable. This should work from any device in the network, but I will run the test from R6.

R6:

R6#tclsh
R6(tcl)#foreach ip {
+>(tcl)#2001:db8::1
+>(tcl)#2001:db8::2
+>(tcl)#2001:db8::4
+>(tcl)#2001:db8::5
+>(tcl)#2001:db8::6
+>(tcl)#2001:db8:12::1
+>(tcl)#2001:db8:12::2
+>(tcl)#2001:db8:25::2
+>(tcl)#2001:db8:25::5
+>(tcl)#2001:db8:45::4
+>(tcl)#2001:db8:45::5
+>(tcl)#2001:db8:26::2
+>(tcl)#2001:db8:26::6
+>(tcl)#2001:db8:4::4
+>(tcl)#2001:db8:6::6
+>(tcl)#} { ping $ip so lo0 repe 3 time 1 }

Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2001:DB8::1, timeout is 1 seconds:
Packet sent with a source address of 2001:DB8::6
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 20/20/20 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2001:DB8::2, timeout is 1 seconds:
Packet sent with a source address of 2001:DB8::6
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 20/20/20 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2001:DB8::4, timeout is 1 seconds:
Packet sent with a source address of 2001:DB8::6
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 20/21/24 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2001:DB8::5, timeout is 1 seconds:
Packet sent with a source address of 2001:DB8::6
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 20/21/24 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2001:DB8::6, timeout is 1 seconds:
Packet sent with a source address of 2001:DB8::6
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 0/1/4 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2001:DB8:12::1, timeout is 1 seconds:
Packet sent with a source address of 2001:DB8::6
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 20/20/20 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2001:DB8:12::2, timeout is 1 seconds:
Packet sent with a source address of 2001:DB8::6
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 16/18/20 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2001:DB8:25::2, timeout is 1 seconds:
Packet sent with a source address of 2001:DB8::6
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 16/18/20 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2001:DB8:25::5, timeout is 1 seconds:
Packet sent with a source address of 2001:DB8::6
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 20/21/24 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2001:DB8:45::4, timeout is 1 seconds:
Packet sent with a source address of 2001:DB8::6
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 20/21/24 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2001:DB8:45::5, timeout is 1 seconds:
Packet sent with a source address of 2001:DB8::6
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 20/20/20 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2001:DB8:26::2, timeout is 1 seconds:
Packet sent with a source address of 2001:DB8::6
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 20/20/20 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2001:DB8:26::6, timeout is 1 seconds:
Packet sent with a source address of 2001:DB8::6
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 0/1/4 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2001:DB8:4::4, timeout is 1 seconds:
Packet sent with a source address of 2001:DB8::6
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 20/21/24 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2001:DB8:6::6, timeout is 1 seconds:
Packet sent with a source address of 2001:DB8::6
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 0/0/0 ms

The network is fully functional! Let’s dive and explore the LSAs…

Router (Type 2001) LSA

Similarly to OSPFv2 used for IPv4 routing, OSPFv3 uses Router LSA to inform routers in the area about its presence and available links. However, as we’ll see, contents of this LSA are somewhat different than those in OSPFv2. For this exercise, we’ll focus on area 45 and router R4. The only reason for this is the size of the database we’ll need to look into, nothing else. So, what do we have there then? Let’s take a look.

R4:

R4#show ipv6 ospf database ?
  adv-router        Advertising Router link states
  database-summary  Summary of database
  external          External link states
  inter-area        Inter-area LSA
  internal          Internal LSA information
  link              Link link states
  network           Network link states
  nssa-external     NSSA External link states
  prefix            Prefix link states
  router            Router link states
  self-originate    Self-originated link states
  unknown           Unknown link states
  |                 Output modifiers

From the available options, we can see that command-line syntax for exploring the database is very similar, if not identical to the one in OSPFv2. Let’s see what Router LSAs we have in our R4′s database.

R4:

R4#show ipv6 ospf database router

            OSPFv3 Router with ID (4.4.4.4) (Process ID 1)

                Router Link States (Area 45)

  LS age: 1095
  Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
  LS Type: Router Links
  Link State ID: 0
  Advertising Router: 4.4.4.4
  LS Seq Number: 80000008
  Checksum: 0x90F4
  Length: 40
  AS Boundary Router
  Number of Links: 1

    Link connected to: another Router (point-to-point)
      Link Metric: 64
      Local Interface ID: 8
      Neighbor Interface ID: 6
      Neighbor Router ID: 5.5.5.5

  Routing Bit Set on this LSA
  LS age: 1163
  Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
  LS Type: Router Links
  Link State ID: 0
  Advertising Router: 5.5.5.5
  LS Seq Number: 80000005
  Checksum: 0x2B5E
  Length: 40
  Area Border Router
  Number of Links: 1

    Link connected to: another Router (point-to-point)
      Link Metric: 64
      Local Interface ID: 6
      Neighbor Interface ID: 8
      Neighbor Router ID: 4.4.4.4

Highlighted red in the output, we can see originating routers of two LSAs. One is originated by ourselves (4.4.4.4) and the other one by R5 (5.5.5.5). Please note that even though they look like IPv4 addresses, Router-IDs are not IPv4 addresses. Just as in OSPFv2, they are 32bit numbers displayed in dotted-decimal format to make them look like IPv4s. We can also observe that there are no IPv6 addresses listed anywhere in the contents of the LSA. If you recall IPv4 Type 1 format, this is a major difference. In OSPFv3, Router LSA carries only a reference to links. These references are highlighted green. The reference consists of the local interface identifier, remote interface identifier and the remote neighbor. This is where Type 0008 (Link) and Type 2009 (Intra-Area-Prefix) LSAs come into play.

Link (Type 0008) LSA

Link LSA is exchanged only between the neighbors sharing the same link (it has a link flooding scope). Here’s a quick look into this LSA, again on R4.

R4:

R4#show ipv6 ospf database link

            OSPFv3 Router with ID (4.4.4.4) (Process ID 1)

                Link (Type-8) Link States (Area 45)

  LS age: 98
  Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
  LS Type: Link-LSA (Interface: Serial0/1/0)
  Link State ID: 8 (Interface ID)
  Advertising Router: 4.4.4.4
  LS Seq Number: 80000008
  Checksum: 0xB1A4
  Length: 56
  Router Priority: 1
  Link Local Address: FE80::20A:B8FF:FE1A:5178
  Number of Prefixes: 1
  Prefix Address: 2001:DB8:45::
  Prefix Length: 64, Options: None

  LS age: 423
  Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
  LS Type: Link-LSA (Interface: Serial0/1/0)
  Link State ID: 6 (Interface ID)
  Advertising Router: 5.5.5.5
  LS Seq Number: 80000008
  Checksum: 0xBAAA
  Length: 56
  Router Priority: 1
  Link Local Address: FE80::20A:B8FF:FE19:C8F0
  Number of Prefixes: 1
  Prefix Address: 2001:DB8:45::
  Prefix Length: 64, Options: None

We can see in this output that R4′s database contains only two Type 0008 LSAs. One is originated by R4 itself and the other one by R5. Contents are very simple. The link-local address of the originating router and all IPv6 prefixes associated with this interface. Note the Link State ID, highlighted green – these are the exact same values used in the Router LSA as link references. We can now tie the two together and learn about the prefixes used on the remote router. There is a problem, however. The flooding scope of the Link LSA means that only directly connected neighbors will know about this.

What about the situation like the one we have in area 0? R1 and R5 are not directly connected, yet they can clearly communicate. This is where Intra-Area-Prefix (Type 2009) LSA comes into play.

Intra-Area-Prefix (Type 2009) LSA

Let’s examine Intra-Area-Prefix database on R4.

R4:

R4#show ipv6 ospf database prefix

            OSPFv3 Router with ID (4.4.4.4) (Process ID 1)

                Intra Area Prefix Link States (Area 45)

  Routing Bit Set on this LSA
  LS age: 8
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 0
  Advertising Router: 4.4.4.4
  LS Seq Number: 8000000A
  Checksum: 0xCDE0
  Length: 64
  Referenced LSA Type: 2001
  Referenced Link State ID: 0
  Referenced Advertising Router: 4.4.4.4
  Number of Prefixes: 2
  Prefix Address: 2001:DB8::4
  Prefix Length: 128, Options: LA, Metric: 0
  Prefix Address: 2001:DB8:45::
  Prefix Length: 64, Options: None, Metric: 64

  LS age: 392
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 0
  Advertising Router: 5.5.5.5
  LS Seq Number: 80000009
  Checksum: 0xA188
  Length: 44
  Referenced LSA Type: 2001
  Referenced Link State ID: 0
  Referenced Advertising Router: 5.5.5.5
  Number of Prefixes: 1
  Prefix Address: 2001:DB8:45::
  Prefix Length: 64, Options: None, Metric: 64

Highlighted red we can see referenced LSA. Referenced LSA can be either Type 2001, as in this case or Type 2002, which we’ll observe next time. Since Type 2001 LSA doesn’t carry any prefixes, in this LSA we’re providing the missing information. The missing information is one or more prefixes. In the case of LSA originated by R4, we have two prefixes advertised. One prefix is for the link to R5 and the other one for the Loopback0.

Conclusions

We’ve demonstrated some important differences between OSPFv2 and OSPFv3 when it comes to LSAs used to carry intra-area information. The logical question to ask at this point would be – what’s the reason for the additional LSAs? Answer may not be immediately obvious, but once exposed becomes very logical.

When a new prefix is added or removed in OSPFv2, new Router LSA needs to be sent. This in turn triggers area-wide SPF run. In OSPFv3, addition and removal of the prefix, does not trigger SPF recalculation, since this information is not carried in Type 2001, but instead in Type 2009 LSA. This is more scalable and efficient approach, than the aging OSPFv2.

Next time, we’ll look into another intra-area LSA – Network (Type 2002).

Happy studies!

–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List

Print Friendly

Most commonly used LSA types in OSPFv2 are listed in the table below, associated with the articles we published on this blog that explain them.

Here is the brief overview of the LSAs used by OSPFv3, with a very brief description.

Happy studies!

–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List

Print Friendly

Flooding I talk about is the process used by dense-mode multicast to “inform” the multicast routers about presence of multicast sources. To recap quickly, in dense-mode networks, when source begins to transmit traffic, this data will be flooded throughout the whole network and then pruned from parts where it’s not needed, i.e. where there are no clients requesting to receive this traffic. This flood-and-prune process repeats every three minutes. This is not a very optimal process, but it solves the problem of maintaining small multicast routing tables in routers and helping provide source information to all routers in the topology.

In sparse-mode networks, the idea is to keep small multicast routing tables and to avoid flood-and-prune process, whenever possible. To accomplish this goal, a meeting place in the network is required where routers with sources can register, as well where routers with clients can look for active sources. This meeting place is router designated to be rendezvous point (RP).

RP is the router that needs to know about all active sources in the network. To reach this goal, all routers that have directly attached sources must register them with the RP. This registration is, of course “PIM Register” we are going to examine today.

Unlike most of my previous posts, which were heavily hands-on oriented, this one will be a little bit different. We’re going to examine from a theoretical point of view what registration is and how it works.

To do that, we’ll enlist the help of a network that looks like the one on Figure 1 below.

As we can see on the diagram, we will use example with three routers and two other devices. Multicast source does not participate in multicast routing, i.e. it doesn’t need to run neither PIM nor IGMP. Multicast client will request traffic for a particular group using IGMP. The three multicast routers are configured to run PIM sparse-mode amongst them. All in all, this is a fairly basic IP multicast routing topology.

So, if source itself does not participate in multicast routing, how does it register its existence with the RP? The answer is simple – it doesn’t. All source needs is to be able to do is generate IP traffic with the destination IP address being in a valid IP multicast range: 224.0.0.0/4 (224.0.0.0 – 239.255.255.255). If the source doesn’t register with the RP, how does then RP know about it?

This is one the responsibilities of the first-hop router, or the router which is directly connected to the source. When a multicast source starts transmitting the traffic and this traffic reaches first-hop-router, this router will do several things. We can say these things happen “simultaneously”, but in reality they happen in sequence. It’s important to keep this in mind when troubleshooting live networks, but for the lab environment, we can treat these as simultaneous events.

1. Source (SRC) starts transmitting the traffic.
2. Multicast state (S,G) is created on FHR, where S is the source IP address of the SRC and G is the group address (destination IP address of the packets).
3. Multicast traffic is encapsulated in unicast packets and sent towards the RP.
4. Upon receiving unicast traffic and decapsulating original multicast packets, RP creates local (S,G) state

Note that there will be no multicast traffic forwarded towards the RP – it will be unicast. This unicast traffic is the source registration. The above events can be summed-up with the following picture.

At this moment, source is registered with the RP. What happens next, depends on whether RP is aware of any clients that want to receive this traffic or not. This leaves us with the following possibilities:

• Source starts sending before there are any interested receivers (clients).
• Clients join the group before source starts sending.
• There are clients directly connected to the FHR or the RP.

We’ll take a better look at these in the next couple of articles.

Happy studies!

–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List

Print Friendly

• BPDU Guard
• BPDU Filter

After reading the above two segments, we can conclude that we are not dealing with two features. Instead, we are dealing with two sets of two different features that share the same names. There are two different features called “BPDU Filter” and two different features called “BPDU Guard”. Allow me to explain in some more detail.

To do so, I will use the simple network shown on the diagram below.

All ports on the two switches except those shown on the diagram are disabled (shutdown) and below is the relevant configuration.

Cat2:

vtp mode transparent
vtp domain IPexpert
!
vlan 23
 name Cat2-Cat3
!
ip routing
!
interface FastEthernet0/2
 switchport mode access
 switchport access vlan 23
!
no interface Vlan 1
!
interface Vlan23
 ip address 192.168.23.12 255.255.255.0
 no shutdown
!

Cat3:

vtp mode transparent
vtp domain IPexpert
!
vlan 23
 name Cat2-Cat3
!
ip routing
!
interface FastEthernet0/5
 switchport mode access
 switchport access vlan 23
!
no interface Vlan 1
!
interface Vlan23
 ip address 192.168.23.13 255.255.255.0
 no shutdown
!

R2:

interface GigabitEthernet0/1
 ip address 192.168.23.2 255.255.255.0
!

R5:

interface FastEthernet0/1
 ip address 192.168.23.5 255.255.255.0
!

I’ll use these IPs just for testing of connectivity and no other purpose. Let’s see if our connection works now.

Cat2:

Cat2#ping 192.168.23.13

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.23.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms

Now we’re ready to explore the different flavors of BPDU Filter and BPDU Guard. We will start doing that by exploring another feature, which is crucial for operation of the two we will be focusing on today. This is “portfast” feature.

Portfast

We all know that a switch will process BPDU frames on every layer 2 port. We also know that spanning-tree requires port to transition through different states before it can actually send any traffic. Depending on the flavor of the spanning tree protocol in use, these states are different, but the basic idea remains. This is all done with the ultimate goal of preventing bridging loops. Regardless of the STP version, this process takes time. Sometimes there is a need to bypass these states and make the port forward traffic immediately. This can be accomplished using “portfast” feature, or enabling the “edge port” functionality in rapid spanning-tree (incidentally, using “portfast” command).

Portfast has two modes of operation. One is global, the other one is per-port configuration. Global configuration will cause access ports to start forwarding traffic immediately, unless BPDU is received on the port. If BPDU is received, port loses portfast status and reverts to normal operation, i.e. passing through all the states.

On the other hand, enabling portfast feature on the port itself is unconditional. Regardless of any BPDU being received, port will remain in portfast state. This small, but, crucial difference is important for the remainder of our analysis. We will see that history, so to speak, repeats itself.

BPDU Filter: Global

Per documentation, global BPDU Filter is configured as part of global “portfast” configuration. The purpose of BPDU Filter is to prevent the switch from sending BPDU frames on ports that are enabled with portfast. Let’s configure portfast globally and enable BPDU filter globally on Cat2. We’ll observe what happens next.

Cat2:

spanning-tree portfast default
spanning-tree portfast bpdufilter default

Cat2#show spanning-tree interface FastEthernet0/2 portfast
VLAN0023            enabled
Cat2#show spanning-tree interface FastEthernet0/20 portfast
VLAN0023            disabled

We can clearly see that port facing R2 is in portfast state, while the port facing Cat3 is not. This is perfectly to be expected. Cat3 is sending BPDU frames (remember, it’s still just a switch) and Cat2 has disabled the portfast status on the port. Since R2 is not a switch, Cat2′s port facing it is still in portfast. While this is all very interesting, it doesn’t answer the question – are BPDU frames being sent from Cat2′s ports? Let’s test that.

I am going to disable both active ports, clear spanning-tree counters, enable them and examine what happens.

interface range FastEthernet0/2 , FastEthernet0/20
 shutdown
!

Cat2#clear spanning-tree counters

Let’s re-enable the ports and check the counters.

Cat2:

interface range FastEthernet0/2 , FastEthernet0/20
 no shutdown
!

Cat2#show spanning-tree interface FastEthernet0/2 detail
 Port 4 (FastEthernet0/2) of VLAN0023 is designated forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.4.
   Designated root has priority 32791, address 0018.baf8.a200
   Designated bridge has priority 32791, address 001b.d4d3.0280
   Designated port id is 128.4, designated path cost 19
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   The port is in the portfast mode by default
   Link type is point-to-point by default
   Bpdu filter is enabled by default
   BPDU: sent 2, received 0
Cat2#show spanning-tree interface FastEthernet0/20 detail
 Port 22 (FastEthernet0/20) of VLAN0023 is root forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.22.
   Designated root has priority 32791, address 0018.baf8.a200
   Designated bridge has priority 32791, address 0018.baf8.a200
   Designated port id is 128.22, designated path cost 0
   Timers: message age 1, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   Link type is point-to-point by default
   BPDU: sent 0, received 3

Note that Cat2 reports it has sent few BPDU frames towards R2 even with BPDU Filter being enabled on all portfast ports. There is a very good reason for this behavior. Imagine two switches connected using access ports with BPDU Filter enabled globally. How would they realize they should be sending BPDU frames to each other? This setup could spell a disaster in a network, so to prevent it, switches with globally enabled BPDU Filter will send “couple of BPDU frames” when they become active in an effort to remedy this race condition.

BPDU Guard: Global

The purpose of globally configured BPDU Guard is to disable (err-disable) all portfast-enabled ports should they ever receive BPDU frames. Let’s see if it works. I will enable the feature globally (first disabling BPDU Filter) and bounce the port between Cat2 and Cat3.

Cat2:

no spanning-tree portfast bpdufilter default
spanning-tree portfast bpduguard default
interface FastEthernet0/20
 shutdown
 no shutdown
!

As soon as the port comes up, we’ll see a log message:

%SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Fa0/20 with BPDU Guard enabled. Disabling port.
%PM-4-ERR_DISABLE: bpduguard error detected on Fa0/20, putting Fa0/20 in err-disable state

It worked like a charm. There is one point I would like to make here. Even though global portfast relies on not receiving any BPDU frames, BPDU Guard will prevent the switch from receiving those frames and disable the port before it can change status. In a sense, BPDU Guard is older than portfast feature.

BPDU Filter: Port

We’ve seen in examples earlier that globally configuring BPDU Filter relies on the portfast status of the port. Behavior of the globally configured BPDU Filter is also not complete – couple of BPDU frames are still being sent when the port becomes active. In short, globally configured BPDU Filter is “conditional”. Contrary to this, BPDU Filter configured directly on the port is unconditional. It will always be active and no BPDU frames will be sent.

To test this claim we can use the existing setup on Cat2 and enable BPDU Filter on the port on Cat3. We have seen in the previous example that Cat2 disables the port when it receives BPDU frame due to BPDU Guard being enabled. if this doesn’t happen after configuring BPDu Filter on Cat3′s port, we will have our proof. Let’s try.

Cat3:

interface FastEthernet0/20
 spanning-tree bpdufilter enable
!

Let’s bounce the port on Cat2 to recover err-disable.

Cat2:

interface FastEthernet0/20
 shutdown
 no shutdown
!

Cat2#show spanning-tree interface FastEthernet0/20

Vlan                Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0023            Desg FWD 19        128.22   P2p Edge

We can see that the port is up, Cat2 considers it to be designated and an edge port. Edge port simply means that no BPDU frames are being received!

BPDU Guard: Port

Similar to BPDU Filter, globally enabled BPDU Guard is conditional. It will work only on portfast ports. If the port is not portfast, BPDU Guard will not be enabled. Simply said, this means it will not be enabled on any trunks by default. If we wish to enable BPDU Guard unconditionally on a port, we should do that on the port itself.

To test this behavior, let’s change the port between Cat2 and Cat3 to be 802.1q trunk. This will disable all BPDU Filter and BPDU Guard features on Cat2, since they are enabled globally. BPDU Filter on Cat3 will remain active, since it’s configured on the port itself.

Cat2:

interface FastEthernet0/20
 shutdown
 switchport trunk encapsulation dot1q
 switchport mode trunk
 no shutdown
!

Cat3:

interface FastEthernet0/20
 shutdown
 switchport trunk encapsulation dot1q
 switchport mode trunk
 no shutdown
!

Cat2:

Cat2#show spanning-tree interface FastEthernet 0/20

Vlan                Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0001            Desg LRN 19        128.22   P2p
VLAN0023            Desg LRN 19        128.22   P2p 

We can see that port is no longer considered Edge and it’s definitely not portfast, since it’s going through the learning state.

We should be seeing similar behavior on Cat3.

Cat3:

Cat3#show spanning-tree interface FastEthernet0/20

Vlan                Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0001            Desg FWD 19        128.22   P2p
VLAN0023            Desg FWD 19        128.22   P2p 

Now, let’s configure BPDU Guard on FastEthernet0/20 on Cat3 and see what happens.

Cat3:

interface FastEthernet0/20
 spanning-tree bpduguard enable
!

It will soon become obvious that absolutely nothing changes! The port is still operational. Remember, we still have BPDU Filter enabled on it:

Cat3:

Cat3#show running-config interface FastEthernet0/20
Building configuration...

Current configuration : 211 bytes
!
interface FastEthernet0/20
 switchport access vlan 23
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
 spanning-tree bpdufilter enable
 spanning-tree bpduguard enable
end

Cat3#show spanning-tree interface FastEthernet0/20 detail
 Port 22 (FastEthernet0/20) of VLAN0001 is designated forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.22.
   Designated root has priority 32769, address 0018.baf8.a200
   Designated bridge has priority 32769, address 0018.baf8.a200
   Designated port id is 128.22, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   Link type is point-to-point by default
   Bpdu guard is enabled
   Bpdu filter is enabled
   BPDU: sent 0, received 0

 Port 22 (FastEthernet0/20) of VLAN0023 is designated forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.22.
   Designated root has priority 32791, address 0018.baf8.a200
   Designated bridge has priority 32791, address 0018.baf8.a200
   Designated port id is 128.22, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   Link type is point-to-point by default
   Bpdu guard is enabled
   Bpdu filter is enabled
   BPDU: sent 0, received 0

The important conclusion we should make here is that BPDU Filter configured locally on the port takes precedence, or as I like to say is older, than BPDU Guard. We can clearly see that switch doesn’t send nor receive any BPDU frames. Let’s now remove BPDu Filter and see what happens.

Cat3:

interface FastEthernet0/20
 no spanning-tree bpdufilter enable
!

Sure enough, as soon as I did that, familiar log message showed up.

%SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Fa0/20 with BPDU Guard enabled. Disabling port.
%PM-4-ERR_DISABLE: bpduguard error detected on Fa0/20, putting Fa0/20 in err-disable state

Conclusions

In the CCIE lab attention to detail is of extreme importance. Not understanding the difference between features and how they behave depending how they have been configured can be a costly mistake. Hopefully this article cleared up some of the misconceptions I heard and read about these Cisco features in Catalyst switches.

Happy studies!

This post has been edited on January 22^nd 2011 to correct minor errors and provide additional clarification of the initial test configuration.

–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List

Print Friendly

There were two things that were on everyone’s mind before “Networkers” started. Will there be a new CCIE track announced (CCIE Data Center) and the overdue blueprint change for CCIE Service Provider. We waited in anticipation for both of these, alas… nothing came out from Cisco. But, there were a lot of technical sessions, marketing presentations and very open and frank conversations with Cisco people that helped us understand what future holds. Without further ado, here we go.

CCIE Routing and Switching

Blueprint is currently in version 4.0 and it is likely to remain like that for at least the next six months. However, that doesn’t mean there are not going to be changes and tweaks. Just to quote one of the people from the program who told me “we are bringing routing to routing and switching”. What that means is that there is going to be more emphasis on the core subjects, like IGP and BGP, as well as interaction (redistribution) between protocols. Another thing that is coming is more in-depth and more relevant troubleshooting tickets. As you will see with some of the other tracks, troubleshooting is becoming a major component of the CCIE exam and students going for the exam must absolutely be ready for it!

What does more distant future for R&S hold? Since troubleshooting is 100% in virtual environment, we believe it’s only a matter of time (perhaps within next 2-3 years) that R&S lab will be 100% virtualized, or at least hybrid of virtual and real equipment, allowing Cisco to create more modular and dynamic lab content. The team of engineers within Cisco responsible for CCIE R&S is very capable and eager to keep this track as the most important and relevant IT certification and they are doing a pretty good job at it!

Summary:

• No pending blueprint update.
• More in-depth troubleshooting
• More focus on “core routing topics”
• More virtualization in the distant future

IPexpert’s Summary:

• Changes mentioned are very well covered by our CCIE R&S Blended Learning Solution
• Minor content update may be forthcoming to include more troubleshooting exercises

CCIE Voice

There were no changes to the blueprint announced (thankfully!). All software versions will remain at 7.0 and are likely to remain at this release for a couple of years. It is worth pointing out that Cisco are well aware of the fact that there are several “bugs/undocumented features” that can be expected with any “.0” release. However candidates are expected to provide workarounds where applicable.

As most of you know, the Core Knowledge questions were removed some time in May 2010 and were replaced with troubleshooting tasks. The speaker repeatedly brought attention to the types of troubleshooting tasks candidates can expect. We have tried to summarize some of the most important points raised below.

• There is no dedicated troubleshooting section for the time being- troubleshooting is embedded into the configuration tasks of the exam. This is subject to change- in other words they may look at providing a dedicated troubleshooting section at some point in the future.
• Troubleshooting tasks account for approximately 15% of the points on the CCIE Voice Lab exam.
• Candidates will have to troubleshoot existing configuration which has built-in errors. More details of example errors are given below.
• Infrastructure tasks will for the most part be complete and will not be the responsibility of the candidate. However configuration might not be 100% correct!
• Going forward phones will be pre-configured into the UCM database. It was mentioned that SIP endpoints have not been tested thus far but candidates should expect SIP endpoints in the lab in the very near future. Interestingly it is the intention to have phones pre-registered with the correct firmware in advance- that means candidates will not be responsible for changing the firmware of the phone. This will come as a relief to many of you since this process is time-consuming.
• Troubleshooting tasks could potentially include in depth knowledge of the protocols used for establishing call setup. Detailed knowledge of the call flow involved in protocols such as SIP/MGCP/H323/SCCP/Q931/etc will be required in order to explain why certain calls to the “provider” are failing. It was mentioned that the candidate may not even have to fix the problem and instead create a text file with the relevant traces/debugs and a suitable explanation. A process not too dissimilar when you create a TAC case.
• Cisco will continuously modify the content of the lab and this includes changing the number of UCM and UCME sites. You can expect 3 UCM sites, 3 UCME sites or anything in between!
• Gatekeeper/CUBE/SIP Trunk tasks will be added to the lab at some point in the near future (if not already!). The PSTN provider in the lab may not necessarily be a T1/E1 connection but rather a H323 or SIP ITSP.
• Security related tasks (authentication and encryption of signaling and media) are not going to be tested since these tasks are too difficult to maintain and implement. However the CCIE Voice Written test which will be updated later this year will cover those topics.
• The Voice CCIE pass rate is currently between 20% and 25% but expect that figure to drop as the impending lab updates will no doubt increase the difficulty of the test.

Overall we were very pleased with the outcome of the discussion- no major updates for a couple of years will come as a huge relief to all training vendors. The IPexpert BLS and bootcamps have for more than a year now been covering SIP Phones, CUBE, multiple UCME sites and detailed knowledge of the protocols involved in call set up. The biggest takeaway from the session was undoubtedly troubleshooting is going to be the singular most important skill candidates will need to pass the lab – if you are going to pass the CCIE Voice going forward you need to focus on the why and not only the how as has been the case in the past.

CCIE Security

This seems to be the least exciting track as far as news go. The content is stable, there are no immediate pending blueprint changes and content updates.

IPexpert’s Summary:

• No pending product updates, based on changes.

CCIE Service Provider

Let me get this out of the way, first. There was no new Service Provider blueprint announced. However, it is ready and will be announced very, very shortly. Blueprint and content are ready, what is pending are hardware upgrades for lab locations. We can expect it to happen at any moment. So, what are the forthcoming changes, then?

IOS XR is making the appearance. It is not a rumor, it is not a speculation, it is going to be there. The major focus area is on IP and MPLS, still, but there will be also a focus on service provider approach to IPv6 and interaction between IOS and IOS XR. We can expect any number of routers running IOS and IOS XR in the new lab, where there will be a mix of IOS and IOS XR devices in the “core” and the same at the edges. CE routers will remain strictly IOS.

Also, there will be troubleshooting on the exam, but it is still not 100% certain whether that includes a dedicated troubleshooting section, or preconfigured faults in the configuration section. For this, we need to wait the official announcement. Everyone afraid of pending changes, should aim to proceed with their lab preparations. If you are not concerned (and really, there is no need to be), keep to your schedule, as planned.

Summary:

• Blueprint change is imminent.
• IOS XR and IOS will be tested.
• IPv6 will be tested.
• Troubleshooting will be a component.

IPexpert’s Summary:

• We are, like everyone else, waiting for blueprint update.

CCIE Service Provider Operations

This track was a mystery for me before going to Cisco Live! What is the idea behind it? Well, after talking to relevant people at Cisco, I actually like this track and I’m likely to go for it in the future. So, let’s see…

CCIE SP Ops is the track that focuses strictly on NOC personell. Cisco sees this as one the fastest growing CCIE tracks in the future, in fact. There is heavy focus on troubleshooting and processes in this exam. In fact, two sections of the lab reflect this. The lab will be split in two parts. The first part is dedicated troubleshooting section, which will include complex problems involving both IOS and IOS XR devices. The second section is scenario-based test, focusing on processes (ITIL) and high-level problem troubleshooting and escalation.

Since this exam is still not available to general public, it remains to be seen what will happen here.

Summary:

• Heavy focus on troubleshooting complex IOS and IOS XR issues.
• Heavy focus on processes and process frameworks (ITIL).

IPexpert’s Summary:

• At this point, we do not have immdiate plans to provide training for this track.

CCIE Wireless

Petentially, one of the most interesting tracks in the future. Fast growing market and ever evolving technology. Cisco understands this and CCIE Wireless is in good hands within Cisco in that respect. So, what’s going on with the exam? First of all, there will be some changes in the next couple of months, but no immediate blueprint change – which will happen within 9-12 months, though. The biggest change that is going to happen soon is that Cisco is “quietly” going to remove Location appliance from the exam. The reason for that is that it’s end-of-life and Cisco wants to replace it with something more relevant. The more relevant thing is Mobilite Services Engine. However, that will require major software changes on the rest of the equipment in the lab and requires blueprint change, which they are not ready for at this moment.

One thing was very much stressed out during the technical session on CCIE Wireless – candidates must understand routing and switching in order to complete the lab successfully! It’s is not as deep as in R&S track, but it is definitely covered on the exam. Students must know how to configure basic spanning-tree, IGP routing and redistribution to be successful. According to Cisco, this is one of the biggest hurdles candidates experience in the exam.

Summary:

• No pending blueprint change.
• Minor content upgrade – Location appliance will be removed.
• Basic switching, unicast and multicast routing configuration.

IPexpert’s Summary:

• Stay tuned for pending product announcements for this track. We will be updating our website this month to reflect the following products:
• CCIE Wireless racks
• Self-study Workbooks (Volume 1 and 2) with Detailed Solution Guides
• A Video on Demand Boot Camp
• A Live 5-Day Instructor Led Class

CCIE Storage

We all expected to see CCIE Data Center announced this year. However, it was not, nor is it planned for immediate future. That being said, Cisco engineers involved in the program informally refer to the Storage track as the CCIE Data Center. Also, they are investigating the future possibility of creating more comprehensive Data Center CCIE, but it’s in the early planning stages as of right now.

However, there are important bullet points that we should mention here for the people who are preparing for this track. First of all, focus of the exam is only on Cisco equipment and devices. Carefully examine the list of devices mentioned in the blueprint and focus the studes on this equimpent.

The world of data centers is fast evolving, which makes it very difficult to create a “stable blueprint” and CCIE program managers are waiting for the product range and technology to stabilise, before they introduce major changes. There are probably going to be blueprint updates in the next 6-12 months, but no major changes will happen overnight.

Summary:

• No pending blueprint update.
• Fast-changing and evolving technology that will only grow in the future.
• Strict focus on Cisco equipment in the exam.

IPexpert’s Summary:

• Stay tuned…Although we currently have several CCIE Storage Racks and Tyson Scott (IPexpert’s x3 CCIE is working on this track, currently) we’re going to wait until the Data Center is announced before we pursue any products in this space.

Overall Summary

It has been a great week for IPexpert and everyone who attended Cisco Live! We met with great people, our former, current and future students. We enjoyed the excellence of Cisco’s technical presentations, immersed ourselves in deep technical discussion with our peers and had the great opportunity to socialize with like-minded network engineers, both from Cisco and elsewhere.

See you all in classes and next year at Cisco Live! 2011 in the CCIE lounge – where you all need to be with fellow CCIEs!

Regards – The IPexpert team

Print Friendly

We promised last week that we will deliver our Core Knowledge / Open Ended Questions preparation material for all tracks we support before April 1^st 2010. We wouldn’t be IPexpert if we didn’t deliver on our promises!

We are pleased to announce the Availability of IPexpert’s Core Knowledge Quiz and Answer Key for Routing and Switching, Voice, Security and Service Provider CCIE tracks!

Customers of our our Blended Learning Solutions, Workbooks or other training material and courses will find these new products added to their student accounts. Everyone else, please get in touch with your Training Advisor to get your copy!

Also, please, take few moments to register for one of our “Ask the Expert” and “vLecture” online training sessions! You can find online registration forms on our website. Just click on the track of your choice and go to “Free Online CCIE Training” link.

Oh and one more thing…

As you know, we announced last week a great new deal for new purchases of BLS – 400 hours of rack time. If you are not already a BLS student, this is a deal you don’t want to miss out on!

For those who already own the BLS, we have “Buy 1 Get 1 Free” going again on our Proctor Labs vRack time. So, if you are getting low, make sure you contact a Training Advisor to take advantage!

–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List

Print Friendly

First of all, in order to qualify, students need to undergo the authorized 360 “workshop” (be sure to recognize that it’s 2 weeks of training and quite a bit more expensive than some of the other options out there) and, as usual, waiver requests need to be approved by the instructor from the workshop. The waiver is then submitted to Cisco for approval and approved or disapproved without clear indication of success of that request. The program is temporary and begins on April 1^st 2010… just as another waiver program (that seems to have failed) is about to end.

The IPexpert team is determined to provide our students with the best possible training material available on the market. For that reason, we pledge right here and right now, that we will have the best preparation material on the market for the Core Knowledge section of the lab exams… by the time this program goes live. Yes, by April 1^st of this year. All IPexpert clients will have access to an OEQ / Core Knowledge eBook (we will be delivering eBooks for the R&S, Voice, Security and Service Provider labs).

Combine that with our current products and offerings:

• World-class Video on Demand (with supplemental Student Slide & Topology Books)
• World-class Audio on Demand (lecture different than VOD)
• World-class ILT Training (Week 1)
• World-class OWLE Training (Week 2)
• World-class Workbooks (and accompanying Detailed Solution Guides)
• World-class Workbook Video Walkthroughs (Hundreds of hours of video solutions)
• World-class Rack Rental at ProctorLabs (Latest & greatest hardware, online, with an unmatched GUI)
• World-class Online Community at OnlineStudyList.com (free online mentoring avenues)
• World-class Technical Support for all issues
• The largest alumni of successful CCIE students overall

In addition to all of the above (current offerings and upcoming FREE Core Knowledge eBook), we are shortly going to introduce two additions to our family of products in all tracks. We call them “vLectures” and “Ask the Expert Sessions”.

vLectures will be 2-4 hour long, live online lectures, delivered by one or more of our instructors on a given subject through our online classroom. These sessions will also be recorded and posted to our student accounts.

Ask the Expert sessions will be 2-4 long online sessions with one or more of our instructors and will focus on either a specific technology or a given lab from our Workbooks. Students attending the sessions will interact with the instructors, ask the questions and gain invaluable expertise. These will, also, be recorded and posted to student accounts.

Oh and one more thing…

These three new products … are going to be FREE for all our current BLS customers in all tracks. No need to qualify or pay premium.

Do our students need OEQ waivers? We think not. Here at IPexpert, we deliver on our promise to make you experts – with no shortcuts. We don’t think you need to “purchase” the ability to pass or “waive” the OEQ portion of your lab (by paying upwards of x2 or x3 as much for less training, less support and less proven success).

Good idea by the 360 team, or an act of desperation to salvage a failing program? You make the call…

Regards,

- Wayne A. Lawson II (CCIE #5244) – Founder & President, IPexpert, Inc.

Print Friendly