Category Archives: Advanced Networking Topics

Standard

Posted by

Posted on

08/28/2014

Posted under

Advanced Networking Topics, Virtualization

Comments

Leave a comment

VDCA550 OBJECTIVE 2.1 – 2.3 (IMPLEMENT AND MANAGE NETWORKING) IN ONE DENSE POST

[ Browse previous post –  VDCA550 OBJECTIVE 1.1 – 1.3 (IMPLEMENT AND MANAGE STORAGE) ]

Here are my notes for the Networking section of the blue print, after tons of reading and lab time.  Again – I am heavily relying on the VCAP5-DCA Official Cert Guide (OCG), and the vSphere 5.5 Documentation Center. 

 

Objective 2.1 Implement and Manage Virtual Standard Switch (VSS) Networks

 Create and Manage VSS Components – OCG page 48

http://pubs.vmware.com/vsphere-55/topic/com.vmware.vcli.examples.doc/cli_manage_networks.11.1.html

# Managing the VSS in the GUI – Options mapped out

VC > Host > Configuration > Networking > vSphere Standard Switch

ALL Available Options:

Networking - Refresh _____________________ Refreshes the Networking View
Networking - Add Networking… ____________ Opens the Add Network Wizard, options below
 - Virtual Machine Portgroup ___________ Choose/create vSwitch, label, vlan-id,
 - VMkernel - choose/create vSwitch ____ Label, vlan-id, mark for vmotion/ft/mgmt, 
                                         ip/ipv6/both, IP assignment
Networking - Properties…_____________________ Checkbox, Enables IPv6 Support on the host system
 vSwitch Port/Portgroup bubbles ___________ Displays the properties: General, Security,
                                         Traffic-Shaping, Failover-LB/NIC
 vSwitch - Remove… _______________ Deletes the vswitch
 vSwitch - Properties…
 * Network Adapters tab
 - Add… _________________ Add an unused physical network adapter (vmnic) to the vswitch.
 - Edit… ________________ Set the NIC speed/duplex settings.
 - Remove…_______________ Unassigns the vmnic from the vswitch
 * Ports Tab
 - Add…____________ Opens the Add Network Wizard [minus the vSwitch selection, same options]
 - Remove…_________ Delete the selected port/portgroup
 - Edit vSwitch… Opens the properties for the selected port/portgroup [4 tabs listed below]
    - General
        Number of Ports ___ Drop-down options: 24, 56, 120, 248, 504, 1016, 2040, 4088
        MTU _______________ 1500 - 9000
    - Security
        Promiscuous Mode ____ Accept - VM adapter receives all traffic on the wire. 
                              Reject - default operation
        MAC Addr Changes ____ Reject disables rx-vm traffic on init/effective MAC mismatch.                               Sw iSCSI initiator requires accept.
        Forged Transmits ____ Reject - Host drops tx traffic on init/effective MAC mismatch.
                              Accept - host says I accept whatevs
    - Traffic Shaping
        Status ______________ Enabled = Applied to each virtual network adapter 
        Avg Bandwidth _______ Bps allowed across a port, averaged over time.
        Peak Bandwidth ______ In Kbits/sec; Allowed range is 1 to 9223372036854775 Kbits 
                              That is ~ 1Million Terabytes
        Burst Bandwidth _____ Burst bonus gained when not all allocated bandwidth is used
    - NIC Teaming
        Load Balancing ___________ Dropdown: Originating Virtual Port ID / IP Hash / Source                                    MAC hash / explicit failover order
        Network Failover Detect __ Dropdown: Link status only / Beacon probing
        Notify Switches __________ Yes / No
        Failback _________________ Yes / No
         Failover Order __________ NIC Failover Function: Active/Standby/Unused Adapters

 - Edit Portgroup/VMKnet… Configurations here override the vSwitch-level configurations.
    - General
        Network Label _______________ Network Name
        Vlan ID _____________________ Specify the VLAN
        VMkernel Int-only settings __ Checkboxes for vMotion, Fault Tolerance Logging, Mana-                                      gement/iSCSI Port Binding/MTU
    - Security
        Promiscuous Mode ____ Accept - VM adapter receives all traffic on the wire. 
                              Reject - default operation
        MAC Addr Changes ____ Reject disables rx-vm traffic on init/effective MAC mismatch.
                              Sw iSCSI initiator requires accept.
        Forged Transmits ____ Reject - Host drops tx traffic on init/effective MAC mismatch.
                              Accept - host says I accept whatevs
    - Traffic Shaping
        Status __________ Enabled - Applied to each virtual network adapter / Disabled
        Avg Bandwidth ___ Bps allowed across a port, averaged over time.
        Peak Bandwidth __ In Kbits/sec; Allowed range is 1 to 9223372036854775 Kbits
                          that is, ~ 1Million Terabytes
        Burst Bandwidth _ Burst bonus gained when not all allocated bandwidth is used
    - NIC Teaming
        Load Balancing ___________ Dropdown: Originating Virtual Port ID / IP Hash / 
                                   Source MAC hash / explicit failover order
        Network Failover Detect __ Dropdown: Link status only / Beacon probing
        Notify Switches __________ Yes / No
        Failback _________________ Yes / No
        Failover Order ___________ Active/Standby/Unused Adapters ; Select vmnic, Move Up / Move Down

 Create and Manage Vmkernel Ports on Standard Switches

# Configuration/Management in the GUI (details in first section)
VC > Host > Configuration > Networking

# Managing Vmkernel ports in the CLI (commands with sample output)
# Query the tags on a vmknic

 ~# esxcli network ip interface tag get -i vmk4
 Tags: Management, VMotion, faultToleranceLogging

# Query the ipv4 summarized information for all vmkernel interfaces

~ # esxcli network ip interface ipv4 get
Name IPv4 Address IPv4 Netmask IPv4 Broadcast Address Type DHCP DNS
---- ------------ ------------- -------------- ------------ --------
vmk0 192.168.0.3 255.255.255.0 192.168.0.255 STATIC false
vmk1 192.168.0.61 255.255.255.0 192.168.0.255 STATIC false
vmk2 10.10.10.10 255.255.255.0 10.10.10.255 STATIC false

# Add a vmkernel interface to a vswitch’s port group

~ esxcli network ip interface add --portgroup-name

# Set the ipv4 information on an existing vmkernel interface

~ # esxcli network ip interface ipv4 set -i vmk4 -I 172.16.0.10 -N 255.255.0.0 -P false
~ # esxcli network ip interface ipv4 get
Name IPv4 Address IPv4 Netmask IPv4 Broadcast Address Type DHCP DNS
---- ------------ ------------- -------------- ------------ --------
vmk4 172.16.0.10 255.255.0.0 172.16.255.255 STATIC false

# Edit the enabled status & MTU of an existing vmkernel interface; e=enabled , i=interface-name , m=MTU

~ # excli network ip interface set -e [true|false] -i vmk# -m 1500

 Configure advanced vSS Settings – OCG Page 66

# Configuration/Management in the GUI (details in first section)
VC > Host > Configuration > Networking

# Managing vSwitches in the CLI (commands with sample output)
# Query all standard vswitch commands

~ # esxcli esxcli command list | grep vswitch.standard
 network.vswitch.standard add
 network.vswitch.standard list
 network.vswitch.standard remove
 network.vswitch.standard set
 network.vswitch.standard.policy.failover get
 network.vswitch.standard.policy.failover set
 network.vswitch.standard.policy.security get
 network.vswitch.standard.policy.security set
 network.vswitch.standard.policy.shaping get
 network.vswitch.standard.policy.shaping set
 network.vswitch.standard.portgroup add
 network.vswitch.standard.portgroup list
 network.vswitch.standard.portgroup remove
 network.vswitch.standard.portgroup set
 network.vswitch.standard.portgroup.policy.failover get
 network.vswitch.standard.portgroup.policy.failover set
 network.vswitch.standard.portgroup.policy.security get
 network.vswitch.standard.portgroup.policy.security set
 network.vswitch.standard.portgroup.policy.shaping get
 network.vswitch.standard.portgroup.policy.shaping set
 network.vswitch.standard.uplink add
 network.vswitch.standard.uplink remove

# Query global settings

~ # esxcli network vswitch standard list
vSwitch0
Name: vSwitch0
Class: etherswitch
Num Ports: 1536
Used Ports: 11
Configured Ports: 128
MTU: 1500
CDP Status: listen
Beacon Enabled: false
Beacon Interval: 1
Beacon Threshold: 3
Beacon Required By:
Uplinks: vmnic0
Portgroups: vmk1-iscsi, VM Network, Management Network

# Query vswitch policy details

~ # esxcli network vswitch standard policy failover get -v vSwitch0
Load Balancing: srcport
Network Failure Detection: link
Notify Switches: true
Failback: true
Active Adapters: vmnic0
Standby Adapters:
Unused Adapters:

~ # esxcli network vswitch standard policy security get -v vSwitch0
Allow Promiscuous: false
Allow MAC Address Change: true
Allow Forged Transmits: true

~ # esxcli network vswitch standard policy shaping get -v vSwitch0
Enabled: false
Average Bandwidth: -1 Kbps
Peak Bandwidth: -1 Kbps
Burst Size: -1 Kib

# Query vswitch portgroups

~ # esxcli network vswitch standard portgroup list
Name Virtual Switch Active Clients VLAN ID
------------------ -------------- -------------- -------
Management Network vSwitch0 1 0
My VMK Interface vSwitch3 1 1234
Prod-201 vSwitch3 1 201
VM Network vSwitch0 4 0

# Query switch port group policy details [works with failover/security/shaping policies]

~ # esxcli network vswitch standard portgroup policy security get -p 'VM Network'
Allow Promiscuous: true
Allow MAC Address Change: true
Allow Forged Transmits: true
Override Vswitch Allow Promiscuous: true
Override Vswitch Allow MAC Address Change: false
Override Vswitch Allow Forged Transmits: false

# Add Standard vSwitch named uber-vswitch with 2000 ports (default to128 configured ports, maximum 4096)

~ # esxcli network vswitch standard add -P 2000 -v uber-vswitch

# add two uplinks to uber-vswitch

~ # esxcli network switch standard uplink add -u vmnic0 -v uber-vswitch
~ # esxcli network switch standard uplink add -u vmnic1 -v uber-vswitch

# Set the MTU on uber-vswitch to 9000

~ # esxcli network switch standard set -m 9000 -v uber-vswitch

# Add a portgroup named uber-PG to uber-vswitch, configure the pg to tag with Vlan 100

~ # esxcli network switch standard portgroup add -p uber-PG -v uber-vswitch
~ # esxcli network switch standard portgroup set -p uber-PG -v 100

# Configure iphash policy with disabled switch notifications, and traffic shaping ~100mb on the uber-PG port group

~ # esxcli network switch standard portgroup policy failover set -p uber-PG -l iphash -n false
~ # esxcli network switch standard portgroup policy shaping set -p uber-PG -e true -b 100000 -k 150000 -t 200000

# About vSwitch NIC Teaming LB Options

explicit ______ Always use the highest order uplink from the list of active adapters which pass failover criteria.
iphash _______ Route based on hashing the src and destination IP addresses
mac Route ___ based on the MAC address of the packet source.
portid Route __ based on the originating virtual port ID.

 

 

Objective 2.2 Implement and Manage Virtual Distributed Switch (VDS) Networks

Determine use cases for and applying VMware DirectPath I/O – OCG Page 61

http://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.vsphere.networking.doc/GUID-BF2770C3-39ED-4BC5-A8EF-77D55EFE924C.html

DirectPath I/O “Passthrough”

Use case: Supporting extremely heavy network activity within a VM, when no other methods are sufficient.

 Migrate a vSS Network to a Hybrid or Full vDS Solution – OCG Page 62

#1 Create vDS, don’t migrate hosts or adapters
VC > Networking > Right Click DC > New vSphere Distributed Switch

#2 Prepare destination PortGroups for any existing networks
VC > Networking > vDS > Configuration > New Port Group...

#3 Connect Hosts
VC > Networking > vDS > Add Host…

#4 Select adapters
- Select the physical adapters
- For each VMkernel interfaces, choose the Destination port groups prepared.

#5 Migrate VM networking
- Check “Migrate virtual machine networking
- Select the Destination port group for each vm-network

#6 Click Finish

 Configure vSS and vDS Settings Using Command Line Tools – OCG Page 80

Not a lot regarding this.here are the available(mostly read) CLI commands for the DVS

~ # esxcli esxcli command list | grep network.vswitch.dvs
network.vswitch.dvs.vmware.lacp.config get
network.vswitch.dvs.vmware.lacp.stats get
network.vswitch.dvs.vmware.lacp.status get
network.vswitch.dvs.vmware.lacp.timeout set
network.vswitch.dvs.vmware list
network.vswitch.dvs.vmware.vxlan.config.stats get
network.vswitch.dvs.vmware.vxlan.config.stats set
network.vswitch.dvs.vmware.vxlan get
network.vswitch.dvs.vmware.vxlan list
network.vswitch.dvs.vmware.vxlan.network.arp list
network.vswitch.dvs.vmware.vxlan.network.arp reset
network.vswitch.dvs.vmware.vxlan.network list
network.vswitch.dvs.vmware.vxlan.network.mac list
network.vswitch.dvs.vmware.vxlan.network.mac reset
network.vswitch.dvs.vmware.vxlan.network.mtep list
network.vswitch.dvs.vmware.vxlan.network.port list
network.vswitch.dvs.vmware.vxlan.network.port.stats list
network.vswitch.dvs.vmware.vxlan.network.port.stats reset
network.vswitch.dvs.vmware.vxlan.network.stats list
network.vswitch.dvs.vmware.vxlan.network.stats reset
network.vswitch.dvs.vmware.vxlan.stats list
network.vswitch.dvs.vmware.vxlan.stats reset
network.vswitch.dvs.vmware.vxlan.vmknic list
network.vswitch.dvs.vmware.vxlan.vmknic.multicastgroup list
network.vswitch.dvs.vmware.vxlan.vmknic.stats list
network.vswitch.dvs.vmware.vxlan.vmknic.stats reset

 Analyze Command Line Output to Identify vSS and vDS Configuration Details

# Config detail from esxcli

~ # esxcli network vswitch dvs vmware list
 grosas-lab-dvs0
 Name: grosas-lab-dvs0
 VDS ID: 01 2f 16 50 eb 4a 7d 3d-d6 5a 7d 55 05 27 76 5b
 Class: etherswitch
 Num Ports: 1536
 Used Ports: 1
 Configured Ports: 512
 MTU: 1500
 CDP Status: listen
 Beacon Timeout: -1
 Uplinks:
 VMware Branded: true
 DVPort:
 Client:
 DVPortgroup ID: dvportgroup-77
 In Use: false
 Port ID: 0

# Config detail from net-dvs

~# net-dvs-l
switch 01 2f 16 50 eb 4a 7d 3d-d6 5a 7d 55 05 27 76 5b (etherswitch)
 max ports: 1536
 global properties:
 com.vmware.common.version = 0x 3. 0. 0. 0
 propType = CONFIG
 com.vmware.etherswitch.ipfix:
 idle timeout = 15 seconds
 active timeout = 60 seconds
 sampling rate = 0
 collector = 0.0.0.0:0
 internal flows only = false
 propType = CONFIG
 com.vmware.common.respools.list:
 netsched.pools.persist.nfs
 netsched.pools.persist.mgmt
 netsched.pools.persist.vmotion
 netsched.pools.persist.vsan
 netsched.pools.persist.hbr
 netsched.pools.persist.iscsi
 netsched.pools.persist.vm
 netsched.pools.persist.ft
 propType = CONFIG
 com.vmware.common.respools.sched:
 inactive
 propType = CONFIG
 com.vmware.common.alias = grosas-lab-dvs0 , propType = CONFIG
 com.vmware.common.uplinkPorts:
 dvUplink1
 propType = CONFIG
 com.vmware.etherswitch.mtu = 1500 , propType = CONFIG
 com.vmware.etherswitch.cdp = CDP, listen
 propType = CONFIG
 host properties:
 com.vmware.common.host.portset = DvsPortset-0 , propType = CONFIG
 com.vmware.common.host.volatile.status = green , propType = RUNTIME
 com.vmware.common.portset.opaque = false , propType = RUNTIME
 com.vmware.common.host.uplinkPorts:
 0
 propType = CONFIG
 port 0:
 com.vmware.common.port.alias = dvUplink1 , propType = CONFIG
 com.vmware.common.port.connectid = 0 , propType = CONFIG
 com.vmware.common.port.volatile.status = free
 com.vmware.common.port.volatile.vlan = VLAN 0
 propType = RUNTIME VOLATILE
 com.vmware.common.port.portgroupid = dvportgroup-77 , propType = CONFIG
 com.vmware.common.port.block = false , propType = CONFIG
 com.vmware.common.port.dvfilter = filters (num = 0):
 propType = CONFIG
 com.vmware.common.port.ptAllowed = 0x 0. 0. 0. 0
 propType = CONFIG
 com.vmware.etherswitch.port.teaming:
 load balancing = source virtual port id
 link selection = link state up;
 link behavior = notify switch; best effort on failure; shotgun on failure;
 active =
 standby =
 propType = CONFIG
 com.vmware.etherswitch.port.security = deny promiscuous; deny mac change; allow forged frames
 propType = CONFIG
 com.vmware.etherswitch.port.vlan = Guest VLAN tagging
 ranges = 0-4094
 propType = CONFIG
 com.vmware.etherswitch.port.txUplink = normal , propType = CONFIG
 com.vmware.common.port.statistics:
 pktsInUnicast = 0
 bytesInUnicast = 0
 pktsInMulticast = 0
 bytesInMulticast = 0
 pktsInBroadcast = 0
 bytesInBroadcast = 0
 pktsOutUnicast = 0
 bytesOutUnicast = 0
 pktsOutMulticast = 0
 bytesOutMulticast = 0
 pktsOutBroadcast = 0
 bytesOutBroadcast = 0
 pktsInDropped = 0
 pktsOutDropped = 0
 pktsInException = 0
 pktsOutException = 0
 propType = RUNTIME
 com.vmware.common.port.respools.cfg:
 netsched.pools.persist.nfs:0:50:-1:255
 netsched.pools.persist.mgmt:0:50:-1:255
 netsched.pools.persist.vmotion:0:50:-1:255
 netsched.pools.persist.vsan:0:50:-1:255
 netsched.pools.persist.hbr:0:50:-1:255
 netsched.pools.persist.iscsi:0:50:-1:255
 netsched.pools.persist.vm:0:100:-1:255
 netsched.pools.persist.ft:0:50:-1:255
 propType = CONFIG

 Configure Netflow – OCG Page 68

http://pubs.vmware.com/vsphere-55/topic/com.vmware.vsphere.networking.doc/GUID-55FCEC92-74B9-4E5F-ACC0-4EA1C36F397A.html

WC > DVS > Right click > All vCenter Actions - Edit Netflow > Provide collector IP/Port > Give DVS Switch IP Address

– Optional: Active flow export timeout
– Optional: Idle flow export timeout
– Sampling Rate

The sampling rate represents the number of packets that NetFlow drops after every collected packet. A sampling rate of xinstructs NetFlow to drop packets in a collected packets:dropped packets ratio 1:x. If the rate is 0, NetFlow samples every packet, that is, collect one packet and drop none. If the rate is 1, NetFlow samples a packet and drops the next one, and so on.

Determine Appropriate Discovery Protocol – OCG Page 68

http://pubs.vmware.com/vsphere-55/topic/com.vmware.vsphere.networking.doc/GUID-A1B145E9-6454-45C0-8E7E-71E04A3BC9FF.html

Use CDP for Cisco Switches / LLDP for everything else…

WC > DVS > Manage > Settings > Properties > Edit > Advanced > Type: CDP/LLDP | Operation: Listen/Advertise/Both

 Determine Use Cases for, and Configure PVLANs – OCG Page 69

http://pubs.vmware.com/vsphere-55/topic/com.vmware.vsphere.networking.doc/GUID-A9287D46-FDE0-4D64-9348-3905FEAC7FAE.html

WC > DVS > Manage > Settings > Private VLAN > Edit

– Define the Primary VLAN ID (VLAN Type Promiscuous)
– Define the Secondary VLANs (VLAN Type Community or Isolated)

Use Case: Private VLANs are used to solve VLAN ID limitations and waste of IP addresses for certain network setups.
A private VLAN is identified by its primary VLAN ID. A primary VLAN ID can have multiple secondary VLAN IDs associated with it. Primary VLANs are Promiscuous, so that ports on a private VLAN can communicate with ports configured as the primary VLAN. Ports on a secondary VLAN can be either Isolated, communicating only with promiscuous ports, or Community, communicating with both promiscuous ports and other ports on the same secondary VLAN.

 Use Command Line Tools to Troubleshoot and Identify VLAN Configurations – OCG Page 73

# Check Vlan IDs for portgroups

~ # esxcli network vswitch standard portgroup list
 Name Virtual Switch Active Clients VLAN ID
 ------------------ -------------- -------------- -------
 Management Network vSwitch0 1 0
 My VMK Interface vSwitch3 1 1234
 Prod-201 vSwitch3 1 300

# Change a Vlan ID on portgroup Prod-201

~ # esxcli network vswitch standard portgroup set -p Prod-201 -v 201

 

 

Objective 2.3 Troubleshoot Virtual Switch Solutions

 Understand the NIC Teaming failover types and related physical network settings – OCG Page 74

Edit Teaming and Failover Policy for a vSphere Standard Switch in the vSphere Web Client
Edit the Teaming and Failover Policy on a Standard Port Group in the vSphere Web Client
Edit the Teaming and Failover Policy on a Distributed Port Group in the vSphere Web Client
Edit Distributed Port Teaming and Failover Policies with the vSphere Web Client

Route based on Originating Virtual Port ID
– This is the default policy.
– The vSwitch assigns the VM’s virtual network adapter to a port number and uses the port number to determine which path will be used to route all network I/O sent from that adapter.
– This implementation does not require any changes on the connected physical switches.
– The vSwitch performs a modulo function, where the Port number is divided by the number of NICs in the team, and the remainder indicates the path to place the outbound I/O.
– If the path fails, the outbound I/O is automatically re-routed to a surviving path.
– This policy does not permit outbound data from a single virtual adapter to be distributed across all active paths on the vSwitch.

The Route based on Originating Virtual Port ID algorithm does not consider load into its calculation for traffic placement

Route based on Source MAC Hash
– This policy uses the MAC address of the virtual adapter to select the path, rather than the port number.
– The vSwitch performs a modulo function, where the MAC address is divided by the number of NICs in the team, and the remainder indicates the path to place the outbound I/O.

The Route based on Source MAC Hash algorithm does not consider load into its calculation for traffic placement.

Route based on IP Hash
– This is the only option that permits outbound data from a single virtual adapter to be distributed across all active paths.
– This option requires that the physical switch be configured for IEEE802.3ad “Link Aggregation”
– The vSwitch must be configured for IP Hash for inbound load balancing.
– The outbound data from each virtual adapter is distributed across the active paths using the calculated IP hash.
– If a virtual adapter is concurrently sending data to two or more clients, the I/O to one client can be placed on one path and the I/O to another client can be placed on a separate path.
– The outbound traffic from a virtual adapter to a specific external client is based on the most significant bits of the IP address of both the virtual adapter and the client. The combined value is used by the vSwitch to place the associated outbound traffic on a specific path.

The Route based on IP Hash algorithm does not consider load into its calculation for traffic placement. But the inbound traffic is truly load balanced by the physical switch.

Route based on Physical NIC Load (DVS Only)
– Factors the load of the physical NIC when determining traffic placement.
– Does not require special settings on the physical switch
– Initially, outbound traffic is placed on a specific path. Activity is monitored.
– When I/O through a specific vmnic adapter reaches a consistent 75% capacity, then one or more virtual adapters are automatically remapped to other paths.
– This is a good choice when Etherchannel on the physical switch is not feasible.

 Determine and Apply Failover Settings – OCG Page 77

http://pubs.vmware.com/vsphere-55/topic/com.vmware.vsphere.networking.doc/GUID-4D97C749-1FFD-403D-B2AE-0CD0F1C70E2B.html

WC > Manage > Networking > Virtual Switches > Edit Settings > Teaming and Failover
WC > DVS > Manage > Ports > Edit Distributed Port Settings

Network Failover Detection

# Link status Only
Relies only on the link status that the network adapter provides.
– Detects removed cables & physical switch port failures.
– Does not detect a physical switch port that is blocked by spanning tree or is misconfigured.
– Does not detect a pulled cable that connects a physical switch to another device.

# Beacon Probing
Sends out and listens for beacon probes on all NICs in the team and uses this information, in addition to link status, to determine link failure. ESX/ESXi sends beacon packets every second.
– Useful with teams of more than 3 nice, allows n-2 failures
– NICs must be in active/active or active/standby, NICs in unused state do not participate in beacon probing.

Notify Switches Yes/No – If Yes, a notification is sent over the network to update the lookup tables on the physical switches.
Set to No for features like Microsoft NLB in unicast mode.

 Configure Explicit Failover to Conform with VMware Best Practices – OCG Page 77

Override switch failover order to manually specify which NICs are Active / Standby / Unused.

 

Configure Port Groups to Properly Isolate Network Traffic – OCG Page 79

– VMware recommends that each type of network traffic is separated by VLANs.
– Separate VLANs for Management, vMotion, VMs, iSCSI, NAS, VMware HA Heartbeat, Fault Tolerance logging.
– Trunk the VLANs on the physical switch.

 

Given a Set of Network Requirements, Identify the Appropriate Distributed Switch Technology to Use – OCG Page 81

# VDS features

NetIOC

Netflow

Switch/Network Discovery [CDP / LLDP]

Network Rollback and Recovery

Port Mirroring
   Switched Port Analyzer[SPAN]
   Remote Switched Port Analyzer [RSPAN]
   Enhanced Remote Switched Port Analyzer (ERSPAN)
Port Security

TCP Segmentation Offload / Jumbo Frames

Single-Root I/O Virtualization (SR-IOV)

Traffic Filtering [ACL]

 

Configure and Administer vSphere Network I/O Control – OCG Page 83

Conveniently I have blogged about this one, and deployed it in production… and I’m running out of steam.

https://nsxtech.net/2012/07/18/vmware-network-io-control-netioc/

http://pubs.vmware.com/vsphere-55/topic/com.vmware.vsphere.networking.doc/GUID-ADEA0213-C969-43E4-B1F4-66D4A916EBDF.html

 

Use Command Line Tools to Troubleshoot and Identify Configuration Items From an Existing vDS

Already covered under Analyze Command Line Output to Identify vSS and vDS Configuration Details

Advertisements
Standard

Posted by

Posted on

09/08/2012

Posted under

Advanced Networking Topics

Comments

Leave a comment

CCIE-RS GOLDlab ASET CCIE Lab 1

Got a free moment to play around on Cisco.com/PEC  – cranked up the lab CCIE RS-FOCUS1  .  Focused on layer two concepts.

“This is an ASET Routing and Switching “focus” lab and is intended to aid your preparation for the CCIE Routing and Switching lab using CCIE Blueprint topics (as of 1/2/2008). This lab deals with the following topics:

  • CATALYST ETHERNET SWITCH CONFIGURATION
  • SPANNING TREE
  • SPANNING TREE OPTIONS
  • CATALYST INTERCONNECTIVITY
  • SWITCH SAFEGUARDS
  • VLAN LOAD BALANCING
  • VLAN FILTER
  • CLIENT AUTHENTICATION

The tasks are marked with checkboxes, my attempt to configure them is bold..

        Configure all switches for VTP domain = ASET101 and VTP mode = transparent.

On all switches:

en
conf t
vtp domain ASET101
vtp mode transparent
end

        Configure SW1 and SW2 for dot1q trunks on ports Fa0/23 and Fa0/24. These interfaces should be trunk interfaces even if their neighbor interfaces are not trunk interfaces.

conf t
int range f0/23 – 24
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
end

        Configure VLAN assignments as per the table below. Configure for static VLAN access and permanent nontrunking mode. 

VLAN SW1 SW2 SW3
13 – Fa0/1, Fa0/3 –
100 Fa0/10 Fa0/4, Fa0/6 –
145 Fa0/1, Fa0/4, Fa0/5 – –
200 – Fa0/2, Fa0/10 –
300 – Fa0/5 Gi0/10

SW1

conf t
vlan 100
vlan 145
exit
!
int fa0/10
switchport mode access
switchport access vlan 100
!
int range fa0/1,fa0/4 – 5
switchport mode access
switchport access vlan 145
end

SW2

conf t
vlan 13
vlan 100
vlan 200
vlan 300
exit
!
int range fa0/1,fa0/3
sw mod acc
sw acc vlan 13
!
int range fa0/4,fa0/6
sw mod acc
sw acc vlan 100
!
int range fa0/2,fa0/10
sw mod acc
sw acc vlan 200
!
int fa0/5
sw mod acc
sw acc vlan 300
!
end

SW3

conf t
vlan 300
!
Conf t
int Gi0/10
sw mod acc
sw acc vlan 300
!

end

1.2   SPANNING TREE

Ensure that all Per VLAN Spanning Tree parameters for active VLANs seen on SW1 are dictated by SW1. In addition, configure VLANS for which SW1 is root, with the following:

        Root priority of zero (0).

        An access port start-up delay, due to Spanning Tree, of 32 seconds.

SW1

!– VLANs 1,100,145

conf t
spann vlan 1 root primary
spann vlan 100 root primary
spann vlan 145 root primary
!
spann vlan 1 forw 16
spann vlan 100 forw 16
spann vlan 145 forw 16

1.3   SPANNING TREE OPTIONS

                                                                                Disable Spanning Tree for VLAN 13 on SW2.

        Configure SW2 to reduce the time it takes to choose a new root port when a link or switch fails or when the Spanning Tree reconfigures itself. Use a single command on SW2 for this.

        Configure SW2 such that the default behavior on all ports is to prevent alternate or root ports from becoming designated ports because of a failure that leads to a unidirectional link.

        Assume that SW2 interface Fa0/12 is connected to a customer’s Ethernet switch. Configure Fa0/12 to go into the root-inconsistent (blocked) state if the customer’s switch wants to become the Spanning Tree root.

        Assume SW2 Fa0/13 will never connect to a switch or bridge. Configure SW2 interface Fa0/13 using a spanning-tree command such that Bridge Protocol Data Units (BPDUs) are not sent on the port.

 

SW2

conf t

no spann vlan 13

spanning-tree uplinkfast

spanning-tree loop guard default

!

int fa0/12

spanning-tree bpduguard enable

!

int f0/13 

spann bpdufilter enable

1.4   CATALYST INTERCONNECTIVITY

Configure the Catalyst switches to prefer maximized bandwidth utilization between SW1 and SW2. Use a standards-based configuration. Configure the four physical interfaces to actively negotiate.

SW1#show cdp nei | in SW2

SW2                 Fas 0/24              148            S I      WS-C3550-2Fas 0/24

SW2                 Fas 0/23              148            S I      WS-C3550-2Fas 

SW2#show cdp nei | in SW1

SW1                 Fas 0/24              150            S I      WS-C3550-2Fas 0/24

SW1                 Fas 0/23              150            S I      WS-C3550-2Fas 0/23

conf t

int range fa0/23 – 24

channel-group 1 mode active

1.5   CONFIGURING SWITCH SAFEGUARDS

Fiber optic connectivity will eventually replace the existing trunks. Additional trunks between SW1 and SW2 will also be added at that time.  In order to assure that the fiber links are installed correctly and traffic is guaranteed to flow in a bi-directional manner, globally configure both switches such that a failing link is shut down in the event of a malfunction.

conf t

udld enable

1.6   VLAN LOAD BALANCING

VLANs 58 and 59 do not currently exist on the switches, but there are plans to use them in the future. Configure SW1 such that VLAN 58 traffic will pass primarily through the Gi0/1 interface and VLAN 59 traffic will pass primarily through the Gi0/2 interface. If one of the interfaces should fail, the remaining interface must carry all traffic. You do not need to actually configure the VLANs on the switches. Configure only Gi0/1 and Gi0/2 to accomplish this task. Your solution should not involve configuring a “cost”.

 

interface GigabitEthernet0/1

 switchport mode dynamic desirable

 spanning-tree vlan 58 port-priority 16

end

SW1(config)#do show run int gi0/2

Building configuration…

Current configuration : 111 bytes

!
interface GigabitEthernet0/2

 switchport mode dynamic desirable

 spanning-tree vlan 59 port-priority 16
end

These last two .. 1.7 requires a VLAN map, I couldn’t remember how.. here are the last two tasks if anyone in the ether wants to take a whack at how you would solve the issues..  I am too sleepy to continue (3am my time) .

– Gabe

1.7   VLAN FILTER

  • On SW2, prevent all DHCP client requests from entering or leaving VLANs 100, 200, and 300.
  • All BOOTP requests should be dropped; all other traffic should be forwarded.
  • Use a map NO-DHCP with access list 100 as part of the solution.

1.8   CLIENT AUTHENTICATION

  • On SW2, place interface Fa0/7 into VLAN 13 and force the interface into access mode.
  • Assume there is an 802.1X-compliant client attached to port Fa0/7. Configure the switch to prompt for client authentication on Fa0/7.
  • Assume a RADIUS server is reachable at 110.1.13.59 and it requires a RADIUS key of cisco. Use default accounting and authorization ports.
  • Do not configure any AAA commands except to enable AAA and then one line for dot1x authentication. A mistake may make SW2 unreachable for assessment purposes.
Standard

Posted by

Posted on

10/17/2011

Posted under

Advanced Networking Topics

Comments

Leave a comment

IPv6 Tunnel on your Cisco Router!

Heya, it’s me again. I thought I’d throw out a quick and dirty post since it’s been a while. Plus, I have a topic that’s more network-related, which is nice for this site since I know it’s trying to stay mainly networking related.

ISPs are still slow to adopt IPv6. Very few of us can say that we have globally-accessible IPv6 addresses. That’s annoying since it’s 2011 and all, but if you have a Cisco router, I can show you how to create an IPv6 tunnel that will you have dual-stacked and on the IPv6 Internet in no time! This article assumes that you cannot use native IPv6 out to the Internet, and that you already have the router properly set up and in use in an IPv4 network.

My router is a 2621XM, I bought it for $150 on eBay. It has two FastEthernet ports. It was manufactured in 1999. So any model at least as recent as that should be able to handle this just fine. I do IPv4 NATing between the two FE ports so that the rest of my home network served by my AT&T U-Verse Residential Gateway stays separate from my lab network, but the lab still has to go through the U-Verse gateway to reach the Internet.

For this to work for me, I needed to configure my U-Verse Gateway to put my Cisco router in “DMZ+” mode, and allow the outside interface of my Cisco router to receive a DHCP address. This allows my U-Verse gateway to assign my router the same public IPv4 address as itself.

We’re going to utilize the free service at Hurricane Electric for this. Follow that link and sign up. It’s their “Tunnel Broker” service that you’re after. After a short quiz, they will give you your very own IPv6 tunnel and your very own IPv6 address space!

All you need to do now is configure your router. If you’re reading this site this is probably elementary to you, so you know what these shorthand commands mean:

Router>en
Router#conf t
Router(config)#ipv6 unicast-routing
Router(config)#exit
Router#copy run start

At this point you have enabled ipv6 routing globally. Next, create a tunnel on your router like this:

Router>en
Router#conf t
interface Tunnel0
description Hurricane Electric IPv6 Tunnel Broker
no ip address
ipv6 enable
ipv6 address 2001:470:1f0e:5a4::2/64 (Use your side of the endpoint that Hurricane electric gave you!)
tunnel source 75.32.98.76 (Your public IPv4 address)
tunnel destination 216.218.224.42 (Hurricane Electric’s IPv4 endpoint for this tunnel)
tunnel mode ipv6ip
ipv6 route ::/0 Tunnel0
end
write

And you’re pretty much done! Configure your clients with an IPv6 address in that space, and you now have IPv6 connectivity all the way to the Internet. Google has a public DNS server at 2001:4860:4860::8888. Test out your tunnel by trying to ping that address. Remember that IPv6 and IPv4 are quite different. There is no NAT in IPv6. Internet communication is the way it was truly meant to be – end to end. That also means the need to protect yourself with firewalls will become more important than ever, since you can’t hide behind a NAT anymore!

Now you can surf the web with a “dual-stack,” meaning that you’re runnnig both IPv4 and IPv6 — and your IPv4 packets will take their normal route, while your IPv6 packets will be diverted through your new tunnel. Seamlessly. Pretty neat huh? Try to ping ipv6.google.com and see what happens! I guess that’ll have to do until ISPs catch up with IPv6 technology.

From here I could go on into configuring your own Windows-based DHCPv6 server, configuring your DNS server for IPv6 clients, etc… but that’s for another post. 🙂

–

Ryan@networkdojo.net

Standard

Posted by

Posted on

10/12/2011

Posted under

Advanced Networking Topics

Comments

Leave a comment

BGP Peering Explored

I had an opportunity to play around with GNS3 briefly today; configured eBGP.  I know a few things about the rules of an eBGP peering relationship from my past reading.  So today I was aiming to validate what I thought I understood.

I configured the following scenario:

Before starting up the BGP protocol and configuring the BGP peers, I configured a default gateway (Gateway of last resort on both sides of this WAN) in the end R1’s loopback 1.1.1.1 was able to ping 2.2.2.2 and vice-versa, all is perfect and well.

I configured everything else above ensuring that my update-source and multihop commands were not forgotten, asserting my self that this would be an easy breezy practice exercise.  When I was finished I went to check the neighbor peering state here is what i got:

R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4   200       0       0        0    0    0 never    Active
R2#show ip bgp summary
BGP router identifier 2.2.2.2, local AS number 200
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4   100       0       0        0    0    0 never    Active

Nooo! No cigar… there is IP connectivity, so what are we missing? Well… I know that an exact route must be in place for a route to be advertised, so I inferred that adding specific routes on both sides should do the trick.  So i went to add a static route for 2.2.2.2 on R1 first… to my surprise, setting up one side did the trick.  Here is what I saw:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ip route 2.2.2.2 255.255.255.255 10.1.1.2
R1(config)#
*Mar  1 00:20:36.119: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
R1(config)#end
R1#show ip bgp
*Mar  1 00:20:43.955: %SYS-5-CONFIG_I: Configured from console by console
R1#show ip bgp summ
R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4   200       4       4        1    0    0 00:00:10        0

The bgp debugs on the other side confirm the handshake was successful:

R2#debug ip bgp

BGP debugging is on for address family: IPv4 Unicast
R2#
*Mar  1 00:20:35.803: BGP: 1.1.1.1 passive open to 2.2.2.2
*Mar  1 00:20:35.807: BGP: 1.1.1.1 went from Active to Idle
*Mar  1 00:20:35.807: BGP: 1.1.1.1 went from Idle to Connect
*Mar  1 00:20:35.819: BGP: 1.1.1.1 rcv message type 1, length (excl. header) 26
*Mar  1 00:20:35.819: BGP: 1.1.1.1 rcv OPEN, version 4, holdtime 180 seconds
*Mar  1 00:20:35.819: BGP: 1.1.1.1 went from Connect to OpenSent
*Mar  1 00:20:35.819: BGP: 1.1.1.1 sending OPEN, version 4, my as: 200, holdtime 180 seconds
*Mar  1 00:20:35.823: BGP: 1.1.1.1 rcv OPEN w/ OPTION parameter len: 16
*Mar  1 00:20:35.823: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar  1 00:20:35.823: BGP: 1.1.1.1 OPEN has CAPABILITY code: 1, length 4
*Mar  1 00:20:35.823: BGP: 1.1.1.1 OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar  1 00:20:35.823: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 00:20:35.827: BGP: 1.1.1.1 OPEN has CAPABILITY code: 128, length 0
*Mar  1 00:20:35.827: BGP: 1.1.1.1 OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar  1 00:20:35.827: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 00:20:35.827: BGP: 1.1.1.1 OPEN has CAPABILITY code: 2, length 0
*Mar  1 00:20:35.827: BGP: 1.1.1.1 OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 1.1.1.1 rcvd OPEN w/ remote AS 100
*Mar  1 00:20:35.831: BGP: 1.1.1.1 went from OpenSent to OpenConfirm
*Mar  1 00:20:35.831: BGP: 1.1.1.1 send message type 1, length (incl. header) 45
*Mar  1 00:20:35.867: BGP: 1.1.1.1 went from OpenConfirm to Established
*Mar  1 00:20:35.867: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up

Interesting.  So you do not need to have exact routes in the routing table on both sides.  Oddly enough, you don’t even need to have the static routes in place after the TCP handshake is completed and the session is established.

R1(config)#no ip route 2.2.2.2 255.255.255.255 10.1.1.2
R1(config)#show ip route
             ^
% Invalid input detected at '^' marker.

R1(config)#do show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.1.1.2 to network 0.0.0.0

     1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback0
     10.0.0.0/30 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, Serial0/0
S*   0.0.0.0/0 [1/0] via 10.1.1.2

R1(config)#do show tcp brief
TCB       Local Address               Foreign Address             (state)
64C9C5B0  1.1.1.1.26251               2.2.2.2.179                 ESTAB

I set the the protocol to 2 second keepalives just to be double sure – and sure enough it stayed up.

R1(config-router)#timers bgp 2 20
R1(config-router)#end
R1#
*Mar  1 00:28:30.899: %SYS-5-CONFIG_I: Configured from console by console
R1#show ip bgp summ
R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4   200      12      12        1    0    0 00:08:01        0

R1#show ip bgp neighbors
BGP neighbor is 2.2.2.2,  remote AS 200, external link
  BGP version 4, remote router ID 2.2.2.2
  BGP state = Established, up for 00:08:22
  Last read 00:00:21, last write 00:00:21, hold time is 180, keepalive interval is 60 seconds
  Configured hold time is 20,keepalive interval is 2 seconds, Minimum holdtime from neighbor is 0 seconds
  Neighbor capabilities:
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                0          0
    Keepalives:            11         11
    Route Refresh:          0          0
    Total:                 12         12

Lessons learned:
Lesson learned #1 – BGP peering requires a specific route (from the specific source initiating the TCP handshake) simply having IP connectivity or a gateway of  last resort is not sufficient for the neighbor peering to establish.  It only requires it on the side initiating the handshake, the replying device can have only a default route.
Lesson learned #2 – BGP peering does not require a specific route once the TCP session is established, that means the requirement for a specific route in the table doesn’t exist so long as the TCP session is established.
Lesson learned #3 – BGP bite you in the rear if you’re not patient and careful!

That’s all for today peeps.  Good fight and good nite!

–

Gabe @ networkdojo.net

Standard

Posted by

Posted on

10/12/2011

Posted under

Advanced Networking Topics

Comments

2 Comments

BGP Quick Notes – Part 1

This is a dense facts review, this one is not meant for learning BGP for the first time; this post is meant to cover many of facts very quickly.  Without further delay…

WHEN SHOULD YOU USE BGP?
Good choice if you connect to multiple ISPs.
If you need to control how traffic enters or exists your network.
If you need to react to Internet topology changes.

BGP ROUTE OPTIONS
Three options for receiving BGP routes from an ISP:

• Default routes from each provider: Simple to configure, low bandwidth and light use of router resources.  The internal IGP metric determines the exit router for all traffic bound outside the autonomous system.  No BGP path manipulation is possible (can lead to suboptimal routing if you use more than one ISP).

• Default routes plus some more specific routes: This option results in medium use of bandwidth and router resources.  It enables you to manipulate the exit path for specific routes using BGP so that traffic takes a shorter path to networks in each ISP.  Thus path selection is more predictable.  The IGP metric chooses the exit path for default routes.

• All routes from all providers: This requires the highest use of bandwidth and router resources.   Typically done by large enterprises and ISPs.  Path selection for all external routes can be controlled via BGP policy routing tools.

TYPES OF ISP CONNECTIONS

•  Single-homed: A site with a single ISP connection.  This is sufficient for a site that does not depend heavily on Internet or WAN connectivity.  Either use static routes, or advertise the site routes to the ISP and receive a default route from the ISP.

• Dual-homed: A site with two connections to the same ISP, either from one or two routers.  Designed with  loadbalancing or with a primary link and  a redundant backup.   Either static or dynamic routing would work with this type.

• Multihoming: A site connecting to more than one ISP at the same time for redundancy, and for better performance if one ISP provides a better path to frequently used networks.  Also gives an ISP-independent solution.  BGP is typically used with multihomed connections.

• Dual multihoming: Two connections to multiple ISPs.  This gives the most redundancy.  BGP is used with the ISPs, and can be used internally as well.

BGP OVERVIEW

• BGP stands for Border Gateway Protocol.
• Routers running BGP are termed BGP speakers.
• BGP uses the concept of autonomous systems(AS).  An AS is a group of networks under a common administration.  IANA assigns AS.
• AS 1 to 64511 are public .  AS 64512 to 65535 are private.
• An AS will run an IGP within, and an EGP between AS.  BGPv4 is the only EGP currently in use.
• Routing between AS is coined interdomain routing.
• The admin distance (AD) for EBGP routes is 20. AD for IBGP routes is 200.
• BGP neighbors are called peers and must be statically configured.
• BGP uses TCP 179.  BGP peers exchange incremental, triggered route updates and periodic keep alives.
• Routers can run only one instance of BGP at a time.
• BGP is a path-vector protocol.  The route to a network consists of a list of AS on the path to that network.
• BGP’s loop prevention mechanism is the AS number.  When an update about a network leaves an AS, that autonomous systems’s number is prepended to the list of AS.  If it finds its own AS number in that list, the update is discarded.
• Use BGP when AS is multihomed, when route path manipulation is needed, or when the AS is a transit AS.
• Do not use BGP in a single-homed AS, with a router that does not have sufficient resources to handle it, or with a staff that does not have a good understanding of BGP path selection and manipulation.

BGP DATABASES
BGP uses 3 databases.  The first 2 are BGP specific, the 3rd is the one shared by all the routing processes on the router…

• Neighbor database:A list of all configured BGP neighbors.  To view it, use the show ip bgp summary command.

• BGP database, or RIB: A list of networks known by BGP, along with thier paths and attributes.  To view it, use show ip bgp command

• Routing table: The one seen with show ip route.

BGP MESSAGE TYPES

• Open: After a neighbor is configured, BGP sends an open message to try to establish peering.  The message includes AS, Router ID, and hold time.

• Update: Message used to transfer routing information between peers.  Includes new routes, withdrawn routes, and path attributes.

• Keepalive: BGP peers echange keepalives every 60 seconds by default.  These are used to maintain the peering session active.

• Notification: When a problem occurs that causes a router to end BGP peering, a notification message is sent to the neighbor, and the connection is closed.
INTERNAL AND EXTERNAL BGP 

Internal BGP (iBGP) is a peering relationship between routers in the same AS

External BPG (eBGP) is a peering relationship between routers in different AS.

Before any peering relationships will be formed a TCP session needs to be established.  There must be IP connectivity to the peer.

In this illustration, basic eBGP peering can be configured using the following commands :

RtrA(config)# Router bgp 65100
RtrA(config-rtr)#  neighbor 10.2.2.2 remote-as 65300
–
RtrD(config)# Router bgp 65300
RtrD(config-rtr)#  neighbor 10.2.2.1 remote-as 65100

If both routers are within a single AS.  The same commands (with the AS adjusted) would create an iBGP peering relationship.
BGP NEXT-HOP SELECTION
By default, the next hop for a route recieved from an EBGP neighbor is the IP address of the neighbor that sent the update.   When this update is relayed to IBGP neighbors, the next hop attribute is not changed.  Therefore IBGP routers must have a route to that next hop IP. Consider the scenario below.

An update from RtrA to RtrB would have a next-hop attribute of 10.2.2.1.  When RtrB passes the update to RtrC, the next hop will remain 10.2.2.1.  If RtrC does not have a route to 10.2.2.0/30 the update from RtrAwill be unusable by RtrC.  We can modify this rule by applying an additional neighbor command on RtrB:

RtrB(config-rtr)#  neighbor 10.3.3.2 remote-as 65200
RtrB(config-rtr)#  neighbor 10.3.3.2 next-hop-self

The next hop self will adjust the next hop attribute.  RtrC will recieve the update as if it had originated at RtrB – as a valid neighbor RtrC will necessarily have route to RtrB, and everything will work well :D.

Next-hop-self logic can also be to prevent extra hops on a Multiaccess Network.  (For example updates to RtrD about 10.2.2.0 do not need to hop through 10.3.3.3.  

BGP SYNCHRONIZATION

The BGP synchronization rule requires that when a BGP router receives information about a network from an IBGP neighbor, it does not use that information until a matching route is learned via an IGP or static route.  IT also does not advertise that route to an EBGP neighbor unless a matching route is in the routing table.  In the topology below if RtrB advertices a route to RtrC, the RtrC does not submit it to the routing table or advertise it to RtrD unless it also learns the route from an IGP source.  If all routers in the Autonomous system are running BGP, it is usually safe to turn off synchronization.  The command would be    Rtr{all}(config-rtr)#no synchronization.

BGP PEER GROUPS

neighbor peer {group-name} peer group  Creates a peer group to which you can assign neighbors.  

• By default, members of the peer group inherit all the configuration options of the peer group. Members also can be configured to override the options that do not affect outbound updates.

All the peer group members will inherit the current configuration as well as changes made to the peer group. Peer group members will always inherit the following configuration options by default:

•remote-as (if configured)
•version
•update-source
•outbound route-maps
•outbound filter-lists
•outbound distribute-lists
•minimum-advertisement-interval
•next-hop-self

BGP assumes neighbors are directly connected .  If they are not, we must specify in BGP to look more than one hop away for the neighbor.  We must apply the following command to the neighbor statement:
Rtr_(config-rtr)#neighbor {ip-address} ebgp-multihop {# of hops}

If we are peering with loopback interfaces, we need to specify the source of the BGP packets to match the loopback.  We would use this command:
Rtr_(config-rtr)#neighbor {ip-address} update-source {interface (ex. loopback 0} 

We can manually take down a peering session:  Rtr_(config-rtr)#neighbor {ip-address} shutdown.

THE BGP NETWORK COMMAND
In BGP, the network command tells the router to originate an advertisement for a network.  The network doesn’t have to be connected to the router; it just has to be in the routing table.

Rtr_(config-rtr)#network prefix mask subnet mask –    Initiates the advertisements

BGP PEERING STATES

Check state using the show ip bgp summary or show ip bgp neighbors.  The status can include the following:

Idle: No peering; router is looking for neighbor.  Idle(admin) means the neighbor has been admin shut.

Connect: TCP handshake completed.

OpenSent, or Active: An open message was sent trying to establish the peering.

OpenConfirm: Router has received a reply to the open message.

Established:  Routers havea  BGP peering session.  This is the desired state.

And lets call that a wrap.   In the next post  we’ll review BGP attributes, Path selection, route filtering, confederations, route reflectors, authentication, and show command review for troubleshooting… well maybe over 2 or 3 more posts.

If you’re still here, you’re nuts! Thanks for reading! 😀

~

Gabe @ networkdojo.net