This week, I am teaching an old class Route, and just want to sum up some of my old notes about some erratic of the course material.

In the discussion of running EIGRP over NMBA (e.g. Frame Relay) network, there is a slide as below:

 

 What's wrong with this slide (at least some pitfall)? This slide seems want to show in the case of partial mesh Frame Relay subscription, it can still work with EIGRP by configurating the IP address in main interface without using subinterface.
In fact, that’s not true. In order to make the above work, there are few things that need to cater.

1. As R2 and R3 do not have a direct PVC between them, in order to make them able to communicate with each other, there must be an explicit "frame-relay map" configuration to map the remote IP to the local DLCI. Yet, wait a minute, as there is no PVC between them, so what DLCI to use? Acutally, you need to map the remote IP to the DLCI number to R1 (middle router).
2. As now, R2 and R3 actually reach each other by using R1, its obvious that the interface of R1 must be up.
3. Even if R2 and R3 can reach each other, it doesn’t necessary means that they can form EIGRP neighbor. In such case, you need to explicitly use the "neighbor <remote IP> <outgoing interface>" statement to manually configure EIGRP neighbor.
4. But once you use the neighbor statement, the multicast method for automatic neighbor discovery will no longer work. That means, you not only need to manually configure neighbor between R2 and R3, you also need to manually configure R1 as neighbor.
5. If you still want to use multicast neighbor, another method it to just let R2 and R3 forming neighbor with R1 only,  without letting them to form neighbor of each other. In such case, you still need to disable split horizon for eigrp in R1 by using “no ip split-horizon eigrp <AS>” command , otherwise R2 can’t learn route from R3 (and vice versa), even thought R2 and R3 still can’t form neighbor. R2 will be able to learn route of R3 (and vice versa), next hop will become R1. You can even skip the frame-relay map (but R2 cannot directly reach R3). Following is the configuration of this method:
   
   For R1:
   hostname R1
   interface Serial0/0/0
    ip address 10.1.110.1 255.255.255.0
    encapsulation frame-relay
    no ip split-horizon eigrp 1
   router eigrp 1
    network 10.0.0.0
   
   For R2:
   hostname R2
   interface Serial0/0/0
    ip address 10.1.110.2 255.255.255.0
    encapsulation frame-relay
    frame-relay map ip 10.1.110.3 221
   router eigrp 1
    network 10.0.0.0
   
   For R3:
   hostname R3
   interface Loopback1
    ip address 10.1.3.1 255.255.255.0
   interface Serial0/0/0
    ip address 10.1.110.3 255.255.255.0
    encapsulation frame-relay
    frame-relay map ip 10.1.110.2 231
   router eigrp 1
    network 10.0.0.0

Now if you show the routing table of R2:

R2#sh ip route
...
     10.0.0.0/24 is subnetted, 2 subnets
D       10.1.3.0 [90/21152000] via 10.1.110.1, 00:07:34, Serial0/0/0
C       10.1.110.0 is directly connected, Serial0/0/0

What's the next hop of the route (10.1.3.0) advertised by R3?

Just finish the FlexPod training, there are 2 things that want to clarify.

The fist thing is about the FCoE connectivity between the Nexus 5K and the Netapp storage. The reference architecture (diagram below) shows that a vPC is formed between the 2 N5K, then the vPC connects to the ifgrp of the Netapp filer.

Here there is an important points to be aware. The vPC can be used to carry traffics for all data VLANs, but not the FCoE traffic. In fact, in the design guide, it mentions that in order to key the SAN A/B design (as from the UCS SAN traffic design, we always keep 2 different storage paths). the FCoE traffic of a particular VSAN (which actuatlly caried by VLAN) will not be send in both links of the vPC. E.g. if the left hand side N5K is carrying the traffic of VSAN 201 over VLAN 101, while the right hand side VSAN 202 over VLAN 102 Then the links from the left hand side N5K to the Netapp will only carry VSAN 201/VLAN 101, while right hand side is VSAN 202/VLAN 102.

While data VLAN will have no restriction, e.g. if VLAN 50 is for data, then the VLAN 50 traffic can be carried over all 4 links (as below).

The 2nd thing is, currrently the FCoE cannot support FCoE port channel, i.e. you can't use 2 parallel links connecting the Netapp filer to the same N5K. Thus for FCoE storage deployment, the reference design is the only valid physical connectivity design.