Wireless Training

Colliers Wireless Training
COLLIERS WIRELESS TRAINING

Overview and Troubleshooting
Abstract
A Tier II Guide to the Architecture of the Colliers Corporate and Guest Networks with basic
Troubleshooting Scenarios..
Jacobsen, Erik
Erik.jaocbsen@colliers.com
AUTHOR | JACOBSEN, ERIK VERSION | 1.0

Contents
Introduction .............................................................................................................................................. 2
Colliers Approved SSIDs ............................................................................................................................ 2
Colliers-Corp.......................................................................................................................................... 3
Network Configuration to Support Wireless ............................................................................................ 4
Common Configuration......................................................................................................................... 4
Offices with MPLS and Local Internet ................................................................................................... 8
Offices with MPLS Only ......................................................................................................................... 8
Offices with Local Internet Only.......................................................................................................... 10
REMS Offices ....................................................................................................................................... 12
Troubleshooting ...................................................................................................................................... 12
General Troubleshooting .................................................................................................................... 12
Troubleshooting COLLIERS-CORP ........................................................................................................ 13
Troubleshooting COLLIERS-GUEST ...................................................................................................... 14
Troubleshooting Exercise ........................................................................................................................ 15
PAGE | 1 VERSION | 1.0

INTRODUCTION
The Colliers corporate wireless system is a global solution that incorporates TWO networks: Colliers-
Corp and Colliers-Guest. Colliers-Corp is intended primarily for Colliers owned or domain joined
devices, although exceptions will be considered on a case-by case basis, and should be limited to
Colliers Employees/Contractors only. Colliers-Guest is for visitors as well as mobile or non-standard
devices. Occasionally, specialized wireless networks will also be implemented although these only when
the sites architecture requires it. These can be Colliers-Voice, to support the Cisco 7925 WiFi SCCP
Phones, or Colliers-AV, for Canadian AV equipment, or less common specialized SSIDs. It is important to
note that each SSID has a different set of requirements and is configured in different ways.
The platform for the Colliers corporate wireless is Cisco Meraki, chosen primarily for its performance and
for its decentralized, cloud-managed architecture. No other WiFi technology is permitted in integrated
offices in North America. Cisco Meraki has a variety of models, however, Colliers has intentionally limited
deployment to four models, two current and two legacy. These models are sold to local as an internal part
number (bundle) and local offices in North America are not permitted to source the equipment
themselves. See below table for 2015 pricing, model numbers, etc for ALL permitted models of Cisco
Meraki WiFi equipment. All pricing is in USD.
Internal Part Number Model Year 1 Price Year 2+ Price
WAP-ENT-02-MR12 MR12 Discontinued $85/year
WAP-ENT-02-MR16 MR16 Replaced by MR18 $85/year
WAP-ENT-02-MR18 MR18 $550 $85/year
WAP-ENT-03-MR34 MR34 $850 $85/year
COLLIERS APPROVED SSIDS

To maintain a single standard configuration for all Corporate Wireless and to speed deployment, any new
deployment of the corporate wireless system must only be made using the standard template. Any offices
not on the standard template may find their WiFi inoperable following corporate-wide WiFi updates. For
monitoring and management purposes, each office is to be placed in its own network. New networks in
the Meraki Dashboard should only be created with the prior written approval of Erik Jacobsen, Ken
McNena, Dave Davies, or Wayne Bayley. The default template for the new network can be found in the
Networks list on the Meraki Dashboard.

To create a new network using the template, in the same drop-down chose Create a new network.
On the new screen, name the network, following standards, make sure the Network Type is Wireless,
and for Configuration, chose Clone from network Default Setup. DO NOT add any inventory at this
time.
Using this template will create a network with the following SSIDs preconfigured: Colliers-Corp, Colliers-
Guest, Colliers-Voice (disabled).
COLLIERS-CORP
The Colliers-Corp wireless network is a RADIUS authenticated network that is functionally identical to
plugging a computer into the LAN in an office. The routing for traffic from wireless devices on Colliers-
Corp is identical to the routing for wired devices in the same office. Further, Colliers-Corp is universal,
meaning that once a computer has been joined to it in one office, it will function in all offices with no
additional configurations necessary.

NETWORK CONFIGURATION TO SUPPORT WIRELESS

While Colliers has many unique styles of office network, there are four general types:
1. Offices with MPLS and Internet connections
2. Offices with MPLS only
3. Offices with Internet only
4. Integrated REMS offices
While these offices require slightly different configurations to support the different data paths, there is only
one standard for the core of the network.
COMMON CONFIGURATION
For all non-REMS offices with the corporate wireless solution, the following is the standard:
1. Two additional VLANs are defined on the core switch: WIFI and GUEST.
a. WIFI is a routable vlan and should have an ID and subnet in line with Colliers standards
(XX for DATA, 1XX for VOICE, 3XX for WIFI). For example: If the office has VLAN 42 for
their DATA vlan and it has a subnet of 10.168.42.0/24, then the WIFI vlan ID should be
342 and the subnet would be 10.166.42.0/24 in the US or 10.165.42.0/24 in Canada. The
core switch will always have an ip of 10.166/5.XX.1/24 and will be the gateway for the
WIFI subnet. The subnet will be redistributed to the Colliers MPLS identically to the DATA
subnet.
b. GUEST is a VRF isolated vlan and will always have an ID of 666. The subnet will be
assigned by Erik Jacobsen and will always be in the 10.1.0.0/16 range of IPs. The size of
the subnet is typically a /24, however, certain large offices may be allocated a /23 or a
/22. The vlan will be defined and VRF isolated as an L2 vlan on the core switch, however,
the core switch will NOT have an IP on the core switch or any switching hardware.
GUEST will not be redistributed into the MPLS. With the exception of Detroit, GUEST
should never be able to see internal networks.
2. The Access Points are PoE so they must always be connected to a PoE capable MANAGED
switch. With certain extraordinary exceptions, which must be allowed in writing from Erik
Jacobsen, Ken McNena or Wayne Bayley, Merakis are ONLY connected to Colliers-managed
Cisco networking gear. The following guidelines must be adhered to:
a. If the core switch is PoE capable, the Access Points should be connected directly to the
core. Preferably, highest available non-uplink standard port.
b. If the core switch is not PoE capable but there are gigabit-capable access switches, the
Access Points will be connected to the highest-numbered non-uplink standard ports (e.g.
47 & 48 on a 48-port Access Switch, 23 & 24 on a 24-port model). The Access Points will
be distributed evenly across all gigabit-capable PoE Access Switches.
c. If the core switch is not PoE-capable and there are no gigabit-capable Access Switches,
the Access Points will be distributed evenly across all switches. The highest non-uplink
standard port will be used.

3. Merakis support LLDP. LLDP is also part of the Colliers standard for integrated offices. When
deploying a Corporate wireless solution, verify that LLDP is running on all Access Switches, the
Core Switch(es) and the CE Router.
4. The ports the Access Points are connected to must be configured as trunk ports, only the WIFI
and GUEST vlans should be allowed unless Colliers-Voice will be enabled, then only WIFI,
GUEST and VOICE vlans will be allowed. The Access Points are not switches so enable
spanning-tree and add the appropriate QoS taggingif Colliers-Voice is enabled. Finally, the port
description must be updated to indicate it is a wireless port. It is Colliers standard practice to
always indicate the use of the switchport via description. Note: the native vlan should always be
the WIFI vlan. An example configuration can be found below where the DATA vlan is 25, the WIFI
vlan is 325 and the GUEST vlan is 666 and is VRF isolated:
5. DHCP for the WIFI vlan should always live on the local office DHCP server. This allows for AD-
integrated DNS, similar to the DATA subnets. In locations without a local DHCP server, the core
switch may fill that role for WIFI. In either case, the IP exclusions are the same as the standard
VOICE exclusions.
6. Routing information is shared between the core switch and the router using a standard interior
routing protocol, NOT by setting a default route on the router and a static route on the L3. The
routing information shared includes the wireless subnets, but NOT guest. The standard for LAN
routing is OSPF. Legacy sites run EIGRP. To prevent the guest subnet from being redistributed
redistribute connected should NEVER be used on the router. redistribute-connected should,
however, be used on the L3 switch. Static routes should only be set on the L3 switch and should
be redistributed to the router via redistribute-static. Static routes should not be set on the router.
Below is the Ontario CE Routers interior routing (Note the loopback being explicitly defined.)
And the Ontario L3 Switch:

7. Only the 10.166.xx.0/xx and 10.165.xx.0/xx subnets are allowed to authenticate to the RADIUS
server (Corp-ca-nps01), thus only those subnets should be used for WIFI. While an exception
may be necessary, written prior approval from Erik Jacobsen, Ken McNena, Wayne Bayley or
Dave Davies must be secured.
The NPS server is configured as below (note there are some non-standard subnets any non-
standard subnet MUST be approved in writing by Erik Jacobsen, Ken McNena, Wayne Bayley or
Dave Davies PRIOR to adding to the NPS server. Subnets should NEVER be removed from the
NPS server without written approval from Erik Jacobsen or Ken McNena.):
8. For offices with MPLS, local routes are redistributed to the wan via BGP. Local subnets are
redistributed using the redistribute ospf or redistribute eigrp command in the BGP
configuration on the CE router. To prevent unwanted subnets from being redistributed, a route-
map is used to only explicitly allow the data/voice/wireless subnets. This route-map, named either
OSPF-TO-BGP or EIGRP-TO-BGP should be edited to include the wireless subnet(s). The
Ontario routers BGP configuration is below (note that the loopback and L3 subnets are explicitly
defined so redistribute-connected isnt needed.):
The Ontario EIGRP-TO-BGP route-map is below:

9. The GUEST DHCP scope always is located on the CE router, the CE router always has a
subinterface of .666 on its link to the core switch (which is always GE 0/0), that subinterface is
always dot1Q tagged with vlan 666 and that subinterface always has an IP of 10.1.X.1. The guest
DNS servers should be public servers only. Below is the Ontario Guest DHCP scope:
Below is the Ontario router LAN interface and subinterfaces:

OFFICES WITH MPLS AND LOCAL INTERNET

For offices with both MPLS and local internet, Guest traffic will be directed out the local internet
connection. This is accomplished by assigning LAN4 on the Checkpoint to 10.1.X.4, where X is the
subnet assigned for guest. LAN4 is then connected to an access switchport on the core switch that is
assigned to vlan 666 (no voice vlan). As vlan 666 is VRF isolated, no traffic will be seen by the internal
subnets. The DHCP scope is adjusted to set the default-router attribute to 10.1.X.4.
OFFICES WITH MPLS ONLY

For offices with MPLS only, GUEST traffic is sent to the CE router, which then forwards it across a GRE
tunnel to its assigned HUB site and then is merged with the VRF isolated guest traffic from the HUB site
and out through the HUB sites CheckPoint Firewall. Guest traffic is restricted to the GRE tunnel with a
route-map, the GRE Tunnel number is always the ASN, and the VRF ID on the core switch is also always
the ASN. At the HUB site, the GUEST traffic is also restricted via both VRF and Route-Maps. Erik
Jacobsen manages the Tunnel subnets as well as the GUEST subnets. Requests for a Tunnel subnet
should be made at least 5 business days in advance. ASNs for new sites are provided by Wayne Bayley.
HUBs are typically assigned by region or billing association. For example, Carlsbad connects to San
Diego. For offices without a clear HUB for the guest traffic, the default egress point is Seattle. Wayne
Bayley, Ken McNena or Erik Jacobsen should always be queried in writing for which HUB site to use.
To configure the Tunnel, the endpoints should be the Loopback IPs of the local office CE router and the
HUB CE router. The description on the local office CE router should explicitly state which HUB site the
tunnel is connecting to. Because the GRE encapsulation creates additional overhead above the standard
TCP headers, the MTU must be decreased to 1436. To ensure the guest traffic entering the guest
subinterface on the local is only directed to the tunnel, a route-map is created on the local CE router that
sets the next-hop to the HUB end of the GRE tunnel. That route-map is applied to the guest subinterface.
Ontario, California is a good example. It has a GUEST subnet of 10.1.83.0/24 and an ASN of 65256. The
HUB site for Ontario is Downtown LA (DTLA). The Ontario side of the tunnel is configured as follows:
The Guest subinterface on the local CE router is configured as follows (note the route-map):
And the route-map on the local CE router is configured as follows (note the next-hop is the DTLA end of
the GRE Tunnel):
On the HUB router, we apply a route-map to the Tunnel interface. The DTLA Tunnel interface is below:

The route-map at the hub sets the next-hop for incoming guest traffic to be the guest interface (LAN4) on
the Checkpoint. Remember to request from the firewall team that the local site guest subnet be allowed
through the Checkpoint. The route-map in DTLA is as follows (note the Checkpoint is non-standard and
uses 10.1.X.2 instead of 10.1.X.4):
And the access list it references is below (note all the guest subnets that HUB through DTLA are defined):
To allow for reverse traffic from the HUB CE to the Local CE, put a next-hop on the Checkpoint
referencing the guest subinterface on the HUB CE router and then put a static route on the HUB CE
Router.
The DTLA static route for Ontario is as follows:
Finally, note that on the HUB router we make sure to update the GUEST-WLAN route-map to include the
local CE router. See below for DTLAs route-map and associated prefix-list:
Below is the over-all architectural diagram for the GRE tunnels in the Greater LA region (Ontario, DTLA,
etc). This diagram can also be found on the Infrastructure Sharepoint:

OFFICES WITH LOCAL INTERNET ONLY

Integrated offices with local internet only connect through one of two technologies: ANIRA or CheckPoint.
In either case, there will be no ASN to use as a VRF ID.
If there is a CheckPoint, GUEST internet access will be configured identically to that of an office with both
MPLS and Local Internet, except the VRF ID will be 100:666 instead of ASN:666.
If there is an ANIRA, GUEST internet access will be tunneled to the appropriate HUB site as in an office
with MPLS only. The only difference is that the Tunnel Number will be the lowest available on the HUB
CE router that is greater than or equal to 100. For example, if the HUB site already has Tunnels
numbering 100 and 101, the next Tunnel number for a non-MPLS office would be 102. The VRF ID will be
set to the Tunnel number. In the current example, that would be 102:666.
For internal (non-Guest wireless), if the office is on a Checkpoints at both the local site and the HUB site
(or IDC) then the Checkpoint tunnel must be configured to also allow the wireless (10.166/165.X.0)
subnet to pass bi-directionally and the appropriate L3 next-hops should be configured. On an ANIRA, a
MACD must be placed with AT&T to add the wireless subnet and to set the next-hop locally to the L3 IP
on the local Core Switch.

The configuration for an ANIRA non-MPLS site can be seen in the diagram for City of Industry (ANIRA,
Local Internet Only):
And the configuration of the ANIRA can be verified by viewing the Route Table:

The route-table can be accessed by selecting Advanced Information on the local ANIRA, as seen below:
REMS OFFICES
For REMS offices, the Access Point is connected to a standard DATA access port (not trunk). GUEST is
not currently supported in REMS offices and should be disabled. No configuration is necessary at the
network level.
With the exception of West Hollywood, all REMS offices are 10.151.xx.yy/25 and the entire 10.151.0.0/16
has already been configured on the RADIUS server and in other locations.
TROUBLESHOOTING
GENERAL TROUBLESHOOTING
The Meraki APs can be viewed as a first alert type of system as they phone home to the cloud and
alerting is handled by the cloud. This, if the connection back to the cloud is degraded or down, the cloud
is still capable of sending alerts to the wireless team. These alerts should not be viewed as the Meraki is
down but rather as an alert that SOMETHING is happening and should be used as a prompt to do a full
site-check. It is not appropriate to simply send an email to the local contact requesting power verification.
Also, please remember that alerts are only very rarely an issue with the Meraki itself, so the assumption
should never be made that the Meraki failed. Rather, the site should be fully troubleshot and only if
troubleshooting indicates the Meraki failed should an RMA be raised with Cisco. Instead, a AP has lost
contact with the cloud type alert should be handled as follows:
1. Verify ability to connect to the local CE router. If the CE router is inaccessible and the site does
not have a local internet connection, this is a full site down issue and should be troubleshot as
such. If the CE router is inaccessible and this site has local internet, verify the Checkpoint/ANIRA
is reachable. If they are unreachable, it is likely a power issue at the local site and first
troubleshooting steps should focus (but not exclusively be limited to) power.
2. If the CE router is accessible and the site has no local internet egress, a good place to start is
testing from DATA to verify connectivity. Focus on the NWBF and routing. It may be that the
wireless was removed from the route-map filtering the EIGRP/OSPF redistribution.
3. If there is local egress and the CE router is accessible, focus on the Checkpoint/ANIRA.
4. If the local egress and the CE router are functioning normally and DATA is functioning normally,
verify the connectivity, vlans, etc of the APs to the switches.

Note that the above are some GENERAL suggestions and investigations should not simply be limited to
the above. Further, only two Merakis out of over 200 deployed have had issues with the unit themselves
(one was DoA, only one has ever failed while in production). While all Colliers-owned Meraki equipment
has enterprise support, rigorous troubleshooting should take place before determining that the unit has
failed. That said, if the unit has failed, a case should be opened with Cisco Meraki support and a
replacement unit should be requested for Next Business Day delivery.
TROUBLESHOOTING COLLIERS-CORP
Since Colliers-Corp is treated exactly the same as plugging in to the wall, if DATA is functioning properly
but Colliers-Corp is not functioning, some good places to start the troubleshooting are as follows:
It the AP is visible to the cloud but users are unable to connect to Colliers-Corp, a good place to start
is the Meraki Dashboard. For example in the case of the below, we can see in Surry both the
switchport the Meraki is connected to and the IP the Meraki has:
In the case of Surry, it is a non-standard site so the 10.168 address is acceptable, but if this were a
standard site, we could see that the AP is a 10.168.X.Y. That would tell us the vlans are
misconfigured on the switchport it is connected to. Given the switchport being 0/27 instead of the
highest available on-uplink port, a good first place to start would be seeing if the AP was moved to a
different port accidentally by local. The switchport config should be similar to:

Verify that the RADIUS server is up and functioning and that the EMEA and NA RADIUS server
configs are in-sync.
If the location connects to Colliers via an ANIRA, you could have a situation where internet and data
works for the LAN users but Wifi does not. A good first step is to check the ANIRA to ensure that it's
properly referencing the Core Switch L3 address as the next hop and the netmask on the subnetting
is correct. Sometimes AT&T has been known to apply to broad a netmask (eg /16) which would be
invalid so the route would not work. Also, it may be useful to check the ANIRA main screen for uptime
and to verify there are no alerts. The below is an example of the City of Industry ANIRA main screen:
It is also worth verifying that the user reporting the issue is not locked out of his or her AD account,
that the issue is impacting more than one user and that the endpoint device is functioning normally
and has wireless enabled and correctly configured. The Service Desk should do all these steps prior
to assigning the incident to the Wireless team, however, it is never safe to assume the Service Desk
has done any troubleshooting.
TROUBLESHOOTING COLLIERS-GUEST
Because COLLIERS-GUEST can take one of two general paths to the internet, any troubleshooting
activity must first determine the guest egress point. Does guest exit via a GRE Tunnel to a HUB site, or
does it exit locally using a Checkpoint or other device? In either case, the following should be checked:
DHCP: Is the DHCP Server accessible and how many available IP addresses does it have? Is a test
device able to acquire an IP address? Is the default-router correctly set to the guest interface on the
Checkpoint or other internet egress device? Id devices are not getting DHCP, verify that the rotuer
subinterface is up and that guest is allowed on the L3 trunk port to the CE router.

Switchports: Is the guest port on the Checkpoint or other egress device correctly connected to an
access switchport set to vlan 666? Does the interface show up/up? Is 666 one of the allowed vlans on
the WIRELESS trunk ports? If the APs are connected to Access Switches instead of to the core, is
666 allowed on the LACP trunk between the Access Switch and the core? Are the trunks using dot1Q
encapsulation?
VLANs: Is 666 correctly defined on the core? Is it correctly defined on the Access Switch? Could
there be a VTP issue? Could it not be defined on the switch the devices are connected to?
VRF: Is VRF configured correctly? Is it applied to vlan 666 correctly?
Meraki: Is guest correctly defined in the local network on the Meraki Dashboard? Is COLLIERS-
GUEST being correctly tagged?
If guest exits through a local internet connection, then it is also important to check the egress point. e.g. Is
the local internet connection up? Is the Checkpoint or other access device up and functioning properly?
This may require involving the Firewall team in the discovery. Was a Checkpoint policy update pushed
down before COLLIERS-GUEST stopped functioning as expected?
If guest tunnels back to a hub site, then there are a few additional common areas to check:
Verify routing on the CE routers. Is the route-map correctly pointing to the remote IP of the GRE
Tunnel? Is the guest subnet or the GRE tunnel IP being redistributed into BGP at either CE router,
causing asymmetric routing? Is redistribute-connected present in either CE routers BGP config?
Verify GRE Tunnel Status. Is the tunnel up/up? Can the remote end be pinged?
Verify the Loopbacks from both CE routers are being broadcast into the MPLS. Can the Local and
HUB Loopbacks be reached from eachother? Can they be reached from a third MPLS location (IDC,
Seattle, NYC, etc)?
On the HUB side, is the Local guest subnet entered in the GUEST-ONLY access list and the GUEST-
WLAN prefix-list? Is the local subnet correctly set in the HUB Checkpoint and with the correct next-
hop?
Has the AP been moved to a different switchport? Vlan 666 is only programmed on the WIRELESS
switchports, the CE router uplink and, if applicable, the egress device guest port and not on any
additional ones.
Specifically for sites with an ANIRA and no MPLS, there can be a situation where internet and data
works for the LAN and COLLIERS-CORP users but Guest Wifi does not function. In that case, verify
the ANIRA that it has a route for the loopback IP and with the proper next hop.
The above is just a general guide to the most common issues and troubleshooting should never be
limited to just these steps.
TROUBLESHOOTING EXERCISE
The following exercise is taken from a real-life issue in Valencia. In this instance, the end users were able
to connect to COLLIERS-CORP but were unable to access any internal resources. They were, however,
able to access external (internet) resources.

First, the Meraki Dashboard was logged into and it was verified that the APs were able to phone home
as seen below:
Analyzing the output of the Dashboard, the AP has an IP in the proper subnet (10.166/165.X.Y), however,
the device is reporting a problem on the Untagged vlanremember the native (or untagged) vlan should
be the wireless vlan on the core switch. In the above, the problem the AP is reporting is that DNS is not
receiving responses. The AP received its IP settings from the same DHCP server as the endpoint
devices on the wireless vlan.
In this case, the DNS settings on the AP as well as the switch and switchport should be recorded.
Then the switch referenced above is connected to and the vlan settings are verified on the above
switchport. This can be seen below:
This is correctly configured, so next a ping test should be made to internal resources (from the wireless
and the data vlans). In this case, the DATA ping succeeds and the wireless ping fails. Next we should
examine the DHCP server where the DNS settings are being provided. In the case of Valencia, the DHCP
server is NON-STANDARD and lives on the core switch, as can be seen below:

It can be seen that the dns-server option is set to two LEGACY servers: 192.168.120.35 and
192.168.200.15. From the legacy site documentation (note: this is why versioning should be used on the
as-built diagrams and related documentation) it is known that 192.168.200.15 was the DNS server in
DTLA (Valencias HUB site) and 192.168.120.35 was the local DNS server in Valencia.
Next a ping-test is run to the local dns-server and it fails:
With a bit more research, it can be easily determined that when VSP was deployed in Valencia and
DTLA, the DHCP server in Valencia was accidentally not updated to point to the new dns-servers. Once
the legacy dns-servers were decommissioned, the wireless clients would no longer be able to access
internal resources. The APs and the internet on windows-based client devices continued to function
because windows has a built-in top level DNS listas do other clientsand the APs have hard-coded
IPs for the Meraki Cloud.
The fix for this issue is to adjust the DHCP to point towards valid primary and secondary dns-servers. The
steps to point towards the local Valencia VSP as primary and Seattle as secondary are:

While that fixes the issue above, at the end of the day, Valencia wireless data should still be adjusted so
that it gets its DHCP from the server (rather than the switch). Wireless voice is the only one that
ALWAYS gets DHCP from the switch.

Wireless Training

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Wireless Training

Transféré par

Droits d'auteur :

Formats disponibles

Colliers Wireless Training

COLLIERS WIRELESS TRAINING

AUTHOR | JACOBSEN, ERIK VERSION | 1.0

PAGE | 1 VERSION | 1.0

COLLIERS APPROVED SSIDS

PAGE | 2 VERSION | 1.0

PAGE | 3 VERSION | 1.0

NETWORK CONFIGURATION TO SUPPORT WIRELESS

1. Offices with MPLS and Internet connections

2. Offices with MPLS only

3. Offices with Internet only

4. Integrated REMS offices

PAGE | 4 VERSION | 1.0

And the Ontario L3 Switch:

PAGE | 5 VERSION | 1.0

The Ontario EIGRP-TO-BGP route-map is below:

PAGE | 6 VERSION | 1.0

Below is the Ontario router LAN interface and subinterfaces:

PAGE | 7 VERSION | 1.0

OFFICES WITH MPLS AND LOCAL INTERNET

OFFICES WITH MPLS ONLY

PAGE | 8 VERSION | 1.0

The DTLA static route for Ontario is as follows:

PAGE | 9 VERSION | 1.0

OFFICES WITH LOCAL INTERNET ONLY

PAGE | 10 VERSION | 1.0

PAGE | 11 VERSION | 1.0

PAGE | 12 VERSION | 1.0

PAGE | 13 VERSION | 1.0

PAGE | 14 VERSION | 1.0

VRF: Is VRF configured correctly? Is it applied to vlan 666 correctly?

PAGE | 15 VERSION | 1.0

PAGE | 16 VERSION | 1.0

Next a ping-test is run to the local dns-server and it fails:

PAGE | 17 VERSION | 1.0

PAGE | 18 VERSION | 1.0

Vous aimerez peut-être aussi