From: Yasser Abdullah (yasser@alharbitelecom.com)
Date: Thu Apr 15 2004 - 11:49:39 GMT-3
Multicast will work around split-horizon issues if you are running
sparse-mode. In sparse mode the outgoing interface list (OIL) is
associated with the neighbor IP address rather than the outgoing
interface.
You need the mapping agent to be at the hub though.
HTH,
Yasser
-----Original Message-----
From: OzgurG@garanti.com.tr [mailto:OzgurG@garanti.com.tr]
Sent: Thursday, April 15, 2004 5:32 PM
To: kwchen@netvigator.com; yasser@alharbitelecom.com
Cc: ccielab@groupstudy.com
Subject: RE: ip pim nbma-mode
that means
141.1.123.1 is the FR hub ip,
and you are pinging from that router,
which means you are not simulating the FR split-horizon problem.
Ozgur
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
William Chen
Sent: Thursday, April 15, 2004 4:50 PM
To: Yasser Abdullah
Cc: ccielab@groupstudy.com
Subject: Re: ip pim nbma-mode
Hi Yasser,
Thx for your reply.
However, how can you explain the follwing example, especially the
mroute
entry:
> (141.1.123.1, 239.39.39.39), 00:00:18/00:03:18, flags: FT
> Incoming interface: Serial0/0, RPF nbr 0.0.0.0
> Outgoing interface list:
> Serial0/0, 141.1.123.3, Forward/Sparse, 00:00:18/00:03:18
>
Serial0/0 is in both the input interface and OIL.
Best Regards,
William Chen
----- Original Message -----
From: "Yasser Abdullah " <yasser@alharbitelecom.com>
To: "'William Chen'" <kwchen@netvigator.com>
Cc: <ccielab@groupstudy.com>
Sent: Thursday, April 15, 2004 8:53 PM
Subject: RE: ip pim nbma-mode
> No, that's not what NBMA is for. It's used to configure a hub router
to
> send the multicast packet to ONLY the spoke that requested it. For
split
> horizon issues just use a GRE tunnel.
>
> HTH,
>
> Yasser
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> William Chen
> Sent: Thursday, April 15, 2004 3:23 PM
> To:
> Subject: ip pim nbma-mode
>
> Dear all,
>
> Anyone confirm me that the command "ip pim nbma-mode" command is
able
> to
> solve the multicast split horizon problem (i.e if the Hub received
> multicast
> packets from one of the spoken will forward to another spoken, if this
> command is turn on).
>
> Following is an example:
>
> Spoken (R1):
> Rack1R1#sh run int s0/0.1
> Building configuration...
>
> Current configuration : 188 bytes
> !
> interface Serial0/0.1 point-to-point
> ip address 141.1.123.1 255.255.255.0
> ip pim sparse-mode
> ip ospf network non-broadcast
> ip ospf priority 0
> frame-relay interface-dlci 102
> end
>
> Spoken (R3):
> Rack1R3#sh run int s1/0.1
> Building configuration...
>
> Current configuration : 188 bytes
> !
> interface Serial1/0.1 point-to-point
> ip address 141.1.123.3 255.255.255.0
> ip pim sparse-mode
> ip ospf network non-broadcast
> ip ospf priority 0
> frame-relay interface-dlci 302
> end
>
> Hub (R2):
> Rack1R2#sh run int s0/0
> Building configuration...
>
> Current configuration : 360 bytes
> !
> interface Serial0/0
> ip address 141.1.123.2 255.255.255.0
> ip pim dr-priority 100
> ip pim nbma-mode
> ip pim sparse-mode
> encapsulation frame-relay
> ip ospf priority 100
> frame-relay map ip 141.1.123.1 201 broadcast
> frame-relay map ip 141.1.123.2 201
> frame-relay map ip 141.1.123.3 203 broadcast
> no frame-relay inverse-arp
> frame-relay lmi-type cisco
> end
>
> Verfication:
> Rack1R1#p
> Protocol [ip]:
> Target IP address: 239.39.39.39
> Repeat count [1]:
> Datagram size [100]:
> Timeout in seconds [2]:
> Extended commands [n]: y
> Interface [All]: Serial0/0.1
> Time to live [255]:
> Source address: 141.1.123.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 1, 100-byte ICMP Echos to 239.39.39.39, timeout is 2 seconds:
> Packet sent with a source address of 141.1.123.1
>
> Reply to request 0 from 141.1.123.3, 164 ms
>
> Rack1R2#sh ip mroute 239.39.39.39
> 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
> Y - Joined MDT-data group, y - Sending to MDT-data group
> Outgoing interface flags: H - Hardware switched
> Timers: Uptime/Expires
> Interface state: Interface, Next-Hop or VCD, State/Mode
>
> (*, 239.39.39.39), 03:30:17/stopped, RP 150.1.5.5, flags: SF
> Incoming interface: Ethernet0/0, RPF nbr 141.1.0.5, Mroute
> Outgoing interface list:
> Serial0/0, 141.1.123.3, Forward/Sparse, 03:30:17/00:03:18
>
> (141.1.123.1, 239.39.39.39), 00:00:18/00:03:18, flags: FT
> Incoming interface: Serial0/0, RPF nbr 0.0.0.0
> Outgoing interface list:
> Serial0/0, 141.1.123.3, Forward/Sparse, 00:00:18/00:03:18
>
> Rack1R1#sh ver | in IOS
> IOS (tm) C2600 Software (C2600-JK9O3S-M), Version 12.2(15)T9, RELEASE
> SOFTWARE (fc2)
> Rack1R2#sh ver | in IOS
> IOS (tm) C2600 Software (C2600-J1S3-M), Version 12.2(15)T5, RELEASE
> SOFTWARE (fc1)
> Rack1R3#sh ver | in IOS
> IOS (tm) C2600 Software (C2600-J1S3-M), Version 12.2(15)T5, RELEASE
> SOFTWARE (fc1)
>
> Best Regards,
> William Chen
>
>
This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 19:48:48 GMT-3