Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
Hi, On Wed, Aug 31, 2011 at 3:49 PM, Chris Kawchuk juniperd...@gmail.com wrote: I don't want to make a giant vlan and put all the devices loopbacks in it, one for scalability issues but also for broadcast related issues. Could you achieve what you want using RVIs rather than loopback interfaces? I think that's precisely what he's trying to avoid. =) Yeah, OK, I guess I missed that bit. But is it really an unscalable solution? Is it really going to suffer from broadcast related issues? Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
Well, part of good design is trying to avoid as many issues (whether likely or unlikely) wherever reasonably possible, right? Chris, thanks for the reply; thats what I was sort of leaning towards. I still think even that is sort of an ugly solution, and like I mentioned in my original email I thought that in a big enough network it still might not scale but...I think it might be nearly impossible to get to that point. Any other ideas? So far thats my #1 I think. Morgan On Tue, Aug 30, 2011 at 11:04 PM, Dale Shaw dale.shaw+j-...@gmail.comwrote: Hi, On Wed, Aug 31, 2011 at 3:49 PM, Chris Kawchuk juniperd...@gmail.com wrote: I don't want to make a giant vlan and put all the devices loopbacks in it, one for scalability issues but also for broadcast related issues. Could you achieve what you want using RVIs rather than loopback interfaces? I think that's precisely what he's trying to avoid. =) Yeah, OK, I guess I missed that bit. But is it really an unscalable solution? Is it really going to suffer from broadcast related issues? Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
Hi, On Wed, Aug 31, 2011 at 4:12 PM, Morgan McLean wrx...@gmail.com wrote: Well, part of good design is trying to avoid as many issues (whether likely or unlikely) wherever reasonably possible, right? Sure. There's also the KISS principle, and the assumption is the mother of all ... screw-ups concept :-) cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
On Wed, Aug 31, 2011 at 2:04 AM, Dale Shaw dale.shaw+j-...@gmail.com wrote: On Wed, Aug 31, 2011 at 3:49 PM, Chris Kawchuk juniperd...@gmail.com wrote: I don't want to make a giant vlan and put all the devices loopbacks in it, one for scalability issues but also for broadcast related issues. But is it really an unscalable solution? Is it really going to suffer from broadcast related issues? My argument against that design is simple: spanning-tree. Why expose yourself to one more thing that can, and sometimes does, malfunction? We live in a world where multi-vendor L3VPN works pretty good, but spanning-tree is apparently really hard to figure out, especially for some vendors who are particularly good at routing and not so experienced at Ethernet bridging. There are plenty of other good reasons not to do a big vlan for all the routers in that area, but the reason above should be good enough for anyone. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
The bigger issue is that like Chris mentioned, I don't have the visibility into my topology like I would with IP'd interfaces. Like I said, wherever reasonably possible. I think this is a reasonable problem to spend some time solving. Morgan On Tue, Aug 30, 2011 at 11:16 PM, Dale Shaw dale.shaw+j-...@gmail.comwrote: Hi, On Wed, Aug 31, 2011 at 4:12 PM, Morgan McLean wrx...@gmail.com wrote: Well, part of good design is trying to avoid as many issues (whether likely or unlikely) wherever reasonably possible, right? Sure. There's also the KISS principle, and the assumption is the mother of all ... screw-ups concept :-) cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
On 2011-08-31, at 4:12 PM, Morgan McLean wrote: Well, part of good design is trying to avoid as many issues (whether likely or unlikely) wherever reasonably possible, right? Chris, thanks for the reply; thats what I was sort of leaning towards. I still think even that is sort of an ugly solution, and like I mentioned in my original email I thought that in a big enough network it still might not scale but...I think it might be nearly impossible to get to that point. Any other ideas? So far thats my #1 I think. Agreed - it's not pretty. Dale's idea is the simplest and the most straightforward. - VLAN800 is simply bridged everywhere, and every core/access switch has a vlan.800 RVI into that shared LAN. - Core switches run OSPF passive (to inject reachability of the management LAN IP Block) on vlan.800 - Core switches run VRRP between each other on vlan 800 (floating the proverbial '.1' out of the LAN) - Access switches default route to the VRRP .1 address anchored on the aforementioned core switches. - No need for loopback IPs / Router-IDs - No need to build an OSPF area, nor an OSPF database - All switches are 1 hop away, routing-wise. Assuming you already have some kind of loop-avoidance mechanism (RSTP, RTGs, LAG Groups, or combinations thereof...) you shouldn't run into any broadcast-related issues. You're just as likely to run into bridging loops on the rest of our VLANs as you are on this one. (This one is simply no different than any of the other VLANs in the Access Network). Downside is that it doesn't show you the undelrying topology if that's important to you. Anyways, we designed ours to scale to approx 700 switches total. (was a specific need we had for a specific access network in the wireless/mobility space. We'd never be putting in more than 700 switches due to geographical constraints - so we knew our maximum scale beforehand). - Chris. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
Chris, Could you elaborate on: Just need to be careful to bridge the VLAN across the trunk link as necessary. (i.e. only bridge what you need - switch to switch - don't use 'vlan members all'). What would be the problem if I did all? I might have say tag 2001 going to a switch that doesn't play on that vlan, but I wouldn't have problems necessarily would I? Thanks, Morgan On Tue, Aug 30, 2011 at 11:28 PM, Chris Kawchuk juniperd...@gmail.comwrote: On 2011-08-31, at 4:12 PM, Morgan McLean wrote: Well, part of good design is trying to avoid as many issues (whether likely or unlikely) wherever reasonably possible, right? Chris, thanks for the reply; thats what I was sort of leaning towards. I still think even that is sort of an ugly solution, and like I mentioned in my original email I thought that in a big enough network it still might not scale but...I think it might be nearly impossible to get to that point. Any other ideas? So far thats my #1 I think. Agreed - it's not pretty. Dale's idea is the simplest and the most straightforward. - VLAN800 is simply bridged everywhere, and every core/access switch has a vlan.800 RVI into that shared LAN. - Core switches run OSPF passive (to inject reachability of the management LAN IP Block) on vlan.800 - Core switches run VRRP between each other on vlan 800 (floating the proverbial '.1' out of the LAN) - Access switches default route to the VRRP .1 address anchored on the aforementioned core switches. - No need for loopback IPs / Router-IDs - No need to build an OSPF area, nor an OSPF database - All switches are 1 hop away, routing-wise. Assuming you already have some kind of loop-avoidance mechanism (RSTP, RTGs, LAG Groups, or combinations thereof...) you shouldn't run into any broadcast-related issues. You're just as likely to run into bridging loops on the rest of our VLANs as you are on this one. (This one is simply no different than any of the other VLANs in the Access Network). Downside is that it doesn't show you the undelrying topology if that's important to you. Anyways, we designed ours to scale to approx 700 switches total. (was a specific need we had for a specific access network in the wireless/mobility space. We'd never be putting in more than 700 switches due to geographical constraints - so we knew our maximum scale beforehand). - Chris. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
Chris, Could you elaborate on: Just need to be careful to bridge the VLAN across the trunk link as necessary. (i.e. only bridge what you need - switch to switch - don't use 'vlan members all'). What would be the problem if I did all? I might have say tag 2001 going to a switch that doesn't play on that vlan, but I wouldn't have problems necessarily would I? Thanks, Morgan You're right. It wouldn't necessarily be an issue. What I'm trying to avoid is bridging VLAN 2001 everywhere (and we're back to the original '1 giant LAN' problem). Switch 1 Switch 2 uses VLAN 2001 Switch 2 Switch 3 uses VLAN 2002 Switch 3 Switch 1 uses VLAN 2003 All inter-switch links declared 'family ethernet switching port-mode trunk members vlan all'. Agreed, if switch 3 doesn't have tag 2001 declared, it'll just ignore it / not pass it back to switch 1. However, if you're using a base RSTP topology (VLAN unaware), then one of those inter-switch links is going to block. You will not have routing/IP connectivity on one of the inter-switch links. However, this is not necessarily a problem If RSTP blocks between a pair of switches, OSPF will just lose the inter-switch adjacency - but not reachability of each switch in the OSPF database (The Type 1's are all still there). The traceroute simply follows the current RSTP forwarding topology. - Chris. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
Thats sort of what I'm expecting. My core is two 8208's running in the same L2 domain with a trunk between them, and they each connect down to a switch per cabinet. So switch A cabinet 1 is connected to core-A and switch B in cabinet 1 is connected to core-B. The machines run bonding and have a drop on each cabinet switch (which are also trunked over a lag together) so I was assuming that only one of the cabinet switches will actually have link to the core at any given time, and the center trunk on the cabinet switches will always be active, allowing the switch without link to still communicate through the lag. We don't use RSTP on a vlan basis, but I don't think I have the need. Thanks! Morgan On Wed, Aug 31, 2011 at 12:12 AM, Chris Kawchuk juniperd...@gmail.comwrote: Chris, Could you elaborate on: Just need to be careful to bridge the VLAN across the trunk link as necessary. (i.e. only bridge what you need - switch to switch - don't use 'vlan members all'). What would be the problem if I did all? I might have say tag 2001 going to a switch that doesn't play on that vlan, but I wouldn't have problems necessarily would I? Thanks, Morgan You're right. It wouldn't necessarily be an issue. What I'm trying to avoid is bridging VLAN 2001 everywhere (and we're back to the original '1 giant LAN' problem). Switch 1 Switch 2 uses VLAN 2001 Switch 2 Switch 3 uses VLAN 2002 Switch 3 Switch 1 uses VLAN 2003 All inter-switch links declared 'family ethernet switching port-mode trunk members vlan all'. Agreed, if switch 3 doesn't have tag 2001 declared, it'll just ignore it / not pass it back to switch 1. However, if you're using a base RSTP topology (VLAN unaware), then one of those inter-switch links is going to block. You will not have routing/IP connectivity on one of the inter-switch links. However, this is not necessarily a problem If RSTP blocks between a pair of switches, OSPF will just lose the inter-switch adjacency - but not reachability of each switch in the OSPF database (The Type 1's are all still there). The traceroute simply follows the current RSTP forwarding topology. - Chris. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
Basically, what we do is what Chris described. In our case, we have Layer 2-only devices in two places in the network - core switching in the larger PoP's and egde switching for aggregating supporting services, e.g., DNS, mail, e.t.c. For the core switches, we run an IP-aware VLAN and enable IS-IS on that. That exchanges routes with the core routers which then allow the devices to be visible across the entire IGP. For the edge switches, those are attached to routers directly (802.1Q Trunking). On the switch, we run an IP- aware VLAN that corresponds to a Management VLAN between the switch and its adjacent router. On the router, that interface is placed into IS-IS (passive mode) and the switch is now reachable across the entire IGP. Has been a solid design since we started it, and it holds pretty nicely. Like Chris, we standardize on the VLAN ID's to use at each PoP where this is necessary, as they are all locally significant to the switches. We really don't like Layer 2 Ethernet switching protocols, and will replace them with IP as often as we can. If we have to use them, we localize them to within the same switch or no more than two. Hope this helps. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Running OSPF to manage loopbacks, only have trunks
So for example, if I have a meshed layer 2 network with switches and I would like to be able to maintain device reachability using something like OSPF, how would I go about doing this? Everything already had two connections to its upstream etc, but they are in the form of trunks. Junos won't let me add a unit when there is already a unit set as ethernet switching and port mode trunk. Is there any way I can create an addressable interface just for point to point ospf neighbor relationships, and maintain my ethernet trunks? What I don't want to do is run additional cables between everything. I already run two uplinks from every access switch into my core switches. I don't want to make a giant vlan and put all the devices loopbacks in it, one for scalability issues but also for broadcast related issues. I could maybe make private vlans between each link, but again thats bad because I'll eventually run out of tags! This is just me getting creative at this point, lol. Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
What platform is this? If its an MX, you can change the encapsulation of the physical interface to flexible-ethernet-services and then you can add a unit with family inet on it. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com From: Morgan McLean wrx...@gmail.com To: juniper-nsp@puck.nether.net Sent: Tue, August 30, 2011 9:55:02 PM Subject: [j-nsp] Running OSPF to manage loopbacks, only have trunks So for example, if I have a meshed layer 2 network with switches and I would like to be able to maintain device reachability using something like OSPF, how would I go about doing this? Everything already had two connections to its upstream etc, but they are in the form of trunks. Junos won't let me add a unit when there is already a unit set as ethernet switching and port mode trunk. Is there any way I can create an addressable interface just for point to point ospf neighbor relationships, and maintain my ethernet trunks? What I don't want to do is run additional cables between everything. I already run two uplinks from every access switch into my core switches. I don't want to make a giant vlan and put all the devices loopbacks in it, one for scalability issues but also for broadcast related issues. I could maybe make private vlans between each link, but again thats bad because I'll eventually run out of tags! This is just me getting creative at this point, lol. Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
Hi Morgan, On Wed, Aug 31, 2011 at 12:55 PM, Morgan McLean wrx...@gmail.com wrote: So for example, if I have a meshed layer 2 network with switches and I would like to be able to maintain device reachability using something like OSPF, how would I go about doing this? Everything already had two connections to its upstream etc, but they are in the form of trunks. Junos won't let me add a unit when there is already a unit set as ethernet switching and port mode trunk. OK.. Is there any way I can create an addressable interface just for point to point ospf neighbor relationships, and maintain my ethernet trunks? What I don't want to do is run additional cables between everything. I already run two uplinks from every access switch into my core switches. I don't want to make a giant vlan and put all the devices loopbacks in it, one for scalability issues but also for broadcast related issues. I could maybe make private vlans between each link, but again thats bad because I'll eventually run out of tags! This is just me getting creative at this point, lol. Could you achieve what you want using RVIs rather than loopback interfaces? i.e. on your dot1q trunks, carry an extra management VLAN and attach a family inet RVI to it? You wouldn't necessarily need to run OSPF on the RVIs on the edge switches - depending on your topology. This is how we manage edge/access switches in L2-only campuses; we have a VLAN 800 carried on uplinks/trunks with a vlan.800 RVI defined on both the core and access switches. On the core side, the vlan.800 interface is part of the OSPF topology but the interface itself is passive. On the access side, OSPF doesn't run at all and the vlan.800 interface in effect makes the switch appear as an IP-enabled end node/station in VLAN 800. cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
I think that's precisely what he's trying to avoid. =) What we did is to use RVIs (vlan.xxx), but had a series of VLANs (VLAN 2000, 2001, 2002, 2003 etc..) setup as point-to-point /30s between the EXes inside a VLAN. Switch 1 to Switch 2 would be VLAN 2002. Switch 2 to Switch 3 would be VLAN 2003, etc. Just need to be careful to bridge the VLAN across the trunk link as necessary. (i.e. only bridge what you need - switch to switch - don't use 'vlan members all'). We could also re-use the same point-to-point VLAN IDs elsewhere in the network to link other switches together OSPF-wise (as the VLAN ID was only locally significant to a pair of switches). I could re-use 2001/2002/2003 elsewhere, perhaps in a different group of switches. Hence, on each switch, we turned on OSPF on those RVIs, allocated some private /30s between the switches, and exported lo0.0 into the ospf area. Ended up with something that looks alot like what you're trying to do. Nice thing is that you can discover the switched network topology easily via a simple traceroute. Makes reachability troubleshooting easy for my new guys; esp if you do the reverse DNS properly: traceroute loopback.switch5.mynetwork.net 1 10ms 10ms 10ms ge-0/0/22.switch1.mynetwork.net [10.222.1.2] 2 10ms 10ms 10ms ge-0/0/24.switch2.mynetwork.net [10.222.2.2] 3 10ms 10ms 10ms ge-0/1/0.switch3.mynetwork.net [10.222.3.2] 4 10ms 10ms 10ms xe-0/1/1.switch4.mynetwork.net [10.222.4.2] 5 10ms 10ms 10ms loopback.switch5.mynetwork.net [10.111.5.1] ^^ fake traceroute, but you get the idea of what's possible. each link between the switches is a /30. Map your reverse DNS appropriately to which interface is shared between the two switches. - Chris. P.S. If you want to get really fancy (or dislike burning a bunch of IP space for /30 connections), use IP unnumbered instead /30s on the vlan.x interfaces. OSPF will form an adjacency and learn. traceroutes will then show the loopback IPs of each switch as you trace through the network instead. I don't want to make a giant vlan and put all the devices loopbacks in it, one for scalability issues but also for broadcast related issues. Could you achieve what you want using RVIs rather than loopback interfaces? i.e. on your dot1q trunks, carry an extra management VLAN and attach a family inet RVI to it? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
