I tried using round-robin to connect two Linux machines together, as they both support this. While I did get more available bandwidth than a single link, the result was not spectacular.
I bonded together two 10G links, in theory allowing 20 Gbps between the hosts. Sometimes I would indeed get close to this, but a lot of the time I would only get 11-15 Gbps....
interface:500 can only be bound once. Either the router's tunnel process has that IP and port, or the NAT engine does. One can limit when NAT applies, but there's no such ability for an application binding a port.
(There are some VRF tricks that can move the tunnel off the outside interface, but this gets very messy.)
So after further examination I had came to conclusion that one of the main reasons trace didn't work for a few devices was because a wrong route was selected.
The issue was directly with OSPF route selection preferring the ASBRs that were redistributing the redistributed route (EIGRP->OSPF) as opposed to the redistributed route from the ASBR that was ...
You have a couple of route-maps that are almost correct. Like you surmised, you need to use communities within BGP routing-policy.
ip community-list standard permit from-ospf <asn>:1
route-map BGP_TO_OSPF deny 10
match community from-ospf
route-map BGP_TO_OSPF permit 20
set tag 222
route-map OSPF_TO_BGP deny 10
match tag 222
route-map OSPF_TO_BGP ...
Without configurations for some of the other routers (RO-4/RO-1) we're basically guessing. However, this sounds like a classic issue of your own routes being announced back to you. If "ISP-2" is supposed to be an ISP's router, it wouldn't be running OSPF with you.
In this messy example, you've created a loop between OSPF area 0 and 1 outside of ...
Had this conversation yesterday. Communities sound complex but are really just tags for BGP. There are a few different ways that you could potentially resolve this. Looking at the topology I am assuming that RO-1 and RO-4 are your redistribution sets. With this in mind you could set a BGP community for 65100:10 and 65200:10 (the number is arbitrary. Standard ...
I do the same in my network, but it does work. I think the difference here is the tagging that you use to redistribute, and is not supported as you mentioned. You can do the filtering on the route map via ip prefix instead of tag. Please, check the example in my router and let me know if it helps.
router ospf 1
redistribute bgp ...
Certain things don’t show up in SNMP configurations- things like snmp user. Use the command show snmp user as for all of the settings- it is possible they are default and thus don’t show for brevity. You might find it under show run all
SWITCH_DISABLE_PASSWORD_RECOVERY cannot be changed from ROMMON -- rather defeats the purpose. If password recovery is disabled, you won't get to the CLI without erasing the configuration. If you're there, just follow the rest of Cisco's documented procedure... disable the startup config (SWITCH_IGNORE_STARTUP_CFG=1) and boot without any config.
It all depends on the network that you are tunneling across.
If that network is under your control, you could increase its MTU so that it can handle the tunneled payload plus the encapsulating overhead. Make sure that all devices connecting to that network can handle the new MTU or L2 frame size ("baby giants") respectively.
If the underlying ...
There is one option available. Create a new VLAN and create new DHCP scope for this VLAN
Assuming you created new VLAN as VLAN 20
Switch (config)#ip dhcp pool Vlan20
Switch(config)#network 192.168.X.X 0.0.255.255
Switch (config)# default-router ip 192.168.1.1
Switch (config)#dns-server 220.127.116.11
Also create the same VLAN 20 on downstream access switches, and ...
Now they have 230 devices and They are going to increase device count by 100.
Within the same subnet? Then you'd have to supernet that subnet to e.g. 192.168.24.0/23.
I cannot change subnet and increased usable IP addresses count because there are many dependencies.
Adding another subnet/VLAN is a better option anyway. As Jesse's already answered, that ...
Questions about protocols above layer 4 are off limits here, however, as a very basic explanation on a layer 2 and layer 3 level, you cannot have multiple VLANs using the same DHCP pool (same subnet). Each VLAN would need a separate DHCP pool (separate subnet) to assign addresses from.
VLAN 100: 192.168.1.0/24
VLAN 200: 192.168.2.0/24
Just to ...
It turns out the Palo Alto tunnel inspection policy was the root of the issue. Once I disabled the policy in each firewall, I was able to ping through the tunnel. I used traceroute to verify from multiple networks that they were taking the GRE tunnel in R1 to reach R2 and its networks. I'll have to revisit the inspection policy at some point to get it ...
I have faced the same issue. In my case one of the interfaces was down. I have activated it and it solved the issue.
Initially, check your routing table
If you are enable mode, use
show ip interface brief
If you are in configuration mode, use
do show ip int bri ( here do is added )
Check the topology of your network and set the ip address ...
The giveaway is the port name Gi1/0/50. An SFP+ DAC generally requires an SFP+ (10G) port. There are very few SFP ports (1G) that accept SFP+ modules.
There are no SFP DACs, so you could use either a simple twisted-pair port (1000BASE-T), or SFP with multi-mode fiber (1000BASE-SX), or single-mode fiber (1000BASE-LX). If you do require 10G you'll need a 10G ...
I found the solution to this eventually, with some help.
The issue was that on the ASR side, the tunnel was in its default configuration which uses GRE, which the ASA doesn't support.
The solution was to change the tunnel mode to ipsec ipv4 like so:
tunnel mode ipsec ipv4
With this done, bidirectional traffic was possible over the tunnel.