• Author : Harshita Rastogi


DHCP Snooping

Introduction EOS supports DHCP Relay feature, which relays DHCP Requests/Responses between DHCP clients and DHCP servers in different subnets. However, DHCP server does not have visibility of where the request originated from and can only make IP address allocation decisions based on the client MAC address alone (client MAC address is included in the DHCP packet as part of the payload). To remedy that, DHCP Option-82 was formalized to allow relay agent to include Remote ID and Circuit ID so that DHCP server can apply more intelligent allocation policy. Switch intercepts DHCP requests from client and insert Option-82 information in...
Continue reading →

DHCP Smart Relay

Introduction EOS DHCP relay agent forwards all the DHCP requests from the clients using the primary IP address of the interface as the ‘giaddr’ in the relayed/forwarded requests even when there are secondary IP addresses configured on the interface and there are multiple IP address pools from secondary IP subnets with available addresses on the server. DHCP smart relay feature supports forwarding requests with secondary IP addresses in the gateway address ‘giaddr’ field. This allows the DHCP server offer addresses to client requests with gateway addresses from secondary IP subnets configured on the interface. The smart relay agent keeps track...
Continue reading →

DHCP Relay

Introduction DHCP Relay feature forwards DHCP packets between client and server when DHCP server is not in the same broadcast domain as client. DHCP Relay should be configured on the gateway interface (SVI/ L3 interface ) for the clients. DHCP Relay agent creates a new unicast DHCP packet and sets the giaddr field to the ‘primary’ IP address of the interface on which DHCP request packet is received. The modified request packet is then relayed to one or more configured DHCP servers. DHCP server assigns ip address to client from the pool corresponding to giaddr field. Platform Compatibility Supported on...
Continue reading →

Understanding Logging Levels

Overview   EOS generates a number of logs to notify various events such as interface going down,spanning-tree state change, agent restart, bgp neighborship flap etc. One event can be more impacting than other and thus it is necessary that respective logs reflect that severity. This is why all the logs are categorized into different severity/logging levels. There are 8 logging levels available, from 0-7, 0 being most critical and 7 being least critical.  alerts         Immediate action needed           (severity=1)  critical       Critical conditions              (severity=2)  debugging      Debugging messages                (severity=7)  emergencies    System is unusable                (severity=0)  errors         Error conditions                  (severity=3)  informational  Informational messages            (severity=6)  notifications...
Continue reading →


Get every new post on this blog delivered to your Inbox.

Join other followers: