From: Gupta, Gopal (NWCC) (gopal.gupta@hp.com)
Date: Sun Nov 11 2007 - 08:12:44 ART
That's where the issue is..my traffic is going to all
neighbors...completely lost into it.
Regards,
Gops
________________________________
From: George Goglidze [mailto:goglidze@gmail.com]
Sent: Sunday, November 11, 2007 16:40
To: Gupta, Gopal (NWCC)
Subject: Re: PIM NBMA Mode
Hi there,
Ignore my last post, I guess I was wrong.
here's what DocCD says:
Usage Guidelines
Use this command on Frame Relay, Switched Multimegabit Data Service
(SMDS), or ATM only, especially when these media do not have native
multicast available. Do not use this command on multicast-capable LANs
such as Ethernet or FDDI.
When this command is configured, each Protocol Independent Multicast
(PIM) join message is tracked in the outgoing interface list of a
multicast routing table entry. Therefore, only PIM WAN neighbors that
have joined for the group will get packets sent as data-link unicasts.
This command should only be used when the ip pim sparse-mode command is
configured on the interface. This command is not recommended for LANs
that have natural multicast capabilities.
So according to DocCD it should go unicast.
Regards,
On Nov 11, 2007 12:05 PM, George Goglidze <goglidze@gmail.com> wrote:
Hi there,
Actually as I understand it, pim nbma mode does not mean it will
no send traffic to all dlci-s.
it just means that it keeps track of how many joins it receives,
and will cease sending traffic when it receives as many *part* messages
as it had *joins*.
because on that kind of link, maybe it had before let's say 5
joins, and then one of the routers send part message, and it stops
sending traffic for all.
so ip pim nbma mode was to prevent this.
Maybe I'm wrong, check it in pim documentation,
I dont have time to check it now.
On Nov 11, 2007 11:37 AM, Gupta, Gopal (NWCC)
<gopal.gupta@hp.com > wrote:
Hi Alex,
As you know it is sparse mode it doesnt send traffic to
those who dont
ask for means it is already pruned and then forward to
those who need
the traffic.
In this case R5 is thinking that join requests are
coming from serial
interface so it is forwarding Traffic out to all DLCIs;
(Which NBMA mode
command should have taken care for to send to only
155.1.0.3...that it
has entry for in its multicast table.
connection is like this
R6-->SW1-->R3-->FRCloud<--R5
For R3
(*, 232.2.2.2), 00:00:20/00:03:24, RP 150.1.4.4, flags:
SF
Incoming interface: Serial1/0.1, RPF nbr 155.1.0.5
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:00:20/00:03:24
( 150.1.5.5 <http://150.1.5.5> , 232.2.2.2),
00:00:08/00:03:21, flags:
Incoming interface: Serial1/0.1, RPF nbr 155.1.0.5
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:00:08/00:03:24
SW1
(*, 232.2.2.2), 01:28:34/stopped, RP 150.1.4.4, flags:
SJC
Incoming interface: Vlan3, RPF nbr 155.1.37.3
Outgoing interface list:
Vlan2, Forward/Sparse, 01:28:34/00:02:06
( 150.1.5.5 <http://150.1.5.5> , 232.2.2.2),
00:00:37/00:02:25, flags: JT
Incoming interface: Vlan3, RPF nbr 155.1.37.3
Outgoing interface list:
Vlan2, Forward/Sparse, 00:00:37/00:02:22
(155.1.0.5, 232.2.2.2), 00:00:37/00:02:25, flags: JT
Incoming interface: Vlan3, RPF nbr 155.1.37.3
Outgoing interface list:
Vlan2, Forward/Sparse, 00:00:37/00:02:22
R6 (Joined Group 232.2.2.2)
*, 232.2.2.2), 01:30:58/stopped, RP 150.1.4.4, flags:
SJPL
Incoming interface: Ethernet0/0, RPF nbr 155.1.67.7
Outgoing interface list: Null
(150.1.5.5, 232.2.2.2), 00:18:19/00:01:41, flags: PLT
Incoming interface: Ethernet0/0, RPF nbr 155.1.67.7
Outgoing interface list: Null
(155.1.0.5, 232.2.2.2), 01:29:46/00:01:41, flags: PLT
Incoming interface: Ethernet0/0, RPF nbr 155.1.67.7
Outgoing interface list: Null
(155.1.58.5, 232.2.2.2), 01:07:50/00:01:55, flags: PLT
Incoming interface: Ethernet0/0, RPF nbr 155.1.67.7
Outgoing interface list: Null
Regards,
Gops
l Message-----
From: Alex Steer [mailto:alex.steer@eison.co.uk]
Sent: Sunday, November 11, 2007 15:52
To: Gupta, Gopal (NWCC)
Cc: Cisco certification
Subject: RE: PIM NBMA Mode
Hi Gops,
It might be, it might not. Could you send a full copy
of your show ip
mroute on all of the routers please (specifically the
S,G entry)?
Nbma is primarily to stop a prune from one of the spokes
sent to r5 from
pruning the other neighbors (default behaviour without
nbma mode). The
other neighbors don't see the prune due to the
Non-broadcast nature of
the interface and so don't prune override it. Pim nbma
causes pim to
store network-hop information for that interface, that
doesn't mean it
can unicast the packet to that 1 neighbor though, merely
means it wont
prune the interface when it receives a prune from one of
the neighbors.
It would be good for my own study to see the output.
-----Original Message-----
From: nobody@groupstudy.com [mailto:
nobody@groupstudy.com <mailto:nobody@groupstudy.com> ] On Behalf Of
Gupta, Gopal (NWCC)
Sent: 11 November 2007 09:56
To: Cisco certification
Subject: PIM NBMA Mode
Hi Folks,
There is issue with pim NBMA mode.
R5 is the hub Router and sending traffic to group
232.2.2.2, The problem
here is that despite of putting ip pim NBMA command on
R5 Serial
interface, i am getting three replies; means R5 is still
sending traffic
to all DLCIs configured under R5 serial interface.
R5#ping 232.2.2.2
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 232.2.2.2, timeout is
2 seconds:
Reply to request 0 from 155.1.67.6, 324 ms Reply to
request 0 from
155.1.67.6, 728 ms Reply to request 0 from 155.1.67.6,
504 ms
Debugs:-
*Mar 1 11:26:16.277: Serial1/0(o): dlci 504(0x7C81),
pkt type
0x800(IP), datagramsize 444 *Mar 1 11:26:16.277:
Serial1/0(o): dlci
501(0x7C51), pkt type 0x800(IP), datagramsize 444 *Mar
1 11:26: 16.289:
Serial1/0(o): dlci 503(0x7C71), pkt type 0x800(IP),
datagramsize 444
These packets are packets for 232.2.2.2 address.
R5#sh ip mr 232.2.2.2
IP Multicast Routing Table
(*, 232.2.2.2), 00:18:05/00:03:14, RP 150.1.5.5, flags:
S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1/0, 155.1.0.3, Forward/Sparse,
00:17:43/00:03:14
Config :--
interface Serial1/0
ip address 155.1.0.5 255.255.255.0
ip pim nbma-mode
ip pim sparse-mode
encapsulation frame-relay
no ip route-cache cef
no ip route-cache
serial restart-delay 0
no dce-terminal-timing-enable
frame-relay map ip 155.1.0.1 501 broadcast frame-relay
map ip
155.1.0.3 503 broadcast frame-relay map ip 155.1.0.4
504 broadcast end
Any Comments...how to overcome this, may i be i am
missing something
here.
Thanks
Gops
This archive was generated by hypermail 2.1.4 : Sat Dec 01 2007 - 06:37:29 ART