From: simon hart (simon@harttel.com)
Date: Tue Oct 04 2005 - 17:29:47 GMT-3
Victor,
Yes kind off right. There are some missing elements to your config that
would be needed to get to this to work. Say for instance that R1 is calling
R2 over an ISDN link, then how does R2 know which dialer interface to bind
to the physical BRI?
As far as I am aware there are two options
dialer caller
&
ppp pap
By using the dialer caller command, the IOS will see the calling line id and
associate it with the dialer interface. This is only good if you want if
you have mutliple dialer interfaces for multiple callers.
With ppp pap you will need to configure ppp authentication pap under the
physical bri0 interface. Then you would need a dialer remote-name statement
under the dialer interface that matches the ppp pap sent-username.
Simon
-----Original Message-----
From: Victor Cappuccio [mailto:cvictor@protokolgroup.com]
Sent: 04 October 2005 19:57
To: simon hart
Cc: CCIEBOB; ccielab@groupstudy.com
Subject: Re: Internetwork Expert Lab 2 - 8.5
I do not have Internetwork Expert, I wish, but there is now a a
time/pocket factor
So looking at
http://127.0.0.1:8080/cc/td/doc/product/software/ios122/122cgcr/fdial_c/fnsp
rt5/dcdiprof.htm#xtocid5
I assume that this could be:.
interface type number (BRI0/0/0)
encapsulation ppp
dialer pool-member number [priority priority] **
interface dialer 1
ip address address mask
encapsulation type (this is not clear in the documentation since the
encapsulation for the physical interface has already establish ppp Thought?)
dialer string dial-string class class-name - Remote side phone
dialer pool number **
dialer-group group-number ACL 1
Then
interface dialer 2
ip address address mask
encapsulation type
dialer string dial-string class class-name - Remote side phone
dialer pool number **
dialer-group group-number ACL 2 (permiting IPV6)
Is this logic correct Simon?
Victor
simon hart wrote:
>I have not seen the answers to this lab, however you can do this by
creating
>dialer interfaces on R5. Then one dialer interface will be the backup for
a
>frame connection, and the other dialer interface can be used for IPv6
>connectivity
>
>Simon
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>CCIEBOB
>Sent: 04 October 2005 02:44
>To: ccielab@groupstudy.com
>Subject: Internetwork Expert Lab 2 - 8.5
>
>
>8.5. Ensure that R5 can trigger an ISDN call to R4 based on any
>IPv6 traffic.
>
>
>
>I don't think this is possible since the interface has been previously
>configured for a backup interface.
>
>
>
>Is this correct or is their a way around this?
>
>
>
>TIA
>
>
>
>
>
>
>
>R5#ping 2001:CC1E:1:4545::4
>
>
>
>Type escape sequence to abort.
>
>Sending 5, 100-byte ICMP Echos to 2001:CC1E:1:4545::4, timeout is 2
seconds:
>
>
>
>*Mar 5 00:10:55.820: IPv6: SAS picked source 2001:CC1E:1::5 for
>2001:CC1E:1:4545::4 (Loopback0)
>
>*Mar 5 00:10:55.820: IPV6: source 2001:CC1E:1::5 (local)
>
>*Mar 5 00:10:55.820: dest 2001:CC1E:1:4545::4
>
>*Mar 5 00:10:55.824: traffic class 0, flow 0x0, len 100+0, prot 58,
>hops 64, Route not found.
>
>*Mar 5 00:10:57.824: IPV6: source 2001:CC1E:1::5 (local)
>
>*Mar 5 00:10:57.824: dest 2001:CC1E:1:4545::4
>
>*Mar 5 00:10:57.824: traffic class 0, flow 0x0, len 100+0, prot 58,
>hops 64, Route not found.
>
>*Mar 5 00:10:59.824: IPV6: source 2001:CC1E:1::5 (local)
>
>*Mar 5 00:10:59.824: dest 2001:CC1E:1:4545::4
>
>*Mar 5 00:10:59.824: traffic class 0, flow 0x0, len 100+0, prot 58,
>hops 64, Route not found.
>
>*Mar 5 00:11:01.824: IPV6: source 2001:CC1E:1::5 (local)
>
>*Mar 5 00:11:01.824: dest 2001:CC1E:1:4545::4
>
>*Mar 5 00:11:01.824: traffic class 0, flow 0x0, len 100+0, prot 58,
>hops 64, Route not found.
>
>*Mar 5 00:11:03.824: IPV6: source 2001:CC1E:1::5 (local)
>
>*Mar 5 00:11:03.824: dest 2001:CC1E:1:4545::4
>
>*Mar 5 00:11:03.824: traffic class 0, flow 0x0, len 100+0, prot 58,
>hops 64, Route not found.
>
>Success rate is 0 percent (0/5)
>
>R5#sho ipv6 route
>
>IPv6 Routing Table - 3 entries
>
>Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
>
> U - Per-user Static route
>
> I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
>
> O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
>
>LC 2001:CC1E:1::5/128 [0/0]
>
> via ::, Loopback0
>
>L FE80::/10 [0/0]
>
> via ::, Null0
>
>L FF00::/8 [0/0]
>
> via ::, Null0
>
>
>
>R5#sho ipv6 inter brief
>
>FastEthernet0/0 [up/up]
>
> unassigned
>
>Serial0/0 [up/up]
>
> unassigned
>
>Serial0/0.1 [up/up]
>
> unassigned
>
>BRI0/0 [standby mode/down]
>
> FE80::207:EFF:FEBA:E9A0
>
> 2001:CC1E:1:4545::5
>
>BRI0/0:1 [administratively down/down]
>
> unassigned
>
>BRI0/0:2 [administratively down/down]
>
> unassigned
>
>FastEthernet0/1 [up/up]
>
> unassigned
>
>Virtual-Access1 [up/up]
>
> unassigned
>
>Loopback0 [up/up]
>
> FE80::207:EFF:FEBA:E9A0
>
> 2001:CC1E:1::5
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>--
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.344 / Virus Database: 267.11.9/116 - Release Date: 30/09/2005
>
>--
>No virus found in this outgoing message.
>Checked by AVG Anti-Virus.
>Version: 7.0.344 / Virus Database: 267.11.9/116 - Release Date: 30/09/2005
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>
>
>
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.9/116 - Release Date: 30/09/2005-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.9/116 - Release Date: 30/09/2005
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:49 GMT-3