Your dialer map statement associates the IP address 172.16.1.2 with the telephone number 5554000. All that isdn1 knows is that it must dial 5554000 if it needs to get to 172.16.1.2.
By adding the name statements, when isdn1 receives a call from isdn2 it associates this call with the dialer map statement i.e. it knows it already has that link up and will not try to open another one when it needs to get back to 172.16.1.2. Whether this is the correct terminology/logic I do not know, but it seems to be the way it works and it's the way I keep it straight (ish) in my head. If you find the real explanation (if it's different) I'd be interested to hear. Cheers, Gaz ""Pierre-Alex Guanel"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Ok, here are the result of my tests (cummulative) > > 1) I gave the loopbacks unique IP addresses and tested > > result: no change > > 2) I assigned isdn1 f0/0 to vlan11 and isdn f0/0 to vlan12 > on isdn1 f0/0 ip address was 192.168.10.1/24 > on isdn2 f0/0 ip address was 192.168.20.1/24 > > I left the default route unchanged on both routers and tested > > result: no change > > > 3) I remove the default route and created specific routes instead > > on isdn1: ip route 192.168.10.0 255.255.255.0 172.16.1.2 > on isdn2: ip route 192.168.20.0 255.255.255.0 172.16.1.1 > > result: no change. When the first bri channel was up, I was able to ping nor > the two fast ethernet interfaces nor the two bri interface. Strange!!! > > > 4) I added the keyword "name" to each map statement (as suggested by Gaz) > > on isnd1:dialer map ip 172.16.1.2 name isdn2 broadcast 5554000 > on isdn2:dialer map ip 172.16.1.1 name isdn1 broadcast 5551234 > > result: double success. RouterA (isdn1) did not try to initiate another > connection AND I was able to ping the fast ethernet interfaces and the bri > interfaces. > > See below: > > isdn2#ping 192.168.10.1 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds: > > 01:12:30: ISDN BR0/0: RX on B1 at 64 Kb/s > 01:12:30: ISDN BR0/0: Event: Accepting the call id 0x10 > 01:12:131009057551: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up > 01:12:30: ISDN BR0/0: TX -> CALL_PROC pd = 8 callref = 0x94 > 01:12:30: Channel ID i = 0x89 > 01:12:30: ISDN BR0/0: TX -> CONNECT pd = 8 callref = 0x94 > 01:12:30: Channel ID i = 0x89 > 01:12:30: ISDN BR0/0: RX 03:55:06: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up. > 01:12:32: BR0/0:1 DDR: dialer protocol up.!!! > Success rate is 60 percent (3/5), round-trip min/avg/max = 32/32/32 ms > isdn2# > 01:12:33: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:1, changed > state to > up > 03:55:09: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:1, changed > state to > up > > Now that the problem is solved (thanks Gaz, Daniel, Ahoang and Thomas), we > need to understand the reasons for the behavior of router A . To summarize: > > 1) Without the "name" keyword, routerA attempts to initiate a connection on > receiving a connection initiated by router B. > > 2) Once the channel setup from B is up, data traffic does not flow even with > proper routes. > > My gut feeling is that "name" keyword is preventing data traffic to flow > between the two routers , even when the channel is up! This would explain > why routeA is attempting to open a new connection even though there is a > channel already up. routerA must be thinking that it is not allowed to use > the already existing channel to reply to router B ... but then it would mean > that something must have leaked from A to B to prone routerA to initiate a > connection ... > but what if not ip data? > > I will do some more research on this and post my findings&remaks&questions > in a next post. > > > Pierre-Alex Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=46666&t=46496 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
