What sort of performance data do you need to make SDN decisions at the network edge?
OpenSSL doesn’t come with its own trusted root certificates; you have to tell it where to find them. This should be straightforward – and it is – but Apple have found a way to make it trickier.
On a normal unix system, openssl is pretty good at locating the root certificates, but it still doesn’t automatically reference them. For example running Ubuntu:
john@ubuntu:~$ openssl s_client -connect www.microsoft.com:443
CONNECTED(00000003)
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network,
OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN =
VeriSign Class 3 Public Primary Certification Authority - G5
verify error:num=20:unable to get local issuer certificate
verify return:0
[...removed for brevity...]
PSK identity hint: None
SRP username: None
Start Time: 1425842365
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
Openssl is unable to validate the Verisign certificate. So where are the trusted root certificates stored? Actually, Openssl will tell us:
john@ubuntu:~$ openssl version -d
OPENSSLDIR: "/usr/lib/ssl"
Add that into the command as the -CApath
parameter, and:
john@ubuntu:~$ openssl s_client -CApath /usr/lib/ssl -connect
www.microsoft.com:443
CONNECTED(00000003)
depth=3 C = US, O = Continue reading
In Cisco IOS packets are forwarded through the router (or Layer 3 switch) by Cisco Express Forwarding (CEF). A data structure called the CEF table contains a list of known IP prefixes and the outgoing interface that packets should be put on in order to get them onwards to their destination. That’s well and good. But how do the IP prefixes make it into the CEF table? To answer that question you have to work backwards and understand the order of operations that IOS goes through in order for a prefix to make it into the CEF table.
The answer to the question of what makes it into the CEF table confused me a bit, particularly when working with complex redistribution schemes. I would end up concentrating so much on admin distance (AD) that I would overlook the other, more important elements that went into determining what went into the CEF table. In order to improve my understanding I came up with this order of operations which helps me not only with redistribution, but in pretty much any situation where I’m trying to do traffic engineering.
You will not find this order of operations on cisco.com or in any Continue reading
The fantastic Troopers 15 conference is in full swing… and I’m done with the presentations ;) The last talk I had during the conference focused on automating network security. The slides are already online; I’ll add the link to the recording when they upload the videos.
Broadcom's non-Trident switch chips add a few high-end options.
The IOS XRv counters virtual routers from Ericsson and Juniper.
In Cisco IOS packets are forwarded through the router (or Layer 3 switch) by Cisco Express Forwarding (CEF). A data structure called the CEF table contains a list of known IP prefixes and the outgoing interface that packets should be put on in order to get them onwards to their destination. That's well and good. But how do the IP prefixes make it into the CEF table? To answer that question you have to work backwards and understand the order of operations that IOS goes through in order for a prefix to make it into the CEF table.