03-06-2017 10:37 AM
Can someone tell me why it is recommended that dynamic arp learning be disabled on the access-interface in BNG? Here's a link to the documentation
http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/bng/configuration/guide/b-bng-cg53xasr9k/b-bng-cg53xasr9k_chapter_0101.html
All I can see in the documentation is the recommendation but there is no explanation for it. My l2connected DHCP sessions are working with or without the command but it makes it harder to troubleshoot whether a customer is actually connected and working or not when there is no arp entry to look for. Is this just recommended so the router does not have to learn ARP for each subscriber to save resources? We're migrating off an old 10008SSG to 9006s running BNG and I'm debating whether to turn it off or not. Is there a different reason in IOS-XR or BNG in general that this should be turned off?
Another thing to note is my subnet l2connected sessions (where a customers IPV4 gateway resides directly on the subinterface) do NOT work with arp learning disable applied to the subinterface. I'm assuming since it doesn't use ip unnumbered it needs to have arp to find the remote connected devices like normal. If anyone can shed some light on this I would appreciate it. Thanks, Matt
03-06-2017 03:25 PM
hi Matt,
it is about saving resources. This document should help:
https://supportforums.cisco.com/document/12766486/troubleshooting-arp-asr9000-routers
Let me know if you have more questions.
regards,
/Aleksandar
03-06-2017 06:45 PM
yeah in addition for subscribers, we have no need to "learn" the arp entries because for the downstream, that is bng to subscriber, we can use the DHCP binding, all the info is there.
as part of speed of learning on normal, non subscriber interfaces, when we see a new mac we can associate that with an ip on the upstream direction and insert it in the ARP table in case we need to go downstream.
since this opens the door for arp poisoning, we decided a more secure implementation for subsribers to leverage the dhcp binding in both directions.
upstream: mac/ip/access interace match? accept packet
downstream: use mac from dhcp binding
this way a malicious user (or application like ettercap) that wants to become the default gateway and route packets THROUGH him to SEE everything will never fly.
so yeah, we dont really need to learn arp entries, so lets save the mem resources.
gotta love it :)
cheers!
xander
03-07-2017 06:50 AM
Yes that is a great step for security. Thanks for the explanation. Just for clarification is DHCP ("initiator dhcp" for subscriber sessions) a requirement for using the command arp learning disable?
The reason I ask is we have a bunch of sub interfaces terminating smaller ipv4 subnets like /29s and /30s for static customers. They work fine with "ipsubscriber ipv4 l2-connected initiator uncalssified-source" for sessions but if I apply the arp learning disabled command that's recommended in the documentation to these interfaces they stop working. Is that expected behavior or should the subinterfaces that don't utilize DHCP just not be configured with arp learning disable?
Thanks, Matt
03-07-2017 07:37 AM
hi matt,
correct, you need either snooping (l2) or proxy (l3) to maintain the binding.
while snooping/proxy consume resources maintaining that binding since they are stateful (as opposed to relay, whereby it is just dhcp packet forwarding really), they also allow for that extra check of the forwarding engine to leverage that binding info.
with that said, if you use proxy or snooping, you dont need arp learning, or better said, the learnt arp info is not used anyway. you could make a nice snooky capture from that by verifying the learnt arp dbase to the proxy/snoop list and if there is a discrepancy you found a possible hacker :).
arp learning is like mac learning. we associate a port with a mac (mac learning) whereas arp learning is associating an ip addr with a mac. but if we know the mac/ip combo already (by bindign) there is no need for me to learn this and might as well skip that phase :)
since ip subs without dhcp like the unclassified source, there is no binding, and we likely need to arp for the destination etc.
if you have static subs, consider conveting them to a dhcp model but handing out static adds either from dhcp OR using radius with framed-ip-addresss/netmask
that way you have bindigns, provide static addresses and can leverage the security proxy provides.
regards
xander
03-16-2017 12:39 PM
Thanks for all the infomation!
Would it cause any problems with BNG if we were to remove the command so enable arp learning is enabled? We have 5000 customers connecting to the router using BNG sessions.
03-16-2017 12:51 PM
when you have bng ip subs, there is really no need for arp learning, because on upstream (that is cpe to bng) we only respond with our default gateway, and we are not listening/updating the subscriber mac with the ip anyway
and on down stream we dont arp because we use the dhcp binding (yeah nice eh! :) for the path to the sub.
xander
01-03-2019 03:29 AM
Great thread !
Typically on access layer, I would deploy DAI and DHCP snooping. What is best practice deployment in scenarios where I have no management over access layer and Opt82 is not used ?
I am looking at additional security on top of subscriber ACLs.
For now, all what I have to go with is C-Tag/S-Tag and access technology can be a combo of FTTH or PON.
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