03-28-2014 05:00 AM
Hello everyone.
I am trying to configure bng on ASR 9001 (5.1.1) for IPoE using available configuration guides. The most confusing part for me is ip address on access interface. Generally there are three components encompassing/referring client's address space using ipv4 unnumbered lo or specific address: dynamic template, access interface and giaddr in dhcp proxy configuration. So if specific address block is allocated to a client and added to a dhcp server (for example 192.168.1.0/24), then giaddr will be one of the address in this block (192.168.1.1), dynamic template will have address from the same block (192.168.1.1), what ip will be applied to access interface? According to a guide for IPoE:
"The IP unnumbered interface for session (local) address assignment is a mandatory feature configured under an IP dynamic template, and provides basic settings for proper IP session establishment. The unnumbered interface IP address will become the default gateway for the IP subscriber associated with the session. This address is also used as the "giaddr" in the dhcp proxy configuration to instruct the DHCP server to select an address in which this ipv4 add is routable in"
So I'm using same ip (192.168.1.1) from client block. Here is my configuration:
radius source-interface Loopback4000 vrf MANAGEMENT
radius-server vsa attribute ignore unknown
radius-server host 172.16.1.1 auth-port 1812 acct-port 1813
key 7 XXXXXXXXXXXXXXXXXXXXX
timeout 5
retransmit 1
!
aaa group server radius BNG_RAD
server 172.16.1.1 auth-port 1812 acct-port 1813
vrf MANAGEMENT
source-interface Loopback4000
!
aaa attribute format MY_AUTH
mac-address
!
aaa attribute format NAS_PORT_FORMAT
circuit-id plus remote-id separator .
!
aaa radius attribute nas-port format e SSAAPPPPQQQQQQQQQQVVVVVVVVVVUUUU type 32
aaa radius attribute nas-port format e SSAAPPPPQQQQQQQQQQVVVVVVVVVVUUUU
aaa radius attribute nas-port-id format NAS_PORT_FORMAT
aaa accounting subscriber default group BNG_RAD
aaa authorization subscriber default group BNG_RAD
aaa authentication subscriber default group BNG_RAD
dhcp ipv4
vrf CLIENT proxy profile CLIENT
profile CLIENT proxy
helper-address vrf CLIENT 192.100.100.1 giaddr 192.168.1.1
relay information option
relay information policy keep
relay information option allow-untrusted
!
interface GigabitEthernet0/0/0/0.50 proxy profile CLIENT
!
dynamic-template
type ipsubscriber IPSUB_TPL
vrf CLIENT
ipv4 unnumbered Loopback346
ipv4 access-group PERM_ALL ingress
ipv4 access-group PERM_ALL egress
!
!
ipv4 access-list PERM_ALL
10 permit ipv4 any any
!
class-map type control subscriber match-any DHCP
match protocol dhcpv4
end-class-map
!
!
policy-map type control subscriber IP_PM
event session-start match-first
class type control subscriber DHCP do-until-failure
5 activate dynamic-template IPSUB_TPL
!
!
end-policy-map
!
interface GigabitEthernet0/0/0/0.50
description ### CLIENT SUBSCRIBERS ###
ipv4 point-to-point
ipv4 unnumbered Loopback346
service-policy type control subscriber IP_PM
encapsulation dot1q 50
ipsubscriber ipv4 l2-connected
initiator dhcp
!
!
interface Loopback345
description ### BASE UNUSED IP FOR ACCESS INTERFACE ###
ipv4 address 11.11.11.11 255.255.255.255
!
interface Loopback346
description ### SUBNET FOR SUBSCRIBERS ###
vrf CLIENT
ipv4 address 192.168.1.1 255.255.255.0
!
interface Loopback4000
description ### Loopback for MANAGEMENT ###
vrf MANAGEMENT
ipv4 address 172.16.1.100 255.255.255.255
!
After commiting, session is not created and in debugs there are errors:
If unnumbered loopback inside access interface is changed to loopback 345 containing some unused ip address (11.11.11.11), then session is created, client received ip and everything is working. In debugs:
After session creation periodically the following warning is observed:
It must be noted that unused ip inside access interface is used by client as DHCP server's IP which forces client to send dhcp messages to a wrong address.
Any help will be appreciated.
05-05-2016 06:26 AM
Do you possibly have DHCP inform messages going around?
if that is the case, which is smells like, since you dont see any affected problems here and also it is said that the ip addr and gateway are fine then I can explain it as follows.
There is a check in sw that does this:
In the code we have this condition: if ((server_id & subnet_mask) != (pak->yiaddr & subnet_mask)) {
so basially if the address of the user and subnet doesnt fit in the gateway and subnet, we spit this message, BUT the issue is with DHCP INFORM. When we sent ACK on INFORM yiaddr will be 0.0.0.0 as per RFC. So this check will fail and print that message.
need to fix that in sw.
so fi you have inform, you can ignore this.
xander
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide