Connection between GNS3 VM and another VM running Tacacs+ on VirtualBox

Scenario:

• Host machine running Ubuntu and VirtualBox
• VM#1 guest Lubuntu and GNS3 v1.3.7
• VM#2 guest Ubuntu server and tacacs+

In order to make VM#1 and VM#2 communicate do the following:

1. Create a new Host-only network by editing VirtualBox preferences
2. Add a new network adapter on each VM using the Host-only network adapter and select the previously created Host-only network
3. Change the Promiscuous mode setting to "Allow all" in both VMs
4. Run GNS3 as an Administrator 
5. In  GNS3 add a new cloud element and configure it using the ethernet interface pointing to the Host-only adapter
6. Connect the cloud element to router in GNS3
7. Configure static IP addresses or use a DHCP server (select respective option in VirtualBox)
8. "No shut" the respective ports on all devices involved
9. You should be able to ping from the router toward the tacacs server and the opposite

Notes

1. Always run GNS3 as Administrator. Otherwise nothing will work.
2. Don't forget to enable Promiscuous mode. Without it I could receive IPs from the DHCP server, but ping wasn't working.
3. You can avoid using the Host-only network and use your normal lan interface where your ADSL router is connected. That way your GNS3 VM will be able to connect to the internet.

BGP Notes

• BGP connection is a TCP connection on port 179
• Only the TCP server needs to approve the source of the packet it receives. Neighbor update-source is actually required only on one side, as long as correct IP addresses are being used
• When two routers attempt a BGP connection simultaneously, only one is preserved, the one from the router with the highest BGP router ID
• You can use the command "debug ip packet detail XXX" where XXX is an ACL matching the src/dst we are interested in
• iBGP learned routes are not advertised to other iBGP peers
• iBGP packets have TTL=255 while eBGP packets have TTL=1 by default
• If you see a message "... Active open failed - no route to peer..." it can be an indication of eBGP multihop missing
• Cisco eBGP performs the following independently
  1. Neighbor is directly connected on a known subnet
  2. Sends packets with TTL=1
• In order to form a neighborship between directly connected router using Loopbacks, you can use eBGP multihop, which actually disables #1 from the above. Alternatively you can use "neighbor disable-connected-check" to do the same.
• eBGP multihop command defaults to TTL=255
• BGP authentication is implemented through TCP option 19
• Unique BGP router ID within the BGP domain is required, in order to avoid traffic blackholes. That is due to loop prevention algorithm.

OSPF notes

• OSPF uses 224.0.0.5 (all routers) and 224.0.0.6 (all DR routers) multicast addresses
• Using per interface syntax injects both primary and secondary IP addresses, unless otherwise instructed
• Can't form a neighborship on a secondary IP address
• Using the network statement with IP unnumbered interfaces, it enables OSPF on both the normal and the unnumbered interface
• Using multipoint non-broadcast interfaces you can specify the OSPF cost per neighbor as an option of the neighbor command.
• The default network type on Loopback interfaces advertises a /32 route in OSPF. You need to change it to point-to-point to advertise let's say a /24
• The command "show ip ospf border-routers" is an easy way to view ABRs & ASBRs along with the costs to reach them. 
• In order to use unicast OSPF packets configure the network type as non-broadcast or point-to-multipoint non-broadcast
• Demand circuit feature is negotiated between neighbors and configuration onone side is enough. It suppresses hellos only on point-to-point links. LSA flooding is also activated and is operational on any type of network type.  Hello suppression is negotiated in hello messages while flooding suppression is negotiated in DBD messages.
• Flood reduction feature is similar to the above, but it's not negotiated. It's activated per interface and it immediately takes effect where it's applied. All LSAs sent on that interface have the DoNotAge(DNA) bit set.
• In case of an existing OSPF virtual link, the "capability transit" OSPF command allows a router to choose a shorter path over a non-backbone area, in order to reach a destination. Normally the router would prefer the route over the virtual link that leads to area 0. This command is enabled by default and you have to disable it if you don't want to transit the non-backbone area.
• When using OSPF virtual links, it's considered a best practice to define specific router-ids on the routers between which the virtual link is configured.
• Virtual links are not supported over stub areas, due to LSA restrictions in such areas
• When using OSPF authentication there are different commands to set the plain text password an the MD5 password. Specifically "ip ospf authentication-key" &  "ip ospf message-digest-key"
• When using OSPF authentication with MD5, Type, Password & Key-ID must match in order for authentication to be successful. 
• In order to enable OSPF authentication over a virtual link, you need to enable authentication for area 0 and configure a matching password using the virtual link command
• After configuring authentication over a virtual link, it's considered best practice to clear the OSPF process in order to verify the correct operation.
• If multiple keys are configured for MD5 authentication, OSPF sends packets multiple times, one for each key. This is how "lossless" key rotation is accomplished. 
• RFC2328 states that OSPF summary routes should inherit the highest metric among the component routes. The old behavior is the one specified in RFC 1583, which is now obsoleted and specifies that the lowest component metric should be used. The default behavior used to be the RFC 1583 but it's supposed to have changed in newer code versions. Either way there is the command "[no] compatible rfc1583" to change this behavior.
• In OSPF only ABR & ASBR routers can perform summarization
• Beware of the "subnets" keyword when performing redistribution in OSPF. If not specified only classful networks are redistributed.
• The router always chooses the longest match of a prefix, independently of the source protocol, distance, metric etc.
• Using duplicate router IDs in different areas is operational as long as no type 5 LSAs are originated from these routers. Type 5 LSAs contain the originator router ID and they are propagated across the OSPF domain, triggering the problem.
• OSPF area types
  Stub area ==> allows type 1, 2, 3, default route as type 3 LSA
  Totally Stub ==> allows type 1, 2, default route as type 3 LSA
  NSSA ==> allows type 1, 2, 3, 7 (optional default route as type 7 LSA)
  Totally NSSA ==> allows type 1, 2, 7, default route as type 3 LSA
• When both "no-summary" and "default-information originate" keywords exist in the "area xxx nssa" command, duplicate default routes are advertised in the NSSA area, with the type 3 LSA being preferred. The cost of the type 3 default route is derived by the cost to reach the ABR who originated the route. The cost of the type 7 default route is configurable with the command "area xxx default-cost" and default value is 1.
• When using NSSA areas you can instruct the router not to translate type 7 LSAs to type 5 LSAs. This is accomplished with the command nssa-only at the redistribution point (redistribute command)
• With existing FA recursion occurs toward the FA, otherwise it occurs toward the advertiser
• In case of multiple NSSA ABRs only the one with the highest Router ID is allowed to preform type 7-to-5 translation
• When an NSSA border router originates both a Type-5 LSA and a Type-7 LSA for the same network, then the P-bit must be clear in the Type-7 LSA so that it isn't translated into a Type-5 LSA by another NSSA border router. This doesn't cause suboptimal routing issues due to the FA being preserved during the translation. Routing occurs toward the FA so it doesn't make any difference who translated the LSA
• Normally during the translation from type 7 LSA to type 5 LSA the Forward Address is set to the ASBR who redistributed the route into the OSPF domain. You can change that behavior either to fix a problem or to filter a specific route using the suppress-fa option in the area xxx command. If the forward address is unknown the receiving router ignores the route, so you achieve some kind of filtering. If you decide to omit the FA from the type 5 LSA, the routers receiving the LSA accept it and forward packets to that destination toward the ABR.
• By filtering the FA from propagating across areas, you block all type 5 LSAs associated with this FA from entering the RIB.
• When OSPF has to choose among two different E2 routes for the same prefix, it always prefers the one with the lowest metric. In case of a tie it uses the cost to the ASBR as a tie breaker, otherwise it installs both routes
• Type 3 LSAs are generated at the ABR by walking the RIB, NOT the LSDB
• Intra-area route filtering only at an ABR
  - "area xxx range [not-advertise]"
  Summarizes ONLY intra-area routes. The rest are propagated normally. Summarization and LSA type 3 generation takes place BEFORE distribute list is applied, so you may not see a route in the RIB, but the respective summary will be propagated.
  - "area xxx filter-list"
  Type 3 LSA generation takes place by looking at the RIB and AFTER distribute list and summarization is applied 
• Inter-area route filtering only at an ABR
  - "area xxx filter-list"
  Type 3 LSA regeneration takes place by looking at the RIB and AFTER distribute list and summarization is applied 
• You can filter LSAs out an interface with "database-filter all out" command. Clearing of OSPF process may be required in certain cases.
• For summarization between OSPF areas at the ABR use "area xxx range"
• For summarization between OSPF and other protocols use at the ASBR use "summary-address"
• A NSSA ABR router is considered to be ASBR because it performs type 7 to type 5 translation, which makes the " summary-address" command perfectly applicable
• Using "max-metric router-lsa" the router advertises all it's non-stub interfaces with maximum metric (that is interfaces where a neighbor is detected).
• OSPF timers - Event detection
  Hello interval & dead timer, configured per interface and must match among neighbors. Using minimal dead interval on an interface, multiplier values can be different among neighbors and form an adjacency without issues
• OSPF timers - Event Propagation
  - Exponential backoff
  LSA initial delay, min interval & max wait, configured per router, not required to match but it's recommended
  - LSA Pacing specifies how LSAs are grouped in the transmit or re-transmit queue. The timers specify the transmission delay on a link or the re-transmission interval if an LSA is not acknowledged. Configured per interface.
• OSPF timers - Event reaction
  - SPF initial delay, min interval, max wait, configured per router and no need to match
  - Min LSA arrival specifies how frequently LSAs can be received. Must be less or equal to the LSA min interval
• You can limit the max LSA number in the LSDB with "max-lsa" command and trigger a warning or drop adjacencies
• You can limit redistributed LSAs with "redistribute-maximum-prefix" command and trigger a warning or take action
• You can instruct a router to display Router IDs as DNS names, by using " ip ospf name-lookup"
• The command "default-information originate" injects an E2 default route into the OSPF domain

RIP notes

• RIP uses multicast address 224.0.0.9 UDP 520
• It supports authentication by using a key chain
• White space is a valid character in the key string. Always verify correct key string using "show key chain"
• You can conditionally advertise a default route over a specific interface using default-information originate. You create a route-map that matches the prefix that requires monitoring and sets the interface over which the default route will be advertised
• It's not required to have a default route in order to advertise it in RIP
• By default RIP performs source validation on updates it receives. The update source must be in the same subnet, otherwise it's ignored. You can use "no validate update-source" to change that behavior.
• An interface with RIP enabled and configured with IP un-numbered doesn't perform source validation .
• RIP doesn't suppress multicasts on an interface, although the neighbor command for static neighborship may be active. You need to make interface passive to stop sending multicasts.

EoMPLS frame

Ethernet frame

EIGRP notes

• In Named mode per-interface commands are configured under af-interface. Beware of existing eigrp commands in interface configuration that can be misleading
• In Named mode wide metrics are used by default
• It's required to configure authentication mode, otherwise it's considered inactive
• Beware of white space in key-strings within key chains. It is considered a valid key-string character. Always use "show key chain" to verify.
• Uses multicast address 224.0.0.10 for the hello messages but you can configure it to use unicast
• Both routers need to be configured as unicast in order to form an "unicast" adjacency .
• Default route advertisement using a summary address should be avoided. By default it creates a summary route with admin distance 5 pointing to null and can lead to blackholes under certain circumstances
• A summary route is advertised with the lowest metric of it's component routes
• Default hello interval 5 sec. On low speed NBMA networks it's 60 sec. Default hold time 4 x hello interval. Both configured per interface.
• Using "eigrp stub" feature the "connected" and "summary" are default keywords included. 
• EIGRP by default uses up to 50% of configured interface bandwidth. If the bandwidth is configured too low, EIGRP starvation may occur. If you have available bandwidth but you  have intentionally configured a low bandwidth for other reasons, you can increase the interface bandwidth or set the percentage to a value >100%
• The command "distance XXX subnet wildcard ACL" changes the distance of the routes matched by the ACL AND and are learned from specific sources matched by the "subnet wildcard" values. It only affects EIGRP internal routes.
• For redistribution from another protocol to EIGRP you need to set the default metric or specify a metric at the redistribute command. No need to specify that for redistribution from static & connected routes and between EIGRP processes.
• Command "show ip eigrp events" very useful for troubleshooting. Displays ignored ppackets and so on.
• You can filter routes using maximum hop count. It defaults to 100 hops.

VTP notes

• In VTP v1 & v2 change mode to transparent to reset revision number
• Vlan state(Active/Suspended) is advertised by VTP. Shutting down a vlan is locally significant to the device the the command was applied
• A transparent switch forwards VTP packets only if they match it's own configured VTP domain
• DTP negotiation between two switches requires VTP domain name to match between switches
• If a switch doesn't receive a VTP pruning response on a port, as a fallback mechanism, it doesn't prune any vlan on that port. As a consequence it requests all vlans from it VTP neighbors, which actually cancels VTP pruning operation. This is true for edge ports too. As a solution either disable VTP on that port(VTPv3) or manually set allowed vlan list. 
• Don't use VTP pruning on a VTP domain that includes transparent switches. Transparent switches only forward VTP packets and don't take part in the negotiation, leading to traffic blackholes
• By default all standard vlans are included in the prune eligible list
• VTP domain name is case sensitive
• In transparent mode vlans are stored in running config
• In client/server mode vlans are stored in vlan database
• In VTPv3 you have to define a primary server in exec mode in order to be able to alter the vlan database
• In VTPv3 you need to disable VTP pruning in order to advertise the extended vlan range
• Useful debug command: debug sw-vlan vtp events