Reducing/removing Layer 2 at network edge of leaf/spine topology Networking |
- Reducing/removing Layer 2 at network edge of leaf/spine topology
- Wildcard masks
- Azure Site to Site VPN - Local Network Gateway options
- STP or VPLS over L3 for different sized site to site links?
| Reducing/removing Layer 2 at network edge of leaf/spine topology Posted: 04 Aug 2019 01:33 PM PDT Hey all, We have a leaf/spine network with a set of border leaves connected to a firewall (ASA). I'm looking for any advice as to how we could potentially move our setup to pure layer 3, having layer 2 adjacency only on point to point links. See the following diagram for the current setup: https://imgur.com/a/rdsLc8f The outside interface of our firewall is connected to a switch , and upstream routers provide a VRRP IP for the default gateway to the internet. We do NAT translations at the firewall for public access to internal private IPs, and we do SNAT for private IPs at the firewall for them to reach the internet. On the inside interfaces of the firewall, we peer it with BGP to each of the border leaves. The firewall announces a default route into the spine/leaf topology. What I'm interested in doing is something like this: https://imgur.com/a/QzEy1k5 (edited to show router + firewall active/standby adjacency) Ideally each side of the firewall (inside and outside) would be BGP peered, and there would be no VRRP. The problem I'm not sure if I can overcome is when NAT comes into play. Are there any ways to make this work where I can have both internal private IPs SNAT to the internet and have NAT rules that map public IPs to private internal IPs? I'm not sure if traffic zones would help here in an async routing case. Thanks! [link] [comments]  |
| Posted: 04 Aug 2019 05:07 AM PDT Does anyone know why when creating ACLs for example, the 0 is the bit value that is the discriminating bit and the 1 is the wildcard bit? For example if the logic was reversed, I could simply type access-list 1 192.168.1.0 255.255.255.0 permit and that would allow me to permit an entire /24 subnet, however because of the bit logic with ACLs, I instead have to type access-list 1 192.168.1.0 0.0.0.255 permit. Does anyone why it is the case that bit values are the way they are? [link] [comments]  |
| Azure Site to Site VPN - Local Network Gateway options Posted: 04 Aug 2019 11:36 AM PDT Setting up a Proof of Concept hybrid network using Azure Site to Site VPN
The only On-Prem device I need to access from Azure is a Windows 2016 Server with DC/DNS roles. I don't have an edge firewall/router or public ip. I did not want to spend thousands on a supported device yet given it's a PoC. Preferred solution would be using a VM within On-Prem acting as the Local Network Gateway e.g. software-based router, virtual F5 Big-IP (30 day evaluation license), etc. Ideas in how you've economically setup a lab hybrid network would be appreciated. [link] [comments]  |
| STP or VPLS over L3 for different sized site to site links? Posted: 03 Aug 2019 09:07 PM PDT We are building a branch location with a few hundred users; The HQ location is connected to the branch location with a 10Gbps wavelength point-to-point circuit from $ISP1 and a 1Gbps VPLS point-to-point circuit from $ISP2. The branch is physically less than a mile away from the HQ location and latancy on either path is < 1MS. We have Aruba 2930F access switches, 5406R campus core switches, and 3810M datacenter top of rack switches. Topology will be: The Palo Alto VM100's are the gateway for all access vlans. So my question is, should we stretch our vlans across the 10G Wave and the VPLS, and use STP to block the 1G VPLS? Or, should we route across the wave and the VPLS and run VXLAN across the routed underlay? Another approach? How would you handle this where you have a branch location with 2 different sized links back to HQ, and the campus location has NO routing, DNS servers, DHCP servers, or anything other than L2 switching? [link] [comments]  |
| You are subscribed to email updates from Enterprise Networking news, blogs and discussion.. To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
| Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States | |
No comments:
Post a Comment