ATM Problem [7:55238]
Greetings, I have a problem/question regarding a current ATM Circuit. Currently, our ATM cloud connects 4 of our sites. We submitted an order to add another site into the cloud. The telco provided the vpi's but only two sites communicate. Site C | | | Site A--- ATM CLOUD Site B | | | NEW Site Sites a, b, & c communicate correctly. The "NEW Site" was added but (pvc's to all sites), but will only communicate with Site A. Teloc has checked the VPI's and insists they are correct. Which brings up another strange item--All the VPI's were the same: New site Originating Destination 90 90 100 100 80 80 I have never noticed VPI's being the same on both ends,,Does this sound correct? OSPF is the routing protocol. But only "new site" and site a exchange info. Site A interface ATM5/0/0 ip address 192.68.135.66 255.255.255.240 ip pim sparse-mode ip ospf authentication-key 7 05180702014D43 ip ospf network non-broadcast map-group TEST atm pvc 1 35 40 aal5snap atm pvc 2 36 50 aal5snap atm pvc 5 95 95 aal5snap atm pvc 6 80 80 aal5snap no atm ilmi-keepalive map-list TEST ip 192.68.135.65 atm-vc 1 ip 192.68.135.67 atm-vc 2 broadcast ip 192.68.135.68 atm-vc 5 broadcast ip 192.68.135.68 atm-vc 6 broadcast NEW Site interface ATM3/0 ip address 192.68.135.68 255.255.255.240 ip ospf authentication-key 7 05180702014D43 ip ospf network non-broadcast map-group TEST atm pvc 1 95 95 aal5snap atm pvc 2 100 100 aal5snap no atm ilmi-keepalive map-list TEST ip 192.68.135.66 atm-vc 1 broadcast ip 192.68.135.65 atm-vc 2 broadcast Site C interface ATM1/0/0 ip address 192.68.135.65 255.255.255.240 ip ospf authentication-key 7 010007097B0A0B4F ip ospf network non-broadcast map-group TEST atm pvc 1 40 40 aal5snap atm pvc 2 100 100 aal5snap atm pvc 3 37 60 aal5snap no atm ilmi-keepalive map-list TEST ip 192.68.135.66 atm-vc 1 ip 192.68.135.67 atm-vc 3 ip 192.58.135.68 atm-vc 2 broadcast Any help is greatly appreciated! Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=55238&t=55238 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ATM Problem [7:55238]
Hi, The New site has 2 ATM PVCs defined, with a ip entry mapped to site A and C. Site C has a typo under it's map-list for the new site, going to 192.58.135.68 instead of 192.68.135.68. New site has no PVCs for site B yet configured. Also, this is multipoint non-broadcast interface so under OSPF you will neighbor statements. HTH, Erick --- Bill Smith wrote: > Greetings, > > I have a problem/question regarding a current ATM > Circuit. Currently, > our ATM cloud connects 4 of our sites. We > submitted an order to add > another site into the cloud. The telco provided the > vpi's but only two > sites communicate. > > > Site C > | > | > | > Site A--- ATM CLOUD Site B > | > | > | > NEW Site > > Sites a, b, & c communicate correctly. The "NEW > Site" was added but > (pvc's to all sites), but will only communicate with > Site A. Teloc has > checked the VPI's and insists they are correct. > Which brings up another > strange item--All the VPI's were the same: > > New site > Originating Destination > 9090 > 100 100 > 8080 > > I have never noticed VPI's being the same on both > ends,,Does this sound > correct? > > OSPF is the routing protocol. But only "new site" > and site a exchange > info. > > Site A > interface ATM5/0/0 > ip address 192.68.135.66 255.255.255.240 > ip pim sparse-mode > ip ospf authentication-key 7 05180702014D43 > ip ospf network non-broadcast > map-group TEST > atm pvc 1 35 40 aal5snap > atm pvc 2 36 50 aal5snap > atm pvc 5 95 95 aal5snap > atm pvc 6 80 80 aal5snap > no atm ilmi-keepalive > > map-list TEST > ip 192.68.135.65 atm-vc 1 > ip 192.68.135.67 atm-vc 2 broadcast > ip 192.68.135.68 atm-vc 5 broadcast > ip 192.68.135.68 atm-vc 6 broadcast > > > > NEW Site > interface ATM3/0 > ip address 192.68.135.68 255.255.255.240 > ip ospf authentication-key 7 05180702014D43 > ip ospf network non-broadcast > map-group TEST > atm pvc 1 95 95 aal5snap > atm pvc 2 100 100 aal5snap > no atm ilmi-keepalive > > > map-list TEST > ip 192.68.135.66 atm-vc 1 broadcast > ip 192.68.135.65 atm-vc 2 broadcast > > > > > Site C > interface ATM1/0/0 > ip address 192.68.135.65 255.255.255.240 > ip ospf authentication-key 7 010007097B0A0B4F > ip ospf network non-broadcast > map-group TEST > atm pvc 1 40 40 aal5snap > atm pvc 2 100 100 aal5snap > atm pvc 3 37 60 aal5snap > no atm ilmi-keepalive > > > map-list TEST > ip 192.68.135.66 atm-vc 1 > ip 192.68.135.67 atm-vc 3 > ip 192.58.135.68 atm-vc 2 broadcast > > Any help is greatly appreciated! [EMAIL PROTECTED] = "Those who are willing to trade freedom for security deserve neither freedom nor security." -- Benjamin Franklin __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=55239&t=55238 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: ATM Problem [7:55238]
Eric, Thank you for your response. It was a typo on my part entering the information in the posting. The map-list in the router does have the correct IP address. I have defined (many times) the additional PVC's on the "NEW SITE" router/map list without any success. I apologize, I should have stated that in my previous posting. I inserted the neighbor statements in the OSPF process, but no success. THE SHOw IP OSPF Neighbor statement shows ATTMPT/DROTHER for site "c" but eventually shows as being down. Also, I receive a message on the "new site" router " sent youngest key0".. Thank You for your assistance.. -Original Message- From: Erick B. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 7:58 PM To: Bill Smith; [EMAIL PROTECTED] Subject: Re: ATM Problem [7:55238] Hi, The New site has 2 ATM PVCs defined, with a ip entry mapped to site A and C. Site C has a typo under it's map-list for the new site, going to 192.58.135.68 instead of 192.68.135.68. New site has no PVCs for site B yet configured. Also, this is multipoint non-broadcast interface so under OSPF you will neighbor statements. HTH, Erick --- Bill Smith wrote: > Greetings, > > I have a problem/question regarding a current ATM > Circuit. Currently, > our ATM cloud connects 4 of our sites. We > submitted an order to add > another site into the cloud. The telco provided the > vpi's but only two > sites communicate. > > > Site C > | > | > | > Site A--- ATM CLOUD Site B > | > | > | > NEW Site > > Sites a, b, & c communicate correctly. The "NEW > Site" was added but > (pvc's to all sites), but will only communicate with > Site A. Teloc has > checked the VPI's and insists they are correct. > Which brings up another > strange item--All the VPI's were the same: > > New site > Originating Destination > 9090 > 100 100 > 8080 > > I have never noticed VPI's being the same on both > ends,,Does this sound > correct? > > OSPF is the routing protocol. But only "new site" > and site a exchange > info. > > Site A > interface ATM5/0/0 > ip address 192.68.135.66 255.255.255.240 > ip pim sparse-mode > ip ospf authentication-key 7 05180702014D43 > ip ospf network non-broadcast > map-group TEST > atm pvc 1 35 40 aal5snap > atm pvc 2 36 50 aal5snap > atm pvc 5 95 95 aal5snap > atm pvc 6 80 80 aal5snap > no atm ilmi-keepalive > > map-list TEST > ip 192.68.135.65 atm-vc 1 > ip 192.68.135.67 atm-vc 2 broadcast > ip 192.68.135.68 atm-vc 5 broadcast > ip 192.68.135.68 atm-vc 6 broadcast > > > > NEW Site > interface ATM3/0 > ip address 192.68.135.68 255.255.255.240 > ip ospf authentication-key 7 05180702014D43 > ip ospf network non-broadcast > map-group TEST > atm pvc 1 95 95 aal5snap > atm pvc 2 100 100 aal5snap > no atm ilmi-keepalive > > > map-list TEST > ip 192.68.135.66 atm-vc 1 broadcast > ip 192.68.135.65 atm-vc 2 broadcast > > > > > Site C > interface ATM1/0/0 > ip address 192.68.135.65 255.255.255.240 > ip ospf authentication-key 7 010007097B0A0B4F > ip ospf network non-broadcast > map-group TEST > atm pvc 1 40 40 aal5snap > atm pvc 2 100 100 aal5snap > atm pvc 3 37 60 aal5snap > no atm ilmi-keepalive > > > map-list TEST > ip 192.68.135.66 atm-vc 1 > ip 192.68.135.67 atm-vc 3 > ip 192.68.135.68 atm-vc 2 broadcast > > Any help is greatly appreciated! [EMAIL PROTECTED] = "Those who are willing to trade freedom for security deserve neither freedom nor security." -- Benjamin Franklin __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=55241&t=55238 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: ATM Problem [7:55238]
Bill, No problem. Well, lets start by trying to ping sites a, b and C from the new sites router console/telnet session. This way the ping is direct. If were able to do this then the PVC and map-list entries are correct. If the above doesn't work, then you'll need to verify the carrier has the PVCs mapped end-to-end correctly in their network. The ATM physical circuit might be fine and dandy but if they have multiple ATM switches this goes through and they have a mis-match in their PVC mappings then it isn't going to work. HTH, Erick --- Bill Smith wrote: > Eric, > > Thank you for your response. It was a typo on my > part entering the > information in the posting. The map-list in the > router does have the > correct IP address. > I have defined (many times) the additional PVC's on > the "NEW SITE" > router/map list without any success. I apologize, I > should have stated > that in my previous posting. > > I inserted the neighbor statements in the OSPF > process, but no success. > THE SHOw IP OSPF Neighbor statement shows > ATTMPT/DROTHER for site "c" > but eventually shows as being down. Also, I > receive a message on the > "new site" router " sent youngest key0".. > > Thank You for your assistance.. > > > -Original Message- > From: Erick B. [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 09, 2002 7:58 PM > To: Bill Smith; [EMAIL PROTECTED] > Subject: Re: ATM Problem [7:55238] > > Hi, > > The New site has 2 ATM PVCs defined, with a ip entry > mapped to site A and C. Site C has a typo under it's > map-list for the new site, going to 192.58.135.68 > instead of 192.68.135.68. New site has no PVCs for > site B yet configured. > > Also, this is multipoint non-broadcast interface so > under OSPF you will neighbor statements. > > HTH, Erick > > --- Bill Smith wrote: > > Greetings, > > > > I have a problem/question regarding a current ATM > > Circuit. Currently, > > our ATM cloud connects 4 of our sites. We > > submitted an order to add > > another site into the cloud. The telco provided > the > > vpi's but only two > > sites communicate. > > > > > > Site C > > | > > | > > | > > Site A--- ATM CLOUD Site > B > > | > > | > > | > > NEW Site > > > > Sites a, b, & c communicate correctly. The "NEW > > Site" was added but > > (pvc's to all sites), but will only communicate > with > > Site A. Teloc has > > checked the VPI's and insists they are correct. > > Which brings up another > > strange item--All the VPI's were the same: > > > > New site > > Originating Destination > > 90 90 > > 100 100 > > 80 80 > > > > I have never noticed VPI's being the same on both > > ends,,Does this sound > > correct? > > > > OSPF is the routing protocol. But only "new site" > > and site a exchange > > info. > > > > Site A > > interface ATM5/0/0 > > ip address 192.68.135.66 255.255.255.240 > > ip pim sparse-mode > > ip ospf authentication-key 7 05180702014D43 > > ip ospf network non-broadcast > > map-group TEST > > atm pvc 1 35 40 aal5snap > > atm pvc 2 36 50 aal5snap > > atm pvc 5 95 95 aal5snap > > atm pvc 6 80 80 aal5snap > > no atm ilmi-keepalive > > > > map-list TEST > > ip 192.68.135.65 atm-vc 1 > > ip 192.68.135.67 atm-vc 2 broadcast > > ip 192.68.135.68 atm-vc 5 broadcast > > ip 192.68.135.68 atm-vc 6 broadcast > > > > > > > > NEW Site > > interface ATM3/0 > > ip address 192.68.135.68 255.255.255.240 > > ip ospf authentication-key 7 05180702014D43 > > ip ospf network non-broadcast > > map-group TEST > > atm pvc 1 95 95 aal5snap > > atm pvc 2 100 100 aal5snap > > no atm ilmi-keepalive > > > > > > map-list TEST > > ip 192.68.135.66 atm-vc 1 broadcast > > ip 192.68.135.65 atm-vc 2 broadcast > > > > > > > > > > Site C > > interface ATM1/0/0 > > ip address 192.68.135.65 255.255.255.240 > > ip ospf authentication-key 7 010007097B0A0B4F > > ip ospf network non-broadcast > >
RE: ATM Problem [7:55238]
Eric, I appreciate your help. SITE A--PINGS ALL SITES SITE C-- PINGS ALL but "new site" NEW SITE--PINGS SITE A ONLY -Original Message- From: Erick B. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 8:30 PM To: Bill Smith; [EMAIL PROTECTED] Subject: RE: ATM Problem [7:55238] Bill, No problem. Well, lets start by trying to ping sites a, b and C from the new sites router console/telnet session. This way the ping is direct. If were able to do this then the PVC and map-list entries are correct. If the above doesn't work, then you'll need to verify the carrier has the PVCs mapped end-to-end correctly in their network. The ATM physical circuit might be fine and dandy but if they have multiple ATM switches this goes through and they have a mis-match in their PVC mappings then it isn't going to work. HTH, Erick --- Bill Smith wrote: > Eric, > > Thank you for your response. It was a typo on my > part entering the > information in the posting. The map-list in the > router does have the > correct IP address. > I have defined (many times) the additional PVC's on > the "NEW SITE" > router/map list without any success. I apologize, I > should have stated > that in my previous posting. > > I inserted the neighbor statements in the OSPF > process, but no success. > THE SHOw IP OSPF Neighbor statement shows > ATTMPT/DROTHER for site "c" > but eventually shows as being down. Also, I > receive a message on the > "new site" router " sent youngest key0".. > > Thank You for your assistance.. > > > -Original Message----- > From: Erick B. [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 09, 2002 7:58 PM > To: Bill Smith; [EMAIL PROTECTED] > Subject: Re: ATM Problem [7:55238] > > Hi, > > The New site has 2 ATM PVCs defined, with a ip entry > mapped to site A and C. Site C has a typo under it's > map-list for the new site, going to 192.58.135.68 > instead of 192.68.135.68. New site has no PVCs for > site B yet configured. > > Also, this is multipoint non-broadcast interface so > under OSPF you will neighbor statements. > > HTH, Erick > > --- Bill Smith wrote: > > Greetings, > > > > I have a problem/question regarding a current ATM > > Circuit. Currently, > > our ATM cloud connects 4 of our sites. We > > submitted an order to add > > another site into the cloud. The telco provided > the > > vpi's but only two > > sites communicate. > > > > > > Site C > > | > > | > > | > > Site A--- ATM CLOUD Site > B > > | > > | > > | > > NEW Site > > > > Sites a, b, & c communicate correctly. The "NEW > > Site" was added but > > (pvc's to all sites), but will only communicate > with > > Site A. Teloc has > > checked the VPI's and insists they are correct. > > Which brings up another > > strange item--All the VPI's were the same: > > > > New site > > Originating Destination > > 90 90 > > 100 100 > > 80 80 > > > > I have never noticed VPI's being the same on both > > ends,,Does this sound > > correct? > > > > OSPF is the routing protocol. But only "new site" > > and site a exchange > > info. > > > > Site A > > interface ATM5/0/0 > > ip address 192.68.135.66 255.255.255.240 > > ip pim sparse-mode > > ip ospf authentication-key 7 05180702014D43 > > ip ospf network non-broadcast > > map-group TEST > > atm pvc 1 35 40 aal5snap > > atm pvc 2 36 50 aal5snap > > atm pvc 5 95 95 aal5snap > > atm pvc 6 80 80 aal5snap > > no atm ilmi-keepalive > > > > map-list TEST > > ip 192.68.135.65 atm-vc 1 > > ip 192.68.135.67 atm-vc 2 broadcast > > ip 192.68.135.68 atm-vc 5 broadcast > > ip 192.68.135.68 atm-vc 6 broadcast > > > > > > > > NEW Site > > interface ATM3/0 > > ip address 192.68.135.68 255.255.255.240 > > ip ospf authentication-key 7 05180702014D43 > > ip ospf network non-broadcast > > map-group TEST > > atm pvc 1 95 95 aal5snap > > atm pvc 2 100 100 aal5snap > > no atm ilmi-keepalive > > > > > > map-list TEST > >
Re: ATM Problem [7:55238]
Again, not claiming to know a lot of ATM, but certainly understanding telcos who don't configure their part correctly.. does your carrier use ILMI at all? if so, you could set up ILMI and then do a debug to see what the telco is sending you. I'm trying to recall if there is a downside to doing a debug atm events of debug atm packet. seems to me I've locked up routers issuing one or the other of those. debug atm packet will show you activity links to pvc's - which in turn can tell you if anything other than keepalives are happening. as with frame relay dlci's, atm vpi / vci numbers are locally significant. I've done a number of RLAN's now ( DSL to ATM ) and the telco I work for has a convention such that anything from the DSLAM to the customer prem is pvc 0/35 and from the host ATM side the PVC represents a particular DSLAM and a particular port on that DSLAM. 2/27 would be DSLAM 2, port 27, etc. just about every problem I've encountered on an RLAN is the result of misconfiguration at the DSL / ATM handoff. best wishes ""Bill Smith"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Eric, > > I appreciate your help. > > SITE A--PINGS ALL SITES > SITE C-- PINGS ALL but "new site" > NEW SITE--PINGS SITE A ONLY > > -Original Message- > From: Erick B. [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 09, 2002 8:30 PM > To: Bill Smith; [EMAIL PROTECTED] > Subject: RE: ATM Problem [7:55238] > > Bill, > > No problem. Well, lets start by trying to ping sites > a, b and C from the new sites router console/telnet > session. This way the ping is direct. If were able to > do this then the PVC and map-list entries are correct. > > > If the above doesn't work, then you'll need to verify > the carrier has the PVCs mapped end-to-end correctly > in their network. The ATM physical circuit might be > fine and dandy but if they have multiple ATM switches > this goes through and they have a mis-match in their > PVC mappings then it isn't going to work. > > HTH, Erick > > --- Bill Smith wrote: > > Eric, > > > > Thank you for your response. It was a typo on my > > part entering the > > information in the posting. The map-list in the > > router does have the > > correct IP address. > > I have defined (many times) the additional PVC's on > > the "NEW SITE" > > router/map list without any success. I apologize, I > > should have stated > > that in my previous posting. > > > > I inserted the neighbor statements in the OSPF > > process, but no success. > > THE SHOw IP OSPF Neighbor statement shows > > ATTMPT/DROTHER for site "c" > > but eventually shows as being down. Also, I > > receive a message on the > > "new site" router " sent youngest key0".. > > > > Thank You for your assistance.. > > > > > > -Original Message- > > From: Erick B. [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, October 09, 2002 7:58 PM > > To: Bill Smith; [EMAIL PROTECTED] > > Subject: Re: ATM Problem [7:55238] > > > > Hi, > > > > The New site has 2 ATM PVCs defined, with a ip entry > > mapped to site A and C. Site C has a typo under it's > > map-list for the new site, going to 192.58.135.68 > > instead of 192.68.135.68. New site has no PVCs for > > site B yet configured. > > > > Also, this is multipoint non-broadcast interface so > > under OSPF you will neighbor statements. > > > > HTH, Erick > > > > --- Bill Smith wrote: > > > Greetings, > > > > > > I have a problem/question regarding a current ATM > > > Circuit. Currently, > > > our ATM cloud connects 4 of our sites. We > > > submitted an order to add > > > another site into the cloud. The telco provided > > the > > > vpi's but only two > > > sites communicate. > > > > > > > > > Site C > > > | > > > | > > > | > > > Site A--- ATM CLOUD Site > > B > > > | > > > | > > > | > > > NEW Site > > > > > > Sites a, b, & c communicate correctly. The "NEW > > > Site" was added but > > > (pvc's to all sites), but will only communicate > > with > > > Site A. Teloc has > > > checked the VPI's and insists they are correct. > > > Which brings up another > > > strange item--All the VPI's were the same: >
RE: ATM Problem [7:55238]
If these are indeed PVP's being supplied, then you should be able to check PNNI to make sure everyone sees each other. You PNNI masking may be off, double check everyone has the same PNNI level mask applied to the NSAP Nodes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Smith Sent: Wednesday, October 09, 2002 5:37 PM To: [EMAIL PROTECTED] Subject: RE: ATM Problem [7:55238] Eric, I appreciate your help. SITE A--PINGS ALL SITES SITE C-- PINGS ALL but "new site" NEW SITE--PINGS SITE A ONLY -Original Message- From: Erick B. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 8:30 PM To: Bill Smith; [EMAIL PROTECTED] Subject: RE: ATM Problem [7:55238] Bill, No problem. Well, lets start by trying to ping sites a, b and C from the new sites router console/telnet session. This way the ping is direct. If were able to do this then the PVC and map-list entries are correct. If the above doesn't work, then you'll need to verify the carrier has the PVCs mapped end-to-end correctly in their network. The ATM physical circuit might be fine and dandy but if they have multiple ATM switches this goes through and they have a mis-match in their PVC mappings then it isn't going to work. HTH, Erick --- Bill Smith wrote: > Eric, > > Thank you for your response. It was a typo on my > part entering the > information in the posting. The map-list in the > router does have the > correct IP address. > I have defined (many times) the additional PVC's on > the "NEW SITE" > router/map list without any success. I apologize, I > should have stated > that in my previous posting. > > I inserted the neighbor statements in the OSPF > process, but no success. > THE SHOw IP OSPF Neighbor statement shows > ATTMPT/DROTHER for site "c" > but eventually shows as being down. Also, I > receive a message on the > "new site" router " sent youngest key0".. > > Thank You for your assistance.. > > > -Original Message- > From: Erick B. [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 09, 2002 7:58 PM > To: Bill Smith; [EMAIL PROTECTED] > Subject: Re: ATM Problem [7:55238] > > Hi, > > The New site has 2 ATM PVCs defined, with a ip entry > mapped to site A and C. Site C has a typo under it's > map-list for the new site, going to 192.58.135.68 > instead of 192.68.135.68. New site has no PVCs for > site B yet configured. > > Also, this is multipoint non-broadcast interface so > under OSPF you will neighbor statements. > > HTH, Erick > > --- Bill Smith wrote: > > Greetings, > > > > I have a problem/question regarding a current ATM > > Circuit. Currently, > > our ATM cloud connects 4 of our sites. We > > submitted an order to add > > another site into the cloud. The telco provided > the > > vpi's but only two > > sites communicate. > > > > > > Site C > > | > > | > > | > > Site A--- ATM CLOUD Site > B > > | > > | > > | > > NEW Site > > > > Sites a, b, & c communicate correctly. The "NEW > > Site" was added but > > (pvc's to all sites), but will only communicate > with > > Site A. Teloc has > > checked the VPI's and insists they are correct. > > Which brings up another > > strange item--All the VPI's were the same: > > > > New site > > Originating Destination > > 90 90 > > 100 100 > > 80 80 > > > > I have never noticed VPI's being the same on both ends,,Does this > > sound correct? > > > > OSPF is the routing protocol. But only "new site" > > and site a exchange > > info. > > > > Site A > > interface ATM5/0/0 > > ip address 192.68.135.66 255.255.255.240 > > ip pim sparse-mode > > ip ospf authentication-key 7 05180702014D43 > > ip ospf network non-broadcast > > map-group TEST > > atm pvc 1 35 40 aal5snap > > atm pvc 2 36 50 aal5snap > > atm pvc 5 95 95 aal5snap > > atm pvc 6 80 80 aal5snap > > no atm ilmi-keepalive > > > > map-list TEST > > ip 192.68.135.65 atm-vc 1 > > ip 192.68.135.67 atm-vc 2 broadcast > > ip 192.68.135.68 atm-vc 5 broadcast > > ip 192.68.135.68 atm-vc 6 broadcast > > > &
RE: ATM Problem [7:55238]
router is a Cisco 827. For other brand CPE routers, the pvc is different. Randall -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of The Long and Winding Road Sent: Wednesday, October 09, 2002 09:32 PM To: [EMAIL PROTECTED] Subject: Re: ATM Problem [7:55238] Again, not claiming to know a lot of ATM, but certainly understanding telcos who don't configure their part correctly.. does your carrier use ILMI at all? if so, you could set up ILMI and then do a debug to see what the telco is sending you. I'm trying to recall if there is a downside to doing a debug atm events of debug atm packet. seems to me I've locked up routers issuing one or the other of those. debug atm packet will show you activity links to pvc's - which in turn can tell you if anything other than keepalives are happening. as with frame relay dlci's, atm vpi / vci numbers are locally significant. I've done a number of RLAN's now ( DSL to ATM ) and the telco I work for has a convention such that anything from the DSLAM to the customer prem is pvc 0/35 and from the host ATM side the PVC represents a particular DSLAM and a particular port on that DSLAM. 2/27 would be DSLAM 2, port 27, etc. just about every problem I've encountered on an RLAN is the result of misconfiguration at the DSL / ATM handoff. best wishes ""Bill Smith"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Eric, > > I appreciate your help. > > SITE A--PINGS ALL SITES > SITE C-- PINGS ALL but "new site" > NEW SITE--PINGS SITE A ONLY > > -Original Message- > From: Erick B. [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 09, 2002 8:30 PM > To: Bill Smith; [EMAIL PROTECTED] > Subject: RE: ATM Problem [7:55238] > > Bill, > > No problem. Well, lets start by trying to ping sites > a, b and C from the new sites router console/telnet > session. This way the ping is direct. If were able to > do this then the PVC and map-list entries are correct. > > > If the above doesn't work, then you'll need to verify > the carrier has the PVCs mapped end-to-end correctly > in their network. The ATM physical circuit might be > fine and dandy but if they have multiple ATM switches > this goes through and they have a mis-match in their > PVC mappings then it isn't going to work. > > HTH, Erick > > --- Bill Smith wrote: > > Eric, > > > > Thank you for your response. It was a typo on my > > part entering the > > information in the posting. The map-list in the > > router does have the > > correct IP address. > > I have defined (many times) the additional PVC's on > > the "NEW SITE" > > router/map list without any success. I apologize, I > > should have stated > > that in my previous posting. > > > > I inserted the neighbor statements in the OSPF > > process, but no success. > > THE SHOw IP OSPF Neighbor statement shows > > ATTMPT/DROTHER for site "c" > > but eventually shows as being down. Also, I > > receive a message on the > > "new site" router " sent youngest key0".. > > > > Thank You for your assistance.. > > > > > > -Original Message- > > From: Erick B. [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, October 09, 2002 7:58 PM > > To: Bill Smith; [EMAIL PROTECTED] > > Subject: Re: ATM Problem [7:55238] > > > > Hi, > > > > The New site has 2 ATM PVCs defined, with a ip entry > > mapped to site A and C. Site C has a typo under it's > > map-list for the new site, going to 192.58.135.68 > > instead of 192.68.135.68. New site has no PVCs for > > site B yet configured. > > > > Also, this is multipoint non-broadcast interface so > > under OSPF you will neighbor statements. > > > > HTH, Erick > > > > --- Bill Smith wrote: > > > Greetings, > > > > > > I have a problem/question regarding a current ATM > > > Circuit. Currently, > > > our ATM cloud connects 4 of our sites. We > > > submitted an order to add > > > another site into the cloud. The telco provided > > the > > > vpi's but only two > > > sites communicate. > > > > > > > > > Site C > > > | > > > | > > > | > > > Site A--- ATM CLOUD Site > > B > > > | > > > | > > > | > > > NEW Site > > > > > > Sites a, b, & c communicate correctly. The "NEW > > > Site
FW: ATM Problem [7:55238]
Regarding RLAN (DSL to ATM), I think pvc "0/35" tells the DSLAM that the CPE router is a Cisco 827. For other brand CPE routers, the pvc is different. Randall -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of The Long and Winding Road Sent: Wednesday, October 09, 2002 09:32 PM To: [EMAIL PROTECTED] Subject: Re: ATM Problem [7:55238] Again, not claiming to know a lot of ATM, but certainly understanding telcos who don't configure their part correctly.. does your carrier use ILMI at all? if so, you could set up ILMI and then do a debug to see what the telco is sending you. I'm trying to recall if there is a downside to doing a debug atm events of debug atm packet. seems to me I've locked up routers issuing one or the other of those. debug atm packet will show you activity links to pvc's - which in turn can tell you if anything other than keepalives are happening. as with frame relay dlci's, atm vpi / vci numbers are locally significant. I've done a number of RLAN's now ( DSL to ATM ) and the telco I work for has a convention such that anything from the DSLAM to the customer prem is pvc 0/35 and from the host ATM side the PVC represents a particular DSLAM and a particular port on that DSLAM. 2/27 would be DSLAM 2, port 27, etc. just about every problem I've encountered on an RLAN is the result of misconfiguration at the DSL / ATM handoff. best wishes ""Bill Smith"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Eric, > > I appreciate your help. > > SITE A--PINGS ALL SITES > SITE C-- PINGS ALL but "new site" > NEW SITE--PINGS SITE A ONLY > > -Original Message- > From: Erick B. [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 09, 2002 8:30 PM > To: Bill Smith; [EMAIL PROTECTED] > Subject: RE: ATM Problem [7:55238] > > Bill, > > No problem. Well, lets start by trying to ping sites > a, b and C from the new sites router console/telnet > session. This way the ping is direct. If were able to > do this then the PVC and map-list entries are correct. > > > If the above doesn't work, then you'll need to verify > the carrier has the PVCs mapped end-to-end correctly > in their network. The ATM physical circuit might be > fine and dandy but if they have multiple ATM switches > this goes through and they have a mis-match in their > PVC mappings then it isn't going to work. > > HTH, Erick > > --- Bill Smith wrote: > > Eric, > > > > Thank you for your response. It was a typo on my > > part entering the > > information in the posting. The map-list in the > > router does have the > > correct IP address. > > I have defined (many times) the additional PVC's on > > the "NEW SITE" > > router/map list without any success. I apologize, I > > should have stated > > that in my previous posting. > > > > I inserted the neighbor statements in the OSPF > > process, but no success. > > THE SHOw IP OSPF Neighbor statement shows > > ATTMPT/DROTHER for site "c" > > but eventually shows as being down. Also, I > > receive a message on the > > "new site" router " sent youngest key0".. > > > > Thank You for your assistance.. > > > > > > -Original Message- > > From: Erick B. [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, October 09, 2002 7:58 PM > > To: Bill Smith; [EMAIL PROTECTED] > > Subject: Re: ATM Problem [7:55238] > > > > Hi, > > > > The New site has 2 ATM PVCs defined, with a ip entry > > mapped to site A and C. Site C has a typo under it's > > map-list for the new site, going to 192.58.135.68 > > instead of 192.68.135.68. New site has no PVCs for > > site B yet configured. > > > > Also, this is multipoint non-broadcast interface so > > under OSPF you will neighbor statements. > > > > HTH, Erick > > > > --- Bill Smith wrote: > > > Greetings, > > > > > > I have a problem/question regarding a current ATM > > > Circuit. Currently, > > > our ATM cloud connects 4 of our sites. We > > > submitted an order to add > > > another site into the cloud. The telco provided > > the > > > vpi's but only two > > > sites communicate. > > > > > > > > > Site C > > > | > > > | > > > | > > > Site A--- ATM CLOUD Site > > B > > > | > > > | > > > | > > > NEW Site > > > > >
Re: ATM Problem [7:55238]
Actually, the pvc 0/35 is just to put numbers in the holes. We have DSL customers over our ATM circuits using every type of router imaginable from speedstream to cisco and they all always have the same pvc on their end. Just my nickel's worth. :) Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=55273&t=55238 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
