Home | Skip to Content | Skip to Search | Skip to Navigation | Skip to Footer |
Worldwide [change] |Register |About Cisco
Guest

Hierarchical Navigation

Dial-on-Demand Routing (DDR)

Using SGBP in LSDO Environments

Downloads

Document ID: 18287


Contents

Introduction
Before You Begin
      Requirements
      Components Used
      Conventions
Background Information
Configure
      Network Diagram
      Configurations
Verify
      Sample show Output for Delirium
      Sample show Output for Prasit
Troubleshoot
      Troubleshooting Commands
      Output for Delirium
      Output for Prasit
Related Information

Introduction

This document describes the way the Stack Group Bidding Protocol (SGBP) is modified and used for dial-out connection bidding in a Large Scale Dial-Out (LSDO) environment. This protocol was originally developed for dial-in using a Multichassis Multilink PPP (MMP) environment.

Before You Begin

Requirements

Before attempting this configuration, ensure that you:

  • verify that the devices are properly configured to accept dial-in calls and to make outbound calls.

  • verify that the authentication, authorization, and accounting (AAA) server is set up so that the information for an LSDO call is passed on to the Network Access Server (NAS) making the outbound call. For more information on the AAA server configuration, refer to the document Configuring Cisco Secure UNIX for Large Scale Dialout Using RADIUS.

Note: Refer to the document Large Scale Dialout for more information regarding prerequisites and restrictions for LSDO.

Components Used

The information in this document is based on the software and hardware versions:

  • Three Cisco 2500 Series Routers running Cisco IOS® Software Version 12.1(5)

  • One BRI circuit connected to each router

Note: SGBP requires a Cisco IOS Plus image as well.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Background Information

LSDO allows dial-out from a stack group of access servers and therefore requires a bidding protocol between the stack-group members. The existing SGBP protocol was modified to meet the requirements of LSDO. The original task of SGBP in a LSDO environment is only to perform dial-out connection bidding in the case of congestion. These are the relevant commands:

  • sgbp dial-bids — This global configuration command allows bidding for a dial-out call.

  • dialer congestion-threshold links — This defines when a dialer interface is congested and bidding should take place.

  • dialer reserved-links {dial-in-link dial-out-link} — This defines the number of links reserved for dial-in and dial-out.

For more information on LSDO, refer to the document Large Scale Dialout. For more information on SGBP, refer to the document Multichassis Multilink PPP (MMP).

Before configuring SGBP for LSDO, be aware of a major change in the way SGBP works. A discussion of its use with Cisco IOS Software Release earlier than 12.1 (1), and with Cisco IOS Software Release 12.1(1) and later, follows:

SGBP and LSDO Using Cisco IOS Software Release Earlier than 12.1(1)

The following steps show what occurs when a congested NAS receives interesting traffic for an LSDO call using a Cisco IOS Software Release earlier than 12.1(1):

  1. A dialer session is created on the NAS.

  2. The NAS sends an SGBP discovery message out to all the active SGBP peers.

  3. The NAS waits for an SGBP offer from all the peers. If the NAS does not receive a reply from each SGBP member within two seconds, the NAS repeats Step 2 and Step 3 up to three times. If it still does not receive a reply from each SGBP member, it dials out.

  4. Every other NAS in the SGBP group replies with an offer that contains a num_link parameter. This parameter is an indication of the congestion status of each SGBP peer.

  5. Based on the answers, the NAS determines which SGBP peer should perform the dial-out.

  6. If it is determined that a different NAS should perform the dial-out, the packets are temporarily stored in the dialer hold-queue associated with the dialer session and an SGBP dial-request is sent to the SGBP peer that won the SGBP bidding process.

  7. As soon as the NAS receives the routing update from the IP Control Protocol (IPCP) connected route from the SGBP peer that performed the dial-out, the following occurs:

    • The dialer hold-queue gets unqueued.

    • Packets are forwarded through the routing process to the correct NAS.

  8. The dialer session times itself out.

In Cisco IOS Software Releases earlier than 12.1(1) that have a stack group of access servers configured for LSDO and access servers configured to receive incoming calls, a problem arises when either:

  • multiple access servers within a stack group dial out to the same remote site

  • an outgoing (LSDO) call on an SGBP peer is generated for an already existing incoming call on another SGBP peer

As an example of this redundant outgoing call, assume server A accepts an incoming call from the remote peer. When the connection is made, server A installs a connected route to the peer. This route should then be redistributed to the routing protocol by server A. Server B (running the same routing protocol) installs a route to the peer with next hop as server A. As a result, any traffic destined for the remote peer is sent to server A, as expected. However, consider the time period between when server A redistributes the peer route into the routing protocol and when server B installs that route into its routing table; if server B receives any traffic for the peer during that time period, it initiates an LSDO outgoing call (since it does not have a route for that peer). As a result, server B establishes an outgoing call to the peer while server A has an incoming call from the peer already in progress.

SGBP and LSDO Using Cisco IOS Software Release 12.1(1) and Later

SGBP was modified to address this problem, starting with Cisco IOS Software Release 12.1(1). Now, SGBP discovery messages are always (not only when congested) sent to SGBP peers on the first call in a multilink bundle. In order to do this, the parameters exchanged in SGBP discovery messages were changed. A description of the changes follows:

  • amount of links (num-links) — amount of links (this parameter remains the same)

  • congested — 0 for no congestion, 1 for congestion

  • remote ip address — IP address of the client that is attempted

  • req_connected — flag (0 or 1) that requests that the peer compare the remote IP address with the connected routes in the routing table to determine if a connection to the remote already exists

  • rpl_connected — flag (0 or 1) that results from the comparison of the remote IP address with the connected routes in the routing table

These parameters can be viewed in the debug sgbp dial-bids command output. Examples are shown in the Troubleshooting Commands section of this document

The following steps show what occurs when a congested NAS receives interesting traffic for an LSDO call using Cisco IOS Software Release 12.1(1) and later:

  1. An NAS receives interesting traffic for an LSDO call and creates a dialer session.

  2. The user-out profile is retrieved from the AAA server.

  3. Before dialing out, the NAS always sends an SGBP discovery message to all active SGBP peers with the req_connected flag set to 1. Every SGBP peer checks its routing table to verify if an open connection with this remote site already exists.

  4. If no SGBP peer has an existing connection, the NAS is not congested, and it has not chosen a less congested NAS from the SGBP offers it received, so it dials out.

  5. If there was an existing connection on one of the SGBP peers, then this peer sets the rpl_connected flag to 1 in its response to the SGBP discovery from the NAS.

  6. The packets are queued in the dialer hold-queue on the NAS until one of the following conditions is met:

    • A routing update arrives from the other NAS.

    • The dialer session times out.

  7. Once the routing update arrives on the NAS:

    • The packets are unqueued.

    • The routing process forwards them to the correct NAS.

  8. The dialer session times out.

Interestingly, the timeout of a dialer session is configurable by issuing the dialer hold-queue timeout command, as follows:

dialer hold-queue size timeout timeout

Configure

In this section, you are presented with the information to configure the features described in this document.

Note:  To find additional information on the commands used in this document, use the Command Lookup Tool (registered customers only) .

Network Diagram

This document uses the network setup shown in the diagram below.

lsdo_sgbp.gif

Configurations

The following section describes the call flow and process that takes place with SGBP and LSDO for this example:

  1. The router Tremens dials into Prasit.

  2. The redistribute connected is removed from Enhanced Interior Gateway Routing Protocol (EIGRP) in Prasit, so Delirium does not have the routing update for 192.168.0.1.

  3. On Delirium, 192.168.0.1 is pinged. The dialer session is created and the SGBP discovery is sent.

  4. Prasit sends an offer with rpl_connected set to 1.

  5. Delirium does not dial out, but waits for the routing update or for dialer session timeout.

  6. After re-enabling redistribute connected on Prasit, Delirium learns the route to 192.168.0.1 using EIGRP and unqueues the packets from the hold-queue. Then, routing forwards the packets to Prasit.

  7. The dialer session on Delirium times out.

Following are the configurations for the two NASs (Delirium and Prasit) that are in the same SGBP stack group. The configuration for Tremens is not shown because it only needs to be configured for a standard dial-in/dial-out.

Delirium (2500)

 
delirium#show running-config
Building configuration... 

Current configuration : 2374 bytes
! 
version 12.1 
service timestamps debug datetime msec 
service timestamps log datetime msec 
no service password-encryption 
! 
hostname delirium 
! 
aaa new-model 
aaa authentication ppp default local group tacacs+ 
aaa authorization network default local group tacacs+ 
aaa authorization configuration default group tacacs+ 
aaa route download 1000 

!--- Enable downloading of the static route and
!--- set the amount of time (in seconds) between downloads.

enable password ww 
! 
username test password 0 ww 
username prasit password 0 ww 
username GPO_group password 0 cisco 

!--- This is the stack group username and password.

! 
ip subnet-zero 
no ip finger 
no ip domain-lookup 
! 
sgbp group GPO_group 

!--- This is the stack group name.

sgbp member prasit 192.168.2.1 

!--- These are the stack group members.

sgbp source-ip 192.168.1.1 
sgbp dial-bids 

!--- This allows the stack group to bid for dial-out connection.

isdn switch-type basic-net3 
! 
interface Loopback0 
 ip address 192.168.1.1 255.255.255.255 
! 
interface Ethernet0 
 ip address 10.200.16.16 255.255.255.0 
! 
interface Serial0 
 no ip address 
 shut
! 
interface Serial1 
 ip address 192.168.1.1 255.255.255.0 
! 
interface BRI0 
 no ip address 
 encapsulation ppp 
 dialer rotary-group 1 
 isdn switch-type basic-net3 
 no cdp enable 
 ppp authentication chap 
! 
interface Dialer1 

!--- This is the dialer rotary interface used for the dial-out.

 ip unnumbered Loopback0 
 encapsulation ppp 
 load-interval 30 
 dialer in-band 
 dialer aaa 
 
!--- This allows the dialer to access the AAA server for dial-out 
!--- information, such as phone number.
!--- The AAA server provides the parameters for the dial-out.

 dialer hold-queue 50 timeout 100 

!--- The hold-queue size for outbound packets is 50, 
!--- and the timeout is 100 seconds.

 dialer-group 1 
 no cdp enable 
 ppp authentication chap 
! 
router eigrp 1 
 redistribute connected route-map tag_connected_routes 
 network 192.168.1.0 0.0.0.255 
 no auto-summary 
 no eigrp log-neighbor-changes 
! 
ip local pool test 1.2.3.4 
ip default-gateway 10.200.16.1 
ip classless 
ip route 0.0.0.0 0.0.0.0 10.200.16.1 
ip route 10.200.20.0 255.255.255.0 10.200.16.1 
no ip http server 
! 
dialer-list 1 protocol ip permit
route-map tag_connected_routes permit 10 
 set tag 98765 
! 
tacacs-server host 10.200.20.133 
tacacs-server key cisco 
! 
line con 0 
 exec-timeout 0 0 
 password ww 
line aux 0 
line vty 0 4 
 password ww 
! 
end

Prasit (2500)

 
prasit#show running 
Building configuration... 

Current configuration : 2025 bytes 
! 
version 12.1 
service timestamps debug datetime msec 
service timestamps log datetime msec 
no service password-encryption 
! 
hostname prasit 
! 
aaa new-model 
aaa authentication ppp default local group tacacs+ 
aaa authorization network default local group tacacs+ 
aaa authorization configuration default group tacacs+ 
aaa route download 1000 
enable password ww 
! 
username spicey password 0 cisco 
username delirium password 0 ww 
username GPO_group password 0 cisco 

!--- This is the stack group username and password.

username ww password 0 ww 
! 
ip subnet-zero 
no ip finger 
! 
sgbp group GPO_group 

!--- This is the stack group name.

sgbp member delirium 192.168.1.1 
sgbp source-ip 192.168.2.1 
sgbp dial-bids 

!--- This allows the stack group to bid for dial-out connection.

isdn switch-type basic-net3 
! 
interface Loopback0 
 ip address 192.168.2.1 255.255.255.255 
! 
interface Ethernet0 
 description ip address 10.200.16.64 255.255.255.0 
 ip address 10.200.16.64 255.255.255.0 
! 
interface Serial0 
 ip address 192.168.2.1 255.255.255.0 
 no fair-queue 
 clockrate 64000 
! 
interface BRI0 
 no ip address 
 encapsulation ppp 
 dialer rotary-group 1 
 isdn switch-type basic-net3 
 no cdp enable 
 ppp authentication chap 
! 
interface Dialer1 
 ip unnumbered Loopback0 
 encapsulation ppp 
 load-interval 30 
 dialer in-band 
 dialer aaa 
 dialer hold-queue 50 timeout 100 
 dialer-group 1 
 no cdp enable 
 ppp authentication chap 
! 
router eigrp 1 
 redistribute connected route-map tag_connected_routes 
 network 192.168.2.0 0.0.0.255 
 no auto-summary 
 no eigrp log-neighbor-changes 
! 
ip classless 
ip route 0.0.0.0 0.0.0.0 10.200.16.1 
no ip http server 
! 
no logging trap 
access-list 101 deny igrp any any 
access-list 101 permit ip any any 
dialer-list 1 protocol ip list 101 
route-map tag_connected_routes permit 10 
 set tag 98765 
! 
tacacs-server host 10.200.20.133 
tacacs-server key cisco 
! 
line con 0 
 exec-timeout 0 0 
 transport input none 
line aux 0 
line vty 0 4 
 password ww 
! 
end

Verify

This section provides information you can use to confirm your configuration is working properly.

Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.

  • show ip route[address [network-mask] | [static] [download]]

    address

    (Optional) The IP address about which routing information should be displayed.

    network-mask

    (Optional) Network mask that allows you to mask network and subnetwork bits.

    static

    (Optional) All static routes.

    download

    (Optional) The route installed using the AAA route download function.

  • show sgbp — This is used to display the status of the stack group members. Use the show sgbp command in the EXEC mode. This command has no arguments or keywords.

Sample show Output for Delirium

The sample output shown below is displayed after the dial connection is made.

delirium# show ip route static download 
Connectivity: A - Active, I - Inactive 

A    192.168.0.0 255.255.255.0 192.168.0.1 
A    192.168.0.1 255.255.255.255 Dialer1 200 name tremens

!--- The static route for the remote host Tremens
!--- is obtained from the AAA server.


delirium# show ip route 192.168.0.1 
Routing entry for 192.168.0.1/32 
 Known via "static", distance 200, metric 0 (connected) 

!--- The route to the peer is a static route (from the AAA server).

 Routing Descriptor Blocks: 
 * directly connected, via Dialer1 
    Route metric is 0, traffic share count is 1


delirium# show sgbp 
Group Name: GPO_group Ref: 0x1EB9B891 
Seed bid: default, 50, default seed bid setting 
 
 Member Name: prasit State: active Id: 1
 Ref: 0x58ADC952
 Address: 192.168.2.1

Sample show Output for Prasit

The sample output shown below is displayed after the dial connection is made.

prasit# show ip route static down
Connectivity: A - Active, I - Inactive

A    192.168.0.0 255.255.255.0 192.168.0.1
A    192.168.0.1 255.255.255.255 Dialer1 200 name tremens 

 
prasit# show ip route 192.168.0.1
Routing entry for 192.168.0.1/32
 Known via "connected", distance 0, metric 0 (connected, via interface)

!--- The route to the peer is a "connected" router
!--- since the call arrived on Prasit.

 Redistributing via eigrp 1

!--- This route is redistributed into EIGRP 1.

 Advertised by eigrp 1 route-map tag_connected_routes 
 Routing Descriptor Blocks:
 * directly connected, via Dialer1
    Route metric is 0, traffic share count is 1 


prasit# show sgbp 
  Group Name: GPO_group Ref: 0x58ADC952 
  Seed bid: default, 50, default seed bid setting
   
   Member Name: delirium State: active Id: 1 
   Ref: 0x1EB9B891 
   Address: 192.168.1.1

Troubleshoot

This section provides information you can use to troubleshoot your configuration.

Troubleshooting Commands

Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.

Note: Before issuing debug commands, please see Important Information on Debug Commands.

  • debug aaa authentication — displays information on AAA/TACACS+ authentication.

  • debug aaa authorization — displays information on AAA/TACACS+ authorization.

  • debug aaa per-user — displays information about the per-user configuration downloaded from the AAA server.

  • debug dialer detailed— displays information about dial-on-demand detailed messages.

  • debug dialer — displays debugging information about the packets received on a dialer interface.

  • debug sgbp dial-bids — displays large-scale dial-out negotiations between the primary NAS and alternate NASs.

  • debug ppp negotiation — displays PPP packets sent during PPP startup, where PPP options are negotiated.

  • debug ip routing — displays details on Routing Information Protocol (RIP) routing table updates and route cache updates.

  • debug isdn q931 — displays information about call setup and teardown of ISDN network connections (layer 3) between the local router (user side) and the network.

Output for Delirium

Note: Some of the following debug output lines are broken into multiple lines for printing purposes.

delirium# show debug 

General OS: 
 AAA Authentication debugging is on 
 AAA Authorization debugging is on 
 AAA Per-user attributes debugging is on 
Dial on demand: 
 Dial on demand events debugging is on 
 Dial on demand detailed messages debugging is on 
MLPVT group: 
 SGBP dial-bids debugging is on 
PPP: 
 PPP protocol negotiation debugging is on 
IP routing: 
 IP routing debugging is on 
ISDN: 
 ISDN Q931 packets debugging is on 
delirium# 

!--- Now dial in to Prasit (other NAS).

 
delirium# show ip route 192.168.0.1
Routing entry for 192.168.0.1/32
 Known via "eigrp 1", distance 170, metric 47250176

!--- The route to the remote network is "known via" EIGRP 
!--- because Prasit redistributed it.

 Tag 98765, type external
 Redistributing via eigrp 1
 Last update from 192.168.2.1 on Ethernet0, 00:01:23 ago
 Routing Descriptor Blocks:
 * 192.168.2.1, from 192.168.2.1, 00:01:23 ago, via Eth0
   Route metric is 47250176, traffic share count is 1
   Total delay is 60000 microseconds, minimum bandwidth is 56 Kbit
   Reliability 255/255, minimum MTU 1500 bytes
   Loading 1/255, Hops 2

!--- Now stop redistributing the route into EIGRP (on Prasit).
!--- This causes the route for the remote end on delirium to be removed.
!--- Refer to Output for Prasit for information on stopping redistribution.

*Mar  6 01:17:28.333: RT: closer admin distance for 192.168.0.1, 
flushing 1 routes 
*Mar  6 01:17:28.337: RT: add 192.168.0.1/32 via 192.168.1.2,
   eigrp metric [170/47250176] 
*Mar  6 01:17:38.489: RT: delete route to 192.168.0.1 via 192.168.1.2,
   eigrp metric [170/47250176] 
*Mar  6 01:17:38.493: RT: no routes to 192.168.0.1 

!--- The route to 192.168.0.1 is removed as Prasit 
!--- no longer redistributes the route.

*Mar  6 01:17:39.633: RT: garbage collecting entry for 192.168.0.1 
*Mar  6 01:17:39.637: RT: add 192.168.0.1/32 via 0.0.0.0, static metric [200/0] 

 !--- A static route for the remote peer is obtained from the AAA server.


delirium# show ip route 192.168.0.1 
Routing entry for 192.168.0.1/32 
 Known via "static", distance 200, metric 0 (connected) 

!--- The route to the peer is a static route (obtained from the AAA server).

 Routing Descriptor Blocks: 
 * directly connected, via Dialer1 
   Route metric is 0, traffic share count is 1
 
delirium# ping 192.168.0.1

!--- Ping the IP address for Tremens (the remote peer). This should generate an
!--- LSDO call. However, since an existing call to Tremens exists on the SGBP peer
!--- Prasit, check with Prasit before initiating the dial.

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds: 
*Mar  6 01:17:52.177: 708: Same state, 0 
*Mar  6 01:17:52.181: DSES 708: Session create 
*Mar  6 01:17:52.185: DSES 0x708: Preparing build dialer map 
*Mar  6 01:17:52.189: DSES 0x708: Building dialer map 
*Mar  6 01:17:52.193: DSES 0x708: Next hop name is tremens 
*Mar  6 01:17:52.193: AAA: parse name=Dialer1 idb type=-1 tty=-1 
*Mar  6 01:17:52.197: AAA: name=Dialer1 flags=0x11 type=6 shelf=0 slot=0 adapter=0
   port=1 channel=0 
*Mar  6 01:17:52.201: AAA: parse name=<no string> idb type=-1 tty=-1 
*Mar  6 01:17:52.201: AAA/MEMORY: create_user (0x46FAA4) user='tremens-out' ruser=''
   port='Dialer1' rem_addr='Dial out' authen_type=NONE service=LOGIN priv=0 
*Mar  6 01:17:52.209: Di1 AAA/AUTHOR/DIALOUT (1746485479): Port='Dialer1'
   list='default' service=unknown 
*Mar  6 01:17:52.213: AAA/AUTHOR/DIALOUT: Di1 (1746485479) user='tremens-out' 
*Mar  6 01:17:52.213: Di1 AAA/AUTHOR/DIALOUT (1746485479): send AV service=outbound 
*Mar  6 01:17:52.217: Di1 AAA/AUTHOR/DIALOUT (1746485479): send AV protocol=ip 
*Mar  6 01:17:52.221: Di1 AAA/AUTHOR/DIALOUT (1746485479): found list "default" 
*Mar  6 01:17:52.221: Di1 AAA/AUTHOR/DIALOUT (1746485479): Method=tacacs+ (tacacs+) 
*Mar  6 01:17:52.225: AAA/AUTHOR/TAC+: (1746485479): user=tremens-out 
*Mar  6 01:17:52.229: AAA/AUTHOR/TAC+: (1746485479): send AV service=outbound 
*Mar  6 01:17:52.229: AAA/AUTHOR/TAC+: (1746485479): send AV protocol=ip 
*Mar  6 01:17:52.449: TAC+: (1746485479): received author response status = PASS_ADD 
*Mar  6 01:17:52.457: Di1 AAA/AUTHOR (1746485479): Post authorization
   status = PASS_ADD 
*Mar  6 01:17:52.461: Di1 AAA/AUTHOR/DIALOUT: Processing AV service=outbound 
*Mar  6 01:17:52.461: Di1 AAA/AUTHOR/DIALOUT: Processing AV protocol=ip 
*Mar  6 01:17:52.465: Di1 AAA/AUTHOR/DIALOUT: Processing AV dial-number=6125 
*Mar  6 01:17:52.469: Di1 AAA/AUTHOR/DIALOUT: Processing AV send-secret=cisco 
*Mar  6 01:17:52.469: Di1 AAA/AUTHOR/DIALOUT: Processing AV send-auth=2 
*Mar  6 01:17:52.473: Di1 AAA/AUTHOR/DIALOUT: Authorization succeeded 
*Mar  6 01:17:52.477: Di1 AAA/AUTHOR/DIALOUT: truncating '-out' suffix,
   user now is 'tremens' 

!--- The AAA server provides dial-out parameters. 
!--- This NAS must now confirm that there are
!--- no other live connections to the intended device.

*Mar  6 01:17:52.481: %LSDialout: temporary debug to verify the data integrity
*Mar  6 01:17:52.481:  dial number = 6125 
*Mar  6 01:17:52.485:  dialnum_count = 1 
*Mar  6 01:17:52.485:  force_56 = 0 
*Mar  6 01:17:52.485:  routing = 0 
*Mar  6 01:17:52.489:  data_svc = -1 
*Mar  6 01:17:52.489:  port_type = -1 
*Mar  6 01:17:52.489:  map_class = 
*Mar  6 01:17:52.493:  ip_address = 0.0.0.0 
*Mar  6 01:17:52.493:  send_secret = cisco 
*Mar  6 01:17:52.497:  send_auth = 2 
*Mar  6 01:17:52.497: tremens DDR: Di1 no map, dynamic 0, ghost 0 
*Mar  6 01:17:52.501: DSES 0x708: create dynamic map for 192.168.0.1 
*Mar  6 01:17:52.505: BRI0:  2 total links, 0 active links 
*Mar  6 01:17:52.505: SGBP-RES:  New bid add request: 708 8 2 1 DAC0 1 1 
*Mar  6 01:17:52.509: SGBP-RES: Sent Discover message to ID 58ADC952  64 bytes,
   req_conn 1 

!--- The NAS sends an SGBP discovery message.

*Mar  6 01:17:52.629: SGBP-RES: Received Message of 64 length: 
*Mar  6 01:17:52.629: SGBP-RES: header 5  30  0  40 2  0  0  3C  0  0  0  0  0  0  
   0 6  0  0  0  1  1E  B9  B8  91  58 AD  C9  52  8  24  B  3  2  C  6 0  0  DA
   C0  D  4  0  1  E  3  1 F  3  1  13  3  1  14  3  1  15  3 0  11  6  5  0  0  1 
*Mar  6 01:17:52.653: SGBP RES: Scan: Message type: Offer 
*Mar  6 01:17:52.653: SGBP RES: Scan: Len is 60 
*Mar  6 01:17:52.657: SGBP RES: Scan: Transaction ID: 6 
*Mar  6 01:17:52.657: SGBP RES: Scan: Message ID: 1 
*Mar  6 01:17:52.661: SGBP RES: Scan: Client ID: 1EB9B891 
*Mar  6 01:17:52.661: SGBP RES: Scan: Server ID: 58ADC952 
*Mar  6 01:17:52.665: SGBP RES: Scan: Resource type 8  length 36 
*Mar  6 01:17:52.665: SGBP RES: Scan: Phy-Port Media type: ISDN 
*Mar  6 01:17:52.669: SGBP RES: Scan: Phy-Port Min BW: 56000 
*Mar  6 01:17:52.669: SGBP RES: Scan: Phy-Port Num Links: 1 
*Mar  6 01:17:52.669: SGBP RES: Scan: Phy-Port User class: 1 
*Mar  6 01:17:52.673: SGBP RES: Scan: Phy-Port Priority: 1 
*Mar  6 01:17:52.673: SGBP RES: Scan: Phy-Port Req_connected: 1

!--- The SGBP req_connected is 1.

*Mar  6 01:17:52.677: SGBP RES: Scan: Phy-Port Rpl_connected: 1 

!--- Rpl_connected is 1. This would be 0 if an SGBP peer 
!--- did not have a route to the remote peer.

*Mar  6 01:17:52.677: SGBP RES: Scan: Phy-Port Congested: 0 
*Mar  6 01:17:52.681: SGBP RES: Scan: Phy-Port remote ip address: 192.168.0.1 
*Mar  6 01:17:52.681: SGBP-RES: received 60 length Offer packet 
*Mar  6 01:17:52.685: SGBP-RES: Server 58ADC952 is directly connected 
*Mar  6 01:17:53.685: SGBP-RES: QScan: Purging entry 
*Mar  6 01:17:53.685: SGBP-RES: deleting entry 286DA8 1EB9B891 from list... 
Success rate is 0 percent (0/5) 
delirium# 

!--- The dialer session was created, but the SGBP sends discovery 
!--- to the active peer and discovers that it has an active connection. 
!--- Packets are put in the hold-queue of the dialer session  
!--- until routing converges. Under normal conditions, this would
!--- occur in a short period of time. However, for this test the route
!--- is not redistributed, so it does not converge. Now, reactivate
!--- redistribution of the connected router on Prasit.

*Mar  6 01:18:04.517: RT: closer admin distance for 192.168.0.1, flushing 1 routes 
*Mar  6 01:18:04.521: RT: add 192.168.0.1/32 via 192.168.1.2, eigrp metric
   [170/47250176] 
*Mar  6 01:18:04.533: DSES 1800: Alternate connected, 5 packets unqueued,
   5 transmitted, 0 discarded

!--- After the routes are redistributed, the packets in the hold-queue 
!--- are unqueued and sent to Prasit for transmission to the remote peer, 
!--- Tremens.

Output for Prasit

Note: Some of the following debug output lines are broken into multiple lines for printing purposes.

prasit# show debug 
General OS: 
 AAA Authentication debugging is on 
 AAA Per-user attributes debugging is on 
Dial on demand: 
 Dial on demand events debugging is on 
 Dial on demand detailed messages debugging is on 
MLPVT group: 
 SGBP dial-bids debugging is on 
PPP: 
 PPP protocol negotiation debugging is on 
ISDN: 
 ISDN Q931 packets debugging is on 

!--- This stops redistributing the route into EIGRP. This stops the route for
!--- the remote end (Tremens) from being added to the routing table of Delirium.

prasit#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
prasit(config)router eigrp 1 
prasit(config-router)#no  redistribute connected route-map tag_connected_route 
prasit(config-router)#no redistribute connected 

!--- This is an incoming call from the client.

*Mar  6 01:17:23.105: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x06 
*Mar  6 01:17:23.109:         Bearer  Capability i =0x8890 
*Mar  6 01:17:23.117:         Channel ID i =0x89 
*Mar  6 01:17:23.125:         Calling Party Number i = 0xA1, '6125', Plan:ISDN,
   Type:National 
*Mar  6 01:17:23.137:         Called Party Number i = 0xC1, '6105', Plan:ISDN,
   Type:Subscriber(local) 
*Mar  6 01:17:23.157: ISDN BR0: Event: Received a DATA call from 6125 on B1 at 64Kb/s 
*Mar  6 01:17:23.169: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0x86 
*Mar  6 01:17:23.177:         Channel ID i =0x89 
*Mar  6 01:17:23.185: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up 
*Mar  6 01:17:23.201: BR0:1 DDR: dialer_in_call_connected() 
*Mar  6 01:17:23.201: BR0 DDR: Increment call, 0 
*Mar  6 01:17:23.205: Di1 DDR: Increment call, 0 
*Mar  6 01:17:23.213: isdn_call_connect: Calling lineaction of BRI0:1 
*Mar  6 01:17:23.213: BR0:1 PPP: Treating connection as a callin 
*Mar  6 01:17:23.217: BR0:1 PPP: Phase is ESTABLISHING, Passive Open 
*Mar  6 01:17:23.217: BR0:1 LCP: State is Listen 
*Mar  6 01:17:23.229: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0x86 
*Mar  6 01:17:23.273: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x06 
*Mar  6 01:17:23.277:         Channel ID i = 0x89 
*Mar  6 01:17:23.353: BR0:1 LCP: I CONFREQ [Listen] id 25 len 10 
*Mar  6 01:17:23.357: BR0:1 LCP:    MagicNumber 0x11660F6E(0x050611660F6E) 
*Mar  6 01:17:23.361: BR0:1 LCP: O CONFREQ [Listen] id 14 Len 15 
*Mar  6 01:17:23.365: BR0:1 LCP:    AuthProto CHAP (0x0305C22305) 
*Mar  6 01:17:23.369: BR0:1 LCP:    MagicNumber 0xEA60000E(0x0506EA60000E) 
*Mar  6 01:17:23.373: BR0:1 LCP: O CONFACK [Listen] id 25 Len 10 
*Mar  6 01:17:23.377: BR0:1 LCP:    MagicNumber 0x11660F6E(0x050611660F6E) 
*Mar  6 01:17:23.385: BR0:1 LCP: I CONFACK [ACKsent] id 14 Len 15 
*Mar  6 01:17:23.389: BR0:1 LCP:    AuthProto CHAP (0x0305C22305) 
*Mar  6 01:17:23.393: BR0:1 LCP:    MagicNumber 0xEA60000E(0x0506EA60000E) 
*Mar  6 01:17:23.393: BR0:1 LCP: State is Open 
*Mar  6 01:17:23.397: BR0:1 PPP: Phase is AUTHENTICATING, by this end 
*Mar  6 01:17:23.401: BR0:1 CHAP: O CHALLENGE id 14 Len 30 from "GPO_group"
*Mar  6 01:17:23.421: BR0:1 CHAP: I RESPONSE id 14 Len 28 from "tremens" 
*Mar  6 01:17:23.425: BR0:1 PPP: Phase is FORWARDING 
*Mar  6 01:17:23.429: BR0:1 PPP: Phase is AUTHENTICATING 
*Mar  6 01:17:23.437: AAA: parse name=BRI0:1 idb type=14 tty=-1 
*Mar  6 01:17:23.437: AAA: name=BRI0:1 flags=0x51 type=2 shelf=0 slot=0 adapter=0
   port=0 channel=1 
*Mar  6 01:17:23.441: AAA: parse name=<no string> idb type=-1 TTY=-1 
*Mar  6 01:17:23.445: AAA/MEMORY: create_user (0x271EFC) user='tremens' ruser=''
   port='BRI0:1' rem_addr='6125/6105' authen_type=CHAP service=PPP priv=1 
*Mar  6 01:17:23.449: AAA/AUTHEN/START (2586908161): port='BRI0:1' list=''
   action=LOGIN service=PPP 
*Mar  6 01:17:23.453: AAA/AUTHEN/START (2586908161): using "default" list 
*Mar  6 01:17:23.453: AAA/AUTHEN/START (2586908161): Method=LOCAL 
*Mar  6 01:17:23.457: AAA/AUTHEN (2586908161): status = ERROR 
*Mar  6 01:17:23.457: AAA/AUTHEN/START (2586908161): Method=tacacs+ (tacacs+) 
*Mar  6 01:17:23.461: TAC+: send AUTHEN/START packet ver=193 id=2586908161 
*Mar  6 01:17:23.681: TAC+: ver=193 id=2586908161 received AUTHEN status = PASS 
*Mar  6 01:17:23.685: AAA/AUTHEN (2586908161): status = PASS 
*Mar  6 01:17:23.913: TAC+: (2765353596): received author response status = PASS_ADD 
*Mar  6 01:17:23.925: BR0:1 CHAP: O SUCCESS id 14 Len 4 
*Mar  6 01:17:23.925: BR0:1 DDR: dialer_remote_name() for tremens 
*Mar  6 01:17:23.929: BR0:1 DDR: Authenticated host tremens with no
   matching dialer map 
*Mar  6 01:17:23.933: BR0:1 PPP: Phase is UP 
*Mar  6 01:17:23.957: BR0:1 CDPCP: I CONFREQ [Not negotiated] id 8 Len 4 
*Mar  6 01:17:23.961: BR0:1 LCP: O PROTREJ [Open] id 15 Len 10 protocol
   CDPCP(0x820701080004) 
*Mar  6 01:17:23.965: BR0:1 IPCP: I CONFREQ [Closed] id 15 Len 10 
*Mar  6 01:17:23.969: BR0:1 IPCP:    Address 192.168.0.1 (0x030605000001) 
*Mar  6 01:17:24.181: TAC+: (724876550): received author response status = PASS_ADD 
*Mar  6 01:17:24.193: BR0:1 IPCP: O CONFREQ [Closed] id 7 Len 10 
*Mar  6 01:17:24.197: BR0:1 IPCP:    Address 192.168.10.1 (0x030602020202) 
*Mar  6 01:17:24.209: BR0:1 IPCP: I CONFACK [REQsent] id 7 Len 10 
*Mar  6 01:17:24.213: BR0:1 IPCP:    Address 192.168.10.1 (0x030602020202) 
*Mar  6 01:17:24.933: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
   changed state to up 
*Mar  6 01:17:25.937: BR0:1 IPCP: I CONFREQ [ACKrcvd] id 16 Len 10 
*Mar  6 01:17:25.941: BR0:1 IPCP:    Address 192.168.0.1 (0x030605000001) 
*Mar  6 01:17:25.945: BR0:1 AAA/AUTHOR/IPCP: Start. Her address 192.168.0.1, we
  want 0.0.0.0 
*Mar  6 01:17:26.173: TAC+: (2992990671): received author response status = PASS_ADD 
*Mar  6 01:17:26.185: BR0:1 AAA/AUTHOR/IPCP: Done.  Her address 192.168.0.1, we want
  192.168.0.1 
*Mar  6 01:17:26.189: BR0:1 IPCP: O CONFACK [ACKrcvd] id 16 Len 10 
*Mar  6 01:17:26.193: BR0:1 IPCP:    Address 192.168.0.1 (0x030605000001) 
*Mar  6 01:17:26.193: BR0:1 IPCP: State is Open 
*Mar  6 01:17:26.205: BR0:1 AAA/AUTHOR/PER-USER: Event IP_UP 
*Mar  6 01:17:26.209: BR0:1 AAA/AUTHOR: IP_UP 
*Mar  6 01:17:26.209: BR0:1 AAA/PER-USER: processing author params. 
*Mar  6 01:17:26.217: BR0:1 AAA/AUTHOR: Parse 'ip route 192.168.0.0 255.255.255.0
   192.168.0.1' 
*Mar  6 01:17:26.393: BR0:1 AAA/AUTHOR: Parse returned ok (0)
*Mar  6 01:17:26.397: BR0:1 AAA/AUTHOR: enqueue peruser IP txt=no ip route
   192.168.0.0 255.255.255.0 192.168.0.1 
*Mar  6 01:17:26.405: BR0:1 DDR: dialer protocol up 
*Mar  6 01:17:26.413: Di1 IPCP: Install route to 192.168.0.1 

!--- The Delirium site has interesting traffic for 192.168.0.1, so 
!--- Delirium creates a dialer session and sends the SGBP discovery.
!--- The following debugs show the SGBP response to the SGBP request.

*Mar  6 01:17:50.701: SGBP-RES: Received Message of 64 length:
*Mar  6 01:17:50.701: SGBP-RES: header 5  30  0  40 1  0  0  3C  0  0  0  0  0  0  0
   6  0  0  0  1  1E  B9  B8  91  58 AD  C9  52  8  24  B  3  2  C  6 0  0  DA  C0  D
   4  0  1  E  3  1 F  3  1  13  3  1  14  3  0  15  3 0  11  6  5  0  0  1 
*Mar  6 01:17:50.725: SGBP RES: Scan: Message type: Discover 
*Mar  6 01:17:50.729: SGBP RES: Scan: Len is 60 
*Mar  6 01:17:50.729: SGBP RES: Scan: Transaction ID: 6 
*Mar  6 01:17:50.729: SGBP RES: Scan: Message ID: 1 
*Mar  6 01:17:50.733: SGBP RES: Scan: Client ID: 1EB9B891 
*Mar  6 01:17:50.733: SGBP RES: Scan: Server ID: 58ADC952 
*Mar  6 01:17:50.737: SGBP RES: Scan: Resource type 8  length 36 
*Mar  6 01:17:50.737: SGBP RES: Scan: Phy-Port Media type: ISDN 
*Mar  6 01:17:50.741: SGBP RES: Scan: Phy-Port Min BW: 56000 
*Mar  6 01:17:50.741: SGBP RES: Scan: Phy-Port Num Links: 1 
*Mar  6 01:17:50.745: SGBP RES: Scan: Phy-Port User class: 1 
*Mar  6 01:17:50.745: SGBP RES: Scan: Phy-Port Priority: 1 
*Mar  6 01:17:50.749: SGBP RES: Scan: Phy-Port Req_connected: 1 
*Mar  6 01:17:50.749: SGBP RES: Scan: Phy-Port Rpl_connected: 0 
*Mar  6 01:17:50.753: SGBP RES: Scan: Phy-Port Congested: 0 
*Mar  6 01:17:50.753: SGBP RES: Scan: Phy-Port remote ip address: 192.168.0.1 
*Mar  6 01:17:50.757: SGBP-RES: received 60 length Discover packet 
*Mar  6 01:17:50.757: SGBP-RES:  Attempting to send offer to 1EB9B891, offer:
   connected 1, congested 0, links 1 
*Mar  6 01:17:50.761: SGBP-RES: Sent Offer message to ID 1EB9B891  64 bytes 

!--- This reactivates redistribution, and Delirium learns the route to Tremens 
!--- prasit(config-router)# redistribute connected route-map tag_connected_routes.

prasit#

Related Information

Updated: Sep 09, 2005 Document ID: 18287