Archive
INE 10 day bootcamp – Review
I’m back from London and it’s been a great experience. Many readers are interested in what
the bootcamp is like. It is a big investment to go for so it is understandable that you
want to know if it will be worth it. I’ll start by describing the teacher and his teaching
methods.
Brian Dennis is a well known and respected man in the network industry. He is CCIE #2210
and has 5x CCIEs. That is among the very best in the world. Brian is not one of those
academic guys that only knows what is written in a book. He as a solid background in the
industry which means he can explain WHY things are the way they are and not just stating
facts without any reasoning behind it. There will be NO powerpoints, it is CLI only and
although he has a topology he is using the configurations are not prebuilt. He will do
them live which means there will be issues, which is GOOD. You get to see a 5x CCIE
troubleshooting and since he hasn’t prepared the faults before you will see how he would
troubleshoot a live problem which is very good practice for the TS lab in the CCIE lab.
Brian is a strong believer in that there are no tips and tricks. If you have an
instructor teaching you all these tips and tricks then that instructor is a fake.
If you know the technology there are no tips and tricks. Sure he can teach you some
useful commands but there are no tips and tricks in routing protocols.
Jeremy Brown is the bootcamp coordinator. He’s a very nice guy and he will help you
with any queries you have about the bootcamp. If you are attending you will be
talking to him for sure.
When you start the class the first day you will be handed a folder with paper and
a pen and some contact information. Brian will introduce himself and give some
general guidelines and explain how the real lab works with TS section and
configuration section etc. Then everyone gets to introduce themselves. My class
had a lot of nationalities, Bolivia, France, Venezuela, Sweden, UK, Ireland,
Norway, Hungary were all represented.
The bootcamp runs from 9 AM in the morning to about 19-20 PM in the evening.
There will be some 15 minute breaks and a lunch break for 1.5h. It is long
days indeed so make sure to get enough sleep in the evening. This is a pure
learning experience, leave the partying for another time. If you want to
have some fun there will be time in the weekend for that.
The first day is about layer two. Since the configuration is built from
scratch it makes sense to start out with layer two. The topology used
is based on Cisco 360 with 5 routers and 4 switches. The routers are ISR
routers and the switches are 3560′s. It is good that this topology is
used since that is very similar to what is being used in the real lab.
When attending the bootcamp you are expected to have a good knowledge
of protocols and that you have watched the INE ATC videos. This is so
that you don’t get overwhelmed by the information in the bootcamp.
The layer two section focused on MST, PPP and frame relay and
spanning tree features like BPDU guard, BPDU filter etc. One advice
that Brian gave is to try to mix in things like PPP, PPPoE, PPPoFR
etc in your labs so that you get used to using these technologies.
Later in the week we moved on to IGPs. OSPF will be the main topic.
This is natural since OSPF will guaranteed be in your lab and you
REALLY need to know OSPF to pass the lab. Brian is an OSPF
machine, he knows the LSDB like the back of his hand. He is very
methodical and will confirm each step and show you in the LSDB
what we are seeing and why we are seeing it. He’s not one of
those guys that clears the routing table when he runs into a
glitch, he will explain how and why it is there. He had a very
good section about the forwarding address, this is an important
part of OSPF and Brian explained why it is used. He had a very
good analogy with BGP where basically if the FA is not set then
you are using next-hop-self and if it is set then the next-hop
is preserved. He also had a good explanation of the capability
transit feature and he did some great diagrams showing which
LSAs go where. This is basic knowledge but he put it so well in
that diagram. We also talked about virtual links and things like
that. One good command he showed was the show ip ospf rib
command. EIGRP and RIP will be shorter sections, he will only
show some more advanced configuration since these protocols are
a bit simpler to understand. For EIGRP he showed hot do do
unequal cost load balancing and how to calculate the metric
if you want to get a certain ratio. He showed how to do
offset-list, leak maps and authentication.
After we were done with IGPs we moved on to route redistribution.
This topic alone is enough to provide a good bootcamp experience.
Brian will in detail explain the difference between control plane
and data plane loops and why loops can occur. The important thing
to remember is that we are trying to protect the routes with a
high AD from being learned in a protocol with a lower AD. Usually
RIP is involved or EIGRP external routes since those have a high
AD. Brian will show you how to take any INE Vol2 lab topology
diagram and just look at it and identify potential issues.
This is a very good practice and when you can look at a diagram
and know what to do without even thinking about configuration
yet then you are in a good place. Brian will with his diagrams
show you where every command lives like the OSPF LSDB, OSPF RIB,
RIB, FIB etc. This is very good practice to make sure you have
a full understanding of what is going on.
BGP is of course an important topic and Brian is covering that
for sure. Brian starts by describing peering and goes through
some common misconceptions. BGP has no authentication,
wait for it…TCP has, this is a common misconception. It is
TCP providing the authentication of packets and not BGP.
He will explain concepts like hot potato vs cold potato routing.
He will show you the difference between disable-connected-check and
ebgp-multihop. He will teach you about route reflectors and
confederations and why you want to use the one or the other.
He will also explain MED in detail, something I found very useful,
explaining how deterministic MED works and always-compare-med.
He has such knowledge of everything and one thing I didn’t know
before is that networks in the BGP table are sorted by age where
the youngest network is listed first.
Building on BGP means MPLS comes naturally. These go hand in
hand and for the v4 CCIE lab you need to know MPLS. Brian
will of course explain the use of RD and RT. Remember that RD
only has a use in BGP. He shows where all the commands and
routes live and how to do troubleshooting for MPLS. The good
thing is that you will run into things that you didn’t maybe
think about and that will provide great troubleshooting. OSPF
is the most complicated PE-CE protocol and he will give you all
the details how to use Domain-ID, sham links and how the
external route tag and DN bit works.
First week is over. Time for some recovery. Have some fun and
go for some sightseeing or just do labs, the choice is yours.
Just make sure that you are well rested for when monday comes.
The second week started out with multicast. This was maybe my
favourite topic and I learned a lot from this section.
As I mentioned earlier Brian doesn’t believe in tips and tricks
and multicast is one of those topics where people have a lack
of understanding and that is why they go looking for tricks.
Multicast is 90% about PIM, you need to know PIM if you want
to be good with multicast. Brian shows common errors like having
a broken SPT or RPF failures and things like that. These usually
occur when hub and spoke frame relay is involved. With just a
few commands you can become very good with analyzing multicast.
Show ip pim interface, show ip pim neighbor,
show ip rpf x.x.x.x and show ip pim rp mapping will give you most
of the information you will need. The best thing about the
multicast section was that when we ran into errors Brian was very
methodical, instead of just pinging over and over he showed us
what was wrong and then cleared the mroute table, this will
make the mtree build again so that you always go back to a
well known state. It is probably common to have the correct
configuration but move away from it due to lack of patience
or lack of understanding of what is really going on.
Time for the killer topic, probably the most hated topic in
the entire blueprint for most candidates. You guessed it, it is
time for PfR. Where does this hate come from? Well it comes
from the fact that the 12.4 implementation of PfR is just so
incredibly bad. If I were to select one topic that is difficult
to study on your own and that you can really benefit from going
to a bootcamp then that would be PfR. Brian starts out with some
basic topologies and then moves on to some more advanced scenarios.
This topic runs for one day or even a bit more. You WILL run into
a lot of issues due to the implementation of PfR in 12.4. If you
have seen the PfR Vseminar then this will be a lot like that
with the added benefit that you can ask Brian questions of course.
The next big topic is QoS. Brian goes through frame relay
traffic shaping using both legacy syntax and MQC. He will go
through how to use policing and shaping. The coolest thing
about this part was how we configured values for policing
like Bc and then Brian showed by sending ICMP packets how the
token buckets are really working. You might be in for some
surprises here! No powerpoints here for sure! He will explain
the difference between single rate and dual rate policers and
why you would configure them for which scenarios. Then he will
go through the Catalyst QoS. This is a confusing section for
many since the Catalyst QoS is a bit convoluted. Brian shows
how the L2 QoS is very similar to MQC but the syntax is just
a bit strange. He shows how to use the priority queue and how
to use the share and shape queues for the SRR queues.
Whatever time is left will be spent on topics like EEM and
services that you would like to go through. If you feel that
you are weak in some service then this would be a good time to
ask Brian to go through it. I left the bootcamp at 3 PM on
friday and I probably missed a couple of hours in the end.
If you can find a later flight or go home on saturday that
could be a good option.
So now you have gone through a wall of text and you are
whondering what I think about it? Well if it wasn’t obvious
from my text then Yes! Go for it! Yes it costs to go and
with everything to account for like living expense and hotel,
yes it is costly. However if you look just at the price for the
bootcamp which is around 5990$. That is actually a good price,
if you consider that you can get 1500$ paid for your lab then
the cost is actually 4500$ Where I live one week of training
at Global Knowledge is usually around 3000$ for a week and
then often you get some Power Point guy reading slides or you
doing labs while the instructor is watching. The one thing I
found best about the bootcamp was that you learn how to think
at a higher level. Being a CCIE is not about knowing a lot of
commands, it is about thinking at a high level. You get to pick
the brain of a 5x CCIE with real world experience, you won’t
find many guys like that in the world and from what I’ve seen
I would rank Brian among the very best of them. The IGP, Multicast,
Redistribution, PfR sections were very good and you will learn a lot
for sure even if you were strong in these areas before.
Hopefully in class you will meet some new friends. I met some
people people in class I had only seen online before and also made
some new friends. I had a great time with David Rothera, Gian Paolo,
Jose Leitao, Susana and Harald. I also met Darren
for the first time, we have known each other online for a while now
but never met. I also had the chance to meet Patrick Barnes which is
another of my online friends
I’ve tried to cover as much as I can remember but always feel free
to ask questions in the comments section if you have anything you are
still thinking about.
More on SSM
As you’ve noticed I’ve been studying SSM and what better way to learn than to blog about it. I recently got a Safari subscription which has been great so far. I’ve been reading some in the book Interdomain Multicast Routing: Practical Juniper Networks and Cisco Systems Solutions which has been great so far.
We are still using the same topology and now we will look a bit more in detail what is happening.
R1 will be the source, sending traffic from its loopback. R3 will be the client running IGMPv3 on its upstream interface to R2. As explained in previous post I am doing this to simulate an end host otherwise I would configure it on R3 downstream interface and then it would sen a PIM Join upstream.
To run SSM we need IGMPv3 or use some form of mapping as described in previous post. It is important to note though that IGMPv3 is not specific for SSM. With SSM a (S,G) pair is described as a channel. Instead of join/leave it is now called subscribe and unsubscribe.
So the first thing that happens is that the client (computer or STB) sends IGMPv3 membership report to the destination IP 224.0.0.22. This is the IP used for IGMPv3. This is how the packet looks in Wireshark.
The destination IP is 224.0.0.22 which corresponds to the multicast MAC 01-00-5E-00-00-16. 16 in hex is 22 in decimal.
We clearly see that it is version 3 and the type is Membership Report 0×22. Number of group records show how many groups are being joined.
Then the actual group record is shown (225.0.0.1) and the type is Allow New Sources. The number of sources is 1. And then we see the channel (S,G) that is joined.
Then R2 sends a PIM Join towards the source.
We can see that it is a (S,G) join. The SPT is built.
R2 will send general IGMPv3 queries to see if there are still any receivers connected to the LAN segment.
The query is sent to all multicast hosts (224.0.0.1) and if still receiving the multicast the host will reply with a report.
The type is Membership Query (0×11). The Max Response Time is 10 seconds which is the time that the host has to reply within.
We can see in this report that the record type is Mode is include (1) compared to Allow New Sources when the first report was sent.
Now R3 unsubscribes to the channel and the IGMP report is used once again.
The type is now Block Old Sources (6).
After this has been sent the IGMP querier (router) has to make sure that there are no other subscribers to the channel so it sends out a channel specific query.
If noone responds to this the router will send a PIM Prune upstream as can be seen here.
Finally. How can we see which router is the IGMP querier? Use the show ip igmp interface command.
R2#show ip igmp interface fa0/0
FastEthernet0/0 is up, line protocol is up
Internet address is 23.23.23.2/24
IGMP is enabled on interface
Current IGMP host version is 3
Current IGMP router version is 3
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query count is 2
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 2 joins, 1 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 23.23.23.2 (this system)
IGMP querying router is 23.23.23.2 (this system)
Multicast groups joined by this system (number of users):
224.0.1.40(1)
We can see some interesting things here. We can see which router is the designated router and IGMP querier. By default the IGMP querier is the router with the lowest IP and the DR is the one with highest IP. DR can be affected by chancing the DR priority. We can also see which timers are used for query interval and max response time among other timers.
So by now you should have a good grasp of SSM. It does not have a lot of moving parts which is nice.
Multicast – SSM mapping
This is a followup post to the first one on SSM. The topology is still the same.
If you want to find it in the documentation it is found in the IGMP configuration guide
I guess the reason to place it under IGMP is that SSM requires IGMPv3. To find SSM mapping go to Products-> Cisco IOS and NX-OS Software-> Cisco IOS-> Cisco IOS Software Release 12.4 Family-> Cisco IOS Software Releases 12.4T-> Configure-> Configuration Guides-> IP Multicast Configuration Guide Library, Cisco IOS Release 12.4T-> IP Multicast: IGMP Configuration Guide, Cisco IOS Release 12.4T-> SSM mapping
So why would we use SSM mapping in the first place? IGMPv3 is not supported everywhere yet. Maybe the Set Top Box (STB) is not supporting IGMPv3 but your ISP wants to support SSM. Then some transition mechanism must be used. There are a few options available like IGMPv3 lite, URD and SSM mapping. IGMPv3 lite is daemon running on the host supporting a subset of IGMPv3 until proper IGMPv3 has been implemented. With URD a router intercepts the URL requests from the user and the router joins the multicast stream to the correct source even though the user is not sending IGMPv3 reports. This requires that the multicast group and source is coded into the web page with links to the multicast streams.
SSM mapping takes IGMPv2 reports and convert them to IGMPv3. We can either use a DNS server and query it for sources or use static mappings as I will explain here. Static mapping is done on the Last Hop Router (LHR) and it is fairly simple. This is how we configure it.
R2(config)#access-list 2 permit 225.0.0.100 R2(config)#ip igmp ssm-map enable R2(config)#ip igmp ssm-map static 2 1.1.1.1 R2(config)#no ip igmp ssm-map query dns
The config is pretty self explanatory. First we create an access-list that defines the groups to be used for SSM mapping. Then we enable SSM mapping. Then we tie together the ACL with the sources that are allowed to send to those groups. Now we need to verify the mapping. First we take a look at R2 with show ip igmp ssm-mapping.
R2#show ip igmp ssm-mapping SSM Mapping : Enabled DNS Lookup : Disabled Mcast domain : in-addr.arpa Name servers : 255.255.255.255
Looks good so far. We will use R3 to simulate a client joining to 225.0.0.100 via IGMPv2. We will debug IGMP to see the report coming in. R3 will join the group via the igmp join-group command. One thing is important to note here. Usually we configure ip igmp-join group on downstream interface to simulate LAN segment and then PIM Join is sent upstream. In this case we want only IGMP join to be sent so therefore we configure the igmp join-group on the upstream interface. Also no PIM should be enabled. This makes the router act as a pure host and not do any multicast routing. What would happen otherwise is that the router will have RPF failures when the source is sending traffic because for traffic not in SSM mode a RPF lookup is done against the RP. Since no RP is configured the RPF would fail, as a workaround we can configure a static RP even though it isn’t really used it would make the RPF check pass.
R3(config)int fa0/0 R3(config-if)#ip igmp join-group 225.0.0.100
This is the debug output from R3.
IGMP(0): Send v2 Report for 225.0.0.100 on FastEthernet0/0
We can clearly see that IGMPv2 report was sent. Now we go to R2 to see if it is converting the IGMPv2 join to IGMPv3.
IGMP(0): Received v2 Report on FastEthernet0/0 from 23.23.23.3 for 225.0.0.100 IGMP(0): Convert IGMPv2 report (*, 225.0.0.100) to IGMPv3 with 1 source(s) using STATIC
It is clear that the conversion is taking place. We look in the MRIB as well.
R2#
sh ip mroute | be \(
(*, 224.0.1.40), 03:18:48/00:02:54, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 03:18:48/00:02:54
Serial0/0, Forward/Sparse, 03:18:48/00:02:44
(1.1.1.1, 225.0.0.100), 03:18:26/00:02:57, flags: sTI
Incoming interface: Serial0/0, RPF nbr 12.12.12.1
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 03:18:26/00:02:57
We see that we now have (S,G) joins in R2! As a final step we will also verify in R1.
sh ip mroute | be \(
(*, 224.0.1.40), 03:20:44/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/1, Forward/Sparse, 03:20:44/00:00:49
(*, 225.0.0.100), 03:20:43/stopped, RP 0.0.0.0, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(1.1.1.1, 225.0.0.100), 00:01:01/00:02:28, flags: T
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/0, Forward/Sparse, 00:01:01/00:03:27
Now the ping should be successful.
R1#ping Protocol [ip]: Target IP address: 225.0.0.100 Repeat count [1]: 5 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Interface [All]: serial0/0 Time to live [255]: Source address: 1.1.1.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 225.0.0.100, timeout is 2 seconds: Packet sent with a source address of 1.1.1.1 Reply to request 0 from 23.23.23.3, 16 ms Reply to request 1 from 23.23.23.3, 16 ms Reply to request 2 from 23.23.23.3, 16 ms Reply to request 3 from 23.23.23.3, 16 ms Reply to request 4 from 23.23.23.3, 16 ms
So the important thing here is to make R3 act as a pure host otherwise it will not work. This is a bit overkill for verification but I just wanted to show how it could be done.
Source Specific Multicast (SSM) and IGMP filtering
Regular multicast is known as Any Source Multicast (ASM). It is based on a many to many
model where the source can be anyone and only the group is known. For some applications
like stock trading exchange this is a good choice but for IPTV usage it makes more
sense to use SSM as it will scale better when there is no need for a RP.
ASM builds a shared tree (RPT) from the receiver to the RP and a
Shortest Path Tree (SPT) from the sender to the RP. Everything must pass through the RP
until switching over to the SPT building a tree directly from receiver to sender.
The RPT uses a (*,G) entry and the SPT uses a (S,G) entry in the MRIB.
SSM uses no RP, instead it uses IGMP version 3 to signal what channel (source) it wants
to join for a group. IGMPv3 can use INCLUDE messages that specify that only these
sources are allowed or they can use EXCLUDE to allow all sources except for these ones.
SSM has the IP range 232.0.0.0/8 allocated and it is the default range in IOS but we can
also use SSM for other IP ranges. If we do we need to specify that with an ACL.
SSM can be enabled on all routers that should work in SSM mode but it is only
really needed on the routers that have receivers connected since that is the place
where the behavior is really changed. Instead of sending a (*,G) join to the RP
the Last Hop Router (LHR) sends a (S,G) join directly to the source.
This is the topology we are using.
It is really simple. R1 is acting as a multicast source and R2 will both simulate a client
and do filtering. R3 will simulate an end host. R1 will source the traffic from its loopback.
OSPF has been enabled on all relevant interfaces.
We will start by enabling SSM for the range 225.0.0.0/24 on R2.
R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#access-list 1 permit 225.0.0.0 0.0.0.255 R2(config)#ip pim ssm range 1
R2 will now use SSM behavior for the 225.0.0.0/24 range. R2 will join the group 225.0.0.1.
We will debug IGMP and PIM to follow everything that happens. When using igmp join-group
on an interface the router simulates IGMP report coming in on that interface. We will see
later why this is important. So first we enable debugging to the buffer.
Also we must enable multicast routing and enable PIM sparse-mode on the relevant interfaces.
R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#ip multicast-routing R1(config)#int s0/0 R1(config-if)#ip pim sparse-mode R1(config-if)#do debug ip pim PIM debugging is on R1(config-if)#
R2(config)#ip multicast-routing R2(config)#int s0/0 R2(config-if)#ip pim sparse-mode R2(config-if)#int f0/0 R2(config-if)#ip pim sparse-mode R2(config-if)#ip igmp version 3 R2(config-if)# *Mar 1 00:18:37.595: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 23.23.23.2 on interface FastEthernet0/0 R2(config-if)#do debug ip igmp IGMP debugging is on R2(config-if)#do debug ip pim PIM debugging is on
Then we join the group on the Fa0/0 interface and look at what happens.
R2(config)#int f0/0 R2(config-if)#ip igmp join-group 225.0.0.1 source 1.1.1.1
We take a look at the log.
IGMP(0): Received v3 Report for 1 group on FastEthernet0/0 from 23.23.23.2 IGMP(0): Received Group record for group 225.0.0.1, mode 5 from 23.23.23.2 for 1 sources IGMP(0): Updating expiration time on (1.1.1.1,225.0.0.1) to 180 secs IGMP(0): Setting source flags 4 on (1.1.1.1,225.0.0.1) IGMP(0): MRT Add/Update FastEthernet0/0 for (1.1.1.1,225.0.0.1) by 0 PIM(0): Insert (1.1.1.1,225.0.0.1) join in nbr 12.12.12.1's queue IGMP(0): MRT Add/Update FastEthernet0/0 for (1.1.1.1,225.0.0.1) by 4 PIM(0): Building Join/Prune packet for nbr 12.12.12.1 PIM(0): Adding v2 (1.1.1.1/32, 225.0.0.1), S-bit Join PIM(0): Send v2 join/prune to 12.12.12.1 (Serial0/0) IGMP(0): Building v3 Report on FastEthernet0/0 IGMP(0): Add Group Record for 225.0.0.1, type 5 IGMP(0): Add Source Record 1.1.1.1 IGMP(0): Add Group Record for 225.0.0.1, type 6
R2 is receiving an IGMP report (created by itself) and then it generates a PIM join and
sends it to R1. We look how R1 is receiving it.
PIM(0): Received v2 Join/Prune on Serial0/0 from 12.12.12.2, to us PIM(0): Join-list: (1.1.1.1/32, 225.0.0.1), S-bit set PIM(0): RPF Lookup failed for 1.1.1.1 PIM(0): Add Serial0/0/12.12.12.2 to (1.1.1.1, 225.0.0.1), Forward state, by PIM SG Join
Then we verify by looking at the mroute table and by pinging.
R1#sh ip mroute 225.0.0.1 | be \(
(*, 225.0.0.1), 00:09:42/stopped, RP 0.0.0.0, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(1.1.1.1, 225.0.0.1), 00:01:49/00:01:40, flags: T
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/0, Forward/Sparse, 00:01:49/00:02:39
Now we do a regular ping which should fail since we are not sourcing traffic from the loopback.
R1#ping 225.0.0.1 re 3 Type escape sequence to abort. Sending 3, 100-byte ICMP Echos to 225.0.0.1, timeout is 2 seconds: ...
This is expected and what is good about SSM is that it makes sending to groups from any
source more difficult which is good from a security perspective.
Now we do an extended ping and source from the loopback.
R1#ping Protocol [ip]: Target IP address: 225.0.0.1 Repeat count [1]: 5 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Interface [All]: serial0/0 Time to live [255]: Source address: 1.1.1.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 225.0.0.1, timeout is 2 seconds: Packet sent with a source address of 1.1.1.1 Reply to request 0 from 12.12.12.2, 52 ms Reply to request 1 from 12.12.12.2, 48 ms Reply to request 2 from 12.12.12.2, 48 ms Reply to request 3 from 12.12.12.2, 36 ms Reply to request 4 from 12.12.12.2, 40 ms
So our SSM is working and we didn’t even have to enable it on R1! What if we have
clients not supporting IGMPv3? Then we could do SSM mapping. I could do that in
another post if there is interest for it. For now lets look at filtering. If we
were using ASM then we use a standard ACL and match which multicast groups are
allowed to send joins for. The joins would be (*,G) which is the same as
host 0.0.0.0 in an ACL.
To filter SSM we use an extended ACL where the source in the extended ACL
is the multicast source and the destination is which group to match. We will
create an ACL permitting 1.1.1.1 as source for the groups 225.0.0.1, 225.0.0.2
and 225.0.0.3. Anything else will be denied which we will see by debugging IGMP.
When we are doing filtering it is important to rembember that the IGMP report
generated by the router itself (igmp join-group) will also be subject to the ACL
so make sure to include that.
R2(config)#ip access-list extended IGMP_FILTER R2(config-ext-nacl)#permit igmp host 1.1.1.1 host 225.0.0.1 R2(config-ext-nacl)#permit igmp host 1.1.1.1 host 225.0.0.2 R2(config-ext-nacl)#permit igmp host 1.1.1.1 host 225.0.0.3 R2(config-ext-nacl)#deny igmp any any R2(config-ext-nacl)#int f0/0 R2(config-if)#ip igmp access-group IGMP_FILTER
Now we make R3 join a group not allowed and look at the debug output on R2.
R3(config)#int f0/0 R3(config-if)#ip igmp version 3 R3(config-if)#ip igmp join-group 225.0.0.10 source 1.1.1.1
This is from the log on R2.
IGMP(0): Received v3 Report for 1 group on FastEthernet0/0 from 23.23.23.3
IGMP(*): Source: 1.1.1.1, Group 225.0.0.10 access denied on FastEthernet0/0
R2#sh ip access-lists IGMP_FILTER
Extended IP access list IGMP_FILTER
10 permit igmp host 1.1.1.1 host 225.0.0.1 (6 matches)
20 permit igmp host 1.1.1.1 host 225.0.0.2
30 permit igmp host 1.1.1.1 host 225.0.0.3
40 deny igmp any any (7 matches)
As we can see that group is not allowed so the IGMP join will not make it through.
SSM can be very useful and it is not difficult to setup. In fact it is mostly
easier than ASM to setup.
Followup on multicast helper map
I had some requests for the final configs so I have fixed those. You can download them here. Also I had some issues getting the traffic through but thanks to my helpful readers like zumzum I now have it figured out.
Lets start on R4 since this is the source of the traffic.
R4 wants to send traffic to 1.1.1.1 with a source of 155.1.12.4. We know that route via RIP and the next-hop is 155.1.12.1. That network is directly connected (secondary). We need to find out the MAC address of 155.1.12.1 for our ARP entry. R3 has proxy arp enabled, which is the default. However it will not respond to R4 ARP request since it does not have the subnet 155.1.12.0/24 connected. R4 must therefore have a static ARP entry. I did an error here earlier by typing in R1 MAC but this should be the MAC of R3 Fa0/0 since that is the link connecting us. We create the static ARP with arp 155.1.12.1 xxxx.xxxx.xxxx arpa. R4 now has all the info needed.
Packet travels to R3. R3 does not have a route for 1.1.1.1. We create a static route, ip route 1.1.1.0 255.255.255.0 155.1.23.2. We also need a static route back to R4 for the 155.1.12.4 IP. Ip route 155.1.12.4 255.255.255.0 155.1.34.4.
Packet now travels to R2. R2 also needs to know about 1.1.1.1 so we add a route there as well. Ip route 1.1.1.0 255.255.255.0 155.1.12.1. R2 also needs to find its way back to R4 so we add a static route, ip route 155.1.12.4 255.255.255.255 155.1.23.2.
Packet goes to R1 which will respond. It will send the packet out Fa0/0. R1 needs to know the MAC address for 155.1.12.4. R2 has proxy ARP enabled so it will reply with its own MAC address to R1. R1 will insert this into ARP cache and adjacency table and then we are good to go.
So except learning a multicast feature we also got to practice how to make connectivitiy in an unusual way and think through the whole process of packet flow.
Multicast helper map and how to verify multicast
The multicast helper map is an interesting feature. It can be used in scenarios where we want to transport broadcast. Routers don’t forward broadcast by default but we can convert this to multicast and transport it across our network and then convert it back to broadcast. Might not be that common in real life if you don’t work at a stock exchange but is fair game for the lab and a topic that we should not be surprised to see at the lab.
So the basic idea is to convert broadcast packets, transport them as multicast and then convert it back to broadcast. First lets look at our topology.
The idea here is to take broadcast coming from R1 in on R2 Fa0/0, convert it to multicast. Transport it to R3 which then converts it back to broadcast and sends it out to R4. Using this technology we can actually exchange routes between non adjacent routers, pretty cool?
You can download a .net file and initial configs for the routers here.
This is our assigned task:
Create a Loopback99 interface on R1 and assign it an IP address of 1.1.1.1/24; advertise this network on R1 using RIP v1 via FastEthernet0/0.
Configure R4 to receive the RIP advertisements from R1. You must use a multicast solution for this. In other words you may not configure solutions involving tunnel interfaces, enable RIP elsewhere than R1 and R4, use bridging, IPsec, magic, etc.
· Use PIM dense mode only.
· You may use a secondary IP address of 155.12.1.4/24 as part of your solution.
· Use access list 120 for any lists you need.
· You do not need to be able to ping 1.1.1.1 from R4
· Use the multicast group 224.9.9.9
So we start by configuring R1. RIP version 1 is broadcast only and it does not include the subnet mask. All we need to do on R1 is configure RIP. We simply announce the network and leave the default settings which is to announce with version 1 and receive version 1 or 2. All the magic will happen on R2 and R3.
Then we proceed to configure R2. This is where most of the magic happens. We need to enable PIM dense mode on both Fa0/0 and S0/0. To be able to process switch the UDP RIP packets coming in we need to configure ip forward-protocol udp rip. Then we will configure the multicast helper map. Lets have a look.
So broadcast coming in on Fa0/0 matching access-list 120 is converted to multicast with a destination of 224.9.9.9. We are running PIM dense mode so later we should be able to see (S,G) entries in the mroute table.
We proceed to configure R3. The config will be very similar to R2.
On R3 we convert back 224.9.9.9 to the broadcast address of the segment between R3 and R4. We need to turn on directed broadcast otherwise we will not be allowed to send this packet out.
On R4 we simply turn on RIP. We were allowed to create a second subnet but lets wait with that.
So now everything should be running. However, we will have some issues. I am not running any IGP between R2 and R3. R3 will not know how to reach the source 155.1.12.1 so we will have a RPF failure which you can see below.
We can also see this if we check the mroute counters.
So how can we fix the RPF failure? We have a few different options. Either we need to run an IGP between R2 and R3 or we could add a static route or we could add a static mroute. This time I chose to use a static mroute because it is easy. Lets add that.
Now the traffic should be reaching R4. However the RIP rout will not be installed. This is because RIP validates the update source. If we receive an update from a non locally connected source the update will not be accepted. We can configure RIP to not validate the update source or we can configure a secondary IP address in same subnet as the source (we were allowed to do this according to the task).
Now we have the route installed. What will the multicast routing table look like? Lets look at R2 and R3. Since we are running dense mode we should only have (S,G) entries.
R2 has the (S,G) entry as expected. It has a flag of T since it is a SPT tree. We don’t have an incoming RPF neighbor since R1 is not running PIM.
Now we will look at R3.
We have R2 as the incoming RPF neighbor. RPF is done via static mroute. We have no outgoing interface. This is usually bad but since we are converting back to broadcast this is OK. If we do a debug of mpacket we will see an error message that OIL is null.
We have completed our task and if this was the lab we would stop here. To take it to the next step lets think what we would need to be able to have reachability from R4 to R1 loopback.
As we can see route recursion fails since we don’t know how to reach 155.1.12.1. Earlier we used a hack to not validate the update source. Lets remove this and add the secondary subnet to R4 instead.
Now the route recursion is working. R4 is using outgoing interface Fa0/0. This is Ethernet so we need to encapsulate the packet and send it to R1 MAC address. Usually we would send ARP request but the devices are not locally connected. Lets try adding a static ARP entry.
Traffic should be able to reach R3. R3 will not know how to reach 1.1.1.1 though. I’ll add static routes on R3 and R2.
Finally I’ll also add a static ARP entry on R1.
Now lets try a ping. It didn’t work. No matter how I try by adding static ARP entries and the correct routes I could not get the ping to succeed. I even tried on R4 to source traffic from 155.1.12.4 but that did not work either. I could see the traffic leaving R4 but not entering on R3. Very strange. If you have any suggestions post them in the comments section.
Common misconceptions about the ip mroute command
Almost all of us know the difference between a static route and a dynamic one, longer match wins. If same length then AD decides and so on.
I have noticed that there are some misconceptions about the equivalent to ip route in multicast, the ip mroute command. One would assume that it works the same way as ip route but it does not.
First, when we are talking about multicast it is pretty much the opposite of regular routing since we care about the source of the packet instead of the destination. In multicast we check that incoming packets are coming in on the interface we would use to send traffic back to the source, the RPF check. It’s basically the same check that can be used for security reasons to avoid spoofing.
Sometimes we have assymmetric routing meaning that the source send traffic in on an interface we are not using to send traffic back to the source. This means we will have a RPF failure and traffic will be dropped. We can solve this by reconfiguring IGP or putting in a static mroute.
So many people think, “Oh I’ll just put in a mroute and traffic MAY come in that interface as well”. The error here is that mroute tells that traffic MUST come in on that interface. So it might not be the quick fix you thought it would be. Another common error is that you put a broad mask or a default route like 0.0.0.0 0.0.0.0. In regular routing anything with a longer match would override the static default but with the mroute the default route takes precedence over IGP routes. The reason is that the AD is lower and the longest match does not apply here. So maybe you just had problems with one source before and now you have problems with all sources except for that one which you just fixed.
If you put several mroute statements in then longest match will apply since the AD will be the same. The easiest way of checking what interface is the RPF interface for a source is to use the show ip rpf command. This command will show what is the RPF interface and where the information was sourced from (IGP or static).
I hope this post has cleared some of the common misconceptions of the static mroute.
Flash cards – multicast added
Added some multicast content to the flash deck. There is now a total of 151 questions in the deck. The next section that will be added when I have finished the labs is MPLS VPN. As usual, the deck is here.
Troubleshooting multicast – RPF failure
In unicast routing we are interested in how to forward packets to their destination. In multicast routing we are interested where the source came from, multicast packets need to pass a RPF (Reverse Path Forwarding) check. Packets that are received on an interface are checked that the route back to the source is through the same interface, otherwise the RPF check will fail. RPF check failing is one of the most common errors in multicast networks. Lets look at the topology.
The goal of the scenario is that R6 should be able to ping SW4 which has joined multicast group 224.10.10.10. PIM dense mode has been enabled on R6 -> R4, between R4 and R5 PIM is only enabled on the frame-relay connection. PIM is enabled between R5 -> SW2 and SW2 -> SW4. Dense mode is being used. This is configuration from SW4.
Rack11SW4#sh run int vlan 10
Building configuration…
Current configuration : 96 bytes
!
interface Vlan10
ip address 155.11.10.10 255.255.255.0
ip igmp join-group 224.10.10.10
end
Ping from R6 to SW4.
Rack11R6#ping 224.10.10.10 re 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds:
…
Not successful, lets look at what multicast packets are being sent. We need to disable fast switching on the interface to see any packets.
Rack11R5(config)#int s0/0/0
Rack11R5(config-if)#no ip mroute-cache
Rack11R5(config-if)#^Z
Rack11R5#debug ip mpacket
IP multicast packets debugging is on
Rack11R5#
Feb 15 10:30:53.727: IP(0): s=155.11.146.6 (Serial0/0/0) d=224.10.10.10 id=93, ttl=253, prot=1, len=104
(100), RPF lookup failed for source
Feb 15 10:30:53.727: IP(0): s=155.11.146.6 (Serial0/0/0) d=224.10.10.10 id=93, ttl=253, prot=1, len=104
(100), not RPF interface
Rack11R5#
Feb 15 10:30:55.723: IP(0): s=155.11.146.6 (Serial0/0/0) d=224.10.10.10 id=94, ttl=253, prot=1, len=104
(100), not RPF interface
Rack11R5#
Feb 15 10:30:57.723: IP(0): s=155.11.146.6 (Serial0/0/0) d=224.10.10.10 id=95, ttl=253, prot=1, len=104
(100), not RPF interface
Packets are not coming in on the RPF interface. Lets look at the multicast routing table.
Rack11R5#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,
V – RD & Vector, v – Vector
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.10.10.10), 00:03:41/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:03:41/00:00:00
Serial0/0/0, Forward/Dense, 00:03:41/00:00:00
(155.11.146.6, 224.10.10.10), 00:00:02/00:02:57, flags:
Incoming interface: Null, RPF nbr 155.11.45.4
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:00:02/00:00:00
Serial0/0/0, Forward/Dense, 00:00:02/00:00:00
(*, 224.0.1.40), 00:39:35/00:02:54, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:38:30/00:00:00
Serial0/0/0, Forward/Dense, 00:14:20/00:00:00
We are interested in the (155.11.146.6, 224.10.10.10) which is a dense mode group. Our RPF neighbor is 155.11.45.4 which is the address of R4 on the S0/1/0 interface which is not enabled for PIM. How do we reach 155.11.146.6?
Rack11R5#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,
V – RD & Vector, v – Vector
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.10.10.10), 00:03:41/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:03:41/00:00:00
Serial0/0/0, Forward/Dense, 00:03:41/00:00:00
(155.11.146.6, 224.10.10.10), 00:00:02/00:02:57, flags:
Incoming interface: Null, RPF nbr 155.11.45.4
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:00:02/00:00:00
Serial0/0/0, Forward/Dense, 00:00:02/00:00:00
(*, 224.0.1.40), 00:39:35/00:02:54, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:38:30/00:00:00
Serial0/0/0, Forward/Dense, 00:14:20/00:00:00
Rack11R5#sh ip route 155.11.146.6
Routing entry for 155.11.146.0/24
Known via “eigrp 100″, distance 90, metric 2172416, type internal
Redistributing via eigrp 100, ospf 1
Advertised by ospf 1 subnets
Last update from 155.11.45.4 on Serial0/1/0, 00:55:04 ago
Routing Descriptor Blocks:
* 155.11.45.4, from 155.11.45.4, 00:55:04 ago, via Serial0/1/0
Route metric is 2172416, traffic share count is 1
Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Traffic to R6 is sent over the S0/1/0 interface which is not enabled for PIM, this is a problem…How can we pass the RPF check? By adding a static mroute we can enable the frame-relay interface to be a valid RPF interface.
Rack11R5(config)#ip mroute 155.11.146.6 255.255.255.255 155.11.0.4
The ping should now be successful.
Rack11R6#ping 224.10.10.10 re 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds:
Reply to request 0 from 155.11.108.10, 52 ms
Reply to request 1 from 155.11.108.10, 44 ms
Reply to request 2 from 155.11.108.10, 44 ms
Traffic is flowing, one final look at the mroute table.
Rack11R5#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,
V – RD & Vector, v – Vector
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.10.10.10), 00:06:53/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:06:53/00:00:00
Serial0/0/0, Forward/Dense, 00:06:53/00:00:00
(155.11.146.6, 224.10.10.10), 00:03:14/00:02:35, flags: T
Incoming interface: Serial0/0/0, RPF nbr 155.11.0.4, Mroute
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:03:14/00:00:00
(*, 224.0.1.40), 00:42:47/00:02:47, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:41:42/00:00:00
Serial0/0/0, Forward/Dense, 00:17:32/00:00:00
The RPF neighbor is now 155.11.0.4 which is the next-hop over frame-relay. When doing multicast we need to think more about traffic patterns and ensuring that interfaces that are in the multicast transit path should be PIM enabled or not be used for multicast traffic.
























