Today's Weekly Show explores new projects in the IETF Routing Area, and examines the organization's role in an age where open-source projects are driving ad hoc standards.
The post Show 285: IETF Routing Area Update appeared first on Packet Pushers.
Vendors had just one week in XO's lab to hammer out any issues.
Hey, it's HighScalability time:
Mark Baker left this comment on my Stretched Firewalls across Layer-3 DCI blog post:
Strange how inter-DC clustering failure is considered a certainty in this blog.
Call it experience or exposure to a larger dataset. Anything you build will eventually fail; just because you haven’t experienced the failure yet doesn’t mean that the system will never fail but only that you were lucky so far.
Read more ...Geoff Huston highlights that the IETF has never completed their standard process. One hundred and forty-six of these RFCs are Informational, four of these are Historic, 23 are Experimental, five are Best Current Practice and the remaining 193 are Standards Track documents. Of these 193 documents, 24 are already obsoleted, 164 are Proposed Standards, just five […]
The post There is NO IPv6 Standard appeared first on EtherealMind.
The post Worth Reading: Certification road map appeared first on 'net work.
We collect the top expert content in the infrastructure industry and fire it along the priority queue.
Sponsored by:
Join us for the NANOG 67 Hackathon -- a one-day event Sunday, June 12, 2016, at the Fairmont Chicago Millennium Park.
The NANOG 67 Hackathon will bring network operators together in a room to develop new ideas and hacks for automating production internet networks. Tools and software beyond those provided by vendors and existing open-source projects are needed to keep those networks up and running. By gathering together at NANOG 67 to collaboratively hack on code or hardware, develop ideas, and documentation we can open the possibilities of holistic network management through automation. And we will have fun while doing it!
event manager applet macNcheese
event mat mac-address 00bb.3a4b.5a01 type add maxrun 90
action 1 syslog msg "It's Mac N Cheese time!"
action 2 cli command "enable"
action 3 cli command "copy https://username:password@some_server/path/to/events.php^V?eventtype=MAC%20N%20CHEESE%20TIME! null:"
action 4 wait 60
action 5 cli command "clear mac address-table dynamic address 00bb.3a4b.5a01"
Most operating systems are not very secure out of the box and favor convenience and ease of use over security. IT Security professionals may not agree with a vendor’s user friendly approach to their OS, but that does not mean they have to accept it. There are steps that can be taken to harden a system and eliminate as many security risks as possible
System Hardening Examples
The most basic hardening procedure is to change the vendor default user name and password. You would be surprised how many vendor default access codes can found with a simple Google search!
System hardening can include configuration settings to remove unnecessary services, applying firewall rules, enforcing password complexity, setting failed login thresholds, and system idle time outs.
System hardening can also include installing an anti-virus program, forwarding logs to a centralized log management solution, and applying vendor released system patches.
Basically system hardening is a way to lock down the Operating System before the system goes into production. The hardening guides can not only detail the steps to follow to secure a system, but can complement any system deployment guides. Along with the list of procedures to follow to improve system security the hardening Continue reading
There are two different ways to configure DHCP in Junos, bootp helper and dhcp relay. These work in very different manner, bootp helper is being phased out and is not supported for example in QFX10k. Behaviour of bootp helper is obvious, it works like it works in every other sensible platform. Behaviour of dhcp-relay is very confusing and it's not documented at all anywhere.
If it's possible in your platform to configure bootp helper, do it. If not, complain to Junos about dhcp-relay implementation and ask them to fix it. The main problem with dhcp-relay implementation is that once you've configured it, you're punting all dhcp traffic in all interfaces. Normal transit traffic crossing your router is subject to this punt, so transit customers will experience larger jitter and delay of packets being punted and almost certainly reordering, because the non-dhcp packet that came after but was not subject to punt will be forwarded first. Technically reordering does not matter, as long as it does not happen inside a flow, but it's not desirable.
How the sequence of operation works in Junos for dhcp-relay: