6

I am trying to configure a 7609 router with a SUP7203BXL, SIP-400 and SPA5xGE as BRAS. The configuration is at the bottom of the question.

The sessions are created, but the clients can't reach Internet. (The 7609 itself can reach internet.) I have a 7206VXR working with the same configuration.

I can see a difference between them.

Virtual-Interfaces in the 7200 appear with the public IP address that Radius gives them, but the Virtual-Interfaces in the 7609 have the local pool which I configured for the template.

I imagine that the 7609 works in a different way so that the configuration running on the 7200 had to be changed.

How can I solve this problem?


Configuration:

version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
service counters max age 10
!
hostname R7609
!
boot-start-marker
boot system disk0:c7600s72033-advipservicesk9-mz.122-33.SRE1.bin
boot-end-marker
!
!
aaa new-model
!
!
aaa authentication login default local
aaa authentication enable default none
aaa authentication ppp default group radius
aaa accounting network default
 action-type start-stop
 group radius
!
!
aaa session-id common
!
ip source-route
!
!
ip domain name 7609PPP.com
ip name-server Y.Y.Y.40
ip name-server Y.Y.Y.20
!
!
!
vtp mode transparent
mls flow ip interface-full
no mls flow ipv6
no mls acl tcam share-global
mls cef error action freeze
multilink bundle-name authenticated
!
!
spanning-tree mode rapid-pvst
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
!
diagnostic bootup level complete
diagnostic cns publish cisco.cns.device.diag_results
diagnostic cns subscribe cisco.cns.device.diag_commands
!
redundancy
 main-cpu
  auto-sync running-config
 mode sso
!
vlan internal allocation policy ascending
vlan access-log ratelimit 2000
!
!
!
bba-group pppoe Servidor_PPPoE
 virtual-template 1
 sessions per-mac limit 1
 sessions per-vlan limit 6000
!         
!
!
interface Loopback1
 ip address X.X.X.X 255.255.255.0 secondary
 ip address 10.10.0.1 255.255.0.0
 no ip redirects
!
interface GigabitEthernet5/1
 no ip address
 shutdown
!
interface GigabitEthernet5/2
 no ip address
 shutdown
!
interface GigabitEthernet8/0/0
 no ip address
 shutdown
 negotiation auto
!
interface GigabitEthernet8/0/1
 description PPPOE_IN
 no ip address
 negotiation auto
 pppoe enable group Servidor_PPPoE
!
interface GigabitEthernet8/0/1.100
 description VLAN_PPPOE
 encapsulation dot1Q 100
 pppoe enable group Servidor_PPPoE
!
interface GigabitEthernet8/0/2
 no ip address
 negotiation auto
!
interface GigabitEthernet8/0/2.10
 description PPPOE_Out
 encapsulation dot1Q 10
 ip address Y.Y.Y.1 255.255.255.0
!
interface GigabitEthernet8/0/3
 no ip address
 negotiation auto
!
interface GigabitEthernet8/0/3.55
 description To_Radius
 encapsulation dot1Q b
 ip address 172.20.3.7 255.255.255.192
!
interface GigabitEthernet8/0/4
 no ip address
 shutdown
 negotiation auto
!
interface Virtual-Template1
 description Template_PPPoE
 ip unnumbered Loopback1
 ip policy route-map toallot
 peer default ip address pool PPPoE_pool
 ppp authentication pap
!
interface Vlan1
 no ip address
!
ip local pool PPPoE_pool 10.10.0.10 10.10.255.254
!
route-map toallot permit 10
 match ip address 100
 set ip next-hop Z.Z.Z.1
!
access-list 100 permit ip any any
!
!
no ip http server
no ip http secure-server
ip route 0.0.0.0 0.0.0.0 Z.Z.Z.1
ip route 192.168.50.0 255.255.255.248 172.20.3.1
radius-server attribute nas-port format d
radius-server attribute 31 mac format unformatted
radius-server attribute 31 send nas-port-detail mac-only
radius-server host 172.20.3.12 auth-port 1812 acct-port 1813 key --------
  • 1
    Thank you for your question... a few things... A) Teun's edits looked valid to me, I'm not sure why you rolled back, but they looked like an improvement. Please let me know if I'm mistaken. B) Could you give us this route-map: toallot, it seems to be missing from the config in the question. C) Can you confirm that this is running on a real 7600 chassis (i.e. not a Catalyst6500 chassis)? – Mike Pennington Mar 14 '14 at 9:42
  • Hi Mike, A)it was a mistake... In fact i couldn't read what he told me... So sorry!!!! B) route-map toallot permit 10 match ip address 100 set ip next-hop Z.Z.Z.1 and the access-list 100 is just permit ip any any (all traffic forced to go to my internet router). C) It is a 7609 chassis. COnfirmed – RS1983 Mar 14 '14 at 10:48
  • The SUP7203BXL has been extracted from a 6509 chassis where was the standby sup in sso redundancy configuration. I uploaded the IOS 12.2(33)SRE for the 7609 to the CompactFlash and inserted in the 7609 chassis... Maybe ths could help (i don't know if something could remain in the config) as long as i only changed configuration and the boot variables...If anymore information is needed ...PLease tell me – RS1983 Mar 14 '14 at 11:12
  • In addition to the configuration, i add all my public ip ranges in the Loopback interface, and the private ip 10.10.0.1 (the first ip of the pppoe pool range ) too. I have a default route to my internet router which has an ip address in the same range as the int gi8/0/2.10 subinterface. The internet router can't reach any subnet of the 7609. Should i change the loopback public address to the 8/0/1.1000 interface (where traffic from the users come in)? – RS1983 Mar 15 '14 at 14:45
  • As the command: aaa authorization network default group radius wasn't defined in the config, the ip was always taken from the pool, not from the Radius Framed-IP-Address attributte. Anyway, that's not all. Router can't ping directed devices... I introduced the command ip redirects in the Loopback interface but the problem persists. – RS1983 Mar 17 '14 at 9:36
1

I used to have lots of strange issues with SIP400 cards and 7609 chassis...

Not sure if this one is matching the behaviour but please check it:

CSCsb69734

SIP400: Sub-int IP state up but not reachable after SSO & reload

Symptom:

In rare situations, the 7600-SIP-400 SPA-2X1GE sub-interfaces can be unreachable even when the interface state is up. Ping or even control plane traffic (such as OSPF hellos) do not pass through the sub-interface but traffic passes through the main interface.

Conditions:

The problem might be encountered when a SSO switchover is done concurrently on one of the routers and line card/SPA reset is done on the directly connected interface on the other router.

Workaround:

When the interface is manually reset the problem disappears (i.e. shutdown, then no shutdown on the interface). A SPA/line card reset also solves the problem.

Further Problem Description:

This problem is seen with IP & IPv6 configurations on the subinterface.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.