Here’s a trick question:
To implement this request you use the following configuration commands (plenty of other commands removed because they don’t impact the results):
router bgp 64500
address-family ipv4
maximum-paths ibgp 32
maximum-paths 32
neighbor 192.168.0.4 next-hop-self
neighbor 192.168.0.1 next-hop-self
address-family vpnv4
maximum-paths ibgp 32
maximum-paths 32
no neighbor 192.168.0.4 next-hop-self
no neighbor 192.168.0.1 next-hop-self
Try to figure out what the end-result will be without connecting to a router or reading the rest of this blog post.
Ok, here’s what totally threw me off (and wasted an hour of my life): next-hop-self is removed from neighbors in the IPv4 address family. Here’s why:
No wonder David Barroso named his library NAPALM (you’ll find the full story in this or this podcast).
I wanted to take just a moment to share the output of an APIC-EM ACL Trace (option in Path Trace). For this example, I have built out the topology below.
The applicable configuration for CSR1000v-2 is as follows–
ip access-list extended TESTING permit ospf any any permit icmp any any permit tcp any any eq telnet deny tcp any any eq 22 permit ip any any ! interface GigabitEthernet2 description to csr1000v-1 ip address 10.0.0.6 255.255.255.252 ip access-group TESTING in ip ospf cost 1 negotiation auto cdp enable
For testing it is possible to run a path trace from 10.1.1.1 (LAN interface on CSR1000v-1) to 10.1.2.1 (LAN interface on CSR1000v-2) with TCP Ports. To expose the layer 4 options, it is necessary to choose more options. The check mark in the “ACL Trace” instructs APIC-EM to evaluate ACLs.
The output indicates a successful trace AND an allowed match through the ACL.
Adjusting the path trace to target TCP port 22 demonstrates how a blocked flow is represented in APIC-EM.
The one caveat I have found is that this is only ‘semi’ real time. APIC-EM downloads the configuration from its Continue reading
A guest post by David Iles of Mellanox . This is the 4th blog in a 4-part series highlighting many of the features in our Cumulus Linux 3.2 release that are designed to help our customers move towards web-scale networking.
If you’ve ever been to an amusement park, you’ve seen those “must be this tall to ride” signs. With data centers, instead of goofy signs mocking the vertically challenged, network architectures plant strict feature requirements into RFPs to weed out the less mature offerings. In many cases, they even place features they don’t really need – sometimes as a way to measure the breadth of the offerings that get submitted.
Just as an archaeologist can determine the historical date of excavation sites based on the artifacts found there, I can usually identify the age of network RFPs by the features embedded in them: