Booting a Brocade Netiron XMR/MLX card into interactive mode

Yesterday I had to replace a 2X 10Gb module in one of my XMRs. The card itself was running a lower version of code than the box itself. At first I could see the LC loading of the software, but after that the card was not able to boot.

I tried loading the software onto the card again, but the box says the card needs to be either UP or in Interactive mode. You’re stuck in a bit of a catch-22 here where you can’t load anything unless the card is in interactive mode.

First you need to figure out which module it is you want to boot. This is easy as line card 1 = 1 and so on. For this example I’m using module 3.

XMR-4000#conf t
XMR-4000(config)#lp boot system interactive 3 
XMR-4000(config)#end

This tells the box to boot the card in interactive mode. You will now need to actually reboot the module:

XMR-4000#power-off lp 3
XMR-4000#power-on lp 3
Slot 3 is powering on.


SYSLOG: <13>Jan 11 10:02:11 XMR-4000 System: Module 3 powered on 
Slot 3: booted to Interactive Mode.

We’ve been told that the card has been booted into interactive mode, but let’s confirm anyway:

XMR-4000#sh module | include S3
S3: NI-XMR-1Gx20-GC 20-port 10/100/1000 Copper Module       CARD_STATE_INTERACTIVE

Now that the card is in interactive mode we can load the software on. In this particular example I’m loading 5.4b so change the filenames for your version

XMR-4000#copy tftp lp 192.168.1.80 xmlb05400.bin monitor 3

XMR-4000#copy tftp lp 192.168.1.80 xmlprm05400.bin boot 3

XMR-4000#copy tftp lp 192.168.1.80 lpfpga05400b.bin fpga-all 3

Once the software is loaded, we need to configure the box to not boot the card into interactive mode:

XMR-4000#conf t
XMR-4000(config)#no lp boot system interactive 3
XMR-4000(config)#end

Finally let’s reboot the card again:

XMR-4000#power-off lp 3
XMR-4000#power-on lp 3

Slot 3 is powering on.


SYSLOG: <13>Jan 11 10:07:12 XMR-4000 System: Module 3 powered on

We should be good to go now:

XMR-4000#sh module | include S3
S3: NI-XMR-1Gx20-GC 20-port 10/100/1000 Copper Module       CARD_STATE_UP

JNCIE-SP Topology #2

I wanted to put together a topology for my JNCIE-SP studies. This may evolve over time as I want to practice new things.

I only have a single tunnel PIC so it’s going to be tricky getting certain things like multicast to work. Let’s see how far I get though.

I’ve got my physical M10 connected to a Cisco 3750G like so:

You’ll notice that the logical topology is extremely similar to the JNCIE-M study guide by Harry Reynolds. I’ve made a few changes here and there, mainly I’m only using ethernet and aggregated ethernet interfaces. I’ll probably expand on this topology in the future with some route-injectors and vm’s acting as hosts. Maybe as I’m not sure if I need them yet.

Click on the image for the full topology as I can’t fit it on the page:

T1, C2, and P1 routers are going to be regular IOS routers as they aren’t doing anything special. If I need to I will add another virtual system for these routers.

This is the config I have used:

set system login class C1-superuser logical-system C1
set system login class C1-superuser permissions all
set system login class DC1-superuser logical-system DC1
set system login class DC1-superuser permissions all
set system login class R1-superuer logical-system R1
set system login class R1-superuer permissions all
set system login class R2-superuer logical-system R2
set system login class R2-superuer permissions all
set system login class R3-superuer logical-system R3
set system login class R3-superuer permissions all
set system login class R4-superuer logical-system R4
set system login class R4-superuer permissions all
set system login class R5-superuer logical-system R5
set system login class R5-superuer permissions all
set system login class R6-superuer logical-system R6
set system login class R6-superuer permissions all
set system login class R7-superuer logical-system R7
set system login class R7-superuer permissions all
set system login user USER1 uid 2001
set system login user USER1 class R1-superuer
set system login user USER1 authentication encrypted-password "$1$lDtkDsHm$eelHGn4WRtFRWoMDOOnJe."
set system login user USER2 uid 2003
set system login user USER2 class R2-superuer
set system login user USER2 authentication encrypted-password "$1$mu8Qv22V$0UNQfvQhofE3U3QcGCvA/1"
set system login user USER3 uid 2004
set system login user USER3 class R3-superuer
set system login user USER3 authentication encrypted-password "$1$..yI5/3y$55Jve0qo3ExZ9fly0RC800"
set system login user USER4 uid 2005
set system login user USER4 class R4-superuer
set system login user USER4 authentication encrypted-password "$1$1bGZut11$/t/kOHd1TOF4RsIC35iKi1"
set system login user USER5 uid 2006
set system login user USER5 class R5-superuer
set system login user USER5 authentication encrypted-password "$1$DORTDfVE$iIQg5wjxlMIbs1or8UH1d."
set system login user USER6 uid 2007
set system login user USER6 class R6-superuer
set system login user USER6 authentication encrypted-password "$1$dru6DbTm$cW/mkb5KKaJoxJnkRZhRk/"
set system login user USER7 uid 2008
set system login user USER7 class R7-superuer
set system login user USER7 authentication encrypted-password "$1$BD5mwm9a$5LdFlrfjdJd0rteIbfDUH1"
set system login user USERC1 uid 2009
set system login user USERC1 class C1-superuser
set system login user USERC1 authentication encrypted-password "$1$xZdBRvek$aFPGNhmNr7gLlSchowTbs/"
set system login user USERDC1 uid 2010
set system login user USERDC1 class DC1-superuser
set system login user USERDC1 authentication encrypted-password "$1$ymRQYukx$FlrTexvuIj364FPk2V/Vo/"
set system services ftp
set system services ssh
set system syslog user * any emergency
set system syslog file messages any notice
set system syslog file messages authorization info
set system syslog file interactive-commands interactive-commands any
set logical-systems C1 interfaces fe-0/0/3 unit 117 vlan-id 117
set logical-systems C1 interfaces fe-0/0/3 unit 117 family inet address 172.16.0.2/30
set logical-systems C1 interfaces fe-1/0/3 unit 114 vlan-id 114
set logical-systems C1 interfaces fe-1/0/3 unit 114 family inet address 172.16.0.6/30
set logical-systems C1 protocols ospf area 0.0.0.0 interface all
set logical-systems DC1 interfaces fe-1/0/3 unit 106 vlan-id 106
set logical-systems DC1 interfaces fe-1/0/3 unit 106 family inet address 10.0.8.1/30
set logical-systems DC1 interfaces fe-1/0/3 unit 107 vlan-id 107
set logical-systems DC1 interfaces fe-1/0/3 unit 107 family inet address 10.0.8.13/30
set logical-systems R2 interfaces fe-0/0/3 unit 12 vlan-id 12
set logical-systems R2 interfaces fe-0/0/3 unit 12 family inet address 10.0.4.6/30
set logical-systems R2 interfaces fe-0/0/3 unit 24 vlan-id 24
set logical-systems R2 interfaces fe-0/0/3 unit 24 family inet address 10.0.4.10/30
set logical-systems R2 interfaces fe-1/0/3 unit 112 vlan-id 112
set logical-systems R2 interfaces fe-1/0/3 unit 112 family inet address 10.0.5.2/24
set logical-systems R2 interfaces ae0 unit 23 vlan-id 23
set logical-systems R2 interfaces ae0 unit 23 family inet address 10.0.4.2/30
set logical-systems R3 interfaces fe-0/0/3 unit 36 vlan-id 36
set logical-systems R3 interfaces fe-0/0/3 unit 36 family inet address 10.0.2.14/30
set logical-systems R3 interfaces fe-0/0/3 unit 103 vlan-id 103
set logical-systems R3 interfaces fe-0/0/3 unit 103 family inet address 172.16.0.13/30
set logical-systems R3 interfaces fe-1/0/3 unit 13 vlan-id 13
set logical-systems R3 interfaces fe-1/0/3 unit 13 family inet address 10.0.4.13/30
set logical-systems R3 interfaces fe-1/0/3 unit 34 vlan-id 34
set logical-systems R3 interfaces fe-1/0/3 unit 34 family inet address 10.0.2.5/30
set logical-systems R3 interfaces ae0 unit 35 vlan-id 35
set logical-systems R3 interfaces ae0 unit 35 family inet address 10.0.2.2/30
set logical-systems R3 interfaces ae1 unit 23 vlan-id 23
set logical-systems R3 interfaces ae1 unit 23 family inet address 10.0.4.1/30
set logical-systems R4 interfaces fe-0/0/3 unit 34 vlan-id 34
set logical-systems R4 interfaces fe-0/0/3 unit 34 family inet address 10.0.2.6/30
set logical-systems R4 interfaces fe-0/0/3 unit 114 vlan-id 114
set logical-systems R4 interfaces fe-0/0/3 unit 114 family inet address 172.16.0.5/30
set logical-systems R4 interfaces fe-1/0/3 unit 24 vlan-id 24
set logical-systems R4 interfaces fe-1/0/3 unit 24 family inet address 10.0.4.9/30
set logical-systems R4 interfaces ae0 unit 45 vlan-id 45
set logical-systems R4 interfaces ae0 unit 45 family inet address 10.0.8.10/30
set logical-systems R4 interfaces ae0 unit 47 vlan-id 47
set logical-systems R4 interfaces ae0 unit 47 family inet address 10.0.2.18/30
set logical-systems R4 interfaces ae1 unit 14 vlan-id 14
set logical-systems R4 interfaces ae1 unit 14 family inet address 10.0.4.17/30
set logical-systems R5 interfaces ae0 unit 56 vlan-id 56
set logical-systems R5 interfaces ae0 unit 56 family inet address 10.0.8.6/30
set logical-systems R5 interfaces ae0 unit 57 vlan-id 57
set logical-systems R5 interfaces ae0 unit 57 family inet address 10.0.8.10/30
set logical-systems R5 interfaces ae1 unit 35 vlan-id 35
set logical-systems R5 interfaces ae1 unit 35 family inet address 10.0.2.1/30
set logical-systems R5 interfaces ae1 unit 45 vlan-id 45
set logical-systems R5 interfaces ae1 unit 45 family inet address 10.0.8.9/30
set logical-systems R6 interfaces fe-0/0/3 unit 106 vlan-id 106
set logical-systems R6 interfaces fe-0/0/3 unit 106 family inet address 10.0.8.2/30
set logical-systems R6 interfaces fe-0/0/3 unit 206 vlan-id 206
set logical-systems R6 interfaces fe-0/0/3 unit 206 family inet address 172.16.0.9/30
set logical-systems R6 interfaces fe-1/0/3 unit 36 vlan-id 36
set logical-systems R6 interfaces fe-1/0/3 unit 36 family inet address 10.0.2.13/30
set logical-systems R6 interfaces ae1 unit 56 vlan-id 56
set logical-systems R6 interfaces ae1 unit 56 family inet address 10.0.8.5/30
set logical-systems R7 interfaces fe-0/0/3 unit 107 vlan-id 107
set logical-systems R7 interfaces fe-0/0/3 unit 107 family inet address 10.0.8.14/30
set logical-systems R7 interfaces fe-1/0/3 unit 117 vlan-id 117
set logical-systems R7 interfaces fe-1/0/3 unit 117 family inet address 172.16.0.1/30
set logical-systems R7 interfaces ae1 unit 47 vlan-id 47
set logical-systems R7 interfaces ae1 unit 47 family inet address 10.0.2.17/30
set logical-systems R7 interfaces ae1 unit 57 vlan-id 57
set logical-systems R7 interfaces ae1 unit 57 family inet address 10.0.8.10/30
set chassis aggregated-devices ethernet device-count 15
set interfaces fe-0/0/0 fastether-options 802.3ad ae1
set interfaces fe-0/0/1 fastether-options 802.3ad ae1
set interfaces fe-0/0/3 vlan-tagging
set interfaces fe-0/0/3 unit 13 vlan-id 13
set interfaces fe-0/0/3 unit 13 family inet address 10.0.4.14/30
set interfaces fe-0/0/3 unit 112 vlan-id 112
set interfaces fe-0/0/3 unit 112 family inet address 10.0.5.1/24
set interfaces fe-1/0/0 fastether-options 802.3ad ae0
set interfaces fe-1/0/1 fastether-options 802.3ad ae0
set interfaces fe-1/0/3 vlan-tagging
set interfaces fe-1/0/3 unit 12 vlan-id 12
set interfaces fe-1/0/3 unit 12 family inet address 10.0.4.5/30
set interfaces ae0 vlan-tagging
set interfaces ae0 unit 14 vlan-id 14
set interfaces ae0 unit 14 family inet address 10.0.4.18/30
set interfaces ae1 vlan-tagging
set interfaces fxp0 unit 0 family inet address 192.168.254.8/31
set routing-options static route x.x.x.x/32 next-hop 192.168.254.9

Note that the user passwords are all passw0rd and the root password is junip3r

The 3750G config is pretty simple:

vlan 12-14,23-24,34-36,45,47,56-57,103,106-107,112,114,117,206
!
interface Port-channel1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
!
interface Port-channel2
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
!
interface FastEthernet1/0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
 channel-group 1 mode on
!
interface FastEthernet1/0/2
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
 channel-group 1 mode on
!
interface FastEthernet1/0/11
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
!
interface FastEthernet1/0/13
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
!
interface FastEthernet1/0/23
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
 channel-group 2 mode on
!
interface FastEthernet1/0/24
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
 channel-group 2 mode on

Initially I was going to run LACP, but the pfe on this old M10 doesn’t support it. Hence the reason the channels are merely ‘on’

My second lab experience

Mobile lab – London

Cisco is running a mobile lab in London for a week and I have booked well in advance. I have already scoped out the place so I know where I’m going. It’s going to take me only 25 minutes to get there from home. I wake up at 06:30 and have breakfast and coffee at home. Ah, the joys of not paying hotel rates for this.

I’m out the door at 07:15 and arrive to the building at 07:45. The exam starts at 08:30. I’m the first one there and I’m asked to wait in reception on the ground floor. At least they let you into the building here unlike in Belgium.

The time is now 08:10 and I’m still the only one there. Am I the only one doing the exam or what? A couple of minutes later someone else finally arrives, then a whole bunch start to arrive. This is definitely a full lab.

Upstairs

08:25 we are told to head upstairs to the top (7th floor) – We give our names at reception and told to take a seat. A few minutes later the proctor arrives. He asks us each to show our identification and then we are told our rack numbers. We are all led to the lab.

Lab time

Once we get in the room we are told to switch off our phones and remove our phones, watches, tablets, etc. I ask the proctor if I can bring my snacks to the desk and he refuses. I’m quite shocked as we were allowed to bring snacks to the table in Belgium. We are only allowed to bring a seal-able bottle of water which I’m lucky to have. We get to our desks and we only have a single pen and pencil. In Belgium we have a large number of different colour pencils. My keyboard is also lop-sided but that gets fixed quickly.

Troubleshooting

I passed TS with ease last time so I was confident. Those 2 hours tick by very quickly,as anyone who has taken the lab exam can confirm. I skip a few questions here and there and nail the ‘easy’ ones quickly. This relieves the pressure on me. I solved two more pretty soon after. At one hour done I’ve completed 8 tickets and I move to the last 2 I skipped. I start to struggle and I’m losing time fast. I end up flipping between both questions as I don’t want to waste too much time on either. This helps as about 20 minutes later I’ve solved 9 questions. The last question takes time. A lot of time. I finally solve it with 10 minutes to go. I immediately go through all 10 questions again to ensure they all still work as I expect and they all do. I’m comfortable about passing TS so with 4 minutes left on the clock I end the section.

Configuration begins

I have a look at the diagram to see what I’m up against. I read through all the questions quickly. I notice a number of dependencies and so make notes of those. This will save me time later by not having to re-do part of my work. I crack on with L2 and get about halfway through L3 before the proctor says we are going for lunch in 5 minutes. I save all of my work.

Lunch

Lunch is terrible. In Belgium we are given a voucher and we go down to the cafeteria for an hour. In London they simply order some sandwiches and we all stand around a table eating. We only have 30 minutes. My appetite was gone but I forced myself to eat at least 2 sandwiches. I also get a coffee from the machine. At this time all I could think of was getting back into the lab and carrying on what I was doing. You can see the pressure on pretty much everyone’s face. Hardly anyone is cracking jokes. We all agree that Cisco needs to have a testing center in London permanently. Proctor says maybe, maybe not. Won’t be soon anyway.

Config, part two

We head back to the lab. We sit down and carry on what we are doing. I’m doing fairly well. I’ve written a few notes here and there. I’ve checked the DocCD for a couple of things and all is going fairly smoothly. About three hours later I am finished. Time to verify.

Verification

I save and reload all my devices. I read through every single question again twice and check my devices to be 100% sure I am happy with my answers. I come accross at least 4 mistakes I’ve made which I fix. I reload again and ensure everything still works. It does.

Roughly 5 minutes before our end time I ensure one last time that no debugs are running and I’ve saved everything. I click on ‘end lab’

The wait

I grab my stuff and I’m out. 30 minutes later I’m back at home. It feels like I’ve just come home from work. Am I confident? Yes, a lot more than last time. Is it enough? I don’t know. I hope so. I think so. But we’ll see what Cisco says.

So I wait.

And Wait.

I take my wife out for dinner but I don’t have an appetite. I’m checking my email every 5 minutes. Nothing. Nothing is coming.

I manage to fall asleep Friday night. I wake up at least 5 times and check my phone. No email.

Wake up Saturday 07:00 – no email.

The wait continues.

I start to second guess myself. Did I do enough? Could I have answered any question differently? I think hard, I stress out. It’s clear to me that I would not change a single answer I gave. but then I doubt again. Still nothing.

Nothing all day.

Waiting. Checking. Nothing.

Mid day I participate in a Packet Pushers show about OSPF with Ethan, Derek, and Paul. I’m nervous as it’s both my first time on the show and I’m waiting for this email to come through. When the show comes out I’m pretty certain you’ll hear that nervousness in my voice!

It’s now Saturday night and I’m tired again. Check at least 5 times before going to bed. Nothing. Check 3 times while in bed. Still nothing.

Fall asleep

The result

I wake up around 2am. Check my phone. There is an email from Cisco. They don’t tell you straight away. No you have to log into the portal and check from there. So I slide out of bed. I’m breathing heavy. I’m sweating. I can feel my heart pumping in my throat. What’s it going to be? Positive or Negative?

I log in, I look at the pass. I can’t believe it. I refresh and check again. Am I sure? Where’s my number. I look up and see #38070. It is done. I have passed and I have received the numbers I’ve been wanting all along. I run back to the bedroom and wake up my wife. She is already awake and knew I was checking. I tell her I passed. I hug her and we both have huge smiles. She get’s up and we down a drink to celebrate!

After this as all done, I tried to get back to sleep. No chance. I tossed and turned. I got up again. Checked again. Heck, why not? Number is still there. This is real, this is not a dream.

CCIE#38070

The wait has been unbearable. I did the lab on Friday and I only just got the result a few minutes ago. I can’t believe it. CCIE #38070

More to come!!!

PIM Assert. Is it really just metric?

EDIT: 24/01/13 – Thanks to IOS ping being funny, some of what is below is a bit inaccurate. Fear not, there will be an update! However not yet. Next week…

There seems to be a common myth that PIM assert meesages are based on route metric alone. This is not always true.
Let’s use the following diagram as a basis for this post. R1 is the source and R4 is the receiver. R4 is attached to the same segment as R2 and R3.

It’s inefficient to have both R2 and R3 forward multicast traffic onto this same segment. When a router receives a multicast packet on the same interface as it’s OIL, it know another router on that segment is sending the same traffic. At this point both will send PIM assert messages to let the other router know who should be sending packets onto this segment.

Let’s see this in practice. For now all routers are running OSPF with default metrics. I will ping the 239.1.1.1 group from R1 with a source of 1.1.1.1 – These packets will go to both R2 and R3 and both will initially send frames off to R4. At this point both will realise that the other router is also sending and so they will need to assert themselves.

R1#ping 239.1.1.1 so lo0 rep 5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.
Reply to request 1 from 10.0.234.4, 88 ms
Reply to request 2 from 10.0.234.4, 84 ms
Reply to request 3 from 10.0.234.4, 84 ms
Reply to request 4 from 10.0.234.4, 84 ms

Let’s take a look at what debug ip pim shows us on R2:

*Jan 24 08:22:17.631: PIM(0): Received v2 Assert on FastEthernet1/1 from 10.0.234.3
*Jan 24 08:22:17.635: PIM(0): Assert metric to source 10.0.13.1 is [0/0]
*Jan 24 08:22:17.639: PIM(0): We lose, our metric [110/2]
*Jan 24 08:22:17.639: PIM(0): Prune FastEthernet1/1/239.1.1.1 from (10.0.13.1/32, 239.1.1.1)

R2 receives an assert message from R3 saying it’s metric is better. R2 therefore prunes fa1/1 off the OIL for this group. But look a bit deeper. R2 says it’s metric is 110/2 which we can confirm:

R2#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "ospf 1", distance 110, metric 2, type intra area
  Last update from 10.0.12.1 on FastEthernet1/0, 00:17:48 ago
  Routing Descriptor Blocks:
  * 10.0.12.1, from 1.1.1.1, 00:17:48 ago, via FastEthernet1/0
      Route metric is 2, traffic share count is 1

R2’s route back to the source has an AD of 110 and a metric of 2. So already we know that AD also comes into play here. But why does R3 say it’s metric is 0/0?

*Jan 24 08:22:17.579: PIM(0): Send v2 Assert on FastEthernet1/1 for 239.1.1.1,
 source 10.0.13.1, metric [0/0]
*Jan 24 08:22:17.583: PIM(0): Assert metric to source 10.0.13.1 is [0/0]

You can see in the previous debug on R2 that it does receive those values from R3. But R3’s metric is like so:

R3#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "ospf 1", distance 110, metric 3, type intra area
  Last update from 10.0.234.2 on FastEthernet1/1, 00:19:36 ago
  Routing Descriptor Blocks:
  * 10.0.234.2, from 1.1.1.1, 00:19:36 ago, via FastEthernet1/1
      Route metric is 3, traffic share count is 1

Even wireshark confirms that R3’s values are 0/0:

What happens if I up R3’s link cost to R1?

R3(config)#int fa1/0
R3(config-if)#ip ospf cost 5

Well, the outputs are interesting in that they match the above output. eh? R3 is still sending it’s metric as 0/0 even though because of the metric change it’s best route is actually through R2. That’s messed up surely.

The only ‘special’ thing about R3 at the moment is that it is the DR for the segment. I lowered the DR priority of R4 to zero and hence R3 became the DR as it had the highest IP address on the segment.

This is where things start to get interesting now. If metric were the only thing to be checked here, what would happen if R2 and R3 had routes back to 1.1.1.1 via different protocols? Protocol metrics are not comparable which is why you need seed metrics (or use built-in seed metrics) when redistributing.

Let’s create a static route to 1.1.1.1 on R2:

R2(config)#ip route 1.1.1.1 255.255.255.255 10.0.12.1
R2(config)#end
R2#
*Jan 24 08:46:08.355: %SYS-5-CONFIG_I: Configured from console by console
R2#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.0.12.1
      Route metric is 0, traffic share count is 1

The AD is 1, the metric is zero.

Who will now forward multicast traffic for the segment? If R3 continues to assert itself as 0/0 it’ll win, if not then R2 will win.

Well, no use posting the output as it’s exactly the same. R3 is still asserting itself as 0/0 and hence is ‘winning’ again.

*Jan 24 08:48:20.163: PIM(0): Received v2 Assert on FastEthernet1/1 from 10.0.234.3
*Jan 24 08:48:20.167: PIM(0): Assert metric to source 10.0.13.1 is [0/0]

This all looks to me like the DR is forcing it’s hand here. You can’t beat a 0/0 AD-metric pair. Maybe the IOS implementation says it must be this way? What does the actual RFC say (RFC4601)?

I am Assert Winner (W)
This router has won an (S,G) assert on interface I. It is now
responsible for forwarding traffic from S destined for G out of
interface I. Irrespective of whether it is the DR for I, while a
router is the assert winner, it is also responsible for forwarding
traffic onto I on behalf of local hosts on I that have made
membership requests that specifically refer to S (and G).

I am Assert Loser (L)
This router has lost an (S,G) assert on interface I. It must not
forward packets from S destined for G onto interface I. If it is
the DR on I, it is no longer responsible for forwarding traffic
onto I to satisfy local hosts with membership requests that
specifically refer to S and G.

Assert metrics are defined as:

struct assert_metric {
rpt_bit_flag;
metric_preference;
route_metric;
ip_address;
};
When comparing assert_metrics, the rpt_bit_flag, metric_preference,
and route_metric field are compared in order, where the first lower
value wins. If all fields are equal, the primary IP address of the
router that sourced the Assert message is used as a tie-breaker, with
the highest IP address winning.

There is this tidbit though:

2. Behavior: The assert winner for (*,G) acts as the local DR for
(*,G) on behalf of IGMP/MLD members.

Assert messages are to elect the Designated Forwarder for the segment. The Designated Router is a different election. The DR is responsible for sending up IGMP joins, while the DF is responsible for forwarding traffic onto the segment. This single line in the RFC to me states that these roles somehow join. Maybe this is why R3 continues to force itself as the DF? It looks like it.

It would be interesting to try the above test in Junos to see what it’s implementation does. I won’t have access to my Junos lab for a few days though so it will have to be another time. I was interested to know as different vendors use different AD values for protocols, and hence a router could in theory ‘beat’ another vendors router even if they have the same protocol metric but different AD values.

If Junos also uses 0/0 when it is a DR, then that would explain a few things as well.

Let’s make R2 the DR and see what happens:

R2(config)#int fa1/1
R2(config-if)#ip pim dr-priority 1000

Oddly now I don’t see any prune messages. Debugging on R1 shows that R3 is immediately sending a prune to R1 and hence R3 doesn’t even begin to forward traffic out on the shared segment. That means no assert is needed.

Hopefully this helps a few people out there. Sometimes things are a bit more tricky than they appear…