Dialer Interfaces (Dialer Profiles)

So far, we have applied all the DDR-specific configuration items directly to a physical interface. This method of configuring DDR is called "legacy DDR ." The problem with legacy DDR is that it forces an interface to use the same parameters for all connections, incoming or outgoing. In the previous example, we set up a dialer map that called two different destinations through the same interface; all the other configuration items for the two destinations were the same. With dialer profiles , we can move the DDR information into the virtual dialer interface, which allows us to create rotary groups , dialer pools, or maps to different DDR information on the same physical interface.

The configuration of a dialer interface is no different from any other interface configuration:

 interface dialer 1
 ip address 10.10.1.5 255.255.255.0
 encapsulation ppp
 dialer string 4105551212

Dialer interfaces can be applied to physical interfaces in two ways: via rotary groups or dialer pools.

12.3.1. Rotary Groups

Rotary groups allow a group of interfaces to act as one to make or receive calls. This grouping is accomplished by mapping a single virtual dialer interface to many physical interfaces. Rotary groups are useful when you have one router that needs to call several destinations at the same time. Using a rotary group lets you avoid the most important limitation of our previous configuration: only one of the remote sites could be connected at a time.

In this example, we create a rotary group that supports three remote offices, using three async interfaces:

 ! First, we configure the dialer interface
 interface dialer1
 description DDR connection to remote offices
 ip address 10.10.1.1 255.255.255.0
 dialer in-band
 ! Create the map for this interface to office2
 dialer map ip 10.10.1.2 modem-script usr system-script office2 555-1111
 ! Create the map for this interface to office3
 dialer map ip 10.10.1.3 modem-script usr system-script office3 555-1112
 ! Create the map for this interface to office4
 dialer map ip 10.10.1.4 modem-script usr system-script office4 555-1113
 ! Set the idle timeouts
 dialer idle-timeout 300
 dialer-group 1
 !
 ! Set up the chat script for the modem (we have only one type of modem)
 chat-script usr ABORT ERROR "" "at z" OK "atdt T" TIMEOUT 20
 chat-script office2 ABORT invalid TIMEOUT 10 name: frank word: letmein ">"
 chat-script office3 ABORT invalid TIMEOUT 10 name: saul word: letme ">"
 chat-script office4 ABORT invalid TIMEOUT 10 name: bob word: letmeback ">"
 !
 ! Now configure the physical interfaces. Each interface is a member of
 ! rotary-group 1
 ! Note that the rotary-group number is the same as our dialer interface
 interface async 1
 no ip address
 dialer rotary-group 1
 interface async 2
 no ip address
 dialer rotary-group 1
 interface async 3
 no ip address
 dialer rotary-group 1
 !
 ! Set a static route to office2
 ip route 10.10.2.0 255.255.255.0 10.10.1.2
 ! Set a static route to office3
 ip route 10.10.3.0 255.255.255.0 10.10.1.3
 ! Set a static route to office4
 ip route 10.10.4.0 255.255.255.0 10.10.1.4
 !
 ! Set up the dialer groups
 ! (Since we left "broadcast" off the dialer maps, denying EIGRP and ICMP
 ! isn't completely necessary. However, it is here as a reminder.)
 access-list 110 deny icmp any any
 access-list 110 deny eigrp any any
 access-list 110 permit ip any any
 dialer-list 1 protocol ip list 110

In this configuration, we use the dialer rotary-group command to collect three async interfaces into rotary group 1. This group is automatically associated with the interface dialer1; the rotary group number must match the dialer interface number. The async interfaces don't have their own IP addresses; the IP addresses are assigned to the dialer interface, which eliminates the need to know which interface will call which office.

We also modified access list 110 to prevent EIGRP traffic from bringing up any of the links. Again, this doesn't prevent EIGRP traffic from being sent over the links, provided that they are already up. Denying ICMP and EIGRP explicitly isn't necessary because we didn't use the broadcast keyword in the dialer map command. However, had we added the broadcast keyword, we would need these lines in our access list. It's a good idea to make your assumptions explicit so that the router won't suddenly change behavior if you later decide that you have to allow broadcast traffic.

12.3.2. Dialer Pools

Dialer pools first appeared in IOS 11.2. They are a bit like rotary groups, but they map many physical interfaces to many virtual interfaces. To best illustrate this feature, consider Figure 12-1, which shows four BRI interfaces that are assigned to three pools. Note that we can assign one interface to two or more pools. The physical interfaces are used as needed by the dialer interfaces you create.

Figure 12-1. Dialer pools

Configuring a dialer pool consists of two steps: assigning a pool number to the dialer interface and making the physical interfaces pool members. Here's the pool configuration for Figure 12-1:

 interface dialer1
 ip address 10.10.1.5 255.255.255.0
 encapsulation ppp
 dialer in-band
 dialer pool 1
 !
 interface dialer2
 ip address 10.10.2.5 255.255.255.0
 encapsulation ppp
 dialer in-band
 dialer pool 2
 !
 interface dialer3
 ip address 10.10.3.5 255.255.255.0
 encapsulation ppp
 dialer pool 3
 !
 interface bri0
 encapsulation ppp
 dialer pool-member 1
 !
 interface bri1
 encapsulation ppp
 dialer pool-member 1
 dialer pool-member 3
 !
 interface bri2
 encapsulation ppp
 dialer pool-member 2
 !
 interface bri3
 encapsulation ppp
 dialer pool-member 2
 dialer pool-member 3

dialer1 can use any of the interfaces that belong to pool 1; likewise, dialer2 can use any of the interfaces in pool 2, and so on. Note that bri1 and bri3 are both members of two pools, pool 1 and pool 3, so these two interfaces can be used by either dialer1 or dialer3. The result is an extremely flexible relationship between the dialers and the actual interfaces.