Saturday, April 28, 2012

When a Router adds the EIGRP summary address interface command, it will inject a route for the summary address to interface Null0 into its global routing table with a default administrative distance (AD) of 5. This is known as the discard route, and it's not exclusive to EIGRP. However, this occurs because if the Router were to lose reachability to a more specific route that fell within the summary, the Router would wind up using the shorter summary route to Null0 for forwarding the traffic, thereby preventing packets from being sent to any neighbors that may no longer have the route.

If the Router did not have such a mechanism and instead forwarded the traffic anyway, then there could be a risk of a next hop neighbor having connectivity to some path that actually leads back to the Router - creating a loop!

In this scenario, the Provider sends a default route to R1 via eBGP with an AD of 20. R1's fa0/1 interface is then configured to send an EIGRP summary route. With no AD configured, a route to the EIGRP summary via interface Null0 with an AD of 5 is injected into the global routing table, thereby removing the previously accepted default route to 10.1.1.100 via eBGP with the AD of 20.R2 learns the advertised route via EIGRP, and installs the route in its global routing table with the AD of 90. At this point, any destinations that R1 receives packets for that are not specifically in the global routing table will take the default route to Null0.

In this scenario, the Provider sends a default route to R1 via eBGP with an AD of 20.

Provider Sends Default route to R1:

router bgp 100

neighbor 10.1.1.1 remote-as 200

neighbor 10.1.1.1 default-originate

Resulting routing table for R1:

R1#show ip route | in 0.0.0.0

Gateway of last resort is 10.1.1.100 to network 0.0.0.0

B* 0.0.0.0/0 [20/0] via 10.1.1.100, 00:00:10

R1's fa0/1 interface is then configured to send an EIGRP summary route.

With no AD configured, a route to the EIGRP summary via interface Null0 with an AD of 5 is injected into the global routing table, thereby removing the previously accepted default route to 10.1.1.100 via eBGP with the AD of 20.

Resulting routing table for R1:

R1# show ip route | include 0.0.0.0

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

D* 0.0.0.0/0 is a summary, 00:21:30, Null0

R2 learns the advertised route via EIGRP, and installs the route in its global routing table with the AD of 90.

Resulting routing table for R2:

R2#show ip route | in 0.0.0.0

Gateway of last resort is 10.12.1.1 to network 0.0.0.0

D* 0.0.0.0/0 [90/2681856] via 10.12.1.1, 00:23:21, Fa0/1

At this point, any destination that R1 receives packets for that are not specifically in the global routing table will take the default route to Null0.

Although not always recommended and depending on your needs, you can remove the Null0 route by adding the AD of 255. However, in this case, a high AD of 220 is configured.

R1 Sends EIGRP Summary to R2:

interface fa0/1

ip summary-address eigrp 100 0.0.0.0 0.0.0.0 220

This allows the previously accepted route with the AD of 20 back to the global routing table, but still maintains a floating route to Null0 in the event the default eBGP route is lost.

Sunday, April 15, 2012

In this scenario, I have 4 switches connected in a loop with two links per switch for peering. I want to configure MSTP in such a way that half of the VLANs use SW1 as the root bridge, and the other half of the VLANs use SW2 as the root bridge. If either SW1 or SW2 were to fail, I want the remaining switch of the two to take over as the root bridge for the failed device. Additionally, I want to ensure that SW3 reaches the root for Instance 1 through SW4 by adjusting port cost, and SW4 to use Fa0/17 to reach the root of Instance 2 adjusting port priority.

To set a baseline; VLANs 10, 20, 30, and 40 are configured for the switching domain, and cabling has been done per the diagram.

I'l start with configuring MST instances 1 and 2 on all 4 Switches (SW1 is shown).

Note that with MST, any VLAN that I have not specifically configured for an instance will be found in MST instance 0.

To configure priority for an instance, I can either use the spanning-tree mst 'x' priority command, or the spanning-tree mst 'x' root command. Using the priority command, I can manually set the value, but using the root command, I allow the switch to calculate the value. Depending on the environment, it may be beneficial to set the priority manually. For MST 1, I'll use the priority command, and for MST 2, I'll use the root command.

Note that the output shows SW1 as the root for MST 1, and SW2 as the root for MST 2; with SW1's priority for MST 2 putting it as the successor if there were a root bridge election, and SW2's priority for MST 1 putting it as the successor if there were a root bridge election. I can look at the inferior bridge priorities for SW3 and SW4 to verify that would indeed be the case.

Looking above, I can see that SW3's root port for MST 1 is currently Fa0/13 which is directly connected to SW1. In order for SW3 to use SW4 for its path to the root using port cost, I'll use 'show spanning-tree mst 1 detail' to learn how much I'll need to adjust the cost.

Looking above, I can see that SW4 is currently using Fa0/16 to reach the root bridge for MST 2. I'll adjust where SW4 will use Fa0/17 as the root port to reach MST 2 by changing the port priority on SW2. Note that this adjustment must be done on SW2 and NOT on SW4 to be effective.

Wednesday, April 11, 2012

I want to simulate an environment where two customers - Customer A and Customer B - are supported by a service provider with private VLANs. In this scenario Customer A has two routers; R3 and R5, Customer B has a single router; R4, and the provider is offering Internet access with R1 and monitoring services to the Customers' loopback addresses with R2.

In this scenario, all Router FastEthernet interfaces are in "Primary" VLAN 20 with addressing in the 10.20.1.0/24 space. With private VLANs, the provider can conserve VLANs by not assigning each customer their own VLAN ID. With this configuration I will allow both Customers access to the services they need, but also ensure that they do not gain access to each other.

Here's a baseline before I begin configuring the Private VLANs.

Switches:

Both switches have had their VTP domain names set to cisco, and have had their VTP modes set to transparent. Fa0/13 on both switches will serve as the trunk port. Currently, only VLAN 1 is configured.

Routers:

All routers have had their Fa0/0 interfaces configured with the IP and mask of 10.20.1.X/24, where X = the router number.

Note: there are 3 port types, or roles, that are used in Private VLANs. There are Promiscuous ports, which talk to all ports, there are Isolated ports, which can only talk to Promiscuous ports, and there are Community ports, which can talk to other Community ports in the same community, as well as promiscuous ports.

In this scenario, R1 and R2's Fa0/0s are operating as Promiscuous ports, R3 and R5's Fa0/0s are operating as mutual Community Ports, and R4's Fa0/0 is operating as an Isolated port. After a successful Private VLAN configuration, I should be able to see that R3 and R5 can communicate within their own Community, as well as with the Promiscuous ports, but will not be able to speak to R4's Isolated port.

Starting with SW1, I'll configure primary and secondary VLANs, and associate the secondaries to the primary:Sw1#conf tEnter configuration commands, one per line. End with CNTL/Z.Sw1(config)#vlan 21Sw1(config-vlan)#name PVLAN_CommunitySw1(config-vlan)#private-vlan ? association Configure association between private VLANs community Configure the VLAN as a community private VLAN isolated Configure the VLAN as an isolated private VLAN primary Configure the VLAN as a primary private VLAN twoway-community Configure the VLAN as a two way community private VLANSw1(config-vlan)#private-vlan communitySw1(config-vlan)#Sw1(config-vlan)#vlan 22Sw1(config-vlan)#name PVLAN_IsolatedSw1(config-vlan)#private-vlan isolatedSw1(config-vlan)#Sw1(config-vlan)#vlan 20Sw1(config-vlan)#name PVLAN_PrimarySw1(config-vlan)#private-vlan primarySw1(config-vlan)#private-vlan association 21,22Sw1(config-vlan)#exitSW1(config)#do sh vlan b

Now I'll configure primary and secondary VLANs, and associate the secondaries to the primary for SW2. I'll follow it up with configuring the individual port modes and map the private VLANs to the correct ports for R2 and R4's switchports.