Why do mapping agents need to be connected to all PIM routers in NBMA?

July 29, 2008 at 2:51 pm | Posted in Multicast | Leave a comment

This is required because of the way multicast dense mode works. When a
router receive a mpacket, it floods the multicast packet out to all
other interface, except the interface it is received on.

Let’s look at the example provided at the link below,

http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/frm_rlay.html

If MA is placed under a spoke router R2, then RP discovery message sent via 224.0.1.40
can be propogated to R2, then to Hub R1, and further to any router
behind R1, but not to other spoke. This is because, when R1 receives
this “RP discovery message”, it floods out all other interface(s), but
not S0.1

If you do sh ip mroute on R1, you will see that the interface S0.1 is
not in the OIL (outgoing interface list) for the group 224.0.1.40.

Similar candidate RP and mapping agent should be communicatable via
224.0.1.39. If they are both spokes, can only be reachable via a hub,

then the MA cannot not event see the RP presence.

If we place MA on a spoke router, we can get multicast working by adding a tunnel between the spokes. The things we should look for are RPF check, and how you route traffic between R2 and R4. It has to be routed via the tunnel interface. This is done via manupulating IGP metric.

R1#sh run

!
ip multicast-routing
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.0
ip pim sparse-dense-mode
!
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
!
interface Serial1/0.1 multipoint
ip address 123.0.0.1 255.255.255.0
ip pim nbma-mode
ip pim sparse-dense-mode
no ip split-horizon eigrp 100
frame-relay map ip 123.0.0.2 102 broadcast
frame-relay map ip 123.0.0.3 103 broadcast
!
!
router eigrp 100
network 0.0.0.0
no auto-summary
!

ip pim send-rp-announce Loopback0 scope 10 interval 5
!
!

R2#sh run

ip multicast-routing
!
!

!
interface Loopback0
ip address 2.2.2.2 255.255.255.0
ip pim sparse-dense-mode
ip igmp join-group 232.0.0.2
!
interface Tunnel23
bandwidth 10000000
ip address 23.0.0.2 255.255.255.0
ip pim sparse-dense-mode
delay 1
tunnel source 123.0.0.2
tunnel destination 123.0.0.3
!

!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
!
interface Serial1/0.1 point-to-point
ip address 123.0.0.2 255.255.255.0
ip pim sparse-dense-mode
frame-relay interface-dlci 201
!

!
router eigrp 100
network 0.0.0.0
no auto-summary
!

!
!
end

R2#

R3#sh run

hostname R3
!

ip multicast-routing
!
!

!
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.0
ip pim sparse-dense-mode
!
interface Tunnel23
bandwidth 10000000
ip address 23.0.0.3 255.255.255.0
ip pim sparse-dense-mode
delay 1
tunnel source 123.0.0.3
tunnel destination 123.0.0.2
!

!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
!
interface Serial1/0.1 point-to-point
ip address 123.0.0.3 255.255.255.0
ip pim sparse-dense-mode
frame-relay interface-dlci 301
!
interface Serial1/1
no ip address
encapsulation frame-relay
serial restart-delay 0
!
interface Serial1/1.1 point-to-point
ip address 34.0.0.3 255.255.255.0
ip pim sparse-dense-mode
frame-relay interface-dlci 314
!

!
router eigrp 100
network 0.0.0.0
no auto-summary
!
!
!
ip pim send-rp-discovery Loopback0 scope 10 interval 5
ip mroute 1.1.1.1 255.255.255.255 Tunnel23
!
!
!
!
end

R4#sh run
Building configuration…

Current configuration : 1573 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R4
!

!
!
interface Loopback0
ip address 4.4.4.4 255.255.255.0
ip pim sparse-dense-mode
!

!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
!
interface Serial1/0.1 point-to-point
ip address 34.0.0.4 255.255.255.0
ip pim sparse-dense-mode
frame-relay interface-dlci 413
!

!
router eigrp 100
network 0.0.0.0
no auto-summary
!

R3#sh ip route
Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

34.0.0.0/24 is subnetted, 1 subnets
C       34.0.0.0 is directly connected, Serial1/1.1
1.0.0.0/24 is subnetted, 1 subnets
D       1.1.1.0 [90/2297856] via 123.0.0.1, 00:18:05, Serial1/0.1
2.0.0.0/24 is subnetted, 1 subnets
D       2.2.2.0 [90/128512] via 23.0.0.2, 00:18:05, Tunnel23
3.0.0.0/24 is subnetted, 1 subnets
C       3.3.3.0 is directly connected, Loopback0
4.0.0.0/24 is subnetted, 1 subnets
D       4.4.4.0 [90/2297856] via 34.0.0.4, 00:17:32, Serial1/1.1
23.0.0.0/24 is subnetted, 1 subnets
C       23.0.0.0 is directly connected, Tunnel23
123.0.0.0/24 is subnetted, 1 subnets
C       123.0.0.0 is directly connected, Serial1/0.1

R3#sh ip mroute 232.0.0.2
IP Multicast Routing Table
Flags: D – Dense, S – Sparse, B – Bidir Group, s – SSM Group, C – Connected,
L – Local, P – Pruned, R – RP-bit set, F – Register flag,
T – SPT-bit set, J – Join SPT, M – MSDP created entry,
X – Proxy Join Timer Running, A – Candidate for MSDP Advertisement,
U – URD, I – Received Source Specific Host Report,
Z – Multicast Tunnel, z – MDT-data group sender,
Y – Joined MDT-data group, y – Sending to MDT-data group
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 232.0.0.2), 00:28:20/stopped, RP 1.1.1.1, flags: SPF
Incoming interface: Tunnel23, RPF nbr 23.0.0.2, Mroute
Outgoing interface list: Null

(4.4.4.4, 232.0.0.2), 00:23:07/00:02:56, flags: T
Incoming interface: Serial1/1.1, RPF nbr 34.0.0.4
Outgoing interface list:
Tunnel23, Forward/Sparse-Dense, 00:18:14/00:02:35

(34.0.0.4, 232.0.0.2), 00:28:20/00:03:02, flags: FT
Incoming interface: Serial1/1.1, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel23, Forward/Sparse-Dense, 00:18:14/00:02:36

R4#ping ip
Target IP address: 232.0.0.2
Repeat count [1]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Interface [All]: Serial1/0.1
Time to live [255]:
Source address: 34.0.0.4
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 1, 100-byte ICMP Echos to 232.0.0.2, timeout is 2 seconds:
Packet sent with a source address of 34.0.0.4

Reply to request 0 from 23.0.0.2, 180 ms

EIGRP Maximum Delay pitfall

July 24, 2008 at 5:55 pm | Posted in EIGRP, Routing | Leave a comment

Setting interface delay to a maximum number will have undesired effect on the routing. You would normally expect that setting it to the max value, EIGRP will unfavor the path via  that link. It is not always the case. I think this is because when exceeding a certain integer number, the metric will be offset back to a small number, and is actually preferred.

Similar weid behavior is observed in OSPF virtual link path cost too. If you set the the “exiting” interface of the router with virtual link the to max of 65535, virtual link wont come up. However, it is OK to set ANY transit link to this maximum value, and the virtual link is fine. That weid things make IOS so beautifull, and attractive ;)

Here again is example of the weird EIGRP behaviour when setting the link delay to max.

IE WB – VOL1 – ver5, Task 5.14

Default Interface Delay

Rack1SW1#sh int vlan 67 | in DLY
MTU 1504 bytes, BW 1000000 Kbit, DLY 10 usec,
Rack1SW1#sh ip eigrp topology 150.1.6.0/24
EIGRP-IPv4 (AS 100): Topology Default-IP-Routing-Table(0) entry for 150.1.6.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 128256
Routing Descriptor Blocks:
155.1.67.6 (Vlan67), from 155.1.67.6, Send flag is 0x0
Composite metric is (128256/128000), Route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 5010 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1504
Hop count is 1

EIGRP is well behaving when Interface Delay is set to 1sec.

Rack1SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1SW1(config)#int vlan 67
Rack1SW1(config-if)#delay ?
<1-16777215>  Throughput delay (tens of microseconds)

Rack1SW1(config-if)#delay 100000
Rack1SW1(config-if)#end
Rack1SW1#sh ip eigrp topology 150.1.6.0/24
02:09:19: %SYS-5-CONFIG_I: Configured from console by console
Rack1SW1#sh int vlan 67 | in DLY
MTU 1504 bytes, BW 1000000 Kbit, DLY 1000000 usec,
Rack1SW1#sh ip eigrp topology 150.1.6.0/24
EIGRP-IPv4 (AS 100): Topology Default-IP-Routing-Table(0) entry for 150.1.6.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 668160
Routing Descriptor Blocks:
155.1.37.3 (FastEthernet0/3), from 155.1.37.3, Send flag is 0x0
Composite metric is (668160/642560), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit

Total delay is 26100 microseconds ! via other path

Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3
155.1.67.6 (Vlan67), from 155.1.67.6, Send flag is 0x0
Composite metric is (25728000/128000), Route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 1005000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1504
Hop count is 1
Rack1SW1#sir 150.1.6.6
Routing entry for 150.1.6.0/24
Known via “eigrp 100”, distance 90, metric 668160, type internal
Redistributing via eigrp 100
Last update from 155.1.37.3 on FastEthernet0/3, 00:00:52 ago
Routing Descriptor Blocks:
* 155.1.37.3, from 155.1.37.3, 00:00:52 ago, via FastEthernet0/3
Route metric is 668160, traffic share count is 1
Total delay is 26100 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 3

EIGRP (or IOS??) is a bad boy when Interface Delay is set to Maximum.


Rack1SW1#
Rack1SW1#
Rack1SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1SW1(config)#int vlan 67
Rack1SW1(config-if)#delay ?
<1-16777215>  Throughput delay (tens of microseconds)

Rack1SW1(config-if)#delay 16777215
Rack1SW1(config-if)#
Rack1SW1#conf t
02:10:40: %SYS-5-CONFIG_I: Configured from console by console
Rack1SW1#sh int vlan 67 | in DLY
MTU 1504 bytes, BW 1000000 Kbit, DLY 167772150 usec,
Rack1SW1#sh ip eigrp topology 150.1.6.0/24
EIGRP-IPv4 (AS 100): Topology Default-IP-Routing-Table(0) entry for 150.1.6.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 127744
Routing Descriptor Blocks:
155.1.67.6 (Vlan67), from 155.1.67.6, Send flag is 0x0
Composite metric is (127744/128000), Route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 4990 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1504
Hop count is 1
Rack1SW1#sir 150.1.6.6
Routing entry for 150.1.6.0/24
Known via “eigrp 100”, distance 90, metric 127744, type internal
Redistributing via eigrp 100
Last update from 155.1.67.6 on Vlan67, 00:00:19 ago
Routing Descriptor Blocks:
* 155.1.67.6, from 155.1.67.6, 00:00:19 ago, via Vlan67
Route metric is 127744, traffic share count is 1
Total delay is 4990 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1504 bytes
Loading 1/255, Hops 1

Verifying EIGRP Weight Metric

July 24, 2008 at 5:14 pm | Posted in EIGRP, Routing | Leave a comment

By default K1 = K3 = 1. All others weight metric are 0. This means, only bandwidth and delays are used in the EIGRP metric equation.

The online IOS help does not provide much information as to what metric a certain K refers to (e.g. K1 refers to bandwidth whereas K3 refers to delay). The Doc CD command reference is the friend in the lab! Also, we can use the show ip protocol command to verify the weight setting.

Rack1R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1R1(config)#router ei 100
Rack1R1(config-router)#metric weight ?
<0-8>  Type Of Service (Only TOS 0 supported)

Rack1R1(config-router)#metric weight 0 ?
<0-255>  K1

Rack1R1(config-router)#metric weight 0

Rack1R1#sh ip protocols
Routing Protocol is “eigrp 100”
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=0, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 100
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
150.1.0.0
155.1.0.0
Routing Information Sources:
Gateway         Distance      Last Update
(this router)         90      00:10:59
155.1.146.4           90      00:05:07
155.1.146.6           90      00:05:07
155.1.13.3            90      00:05:07
155.1.0.5             90      00:05:07
Distance: internal 90 external 170

File system commands

July 24, 2008 at 4:40 pm | Posted in IOS services | Leave a comment

Rack1R1#sh flash

System flash directory:
File  Length   Name/status
1   29715256  c2600-adventerprisek9-mz.124-13b.bin
2   1233     R1-initial
3   714      r1-confg
4   291459   crashinfo_20020301-002307
5   1687     eigrp-vol1-v5
[30010676 bytes used, 19796680 available, 49807356 total]
49152K bytes of processor board System flash (Read/Write)

This command is useful to make sure that the IOS on flash (e.g. just downloaded from an TFTP server) is not corrupted before reloading the router.
Rack1R1#verify flash:c2600-adventerprisek9-mz.124-13b.bin
Verifying file integrity of flash:c2600-adventerprisek9-mz.124-13b.bin…….
Computed Hash   MD5 : CC7886F52DE2ABC79DF0F7ADB414466C
CCO Hash        MD5 : E9AB5025BDEDB2C5B9013BE635AC24FE

Signature Verified
Verified flash:c2600-adventerprisek9-mz.124-13b.bin

“More” is similar to Cat in Linux or Type in DOS Windows is used to check content of a text file.

Rack1R1#more flash:eigrp-vol1-v5
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Rack1R1
!
boot-start-marker
boot-end-marker
!
enable password cisco
!
no aaa new-model
no network-clock-participate slot 1
no network-clock-participate wic 0
ip cef
!
!
!
!
no ip domain lookup
!

EIGRP summarization caveat

July 24, 2008 at 4:14 pm | Posted in EIGRP, Routing | Leave a comment

WB1-Ver5-Task 5.11

By default when advertizing a summary route in EIGRP (and also OSPF, and BGP), router automatically installs a route to Null0 to match the summary. This is to prevent the router from forwarding traffic for destination inside the summary that it does not have a longer match for.

However in certain design scenario this could be undesirable behavior. To resolve this, we can implemen one of these options:

    • Keep the default admin distance of 5 for summary route, but add another route with distance of 1-4, e.g. a static route, to override the route to null.
    • Change the default distance of 5 to 255, meaning the router will not install the route to null0

      This is difference from summarization in RIP. RIP does not installs a route to null, which may create a “route feedback”, which may make the network unstable (reachblility is on and off). More specifically, the router may receives a route from neighbor, without knowing that the orignator is itself. The router then advertize this “”new route” with a new RIP metric, creating a route-advertisment loop. The route eventually become a dead route, due to infinte metric, and is then removed from the routing table. When the original router removes it from the routing table, the cycle starts again with the summarize route being advertized with original metric of 1. To guard again this route feedback behaviour, we can implement one of the following options:

        • Set a static route, pointing to null on the router that originate default route.
        • Filter this route from being learnt from its neighbor, or
        • Advertize the summary route to ALL its neighbors.

          Blog at WordPress.com.
          Entries and comments feeds.