Why does not a dialer interface need a "dialer string"?

[fastethernet0]

Hi guys, when connecting an ISP using xDSL why does not it need a "dialer string"? The dialer interface is not supposed to make a call or dial or something like that? Thanks.

[Peter Paluch · Accepted solution]

Hi,

DSL technologies do not make calls across your  telephone network at all. They just use the wires connecting your home  or office to the nearest telephone exchange (the so-called local loop)  to transmit data over significantly higher frequencies than what would  be allowed to pass through the telephone exchange. These DSL signals are  branched off before the telephone exchange and diverted to a DSL Access  Multiplexer (DSLAM) while voice signals continue to be processed by the  telephone exchange. On the DSLAM, the DSL signals are processed as data  and subsequently carried over the provider's data network.

So because the DSL signals are not in fact carried  through telephone exchanges, no calls are made, and consequently, there  is no dialer string necessary. The DSL is an always-on technology - as  soon as you plug your DSL modem or router to the phone line, it starts  to talk over the line to the nearest DSLAM right away.

Please feel welcome to ask further!

Best regards,

Peter

[fastethernet0]

Thanks Peter, as you see below is a sample configuration of a dialer interface for ISDN.

Actually there is no much diffrence between xDSL and ISDN when comes to configure a dialer interface.  What makes me confuse is that if xDSL doesn't use the dialer interface  for dialing(or call) why does it need a "dialer interface"? And how does  the dialer interface know it is going to use a xDSL or ISDN?  if there  is no  

dialer string 2310559500

command, it means it is going to use xDSL?

R1(config)#interface dialer 0

R1(config-if)#description Internet-Dialup

R1(config-if)#ip address negotiated

R1(config-if)#encapsulation ppp

R1(config-if)#ppp authentication chap pap callin

R1(config-if)#ppp chap hostname abc

R1(config-if)#ppp chap password cisco

R1(config-if)#ppp pap sent-username abc password cisco

R1(config-if)#dialer string 2310559500

R1(config-if)#dialer pool 5

R1(config-if)#dialer-group 1

R1(config-if)#ip nat outside

[Peter Paluch · Accepted solution]

Hi,

Actually there is no much diffrence between xDSL and ISDN when comes to configure a dialer interface. 

Yes, that is true. Whether you are using an analog dialout, an ISDN or a DSL line does not matter much from the perspective of a Dialer interface.

What makes me confuse is that if xDSL doesn't use the dialer interface   for dialing(or call) why does it need a "dialer interface"?

Think of it this way: it was a natural technological progression to carry data over a telephone network or over a part of it, starting with analog dialout through ISDN towards DSL. In all these cases, the underlying carrier network was different but from PPP encapsulation upwards, it is still the same to the customer. Obviously, Cisco decided to reuse the Dialer interface for DSL as it was already widely used with analog and ISDN technologies. Administrators already familiar with the use of Dialer interfaces with analog and ISDN networks could migrate their configuration very easily to the DSL. So we continue to use Dialer interfaces with DSL although there is no real call ever made.

And how does  the dialer interface know it is going to use a xDSL or ISDN?  if there  is no  

dialer string 2310559500

command, it means it is going to use xDSL?

No, it does not depend on the

dialer string

command. Instead, the command you are interested in is the

dialer pool

command, in your case, it is

dialer pool 5.

Back in dialout scenarios, it was common to have multiple dialout interfaces available - either multiple legacy lines, or at least one ISDN connection that had 2 B channels and could therefore make two simultaneous calls. Any dialout interface you had installed was typically capable of calling any number, i.e. they were equivalent to each other. Configuring the necessary information - encapsulation, IP addressing, dialer strings, etc. - on physical dialout interfaces was possible but very inefficient because that caused the interface to be "locked" to the single dialed number and single called peer. That basically disallowed reusing a currently free dialout interface to make a call to an arbitrary location.

Therefore, a concept of "dialer pools" was invented. Physical dialout interface were no longer configured with the dialer strings, IP addresses, etc., but instead, they were assigned to so-called dialer pools: pools of interfaces free and available to be used if a call is made. The configuration was moved from physical interface to Dialer interfaces, and each Dialer interface is told which dialer pool it is supposed to use when it needs to make a connection.

Consider this configuration:

interface BRI0/1/0

  encapsulation ppp

  dialer pool-member 1

  no shutdown

!

interface BRI0/1/1

encapsulation ppp

dialer pool-member 1

no shutdown

!

interface FastEthernet0/0

pppoe-client dial-pool-member 2

no shutdown

!

interface Dialer0

encapsulation ppp

dialer pool 1

dialer string 1234

dialer-group 3

ip address 1.2.3.4 255.255.255.0

! other configuration

!

interface Dialer1

encapsulation ppp

dialer pool 1

dialer string 5678

dialer-group 3

ip address negotiated

! other configuration

!

interface Dialer2

encapsulation ppp

dialer pool 2

ip address negotiated

! other configuration

!

dialer-list 3 protocol ip permit

Here, there are two ISDN interfaces, both offering their services in dialer pool 1 because of the

dialer pool-member 1

command. Any Dialer interface configured with

dialer pool 1 

command can at any time pick any free interface (and ISDN channel) from the dialer pool 1 to make its call. And indeed, there are two Dialer interfaces configured, one of them calling 1234, the other calling 5678. Whenever they need to make a call, they pick a currently free interface from the dialer pool 1 and make a call using their own configuration. After the call ends, the Dialer interface returns the interface back to the pool so it can be reused later.

Notice now how the Dialer2 is configured - it simply uses a different dialer pool, in this case, pool 2. This pool currently contains the PPPoE client running on Fa0/0 interface, so, in the same way as before, the PPPoE client is offering its services in the pool 2 to any Dialer interface configured to be served by the dialer pool 2. When Dialer2 decides to make a call, it - unknowingly - does this over the PPPoE client running on Fa0/0. If you ever decided to change DSL back to ISDN, you would simply change the

dialer pool setting on Dialer2 and add the

dial string and dialer-group

all other would remain the same.

The

dialer-group

command visible on Dialer0 and Dialer1 has nothing to do with physical interface selection. Instead, it refers to a so-called

dialer-list 

that contains a description of traffic for which it is allowed to make a call. With toll calls, you probably do not want every irrelevant ping or traceroute to bring up your line and make a call - and make you pay - so the

dialer-group 

command refers to a list of traffic that is so "interesting" or "important" that when such traffic needs to be sent out over a Dialer interface, your router will make a call if the link is not already up. With DSL as an always-on technology, neither

dialer-group nor dialer-list

are required because there are no calls, as we've discussed earlier.

Would this explain the issue?

Best regards,

Peter

[fastethernet0]

Wow, thank you, really appreciate your help. You solved my confusion. Thank you again.

[kirandeep.singh]

What an explanation!!!! Thanks

[Joseph W. Doherty]

". . . or at least one ISDN connection that had 2 B channels and could therefore make two simultaneous calls."

Indeed, but some additional side notes (for USA).

The 2 B channel setup was BRI-ISDN (more or less) equivalent for your local loop analog phone.  Hub locations, using ISDN, might be more likely found with the PRI-ISDN equivalent of a T1, supporting more B channels, 24 of them.

An additional ISDN feature was ISDN being capable of bonding and de-bonding multiple B channels, dynamically, based on actual bandwidth demand.

As Peter correctly describes, with ISDN far side was truly dialed, however, that was performed so quickly, if often seemed your network was always connected.

Lastly, ISDN had so many options, no one seemed to actually fully understand it, well maybe the original designers did (and I hear they are all doing very well in their sanitorium).  

[Joseph W. Doherty]

". . . transmit data over significantly higher frequencies than what would  be allowed to pass through the telephone exchange."

Indeed, and just a side note (for USA), as I don't know whether anyone still uses DSL to also support their analog phone, but years ago I did have such a setup, and telco provided some high frequency filters to place between analog phone(s) and its connection to house's phone line (now also being used by DSL).