Went over all my notes for Multicast on Friday 14/12/07. Good to go over this, I also listened to the 2 “Advanced Multicast” CoD from IE. This has helped me solidify my knowledge. A few notes:
ip pim sparse-mode
If you don’t see any interfaces in the OIL list for group 224.1.0.40, and you are using sparse mode, ensure that you have “ip pim auto-rp listener” enabled. If you haven’t, this will be the reason why.
I used ntp to verify the multicast solution. On the directly connected router to the multicast ntp server. Before any clients had been configured, you can see that for groups 226.6.6.6 ( I used this for the ntp multicast group) and group 224.0.1.1 (this is the multicast group that is assigned to ntp according to the RFC) that the DR is continually trying to register the groups. Because the RP hasn’t learned of any clients, it will keep sending a “Register-Stop” packet back:
(*, 226.6.6.6), 00:01:12/stopped, RP 150.1.5.5, flags: SJCF
Incoming interface: Serial0/0, RPF nbr 155.1.0.5
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:01:12/00:02:19
(155.1.146.6, 226.6.6.6), 00:00:05/00:02:59, flags: FT
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0, Registering
Outgoing interface list:
Serial0/0, Forward/Sparse, 00:00:05/00:02:59
(*, 224.0.1.1), 00:01:29/stopped, RP 150.1.5.5, flags: SJCF
Incoming interface: Serial0/0, RPF nbr 155.1.0.5
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:01:29/00:02:18
(155.1.146.6, 224.0.1.1), 00:00:14/00:02:51, flags: PFT
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0, Registering
Outgoing interface list: Null
On the RP:
(*, 226.6.6.6), 00:03:42/00:02:45, RP 150.1.5.5, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/0, Forward/Sparse, 00:03:42/00:02:45
(155.1.146.6, 226.6.6.6), 00:02:35/00:01:28, flags: P
Incoming interface: Serial0/0, RPF nbr 155.1.0.1
Outgoing interface list: Null
(*, 224.0.1.1), 00:03:58/00:03:27, RP 150.1.5.5, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/0, Forward/Sparse, 00:03:59/00:03:25
(155.1.146.6, 224.0.1.1), 00:02:44/00:01:19, flags: P
Incoming interface: Serial0/0, RPF nbr 155.1.0.1
Outgoing interface list: Null
The RP is pruning back the traffic.
On the RP once a client had requested the multicast ntp:
(*, 226.6.6.6), 00:05:56/00:03:28, RP 150.1.5.5, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:00:20/00:03:09
Serial0/0, Forward/Sparse, 00:05:56/00:03:28
(155.1.146.6, 226.6.6.6), 00:04:50/00:01:34, flags:
Incoming interface: Serial0/0, RPF nbr 155.1.0.1
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:00:21/00:03:08
If you aren’t getting any rp mappings, check the pim neighbours
If you still aren’t getting any rp mappings, check the RPF on the mapping agent address
If you are getting rp mappings but aren’t getting any traffic from the RP, check the RPF on the RP address
If traffic on the RP is being received on a NBMA interface and needs to be sent out the same interface to clients, you will need to enter the “ip pim nbma-mode”, this overrides the “split-horizon” issue.
If the Auto-RP dense groups (224.0.1.39/40) need to be sent up to a hub into a NBMA interfaace and this needs to go other spokes, the “ip pim auto-rp listenter” won’t help. This command is only used for sparse-mode traffic. To get other spokes to learn the rp mappings from the mapping agent when the mapping agent itself is a spoke, use tunnels to send the dense mode traffic over.
The easiest way to avoid these issues is to either statically configure the RP’s or simply use BSR. I used BSR in this topology and it was very straightforward to configure/verify!
Amount of time studying today – 6hrs 8 mins
Total Studying hours so far since starting this blog – 203hrs 55mins
15th December 2007
Yesterday I went over my notes for the 1st 4 labs in IEWB Vol II. It’s suprising how much you can forget within the space of a few days!! I think every week I will make time to go over the notes of the labs that I have done.
I also completed IEWB Vol III Lab 5. A couple of notes on the lab:
If you are asked to configure frame-relay over a WAN and to not use more than 1 frame-relay map command on any router simply use PPPoFR on all routers involved. On the hub use the following config to point more than 1 DLCI out of the interface:
interface Serial0/0.1 multipoint
frame-relay interface-dlci 501 ppp Virtual-Template1
frame-relay interface-dlci 502 ppp Virtual-Template1
Ensure you also configure the spoke ends with PPPoFR as well otherwise you won’t be able to ping across the WAN.
When using PPPoFR, you will NOT see any output from the show frame-relay map command
The WAN where the spokes haven’t got layer 2 reachability to one another wasn’t area 0.
This area has to be a transit area for a virtual link configuration, but the ABR for Area 0/Transit area isn’t advertising it’s RID (loopback) interface out. You cannot create a virtual link between the 2 ABR’s directly, as they are not OSPF neighbours and don’t know each others RID. What you have to do is create a virtual link from the spokes to the hub; the hub will have 2 entries for the virtual link.
2 other stupid mistakes I made. A solution called for a tunnel to be used. I configured this, but the tunnel wouldn’t come up. It took me at least 10 minutes before I found out that I had configured the same IP address on both ends of the tunnel!!! Wot a prick!!
Within the lab, dialer interfaces were used. When configuring RIPv2, i used the “passive-interface default” command and “unpassified” the interfaces I needed to run RIPv2 over. After a good 15 minutes of trying to workout why my RIP routes weren’t being exchanged, it finally dawned on me that I had “unpassified” the physical interface and not the dialer interface!! I was nearly headbutting the f&$%ing table in frustration!!!
Amount of time studying today – 7hrs 42mins
Total Studying hours so far since starting this blog – 211hrs 37mins
Filed under: IEWB Vol III Lab V, Multicast | Leave a comment »