Why Easter doesn’t it fall at different times in different time zones

If Easter Sunday falls “on the first Sunday AFTER the first full moon after the vernal equinox”, why doesn’t it fall at different times in different time zones?  This year for example, tonight’s (Easter Saturday March 31 2018) full moon occurs after midnight in places between the International date line and the UTC+11 time zone. So according to the formula, Kiwi kids should have to wait another week before breaking open those chocolate eggs.

Well, it turns out that the formula is not set by the astronomical path of the moon, but by a bunch of men (I’ve no doubt women weren’t invited) who formulated the Ecclesiastical Lunar Calendar so long ago that it was before the split of the Gregorian and Julian calendars. (In 325 AD/CE in fact).

Which means today we actually have two Easters, one for each of the divergent calendars, even though both follow the same formula.

Anyway, in the said Ecclesiastical Lunar Calendar, the vernal equinox is always March 21, irrespective of the position of the earth in regard to its transit around the sun. And Easter is always the Sunday following the Pascal Full Moon. And for the calculation of Easter, the Pascal Full moon is defined as been the 14th day after the Ecclesiastical Lunar new moon – so we are back to the Ecclesiastical Lunar Calendar and its ancient origins.

Now it’s probably a good thing that there is a universal standard or two, it means we only have two variations – the Gregorian and the Julian – of Easter throughout the world, and children in New Zealand, Fiji etc. don’t have to hang out for another week to get their Easter Eggs – oh that’s unless they are following the Julian calendar (as Orthodox Christians do), it which case they will have to wait until April 8 2018!

RedNectar

Advertisements
Posted in blog, opinion

CSMA/CD and full duplex for wireless? It could be coming

A group of researchers at National Instruments have found a way to listen to radio signals while receiving on the same frequency.

The team found a solution that relies on in-band full duplex, so it can sense while transmitting, which potentially eliminates all collision overheads in wireless networks.

This could have huge implications – and even give your home wifi a boost if you have a lot of users – certainly will give the office and cafe wifi hotspots a boost.

The problem with existing wireless communications is that once a device starts transmitting, it doesn’t know if another device has transmitted at the same time (causing a collision) until it has finished transmitting and waited for an acknowledgement from the Access Point.  If no acknowledgement comes, it tries again. This is called Carrier Sense, Multiple Access with Collission Avoidance (CSMA/CA).

Your ancient (1980-c2000) shared Ethernet on the other hand operated in much the same way, a device would start transmitting, but was able to detect if any other device transmitted at the same time, and so stop transmitting immediately. This was called  Carrier Sense, Multiple Access with Collission Detection (CSMA/CD) and is course much more efficient than Collision Avoidance.

But that is not the whole story. Modern wired Ethernet networks use two pairs of wires to transmit, and another to recieve, meaning they can transmit AND receive at the same time. Full Duplex.  If we could do that for wireless, (and this article indicates that they have achieved full-duplex operation albeit with just 6 devices at this stage), then the benefits could be much greater.

RedNectar

Posted in blog, opinion, wifi, wireless network | Tagged ,

Why have WordPress made it soooo hard to follow someone?

WordPress, you have hosted my blog since 2010.  I won’t start a tirade of things you STILL can’t do on WP, but I am going to have a whinge about one feature you have obscured.

Why have WordPress made it soooo hard to follow someone?  I should never have to respond to a reader’s comment such as the one I got today.

I would like to thank you sooooo much for such a awesome ACI blogs, I found things here which are not well documented even in Cisco Docs. You are surely doing a great job. I wish to find a subscriber button on your website and keep up with your great work.

For those who would like to follow my blog, or any other wordpress.com blog, you have to move your cursor to the bottom right-hand corner of the page, and/or scroll up a bit (scrolling is clearly the only option on a mouseless device). You will then get an option pop up giving you the chance to follow or subscribe to my blog.

folllow-subscribe

Posted in opinion, rant, wordpress | Tagged | 2 Comments

RedNectar’s HX Pre-Install Checklist

…has been updated and is found here: https://rednectar.net/2018/10/06/rednectars-hyperflex-pre-install-checklist-updated/

Posted in Cisco, Data Center, Data Centre, Hyperflex, UCS | Tagged , , ,

ISIS, COOP, BGP and MP-BGP in Cisco ACI

Note: This post started as an answer I gave on the Cisco Support Forum. This version is slightly expanded with pictures and examples.

In this post I will examine the roles of three very important protocols that exist in the ACI environment.

I will explain

  • that IS-IS is the underlying routing protocol that is used by the leaves and spines to learn where they sit in the topology in relation to each other
  • how Leaf switches use COOP to report local station information to the Spine (Oracle) switches
  • how BGP and MP-BGP is used to redistribute routes from external sources to leaf switches.

Let me start with a picture.  Imagine a simple 2leaf/2spine topology with HostA attached to to Leaf1 and with HostB attached to to Leaf2.

  • Leaf1 has a VTEP address of 10.0.1.101
  • Leaf2 has a VTEP address of 10.0.1.102
  • Spine1 has a VTEP address of 10.0.1.201
  • Spine2 has a VTEP address of 10.0.1.202
  • HostA has a MAC address of A and an IP address of 192.168.1.1 and is attached to port 1/5 on Leaf1
  • HostB has a MAC address of B and an IP address of 192.168.1.2 and is attached to port 1/6 on Leaf2

Enter IS-IS

The leaves and spines will exchange IS-IS routing updates with each other so that Leaf1 sees that it has two equally good paths to reach Leaf2, and Leaf2 sees that it has two equally good paths to reach Leaf1.


Leaf1# show ip route vrf overlay-1 10.0.1.102
IP Route Table for VRF "overlay-1"

10.0.1.102/32, ubest/mbest: 2/0
*via 10.0.1.201, eth1/51.2, [115/3], 6d20h, isis-isis_infra, L1
*via 10.0.1.202, eth1/52.2, [115/3], 6d20h, isis-isis_infra, L1

For now, that’s all we need to know about IS-IS – it is the routing protocol used by the VTEPs to learn how to reach the other VTEPs.

Now think about the hosts.

This is where COOP comes in.

When Leaf1 learns about HostA because, say HostA sent an ARP request seeking the MAC address of 192.168.1.2 (which you know is HostB, but that’s not relevant at the moment), Leaf1 looks at that ARP request, and just like a normal switch, learns that MAC A is present on port 1/5.  But the leaf is a bit more clever than that, and looks INSIDE the payload of the ARP packet and learns that Host1 also has an IP address of 192.168.1.1 and records all this information in its Local Station Table.

Leaf1#show endpoint interface ethernet 1/5

VLAN/Domain  Encap VLAN  MAC/IP Address  Interface
+-----------+----------+----------------+---------
65           vlan-2051  a036.9f86.e94e L eth1/5
Tenant1:VRF1 vlan-2051  192.168.1.1    L eth1/5

AND THEN reports this information to one of the spine switches (chosen at random) using the Council Of Oracles Protocol (COOP).  The spine switch (oracle) that was chosen then relays this information to all the other spines (oracles) so that every spine (oracle) has a complete record of every end point in the system.

The spines (oracles) record the information learned via the COOP in the Global Proxy Table, and this information is used to resolve unknown destination MAC/IP addresses when traffic is sent to the Proxy address.

Note that all of this happens without anything to do with BGP.

But to round off the COOP story, we would assume that at some stage Leaf2 (a citizen) will also learn HostB‘s MAC and IP and also inform one of the spines (oracles) at random of this information using the COOP.

Spine1#show coop internal info repo ep | egrep -i "mac|real|-"
------------------------------------------
EP mac : A0:36:9F:86:E9:4E
MAC Tunnel : 10.0.1.101
Real IPv4 EP : 192.168.1.1
------------------------------------------
EP mac : A0:36:9F:61:88:FD
MAC Tunnel : 10.0.1.102
Real IPv4 EP : 192.168.1.2

So COOP is used solely for the purpose of distributing endpoint information to spine switches (oracles). As far as I know, spine switches never use COOP to distribute end host information to leaf switches.

So where does BGP fit in?

BGP is not needed until an external router is connected.  So now imagine that Leaf2 has had a router connected and has learned some routes from that external router for a particular VRF for a particular Tenant.

How can Leaf2 pass this information on to Leaf1 where HostA is trying to send packets to one of these external networks?  For Leaf2 to be able to pass routing information on to Leaf1 and keep that information exclusive to the same VRF, we need a routing protocol that is capable of exchanging routing information for multiple VRFs across an underlay network

Which is exactly what MP-BGP was invented for – to carry routing information across MPLS underlay networks.  In the case of ACI, BGP is configured by choosing an Autonomous System number and nominating one of the spine switches to be a route reflector.  MP-BGP is self configuring, you don’t need to do anything to make it work!

(Although you will have to configure your Tenant to exchange routes with the external router.)

Leaf1# show ip route vrf Tenant1:VRF1

192.168.1.0/24, ubest/mbest: 1/0, attached, direct, pervasive
*via 10.0.1.102%overlay-1, [1/0], 04:43:32, static, tag 4294967295
192.168.1.10/32, ubest/mbest: 1/0, attached, pervasive
*via 192.168.1.10, vlan25, [1/0], 03:52:23, local, local
1.0.0.0/8, ubest/mbest: 1/0
*via 10.0.1.102%overlay-1, [200/5], 00:11:41, bgp-1, internal, tag 1

RedNectar
aka Chris Welsh

Posted in ACI, ACI configuration, APIC, Cisco, Data Center, Data Centre, EPG, L3 Out, L3out | Tagged , ,

Guest Post! WTF Are all those Checkboxes? (ACI L3 Outs) – Part 2 of ???

Found this great post explaining a lot of fine detail on ACI L3 outs – make sure you check out the original!

Come Route With Me!

My friend and colleague Mr. Jason Banker recently ran into some good times with the mysteries of the ACI L3 Out Checkbox Madness! He Slack’d me and told me he’d found some clowns blog post about it (yours truly) and that some updates and additional information was needed, so he kindly volunteered some time to help out! Without further ado here is Jason’s Checkbox Madness:


As we continue to deploy fabrics we always joke about these damn routing checkboxes shooting us in the foot.  We play with different scenarios in the lab to ensure we understand how these pesky boxes work and what other options we have for future deployments.   The scenario here was to use get different OSPF areas connected to the same border leaf using ACI as the transit.  This scenario brings up some certain challenges and hopefully my testing will help others understand it a little better…

View original post 999 more words

Posted in GNS3 WorkBench

Non overlapping VTEP IP addresses in Cisco ACI

In a Cisco ACI deployment, Cisco recommends that “The TEP IP address pool should not overlap with existing IP address pools that may be in use by the servers (in particular, by virtualized servers).”

Let me tell you a reason much closer to reality why you might want to avoid overlapping your Cisco ACI TEP addresses with your locally configured addressing scheme.

When you first configure a Cisco ACI fabric, you need to configure a range of IP addresses that the ACI Fabric uses internally for VTEP addressing of the APICs, leaf and spine switches and other internally used addresses like anycast addresses for the spine proxy functions.

As I mentioned, Cisco recommends that “The TEP IP address pool should not overlap with existing IP address pools that may be in use by the servers (in particular, by virtualized servers).” I can only guess by the wording of this advice that Cisco sees that there may be some issue with the APICs being able reaching remote VTEPs on Cisco AVS virtual switches, but I see this as an outlier scenario.

The problem with VTEP IP address pools is the APICs.  You see, the APICs can’t handle:

  1. having a management IP address that overlaps with the VTEP address space, (it can’t figure out which interface to send management responses on) or
  2. being accessed from a workstation that is using an IP address that overlaps with the VTEP address space.

Since it is conceivable that any internal IP address may need to access the APIC for some reason sometime, I would recommend that you don’t overlap VTEP addresses with any currently used internal addresses.

Below is an example of the routing table from an APIC:


apic1# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         172.16.11.1     0.0.0.0         UG        0 0          0 oobmgmt
10.0.0.0        10.0.0.30       255.255.0.0     UG        0 0          0 bond0.3967
10.0.0.30       0.0.0.0         255.255.255.255 UH        0 0          0 bond0.3967
10.0.32.64      10.0.0.30       255.255.255.255 UGH       0 0          0 bond0.3967
10.0.32.65      10.0.0.30       255.255.255.255 UGH       0 0          0 bond0.3967
169.254.1.0     0.0.0.0         255.255.255.0   U         0 0          0 teplo-1
169.254.254.0   0.0.0.0         255.255.255.0   U         0 0          0 lxcbr0
172.16.11.0     0.0.0.0         255.255.255.0   U         0 0          0 oobmgmt
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
apic1#

In this case, the VTEP address range is 10.0.0.0/16, and the APIC sees all 10.0.x.x IP addresses as being reachable via the bond0.3967 interface, as shown by the
10.0.0.0 10.0.0.30 255.255.0.0 UG 0 0 0 bond0.3967
routing table entry on the APIC.

Recall I said that the APICs can’t handle:

  1. having a management IP address that overlaps with the VTEP address space, (it can’t figure out which interface to send management responses on) or
  2. being accessed from a workstation that is using an IP address that overlaps with the VTEP address space.

I’ll deal with case #2 first.

Now imagine for a minute I have a workstation with an IP address of say 10.0.11.11 that wishes to communicate with the OOB (Out of Band) management IP address of the APIC, which happens to be 172.16.11.111.  Now that remote workstation of 10.0.11.11 may well have a perfectly good route to 172.16.11.11, and may indeed be able to send packets to the APIC.

The problem of course arises when the APIC tries to send the reply packets to 10.0.11.11. As per the APIC’s routing table, the APIC would expect to reach 10.0.11.11 via its bond0.3967 interface, as shown by the
10.0.0.0 10.0.0.30 255.255.0.0 UG 0 0 0 bond0.3967
routing table entry on the APIC.

Similarly, with case#1. This time, imagine I had used 10.0.11.0/24 as https://supportforums.cisco.com/discussion/13311571/overlapping-or-non-overlapping-vtep-poolmy OOB Management subnet.  Since that overlaps with my VTEP range (10.0.0.0/16) there is potential that IP addresses from my OOB subnet (10.0.11.0/24) could be allocated to VTEPs somewhere – and if that happened my APIC would be unable to communicate with any other 10.0.11.0/24 address on the OOB subnet that clashes with a VTEP address.  In theory, the APIC would still be able to communicate with the VTEP addresses because it adds a /32 address to its routing table for every VTEP, but in my experience when I saw a customer with this configuration there was a problem communicating with the OOB subnet.

RedNectar

STOPPRESS
Just been reading this discussion on the Cisco forum – it seems that the docker0 interface that was introduced in version 2.2 may also screw up the APIC’s view of the rest of the world in the same way

References:

This is an expansion of a reply I gave on the Cisco Support forum

More information on VTEP addressing in the Cisco Application Centric Infrastructure Best Practices Guide

Posted in ACI, ACI configuration, APIC, Cisco, Data Center, Data Centre | Tagged , , , ,