From: Brian Dennis (brian@labforge.com)
Date: Sun Jun 01 2003 - 01:57:20 GMT-3
Fabrice,
<Quote>
Your assumption was correct except that the multicast will still
initiate the SVC.
For example, for EIGRP, one router (R1) sends a multicast packet using
224.0.0.10, the other end (R2) ACKs this packet.
</Quote>
How could the multicast packet initiate the SVC if there is not a
mapping to begin with? The router will not send an ARP request to the
ARP server asking for the ATM NSAP address of 224.0.0.10 as you know. If
there isn't a mapping already the multicast packet will get an
encapsulation failed error.
The whole process will not even start unless you are running a dynamic
protocol directly with the ARP server itself. Try using three ATM
routers with one as the ARP server and the other two as "clients". Run
EIGRP between just the two clients. They will never be able to
communicate via EIGRP multicast unless a unicast packet triggers and ARP
request.
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Fabrice Bobes
Sent: Saturday, May 31, 2003 10:30 AM
To: 'Daniel Cisco Group Study'; ccielab@groupstudy.com
Subject: RE: ATM SVCs + Routing Protocols
Daniel,
Per RFC 1577 (Classical IP with SVC over ATM): "8. IP Multicast Address
ATM does not support multicast address services, therefore there are
no mappings available from IP multicast addresses to ATM multicast
services.
"
In other words, you need the neighbor command to establish adjacency for
routing protocols that use normally multicast.
Your assumption was correct except that the multicast will still
initiate the SVC.
Let me try to explain what happens:
For example, for EIGRP, one router (R1) sends a multicast packet using
224.0.0.10, the other end (R2) ACKs this packet.
R1 then installs an ARP entry in order to reach R2 but this ARP
corresponds to R2's IP address, not to the multicast address of course.
The EIGRP relationship is then up and the problem is that it sounds like
everything is working fine.
R1 continues to send its hello packets using 224.0.0.10 (not R2's IP
address), the ARP entry to reach R2 is removed from the ARP table (times
out), the SVC is then torn down and gets recreated with the next hello
packet.
So yes, you need the neighbor command when running protocols like OSPF,
EIGRP over ATM CLIP. Otherwise, you will see the neighbor adjacency
going up and down.
I hope this helps,
Fabrice
http://www.6CoLabs.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Daniel Cisco Group Study
Sent: Saturday, May 31, 2003 3:54 AM
To: ccielab@groupstudy.com
Subject: ATM SVCs + Routing Protocols
Unfortunately I don't have any further access to ATM equipment. This is
something that I didn't test when I did.....
Maybe someone could try this out, or knows the answer.....
I've seen some ATM configs using Classical IP over ATM (ie ARP Servers),
where they specified neighbor commands under the routing protocol
configuration. The config I saw today was specifically for RIP V2, but I
think that I've seen it for other routing protocols as well.
Question: Are neighbor commands required?
My guess is probably yes.....
Why?
My guess is that since we are relying on ARP, there's no way for
classical IP over ATM to know WHERE to initiate the SVC to..... ie how
can we find the NSAP address of a routing protocol's multicast or
broadcast packet????
Of course, if you bring up the SVC with a ping, and then run the routing
protocol, everything should work..... Reboot (or kill the SVC), and my
theory would suggest that the routing protocol will not bring up the
SVC....
Am I correct? Can someone try this out, correct, or agree with me?
Thanks in advance.
Daniel
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:10:50 GMT-3