From: Kevin Tang (Kevin.Tang@telecom.co.nz)
Date: Fri Jun 20 2003 - 07:16:29 GMT-3
Hello, Brian
Have you find the solution?
Regards
K
-----Original Message-----
From: Brian Dennis [mailto:brian@labforge.com]
Sent: Sunday, 1 June 2003 17:00
To: 'Brian McGahan'; 'Fabrice Bobes'; 'Daniel Cisco Group Study';
ccielab@groupstudy.com
Subject: RE: ATM SVCs + Routing Protocols
Brian,
How is this going to solve the problem? The fundamental problem is that
a router will not send an ARP request to the ARP server for a layer 3
multicast address. As you and I know routing protocols need a layer 3 to
layer 2 mapping for the multicast/broadcast packets. The ARP server does
not provide this function directly and is why the router will not
initiate an ARP request for a layer 3 multicast address.
Routing protocols "can" function if a mapping already exists due to a
"unicast" packet initiating an ARP request but the multicast packets
themselves can not initiate the ARP request.
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brian McGahan
Sent: Saturday, May 31, 2003 2:58 PM
To: 'Fabrice Bobes'; 'Daniel Cisco Group Study'; ccielab@groupstudy.com
Subject: RE: ATM SVCs + Routing Protocols
Fabrice,
After further investigation, it looks like we're both right and
wrong on this issue. I'll give TAC a call on Monday, but it looks like
it's a bug.
Multicast can be passed over an ATM CLIP VC as a replicated
unicast, just as a broadcast packet is. By default, broadcast is
enabled on a CLIP VC, therefore multicast can pass over the VC as well.
The issue with this configuration, as you mentioned, is the
timing out of the dynamic ATM mapping. Based on how the IOS wants to
act, you will get either of the following outputs every 60 seconds:
00:05:12: ATMARP:(ATM3/0): Removing inactive map
This indicated that the dynamic ATM map has been inactive for
the past 60 seconds, and is being flushed.
Next, an EIGRP multicast packet is sent over the interface, and
the encapsulation fails:
00:05:16: ATM(ATM3/0) Send:Error in encapsulation, No VC for address
0xE000000A
A few seconds later, the ATM ARP is refreshed, and the process
starts over.
00:05:30: IP ARP: creating incomplete entry for IP address: 1.0.0.8
interface ATM3/0
00:05:30: ATMARP(ATM3/0): Sending ARP to 1.0.0.8
00:05:30: ATM(ATM3/0): Encapsulation error1, link=7, host=1000008
00:05:30: IP ARP throttled out the ARP Request for 1.0.0.8
00:05:30: ATMARP:(ATM3/0): ARP reply from 1.0.0.8 ->
47.009181000000001007476C01.888888888888.00
00:05:30: IP ARP throttled out the ARP Request for 1.0.0.8
00:05:30: ATMSM(ATM3/0): Attaching to VC #6 for type 1 traffic
00:05:30: ATMARP(ATM3/0): Opening VCC to
47.009181000000001007476C01.888888888888.00
00:14:12: ATMARP(ATM3/0): Sending ARP to 1.0.0.8
00:14:12: ATMARP:(ATM3/0): ARP reply from 1.0.0.8 ->
47.009181000000001007476C01.888888888888.00
00:14:12: ATMARP(ATM3/0): ARP Update from VCD#6 1.0.0.8 MAP VCD#6
As an alternative to this, IOS will automatically request and refresh
the ARP entry every 60 seconds. This is the correct behavior for the
VC:
00:26:12: ATMARP(ATM3/0): Sending ARP to 1.0.0.8
00:26:12: ATMARP:(ATM3/0): ARP reply from 1.0.0.8 ->
47.009181000000001007476C01.888888888888.00
00:26:12: ATMARP(ATM3/0): ARP Update from VCD#6 1.0.0.8 MAP VCD#6
00:27:12: ATMARP(ATM3/0): Sending ARP to 1.0.0.8
00:27:12: ATMARP:(ATM3/0): ARP reply from 1.0.0.8 ->
47.009181000000001007476C01.888888888888.00
00:27:12: ATMARP(ATM3/0): ARP Update from VCD#6 1.0.0.8 MAP VCD#6
00:28:12: ATMARP(ATM3/0): Sending ARP to 1.0.0.8
00:28:12: ATMARP:(ATM3/0): ARP reply from 1.0.0.8 ->
47.009181000000001007476C01.888888888888.00
00:28:12: ATMARP(ATM3/0): ARP Update from VCD#6 1.0.0.8 MAP VCD#6
Why is it choosing one over the other though? I'm not sure.
The config is exactly the same in either case. I'll post my further
findings on the issue, but as far as I can tell, it's not a
unicast/broadcast/multicast issue, it's an ATM mapping issue.
HTH
Brian McGahan, CCIE #8593
Director of Design and Implementation
brian@cyscoexpert.com
CyscoExpert Corporation
Internetwork Consulting & Training
Toll Free: 866-CyscoXP
Outside US: 847.674.3392
Fax: 847.674.2625
P.S. Here are the configs:
Rack6R6#sh ip eigrp nei
IP-EIGRP neighbors for process 1234
H Address Interface Hold Uptime SRTT RTO Q Seq
Type
(sec) (ms) Cnt Num
0 1.0.0.8 AT3/0 11 00:22:04 4 200 0 14
Rack6R6#sh run int atm3/0
Building configuration...
Current configuration : 211 bytes
!
interface ATM3/0
ip address 1.0.0.6 255.0.0.0
atm esi-address 666666666666.00
no atm ilmi-keepalive
atm arp-server nsap 47.009181000000001007476C01.888888888888.00
pvc 0/5 qsaal
!
pvc 0/16 ilmi
!
end
Rack6R6#sh run | b router eigrp 1234
router eigrp 1234
passive-interface Loopback0
network 1.0.0.0
network 6.0.0.0
auto-summary
eigrp log-neighbor-changes
Rack8R6#sh ip eigrp ne
IP-EIGRP neighbors for process 1024
IP-EIGRP neighbors for process 1234
H Address Interface Hold Uptime SRTT RTO Q Seq
Type
(sec) (ms) Cnt Num
0 1.0.0.6 AT3/0 14 00:23:08 4 200 0 14
Rack8R6#sh run int atm3/0
Building configuration...
Current configuration : 167 bytes
!
interface ATM3/0
ip address 1.0.0.8 255.0.0.0
atm esi-address 888888888888.00
no atm ilmi-keepalive
atm arp-server self
pvc 0/5 qsaal
!
pvc 0/16 ilmi
!
end
Rack8R6#sh run | b router eigrp 1234
router eigrp 1234
network 1.0.0.0
network 8.0.0.0
auto-summary
no eigrp log-neighbor-changes
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Fabrice Bobes
> Sent: Saturday, May 31, 2003 12:30 PM
> 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 communication, including any attachments, is confidential.
If you are not the intended recipient, you should not read
it - please contact me immediately, destroy it, and do not
copy or use any part of this communication or disclose
anything about it. Thank you."
------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:11:02 GMT-3