From: Cristian Henry H (chenry@reuna.cl)
Date: Tue Jun 10 2003 - 11:42:02 GMT-3
OSPF network point-to-multipoint over ATM CLIP mapping topolopy without
neighbor commnads works very well!
Daniel Cisco Group Study ha escrito:
>
> I'm just digesting this, and writing notes about the subject.....
>
> In summary, for ATM CLIP, you need Neighbor commands for all routing protocols which use multicasts:
>
> ie RIPv2, EIGRP, OSPF.
>
> Questions:
> (1) What about ISIS? Does this work properly over ATM CLIP?
>
> My thoughts.... ISIS uses CLNS multicasts(?) ..... ATM CLIP was designed for IP.... So, ISIS would not be supported unless you use some workaround like GRE tunnels????
>
> (2) What about RIPv1 & IGRP, which use broadcasts to 255.255.255.255. How is this handled by ATM CLIP? Would neighbor commands be required here as well?
>
> My thoughts..... same problems as with multicasts - need to get the SVC up in the first place. Therefore need neighbor commands.... ?
>
> Thanks.
>
> Daniel
>
> -----Original Message-----
> From: Fabrice Bobes [mailto:study@6colabs.com]
> Sent: Monday, 2 June 2003 12:59
> 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
> **********************************************************************
-- Cristian E. Henry REUNAE-mail: chenry@reuna.cl Fono: 56-2-3370336
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:10:56 GMT-3