From: Daniel Cisco Group Study (danielcgs@imc.net.au)
Date: Mon Jun 02 2003 - 17:53:43 GMT-3
Thanks all... That's what I guessed.... :)
Daniel
-----Original Message-----
From: Fabrice Bobes [mailto:study@6colabs.com]
Sent: Monday, 2 June 2003 12:59 PM
To: 'Brian Dennis'; Daniel Cisco Group Study; ccielab@groupstudy.com
Subject: RE: ATM SVCs + Routing Protocols
Gotcha! It makes a lot of sense even though it's hard for me to think
logically :-)
So Daniel, in short, we need the neighbor command since there is no
support for multicast address registration.
Fabrice #8609
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brian Dennis
Sent: Sunday, June 01, 2003 6:47 PM
To: 'Fabrice Bobes'; 'Daniel Cisco Group Study'; ccielab@groupstudy.com
Subject: RE: ATM SVCs + Routing Protocols
Try this with three routers. One router as the ARP server and the other
two routers as clients. Then run EIGRP only on the clients. EIGRP will
not work unless a unicast packet triggers the ARP request and creates
the mapping.
Think about it logically. Since the ARP server does not resolve
multicast IP addresses to ATM NSAP addresses it's the unicast traffic
that is creating the mapping. If IP multicast was triggering the ARP
request and in turn creating the mapping, the ARP server would have to
support multicast registration.
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
-----Original Message-----
From: Fabrice Bobes [mailto:study@6colabs.com]
Sent: Sunday, June 01, 2003 8:30 AM
To: 'Brian Dennis'; 'Daniel Cisco Group Study'; ccielab@groupstudy.com
Subject: RE: ATM SVCs + Routing Protocols
Brian D,
I had 2 routers R13 and R14 running EIGRP and R14 was the ARP server.
Here are some outputs (taken from R13):
01:15:42: Building MULTICAST UPDATE packet for ATM2/0, serno 15-16
01:15:42: Items: U15 U16
01:15:42: Packet acked from 150.4.100.14 (ATM2/0), serno 15-16
01:15:42: Flow blocking cleared on ATM2/0
01:15:42: Multicast acked from ATM2/0, serno 15-16
R13 installed the following ARP map:
Map list ATM2/0_ATM_ARP : DYNAMIC
arp maps to NSAP 47.009181000000123456781234.141414141414.00
, connection up, VC 18, VPI 0, VCI 73, ATM2/0
ip 150.4.100.14 maps to NSAP 47.009181000000123456781234.141414141414.00
, broadcast, connection up, VC 18, VPI 0, VCI 73, ATM2/0
This map finally times out.
Based on this output, it sounds to me that the multicast triggered the
connection (!) but unfortunately, I have no time to test further today.
I will definitely investigate a little bit more.
Thanks,
Fabrice #8609
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brian Dennis
Sent: Saturday, May 31, 2003 9:57 PM
To: 'Fabrice Bobes'; 'Daniel Cisco Group Study'; ccielab@groupstudy.com
Subject: RE: ATM SVCs + Routing Protocols
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 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:51 GMT-3