Understand VPC in different Nexus platform

VPC loop prevention:

N7K

• vPC will not allow traffic that was RECEIVED over a VPC peer-link to be sent out a vPC member port

This means any traffic from peer-link will not be sent out a VPC member port, doesn't matter it is from the same port channel or not. 

For example traffic from vpc member 1 on switch 1 with switch 2 's mac as destination mac address. The traffic will send across peer link and then switch 2 will do the routing. If the traffic needs to go out the vpc member 2 on switch, the traffic will be drop even it is different vpc member. 

Because VPC supports to use local VPC member to forwarding the traffic either L2 bridging or L3 routing. 

http://www.ccierants.com/2012/03/vpc-gotchas-you-need-to-know.html



N5K

http://www.cisco.com/c/en/us/support/docs/switches/nexus-5000-series-switches/115900-l2mp-vpc-switch-00.html

This link provides details of the packet flow between peer link using fabricpath and how loop avoidance works in the new 5500.  



Commands

peer-switch:

When peer-switch is enabled, each Nexus 7000 switch shares a virtual bridge ID, which allows both switches to act as root for the VLAN.

http://www.cisco.com/c/en/us/support/docs/routers/7000-series-routers/116140-config-nexus-peer-00.html

peer-gateway: 

you can use the peer-gateway command to allow Cisco Nexus 5500 Platform switches to perform Layer 3 forwarding if the destination MAC of the incoming packet is the MAC of its vPC peer switch. The peer-gateway command avoids forwarding such packets to the vPC peer link. 

You must configure the peer-gateway command on both vPC peer switches.

Fiber SFP Gigabit Ethernet

Most of the vendors won't allow auto-negotiation. If there is mismatch, the Interface will become down/down.

Cisco Switch (C4900)
For fiber Gigabit Ethernet interfaces, the default is no speed nonegotiate, which sets the speed to 1000 Mbps and enables link negotiation for flow-control parameters and remote fault information. The speed nonegotiatecommand disables link negotiation.

Router:

no negotiation auto

show interface

Full Duplex, 1000Mbps, link type is force-up, media type is LX  (when nonegotiate)

Full Duplex, 1000Mbps, link type is auto, media type is LX  (when auto negotiate)

EIGRP Redistribution

EIGRP redistribution

There is no default metric for EIGRP so you need to manually configure metric when you redistribute routes from other routing protocol. But there are some exceptions:

1. Static route using next hop
          EIGRP will redistribute the static route using the exiting (next hop) interface's metric

2. IGRP
          If they have the same AS number, it will automatically redistribute between each other. Otherwise you need to manually configure but not need to configure metric.

3. Static route using interface
          You can use network statement (EIGRP internal route) or redistribute static (EIGRP external route) to advertise the route.

G.729/G.729a

G.729 and G.729a are compatible. The only difference is on the encode site. In RTP stream, both G.729/G.729a use the same payload type(15).


The following is from the IEEE.

This article describes the ITU-T Recommendation G.729 Annex A
(G.729A) for encoding speech signals at 8 kb/s with low complexity. G.729A
is the standard speech coding algorithm for multimedia digital simultaneous
voice and data (DSVD). G.729A is bitstream interoperable with G.729; that
is, speech coded with G.729A can be decoded with G.729, and vice versa. OF CLIP>

DSP resource

Normally we refer one DSP as PVDM2-16 which has 16 channel. So PVDM2-64 have four DSPs onboard.

Trancode can share DSP with voice channel. Conference will use dedicated/whole DSP even you just need fewer session.

1. One DSP has 240 flex credits.
2. Low complexity voice or transcoder uses 15 credits. This is for G.711.
3. Medium complexity voice or transcoder uses 30 credits. This is for G.729a.
4. High complexity voice or transcoder uses 40 credits. This is for G.729.


Here we can calculator how many transcoders one DSP can support.
1. 6 sessions for G.729
2. 8 sessions for G.729a.
3. 2 session for conference with 8 conferees each for G.729/G.729a. Total 16 conferees.
4. 8 session for conference with 8 conferees each for G.711. Total 64 conferees.
5. 16 G.711 voice channels.
6. 8 G.729a voice channels.
7. 6 G.729 voice channels.

Another thing interesting is:
1. For remote branch, PSTN comes in and send to Unity which is G.729a and use 30 credits. Then the call will be forward to local branch, but the Cisco GW still allocated 30 instead of 15 credits.

CUCM call recording

To enable call recording in CUCM,

1) Enable Built-in-bridge on the phone setting.
2) Enable Call monitoring on the DN. There are two configuration, one is "Recording Option", the other is "Recording Profile".

When you set "Recording option" to "Automatic Call Recording Enabled", when the RTP stream is estabilished, the codec will be locked which will cause some issues.

Let's look at a sample, agent A and B are on the same location. User from remote branched call agent A and this is a G729 call. Then agent A transferred the call to agent B using consultative transfer which will create a G722 RTP. Note that right now agent B is locked to G722. But based on the region setting, it should use G729 between the user and agent B. So when agent A hit transfer again, the call will be disconnected.

Here is the solution:
1. Disable G722 option for call recording DNs.
2. Setup Transcoder per branch which will have call recording enabled.

Finally I became a CCIE.

I passed my R&S CCIE on Sept 25, 2009 at RTP. What a relief!! Now I am starting my voice CCIE.

Cat QoS

3550 support both inbound and outbound policy. 3560 only support inbound policy.

1. 3550 per-port per-vlan policy
class-map match-any dscp-class
match ip dscp af31
!
class-map match-all vlan-class
match vlan 5 10-30 40
match class-map dscp-class
!
policy-map vlan-dscp
class-map vlan-class
set dscp CS3
police 128000 8000 exceed-action drop
!
inter fa 1/13
service-policy input vlan-dscp


2. 3560 SVI by using hierarchical policy maps
!
! Any non-IP traffic
!
mac access-list extended MAC_ANY
permit any any 0x0 0xFFFF

!
! Any IP traffic
!
ip access-list extended IP_ANY
permit ip any any

!
! Class for any non-IP traffic
!
class-map MAC_ANY
match access-group name MAC_ANY

!
! Class for any IP traffic
!
class-map IP_ANY
match access-group name IP_ANY

!
! Class to match the port connected to R1
!
class-map PORT_R1
match input-interface FastEthernet 0/1

!
! Class to match the port connected to R3
!
class-map PORT_R3
match input-interface FastEthernet 0/3

!
! Inteface-level policy-maps, limit rate per-port (R1 & R3)
!
policy-map PORT_R1
class PORT_R1
police 64000 8000

!
policy-map PORT_R3
class PORT_R3
police 512000 64000

!
! VLAN policy-map; two levels
!
policy-map VLAN_POLICY
class IP_ANY
set dscp 24
service-policy PORT_R1
class MAC_ANY
set dscp ef
service-policy PORT_R3
!
! Attach a switch-wide VLAN policy
!
interface VLAN 1
service-policy input VLAN_POLICY
!
! Enabe VLAN based-QoS on some ports
!
interface range FastEthernet 0/1, FastEthernet 0/3
mls qos vlan-based

Route-map for Redistribution

1. match ip next-hop prefix-list is not supported in redistribution route-map.
So it is better to use ACL whenever is possible in route-map when doing redistribution.

Wording

1. Using MQC, rate limit the traffic to 8kbps with minimum possible burst.
The burst doesn't Be, it is actually mean Bc. So the minimum configuration for bc is 1000
So the command would be "policy cir 8000 bc 1000"

NAT virtual interface

Legacy NAT is domain based NAT. You need to define inside and outside. And the order of routing and NAT is different.
Traffic from outside, NAT first then routing.
Traffic from inside, routing first then NAT.

The new NAT virtual interface has no difference between interface outside or inside.
1. First it will check the packet to see if it needs to be NAT
2. If it needs to be NAT, it will be routed to the virtual interface then doing the NAT.
3. After the NATed, it will be routed again.

Sample:

R3:
interface Serial 1/0.301 point-to-point
no ip nat inside
ip nat enable
!
interface Serial 1/0.302 multipoint
no ip nat outside
ip nat enable

!
!  Remove old rules
!
no ip nat inside source static 155.1.13.1 155.1.23.1
no ip nat outside source static 155.1.23.2 155.1.13.2

!
! Add "domainless" rules
!
ip nat source static 155.1.13.1 155.1.23.1
ip nat source static 155.1.23.2 155.1.13.2

Frame relay QoS

MQC_Based Frame relay traffice shaping:

In summary:

- Legacy command frame-relay traffic-shaping is incompatible with MQC-based FRTS (you can’t mix them)
- Fancy queueing could not be used as a PVC-queueing strategy: CBWFQ is the only option available
- Per-VC CBWFQ is configured via hierarchical policy-maps configuration: Parent policy sets shaping values, while child policy implements CBWFQ
- You may apply policy-map per-interface (subinterface) or per-VC, using match fr-dlci under class-map submode
- You can’t apply FRF.12 fragmentation with MQC commands – it should be applied at physical interface level. By doing so, FRF.12 is effectively enabled for all PVCs
- Physical interface queue could be set to any of WFQ/CQ/PQ or CBWFQ (not restricted to FIFO as with FRTS legacy) – though this is rarely needed

Sample: Shape PVC DLCI 112 to 384Kpbs and enable FRF.12 fragmentation for all PVCs

class-map VOICE
match ip dscp ef
!
class-map DATA
match ip dscp cs1

!
! Match the specific DLCI
!
class-map DLCI_112
match fr-dlci 112

!
! "Child" policy-map, used to implement CBWFQ
!

policy-map CBWFQ
class VOICE
priority 64
class DATA
bandwidth 128
class class-default
fair-queue

!
! "Parent" policy map, used for PVC shaping
! With multiple classes, we can match different DLCIs
! all at the same physical interface (where they belongs)
!

policy-map INTERFACE_POLICY
class DLCI_112
shape average 384000
shape adaptive 192000
service-policy CBWFQ

!
! Apply the parent policy map at physical interface level
! Also, configure FRF.12 "global" settings here
!

interface Serial 0/0/0
service-policy output INTERFACE_POLICY
frame-relay fragment 640 end-to-end


==========================================================

Legacy Frame Relay traffic shaping:

- Enabled with frame-relay traffic-shaping command at physical interface level
- Incompatible with GTS or MQC commands at subinterfaces or physical interface levels
- With FRTS you can enforce bitrate per-VC (VC-granular, unlike GTS), by applying a map-class to PVC
- When no map-class is explicitly applied to PVC, it’s CIR and Tc are set to 56K/125ms by default
- Shaping parameters are configured under map-class frame-relay configuration submode
- Allows to configure fancy-queueing (WFQ/PQ/CQ) or simple FIFO per-VC
- No option to configure fancy-queueing at interface level: interface queue is forced to FIFO (if no FRF.12 is configured)
- Allows for adaptive shaping (throttling down to minCIR) on BECN reception (just as GTS) and option to reflect incoming FECNs as BECNs
- Option to enable adaptive shaping which responds to interface congestion (non-empty interface queue)

Frame Relay Fragmentation

FRF.12 - Enable under the class map

FRF.11 Annex C - use "vofr" under frame relay dlci configuration mode

Cisco - use "vofr cisco" under frame relay dlci configuration mode

Notes:
1. The class-map defines the fragment size, vofr [cisco] just states that the dlci is encapsulated using FRF.11 or Cisco.

Frame Relay Compression

Stacker vs Predictor
1. Stacker is more CPU intensive.
2. Predictor is more Memory intensive.

Frame relay compression schemes:
1. Data payload compression.
1.1 Cisco proprietary packet-by-packet payload compression. It uses Stacker compression
For a multiple interface use:
frame-relay map ip 10.1.1.1 100 payload-compress packet-by-packet
For P2P interface:
frame-relay payload-compress packet-by-packet.

1.2 FRF.9 uses Stacker. It has better compression ratio than packet by packet.
You should use IETF encapsulation for the pvc that uses FRF.9. Actually when you enable the rfr9 stac keyword, IETF encapsulation is automatically enabled.
For a multiple interface use:
frame-relay map ip 10.1.1.1 100 payload-compress FRF9 stac
For P2P interface:
frame-relay payload-compress FRF9 stac.



2. Packet header compression
2.1 TCP/IP. See RFC 1144
It is important to note that TCP/IP header compression is hop-by-hop compression scheme. The TCP/IP header must be replaced at each node. So it adds latency and CPU load.
And TCP/IP compression requires Cisco proprietary encapsulation.
For physical interface:
frame-relay ip tcp head-compression [passive]
For DLCI
frame-relay map ip 10.1.1.1 100 tcp header-compression [active|passive]
You can also disable it by:
frame-relay map ip 10.1.1.1 100 nocompress

2.2 RTP. See RFC 1889
It is also hop-by-hop compression. And only support Cisco encapsulation
frame-relay ip rtp header-compression [passive]
frame-relay map ip 10.1.1.1 100 rtp header-compression.
frame-relay map ip 10.1.1.1 100 compress (Enabel both tcp and rtp compression).

BGP desicion

With the best-path algorithm, BGP assigns the first valid path as the current best path. BGP then compares the best path with the next path in the list, until it reaches the end of the list of valid paths. The newest one is the first one and the eldest one is the end.



WLLA
OMNI

1. Weight
2. Local Prefer
3. Local injected
4. AS_Path

5. Original. IGP>EGP>Incompleted
6. Metric
7. Network Type. EBGP > IBGP
8. IGP metric to next hop.


The following has more details from cisco.com.

===================================================================

How the Best Path Algorithm Works

BGP assigns the first valid path as the current best path. BGP then compares the best path with the next path in the list, until BGP reaches the end of the list of valid paths. This list provides the rules that are used to determine the best path:

1. Prefer the path with the highest WEIGHT.
Note: WEIGHT is a Cisco-specific parameter. It is local to the router on which it is configured.

2. Prefer the path with the highest LOCAL_PREF.
Note: A path without LOCAL_PREF is considered to have had the value set with the bgp default local-preference command, or to have a value of 100 by default.

3. Prefer the path that was locally originated via a network or aggregate BGP subcommand or through redistribution from an IGP.
Local paths that are sourced by the network or redistribute commands are preferred over local aggregates that are sourced by the aggregate-address command.

4. Prefer the path with the shortest AS_PATH.
Note: Be aware of these items:
a. This step is skipped if you have configured the bgp bestpath as-path ignore command.
b. An AS_SET counts as 1, no matter how many ASs are in the set.
c. The AS_CONFED_SEQUENCE and AS_CONFED_SET are not included in the AS_PATH length.

5. Prefer the path with the lowest origin type.
Note: IGP is lower than Exterior Gateway Protocol (EGP), and EGP is lower than INCOMPLETE.

6. Prefer the path with the lowest multi-exit discriminator (MED).
Note: Be aware of these items:
1) This comparison only occurs if the first (the neighboring) AS is the same in the two paths. Any confederation sub-ASs are ignored.
In other words, MEDs are compared only if the first AS in the AS_SEQUENCE is the same for multiple paths. Any preceding AS_CONFED_SEQUENCE is ignored.
2) If bgp always-compare-med is enabled, MEDs are compared for all paths.
You must disable this option over the entire AS. Otherwise, routing loops can occur.
3) If bgp bestpath med-confed is enabled, MEDs are compared for all paths that consist only of AS_CONFED_SEQUENCE.
These paths originated within the local confederation.
4) THE MED of paths that are received from a neighbor with a MED of 4,294,967,295 is changed before insertion into the BGP table. The MED changes to to 4,294,967,294.
5) Paths received with no MED are assigned a MED of 0, unless you have enabled bgp bestpath med missing-as-worst .
If you have enabled bgp bestpath med missing-as-worst, the paths are assigned a MED of 4,294,967,294.
6) The bgp deterministic med command can also influence this step.
Refer to How BGP Routers Use the Multi-Exit Discriminator for Best Path Selection for a demonstration.

7. Prefer eBGP over iBGP paths.
If bestpath is selected, go to Step 9 (multipath).
Note: Paths that contain AS_CONFED_SEQUENCE and AS_CONFED_SET are local to the confederation. Therefore, these paths are treated as internal paths. There is no distinction between Confederation External and Confederation Internal.

8. Prefer the path with the lowest IGP metric to the BGP next hop.
Continue, even if bestpath is already selected.

9. Determine if multiple paths require installation in the routing table for BGP Multipath.
Continue, if bestpath is not yet selected.

10. When both paths are external, prefer the path that was received first (the oldest one).
This step minimizes route-flap because a newer path does not displace an older one, even if the newer path would be the preferred route based on the next decision criteria (Steps 11, 12, and 13).
Skip this step if any of these items is true:
1) You have enabled the bgp best path compare-routerid command.
Note: Cisco IOS Software Releases 12.0.11S, 12.0.11SC, 12.0.11S3, 12.1.3, 12.1.3AA, 12.1.3.T, and 12.1.3.E introduced this command.
2) The router ID is the same for multiple paths because the routes were received from the same router.
3) There is no current best path.
The current best path can be lost when, for example, the neighbor that offers the path goes down.

11. Prefer the route that comes from the BGP router with the lowest router ID.
The router ID is the highest IP address on the router, with preference given to loopback addresses. Also, you can use the bgp router-id command to manually set the router ID.
Note: If a path contains route reflector (RR) attributes, the originator ID is substituted for the router ID in the path selection process.

12.If the originator or router ID is the same for multiple paths, prefer the path with the minimum cluster list length.
This is only present in BGP RR environments. It allows clients to peer with RRs or clients in other clusters. In this scenario, the client must be aware of the RR-specific BGP attribute.

13. Prefer the path that comes from the lowest neighbor address.
This address is the IP address that is used in the BGP neighbor configuration. The address corresponds to the remote peer that is used in the TCP connection with the local router.

STP port stat

How to decide which port is root port.

1. root cost
2. neighbor bridge identifier
3. neighbor port identifier
4. local port identifier

Match Traceroute reply packet

NAT better remember enable overload.


ip nat inside source list 100 interface Loopback0 overload

permit icmp any any time-exceeded
permit icmp any any port-unreachable

BGP policy processing order

BGP Policy Processing Order

Inbound

1. Route map
2. Filter list, AS-path access list, or IP policy
3. IP prefix list or Distribute list

Outbound
1. IP prefix list or Distribute-list
2. Filter list, AS-path access list, or IP policy
3. Route map

BGP OSPF redistribution.

1. By default, BGP only redistribute ospf network type internal. To redistribute other type of ospf network, you need to add to the redistribution
redistribute ospf 1 ------ Only internal (intra and inter-area) routes
redistribute ospf 1 match external ---- Only external type 1 and 2 route
redistribute ospf 1 match internal external 2 --- only internal and external type 2
redistribute ospf 1 match nssa-external 1 ---- Only nssa-external type 1.

2. By default, iBGP redistribution into IGP is disabled.
Issue the bgp redistribute-internal command under router bgp process in order to enable redistribution of iBGP routes into IGP.

3. BGP and OSPF router-id
If BGP synchronization is enabled, there must be a match for the prefix in the IP routing table in order for an internal BGP (iBGP) path to be considered a valid path.

4. Link for tips. 911network.

IPv6 ACL implicit rules

IPv6 ACL Implicit Rules
• Implicit permit rules allow neighbor discovery

The following implicit rules exist at the end of each IPv6 ACL to allow ICMPv6 neighbor discovery:

permit icmp any any nd-na
permit icmp any any nd-ns
deny ipv6 any any