Influencing EIGRP Path Selection

 

Being an enhanced distance vector IGP, there are several ways to influence the route and path selection of EIGRP

Administrative Distance:

Consider the topology below. We would like to prefer the link between R7 and R1 when sending traffic to the 4.4.4.4 network (R4's loopback)

Currently we have 2 equal cost routes to 4.4.4.4 as shown in the ip routing table

Also, in the EIGRP topology table, we see the 2 successor routes of equal cost

Here, we are going to use the distance command to change the AD of the route for 4.4.4.4 on R7, preferring the path towards R1s neighbor interface.

First thing is define the route in an access list 

R7(config)#access-list 1 permit host 4.4.4.4 

Next we jump into router config mode and issue the distance command, with the source interface being R1's neighbor interface (10.1.17.1) and access-list 1 on the end to define the route - 4.4.4.4

R7(config)#router eigrp 7
R7(config-router)#distance 88 10.1.17.1 0.0.0.0 1

Now we can see that the AD is 88, lower then the default of 90, so R7 will prefer this this path on the way to 4.4.4.4 only.

The EIGRP topology table remains the same as above...as we haven't changed the link metrics in any way. We'll explore that next !

Interface Bandwidth and Delay values:

If we take a look at the current values of interface gig 0/0 on R7 (the link that we want to prefer here), we see the following (truncated)

R7#show interfaces gigabitEthernet 0/0

GigabitEthernet0/0 is up, line protocol is up 

  Hardware is iGbE, address is 5254.0014.1def (bia 5254.0014.1def)

  Internet address is 10.1.17.7/24

  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec, 

     reliability 255/255, txload 1/255, rxload 1/255

To favor this link, we can increase the bandwidth or decrease the delay, which will cause EIGRP to recalculate it's route. We can also do the inverse on a link we do NOT want to favor to make the EIGRP metric WORSE - increase the delay and decrease the bandwidth. And in this case, I need to do just that since the delay and bandwidth metrics on these links are already at their optimum value as shown above, and can't be made better.

Here I decrease the bandwidth to 50000 Kbps (or 500 Mbps) and increase the delay to 20 (in 10 of miroseconds) which would be 200 usec.

interface GigabitEthernet0/1

 bandwidth 500000

 delay 20

Now we get this

GigabitEthernet0/1 is up, line protocol is up 

  Hardware is iGbE, address is 5254.000f.ef31 (bia 5254.000f.ef31)

  Internet address is 10.1.27.7/24

  MTU 1500 bytes, BW 500000 Kbit/sec, DLY 200 usec, 

     reliability 255/255, txload 1/255, rxload 1/255

show ip route - Link between R7 and R1 is now preferred.

show ip eigrp topology - metric is worse on Gig0/1 link as show shown in the topology table

Of course this affects all routes egressing from R7 towards R1, R2 and beyond.

EIGRP Offset List:

Another way to influence EIGRP routes is via an offset list. You can only make a metric WORSE with an offset list, not BETTER...so you'll need to set the offset on the link you do NOT want to favor.

Here we add the offset list to the incoming interface on R7 - (R2-R7 Link) 

offset-list <access list defining route you want to alter><in\out><off set list value><interface>

R7(config-router)#offset-list 1 in 2 gigabitEthernet 0/1

You can see below - route table favors the R1-R7 link, and only for the 4.4.4.4 route defined by access-list 1....which is nice.

And the EIGRP topology table shows the incremented metric value on the R2-R7 link - 2 above, just enough to make it fall back to a feasible successor.

If you run a show ip protocol on R7 - it will tell you that an offset list has been applied and state the additional metric.

show ip protocol

Routing Protocol is "eigrp 7"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Incoming routes in GigabitEthernet0/1 will have 2 added to metric if on list 1
Default networks flagged in outgoing updates
Default networks accepted from incoming updates

There you have it...hope this was helpful!

MPLS3 with GETVPN

Hello all…wanted to share my version of a MPLS lab with you....as if there's not enough MPLS material online! Well, here's one more! The base of the lab was configured with the guidance of Keith Barker, who put up an excellent you tube video on MPLS-check it out here!

https://www.youtube.com/watch?v=pia2WceaevQ&list=PLC3E6D83668FB81C7&index=2

I just kind of elaborated on it a bit-added a second customer, a third customer CE, and some GETVPN to get some traffic encryption going. Here’s the config for PE-R2…… at the end of all this, I’ll make my GNS3 lab available for those who want to download it.

version 15.2 service timestamps debug datetime msec service timestamps log datetime msec ! hostname PE-R2 ! boot-start-marker boot-end-marker ! ! vrf definition dtech  rd 120:120  !  address-family ipv4   route-target export 20:20   route-target import 30:30   route-target import 40:40   route-target import 137:137  exit-address-family ! vrf definition isp  rd 137:137  !  address-family ipv4   import map DTECH_SELECT   route-target export 137:137   route-target import 21:21   route-target import 31:31   route-target import 20:20   route-target import 30:30   route-target import 40:40  exit-address-family ! vrf definition pizza  rd 121:121  !  address-family ipv4   route-target export 21:21   route-target import 31:31   route-target import 137:137  exit-address-family ! no aaa new-model no ip domain lookup ip domain name lab.local ip cef no ipv6 cef ! ! multilink bundle-name authenticated ! interface Loopback0  ip address 2.2.2.2 255.255.255.255 ! interface FastEthernet0/0  ip address 10.0.23.2 255.255.255.0  speed auto  duplex auto  mpls ip ! interface FastEthernet0/1  ip address 10.0.24.2 255.255.255.0  speed auto  duplex auto  mpls ip ! interface FastEthernet1/0  vrf forwarding dtech  ip address 172.16.12.2 255.255.255.0  speed auto  duplex auto ! interface FastEthernet1/1  vrf forwarding pizza  ip address 172.16.29.2 255.255.255.0  speed auto  duplex auto ! router ospf 2 vrf pizza  router-id 0.0.29.29  redistribute bgp 27 subnets  network 172.16.29.0 0.0.0.255 area 0  default-information originate ! router ospf 1  network 2.2.2.2 0.0.0.0 area 0  network 10.0.0.0 0.0.255.255 area 0 ! router rip  !  address-family ipv4 vrf dtech   redistribute bgp 27 metric 2   network 172.16.0.0   no auto-summary   version 2  exit-address-family ! router bgp 27  bgp log-neighbor-changes  neighbor 7.7.7.7 remote-as 27  neighbor 7.7.7.7 update-source Loopback0  neighbor 11.11.11.11 remote-as 27  neighbor 11.11.11.11 update-source Loopback0  !  address-family vpnv4   neighbor 7.7.7.7 activate   neighbor 7.7.7.7 send-community extended   neighbor 11.11.11.11 activate   neighbor 11.11.11.11 send-community extended  exit-address-family  !  address-family ipv4 vrf dtech   redistribute rip  exit-address-family  !  address-family ipv4 vrf pizza   redistribute ospf 2  exit-address-family ! ip forward-protocol nd ! ! no ip http server no ip http secure-server ! ! ip prefix-list DTECH_LOOPS seq 5 permit 1.1.1.1/32 ip prefix-list DTECH_LOOPS seq 10 permit 8.8.8.8/32 ip prefix-list DTECH_LOOPS seq 15 permit 12.12.12.12/32 ! route-map DTECH_SELECT deny 10  match ip address prefix-list DTECH_LOOPS ! route-map DTECH_SELECT permit 20

Define your customer VRF and assign a unique Route Distinguisher value in order to keep possible overlapping customer routes unique when traversing MP-BGP. Define which routes in the customer’s VRF you want to share with other VRFs route-targets. Most times you can just assign the same value for import and export, since you would normally want to share all routes among the same customer vrf, but I just wanted to make them unique for each vrf instance. One for each PE. For the ISP vrf, I used a route map import so that only select routes were imported in, and others denied. Using the route-target values is all or nothing. Import and export maps will give you more control. In this case, the ISP vrf is importing all other vrf routes, with the exception of dtech, and are modified via the import map command. See at the bottom of the config… Enable mpls for the interfaces connecting your core routers This would be your customer facing interface- you’ll want to place this interface in the vrf for your customer. This interface will also exchange routes with the CE’s local routing protocol. This customer (pizza) uses OSPF as their IGP at the CE. This OSPF instance is placed in the customer vrf and MP-BGP is redistributed into it- which is carrying the injected routes through the MPLS core from the other customer VRFs\PE interface. Note the use of “default-information originate” here. This is necessary to distribute a default route to the CE via OSPF. The route is originated on PE-R7 in the isp vrf, and distributed via MP-BGP like the rest of the routes. OSPF 1 servers as the core IGP for the MPLS backbone This customer (dtech) uses RIPv2 as their IGP at the CE. This rip instance is placed in the customer vrf and MP-BGP is redistributed into it- which is carrying the injected routes through the MPLS core from the other customer VRFs\PE interfaces Here we are defining the BGP pairings for our PE routers that define the MPLS backbone. I did a full mesh between the 3. Also using the loopback0 as the update source instead of the physical interface for redundancy. It’s here, in the vpnv4 address family, where you are activating the PE BGP neighbors to send vpnv4 customer prefixes which are made globally unique by use of the Route Distinguisher defined earlier. Also, it is the enabling of the extended send-communities in MP-BGP that carry the RD and RT information needed for MPLS vpns to work. Next, we redistribute the CE’s local IGP into BGP within the respective customer vrfs Here’s the prefix used in the above import map. I didn't want the isp vrf to show the dtech loopback networks (lets pretend these were top secret networks). So the loopbacks are defined in the prefix list here, then denied in the DTECH_SELECT route map, effectively preventing them from importation on the to the isp network. Notice the unmatched permit statement at the end of the route map…basically saying “leave everything else as is”

Now, take a look at PE-R7…I’ll go over the differences from PE-R2- it’s all configured the same except for these exceptions.

When your CE’s are using EIGRP as there local routing IGP, you can just create a single EIGRP AS instance on the PE (AS 7 in this case)- then, under your address-family commands, reference the CE’s local EIGRP AS number…. (8, 10, 13 respectively)- then you’ll redistribute BGP into those AS’s so that your customers get the routes.

router eigrp 7

 !

 address-family ipv4 vrf dtech

  redistribute bgp 27 metric 1 1 1 1 1

  network 0.0.0.0

  autonomous-system 8

 exit-address-family

 !

 address-family ipv4 vrf pizza

  redistribute bgp 27 metric 1 1 1 1 1

  network 0.0.0.0

  autonomous-system 10

 exit-address-family

 !

 address-family ipv4 vrf isp

  redistribute bgp 27 metric 1 1 1 1 1

  network 0.0.0.0

  autonomous-system 13

 exit-address-family

Now, there’s a default static route on PE-R7 pointing to the ISP router. I have this route shared among all the vrfs, so that any traffic wo specific routes heads out towards the internet. I distributed this route via the MPLS network to the CEs.

ip route vrf isp 0.0.0.0 0.0.0.0 137.137.137.13

router bgp 27

address-family ipv4 vrf isp

  redistribute static

  default-information originate

 exit-address-family

You’ll want to redistribute static routes into BGP for the isp vrf as shown above- you’ll also need default-information originate so that’s it’s distributed via MP-BGP and shows up in the ipv4 tables for all the vrfs on all the Pes. I’m also peering with the ISP routers local EIGRP as show above on this PE-R7…..other than that, it’s the same as PE-2

The CE routers are just straight peering with their respective IGPs (no redistribution done at the CEs)- advertise the networks you want (I advertised all the CE loopbacks- ie R1 loopback is 1.1.1.1/32) and you should be good to go. You should see the routes for your respective customer offices on the CE (show ip route).

 To check the that you have the correct BGP routes on your PE routers, use show ip bgp all - you'll get a table for each vrf under the VPNv4 address family. (see below) Note the default route in each vrf

Now, you have a functioning MPLS network serving 2 customers! Pretty cool! But….dtech is worried about the security of their traffic between office locations. Pizza doesn’t care- they’re busy making pizzas! So, I’ll implement GETVPN over MPLS to encrypt the interoffice traffic for DTech in the next section. And I'll upload the lab files as well.......  until then....thanks for reading.

Update: 3-2015.............................................................................................................................

Actually....I went through the GETVPN config on another lab.....combining it with DMVPN....so if interested, you can head there and take a look.    http://techjuice.blogspot.com/2015/03/dmvpn-w-getvpn-for-encryption.html

Update: 1-2024...............................................................................................................................

Added new Cisco Modeling Labs version of the lab (Less the GET-VPN part)  Download Lab

Adjusting OSPF path selection

 

If you want to adjust the the path of an ospf router, beyond the route type (which is it's first and foremost criteria), there are a couple ways you can do it.

Link Cost:

Fist way is adjusting the cost of the link from the perspective of the ospf router. Lower cost is preferred, and if there are a couple links with equal cost, then they will be load balanced automatically.

First thing you may want to do is set your reference bandwidth across all ospf routers. A setting of 10,000 (expressed in Mbps - 10,000 Mbps is 10 Gbps) will be equivalent to 10 Gig, so  a 10 Gig interface will have a cost of 1, a 1 Gig interface a cost of 10, 100Mbps a cost of 100, and so on.

router ospf 1
auto-cost reference-bandwidth 10000

Consider the topology below...currently the route from R7 to the 4.4.4.4 network has the option of 2 paths -  both of equal cost - so they will be load balanced by ospf.

But if we want to only use say the link between R7 and and R1, we can do that by changing the link cost.

Current cost is 10 - and the route table for R7 is shown below- 2 equal cost routes to 4.4.4.4. Note that the loopback interface has a cost of 1, as it's a connected interface.....hence the 3 x 10 links + 1 gives you the 31.

Using the ip ospf cost # command under the respective interface will will change it the cost

R7(config)#interface gigabitEthernet 0/0
R7(config-if)#ip ospf cost 9

Now, we get this - a cost of 9

with a single "better" route (cost of 30 vs 31) to 4.4.4.4

This works fine...BUT...it will effect ALL routes advertised, and destined, across that link. May not be what we need. 

Administrative Distance (AD):

You can use the distance command to change the Administrative Distance of a specific route (AD)

First define the route you want to change the AD for in an access-list... in this case, it's 4.4.4.4/32 

R7(config)#access-list 1 permit host 4.4.4.4

Next determine the advertising router - the router that the route is learned from, in this case it's R3 - we need to use the routers ospf router id - which is 3.3.3.3 as shown below

Apply the distance command

distance <AD value> <advertising router id\wild card mask> <route defined in access list>

R7(config)#router ospf 1
R7(config-router)#distance 99 3.3.3.3 0.0.0.0 1 

This works, BUT, it does nothing to favor one link over another - you still have equal cost over the 2 links to the route

Due to OSPF's link-state nature, it's more preferable to use policy based routing (PBR), and direct the traffic type you want over a certain link.

PBR:

In the topology below, we will set the next hop to for ICMP traffic originating at R8, to use the link between the R1 and R7.

We will first create an access list to identify the route (destination in this case)

ip access-list extended ICMP

 permit icmp any host 4.4.4.4

Next we create a route-map to match the traffic type (icmp) and set the next hop

route-map PBR-ICMP permit 5

 match ip address ICMP

 set ip next-hop 10.1.17.1

Now tie it in and activate the PBR on the incoming incoming interface on R7 from R8

interface GigabitEthernet0/2

 ip policy route-map PBR-ICMP

Execute a ping on R8 to 4.4.4.4

You can observe the route-map matches incrementing here

Also, if you enable some debugging on R7 - then execute a ping on R8, you can validate the PBR is taking action on the traffic destine for 4.4.4.4

R7#debug ip policy

Hope this has been a useful reference on influencing OSPF routes

Here's a quick table of the OSPF route and LSA types:

Intra-Area (O)

Inter-Area (O IA)

External Type 1 (E1)

NSSA Type 1 (N1)

External Type 2 (E2)

NSSA Type 2 (N2)

LSA Type 1:            Router LSA

LSA Type 2:            Network LSA

LSA Type 3:            Summary LSA

LSA Type 4:            Summary ASBR LSA

LSA Type 5:            Autonomous system external LSA

LSA Type 6:            Multicast OSPF LSA

LSA Type 7:            Not-so-stubby area LSA

LSA Type 8:            External attribute LSA for BGP

 

Windows 10 Holds on to an IP address for dear life!

Came across an interesting, and horribly annoying, behavior with Windows 10..and probably any recent version of Windows. Windows will ALWAYS try to reuse the last successful dhcp lease it receives, even across reboots! So you may ask, why should I care about this? Well, if you are in say a school campus environment, with domain-ed clients, that are shared by students and faculty, which in turn are placed on different vlans...this behavior will indeed create havoc! The ip leased by say a student, will "stick" in the registry, and as long as the dhcp lease is still valid, it will be reused. Now a faculty member logs on, they end up associated to an AP and get assigned the faculty vlan at layer 2...but are stuck with an IP from the student vlan that's invalid for the that subnet.

The interface ip lease information is stored here (see example reg values below)



HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{Interface GUID}

"DhcpIPAddress"="10.2.21.28"

"DhcpSubnetMask"="255.255.252.0"

"DhcpDomain"="mydomain.local"

"DhcpNameServer"="10.1.2.19 10.1.2.17"

"DhcpDefaultGateway"=hex(7):31,00,30,00,2e,00,32,00,2e,00,32,00,30,00,2e,00,31,\
00,00,00,00,00

"DhcpSubnetMaskOpt"=hex(7):32,00,35,00,35,00,2e,00,32,00,35,00,35,00,2e,00,32,\
00,35,00,32,00,2e,00,30,00,00,00,00,00

This key is changed to the broadcast address from 10.1.2.19

"DhcpServer"="255.255.255.255"

And like I mentioned...this is stored across reboots.

The various ways to "reset" or clear these reg key values are as follows:
 
ipconfig /release from an active connection under the current session then log off or shutdown- ready for the next user

Log in as an administrative user and restart\stop the DHCP service- then log off or shutdown.

Neither option is particularly easy to trigger and schedule via a scheduled task....so what I ended up doing was multi-layered approach. I needed the above reg values to be cleared whether the machine was connected to the network or not...so this meant dropping the scripts locally. I used group policy preferences in a GPO to do that. 2 files, one the PS script to clear the reg...which is also searches for the correct interface GUID based on the name of the network connection...in our case "WiFi"

cd\cls$ErrorActionPreference='silentlycontinue'$NIC=Get-WmiObject -class Win32_NetworkAdapter -Filter "NetConnectionID='Wi-Fi'" | select -Property GUID -ExpandProperty GUID #needed to just get string wo headerRemove-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\$NIC -Name DhcpIPAddressRemove-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\$NIC -Name DhcpSubnetMaskRemove-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\$NIC -Name DhcpDomainRemove-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\$NIC -Name DhcpNameServerRemove-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\$NIC -Name DhcpDefaultGatewayRemove-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\$NIC -Name DhcpSubnetMaskOptSet-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\$NIC" -Name DhcpServer -Value 255.255.255.255exit

The other, a one liner cmd script to trigger the ps script:


C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noprofile -executionpolicy bypass -file C:\users\IPReleaseV3.ps1


The latter script, I used the same computer based GPO configured with a shutdown script referencing the local cmd script....so once the domained machine has the GPO associated and applied, the script will trigger on shutdown or restart whether on the network or not.....which is what we want.

C:\users\IPRelease.cmd

I seemingly had it licked now...but found out that thanks to Windows Hiberboot or Fast Startup they call it, a shutdown script will NOT be processed on shutdown ! It will just be skipped. On restart it does seem to execute though.

Anyway...I went ahead and pushed the following reg setting to disable Hiberboot..again, using GP preferences:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\

HiberbootEnabled=0

So there you have it...a bit of a clunky solution but an absolute life saver in our situation. 

Hope somebody finds this helpful ! 

Unable to advertise static routes via MP BGP to PE routers

Wanted to quickly post this MP BGP MPLS config I had trouble with here. Below is the Cisco support thread that covers it.

I wanted to do a straight bgp only L3 service across my ISP PEs....using different AS for each customer site. No other core IGP is used- just BGP and static routes to form the neighborships between PE-R8 and PE-R9. In order to get full end to end connectivity for the site networks, I had to advertise the transit networks between the PE routers and the P router. (the .140 and .144) The key to get them advertised out to the CEs was first get define the static routes on the PE in the global routing table. Then redistribute those into the ipv4 BGP table. THEN...import those routes into the customer vrf using the import command that references a route-map, that references an ip prefix-list to scope the routes. After all that- they finally appeared in the vpnv4 address family on the PE routers, and in BGP on the vrf attached CEs
This was the only way I could get them to work - maybe there's an easier way !


Unable to advertise static routes via MP BGP to PE routers


PE-R8#show ip bgp
  Network          Next Hop            Metric LocPrf Weight Path
 r>i 8.8.8.8/32       152.177.58.146           0    100      0 ?
 *>  9.9.9.9/32       152.177.58.141           0         32768 ?
 r>i 152.177.58.140/30
                             152.177.58.146           0    100      0 ?
 *>  152.177.58.144/30
                             152.177.58.141           0         32768 ?
show ip bgp all
For address family: VPNv4 Unicast
Route Distinguisher: 120:120 (default for vrf TGI)
Import Map: IMPORT_STATIC_MAP, Address-Family: IPv4 Unicast, Pfx Count/Limit: 1/1000
 *>  10.7.1.0/24          152.177.58.138    0             0 65002 i
 *>i 10.24.20.0/22      9.9.9.9                  0    100      0 65001 i
 *>i 51.64.56.252/30  9.9.9.9                  0    100      0 65001 i
 *>i 130.148.200.126/32
                                  9.9.9.9                  0    100      0 65001 i
 *>i 152.177.58.132/30
                                 9.9.9.9                  0    100      0 65001 i
 r>  152.177.58.136/30
                                152.177.58.138           0             0 65002 i
 *>  152.177.58.144/30
                       152.177.58.141           0         32768 ?


So..to sum up...here's the config that worked: (for PE-R8....R9 config'd similarly)

ip vrf TGI
rd 120:120
import ipv4 unicast map IMPORT_STATIC_MAP
route-target export 20:20
route-target import 20:20

router bgp 65000
bgp router-id 8.8.8.8
bgp log-neighbor-changes
neighbor 9.9.9.9 remote-as 65000
neighbor 9.9.9.9 update-source Loopback8
!
address-family ipv4
redistribute static
neighbor 9.9.9.9 activate
exit-address-family
!
address-family vpnv4
neighbor 9.9.9.9 activate
neighbor 9.9.9.9 send-community both
exit-address-family
!
address-family ipv4 vrf TGI
neighbor 152.177.58.138 remote-as 65002
neighbor 152.177.58.138 activate
exit-address-family

ip route 9.9.9.9 255.255.255.255 152.177.58.141
ip route 152.177.58.144 255.255.255.252 152.177.58.141
!
!
ip prefix-list IMPORT_STATIC seq 5 permit 152.177.58.144/30
!
route-map IMPORT_STATIC_MAP permit 10
match ip address prefix-list IMPORT_STATIC

Windows VLAN Stripping - Intel(R) PRO/1000 PT Quad Port NIC w GNS3

It's been widely know that Windows OS's by default, will strip VLAN tags as they enter the stack. It's driver dependent really....and some nic driver are designed to cope with it, and some not. Luckily, my Intel(R) PRO/1000 PT Quad Port LP Server Adapter (aka "HP NC364T PCI EXPRESS QUAD-PORT GIGABIT SERVER ADAPTER") is able to deal with this annoyance with a couple of simple settings.

First, you want to set you Priority and VLAN settings to enabled for both..

Second is a registry key and setting. In the case of the Intel Quad, there'll be 4 of these...one for each physical interface:

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0006]

"MonitorModeEnabled"=dword:00000001


You want to create the DWORD value "MonitorModeEnabled" under the above key and set it to 1. Note that the numbered end of the key name "00nn" will be different on your system- one of mine is 0006.

That's it.... give your machine a reboot and you'll be passing VLAN tags through your Windows systems to your virtual machines or for example, GNS3 labs. This is huge to able able to attach your virtual GNS3 routers to say, your real physical switch stack and trunk VLAN tags as normal for labbing etc.....


As an example, I labbed a little MPLS network recently, and took a capture to make sure my physical laptop, plugged in to a real switch port in VLAN 40, was not having the tags stripped after the above changes.

I sent a ping from the laptop, through the switch port, out the trunk connected to my Quad 2 nic, into my GNS3 network....to the CE-5 loopback at 5.5.5.5...... proof that VLAN tags are now in tact!

Here's a capture of the ping below. And incidentally, you'll want to set your destination Cisco SPAN port with dot1q encapsulation, like this....or it will get stripped there as well. Hope this helps somebody....

monitor session 1 source interface Fa0/48

monitor session 1 destination interface Fa0/47 encapsulation dot1q

Basic Campus Network with Cisco Packet Tracer

 

    As if there's not enough network diagrams and designs out there...here's one more! I wanted to just share out a basic campus network design using good old CPT. For all it's limitations and flakiness, it's still damm cool to have an entire functioning network, albeit somewhat dated, stuffed into a single pkt file! A good review and reference of some basic design principles using HSRP, splitting Vlan traffic among the distribution switches, gateway redundancy, split DHCP scopes... things like that. Even has a telephony router and some ip phones...not too shabby! I'll make the pkt file available too for anybody who wants to download the topology.

Download PKT File