Hello Bill, you have been provided several good suggestions by Rick and Joseph and by Peter.   The first important key point is the default gateway settings on PCs that should be the new switch C3850 SVI interface IP address in all cases. What is special about vlan 10? Not the fact the vlan 10 is the native vlan in your trunk ports, this is an OSI layer 2 concept. You have issues at OSI layer 3 IP routing level ( if any) In vlan 10 subnet 172.16.0.0/24 you have: the external internet facing router with IP address 172.16.0.1 the DHCP server with IP address 172.16.0.X  a pair of hosts in same IP subnet.   Verify on the windows DHCP server what default gateway it has. If the DHCP server was already installed before introducing the new L3 switch, it is likely pointing to 172.16.0.1 instead of 172.16.0.254 (new switch). Of course it can ping the directly connected 172.16.0.254 it is just a question of ARP resolution. If the DHCP server cannot ping the other SVI interfaces on the new switch the possible issues are: DHCP server has default gateway pointing to 172.16.0.1 the router at 172.16.0.1 has no knowledge of the new Vlans behind the new switch.   Check the ip routing table on the router. If needed you should add static routes like ip route 172.16.30.0 255.255.255.0 172.16.0.254.   This should fix your network about intervlan routing and capability to ping the router from different Vlans then vlan 10.   The question of the ip helper-address has to be troubleshooted later when inter Vlan routing is working as desired.   Hope to help Giuseppe     ... View more

Hello umutyar, your network scenario is quite complex and a network diagram would help. Can you post a network diagram as an attachment file? Can you explain how the two DMVPN clouds are implemented ? Each device is using an MPLS link and two internet facing links from different providers one for DMVPN1 and one for DMVPN2? Or both the DMVPN clouds use the same internet facing link?.   >> Dmvpn using ibgp and mpls using ebgp between hub and spokes. Each Cloud has single hub and these two hubs sharing same DC LAN Network subnet and using eigrp in DC. Can you provide the configuration of: DMVPN1 Hub1 DMVPN2 Hub2 and one or two Spokes again as attachment files in text format. It is not clear to me how you can implement eBGP sessions and iBGP sessions between the same set of devices I can guess you are using neighbor local-as command and its variations. Note: unless the MPLS service is a layer3 VPN and you are doing eBGP with the PE node of the MPLS provider on each device. This is also another point that needs to be clarified.   >> But once both mpls links goes down on hubs or, mpls uplink goes down on spoke, spoke egress trafic uses dmvpn1 and ingress traffic uses dmvpn2. Is there any way to prevent this and force ingress traffic to use dmvpn1 as well?   You are using iBGP, eBGP and EIGRP on the hub routers. The upstream traffic from spoke to DMVPN1 is chosen on spoke using iBGP (likely an higher weight or local preference is given to iBGP route coming from HUB1 on DMVPN1 when compared to route received from HUB2 on DMVPN2). The return traffic is chosen by EIGRP protocol in the data center. How do you redistribute iBGP routes into EIGRP in HUB1 and HUB2?   You need to use route-maps, but if you want to be sure that HUB1 is also used in return path you need to tune EIGRP metric used in redistribution Example: HUB1 router eigrp 100 default-metric 20000 100 255 1 1500 redistribute bgp 65000 route-map BGP-into-EIGRP   ! on Hub2 you need to use a different seed metric   Hub2: router eigrp 100 default-metric 10000 1000 255 1 1500 redistribute bgp 65000 route-map BGP-into-EIGRP see the EIGRP command reference. The first value is bandwidth and the second is delay. The other parameters are not important with default K values in EIGRP   https://www.cisco.com/c/m/en_us/techdoc/dc/reference/cli/nxos/commands/eigrp/default-metric-eigrp.html   To be noted the route-maps BGP-into-EIGRP must take in account if the routes are learned via eBGP or via iBGP and set a seed metric accordingly. This can be done by checking the BGP next-hop. This is just a suggestion on what should be done. If you provide the configuration details of the Hub1, Hub2 devices and one Spoke it is possible to provide more focused suggestions.   Hope to help Giuseppe         ... View more

Hello cisc0.ameer, I try to answer to your questions:   >> 1-did you mean if we have Route-Reflector server in our topology we can assigned RD values in each PE but not necessary to use that RD in other PEs ?   in this case we can have different RD value but using RT /   Your understanding is correct in case of a multihomed VRF site using two different RD values on the two PE nodes serving the site provide the benefits that both sets of VPNv4 routes are propagated even if using Route Reflector servers.   >> 2-what you mean by :not comparable RRS see them as different not comparable   As I have explained in my previous post the VPNv4 is made by prepending the 64 bit RD to the IPv4 subnet. So, from the point of view of the RRS the two VPNv4 prefixes: 65000:1001:10.10.10.0/24      RT 65000:500 65000:1002:10.10.10.0/24      RT 65000:500 are two different not comparable VPNv4 prefixes, as a result of this the RRS does not perform a best path choice and both of them are propagated to all other PE nodes and other RRS. (this is the key point making the VPNv4 prefixes different so that they are not compared for best path selection otherwise only the routes of one PE node will be propagated by RRS usually the one generated by PE node with lower BGP router-id) The remote PE nodes will import both VPNv4 routes because of the same route-target value. At this point the remote PE node can even install both paths via PE1 and PE2 if configured for doing that. By default the remote PE will install only a single route the BGP best path ( likely the route originated by the PE node with the lowest BGP router-id if the IGP metric to next-hop is the same).   >> 3- just for clarifying for last time in Full Mesh scenario usually if we assign RD value like 100:1 in other PE we generally use 100:1 ...am i right ?because you mentioned The RD are needed locally in a single PE and are used also on remote PE when importing prefixes. (this is correct i think in case we have full mesh scenario because in my scenario it used different RD and never used it in other PEs )   Let me say again in a any to any VPN = Full Mesh the habit is to use the same RD on all PE nodes. But the connectivity model is decided by RT values. using a single route-target value for importing and exporting creates an any to any connectivity model the simplest one. RD values are only used to support address overlapping on same PE node and also for allowing differentiation of VPNv4 prefixes on RRS as explained above for multihomed VRF sites when looking from the point of view of a remote PE node. This is the sense of my sentence. I'm sorry it it was causing confusion.   However, I would like to make you aware that RD can be populated in a different manner: RD:    two bytes cannot be configured and are chosen depending on the format used for the RD configurable fields:   Possible options for RD are the following: a) two bytes AS number followed by a 32 bit integer value example:  65000:1001 You know this already. b) four bytes IP address of the loopback address PE node followed by 16 bit integer Example:   PE:loop0 address is 172.16.255.21/32  a possible RD is 172.16.255.21:1001 where PE:loop0 is the BGP router-id, MPLS LDP RID and OSPF RID (if OSPF is used). When using this second convention in building RD values we have the advantage of immediately be able to read the originator PE loopback address. So this format is handy and used in some environments.   Hope to help Giuseppe     ... View more