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
[j-nsp] Allocate Static IPs to subscribers on Junos 9.3 ERX
Hi Guys, Have any of you guys configured a juniper ERX 1440 to allocate subscribers with the same IP address, even though a local ip pool is used and lease time appears set by the Radius server in use? Thanks Jon *DISCLAIMER* This electronic transmission (and any attached document) is intended exclusively for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any disclosure, copying, distribution or other action based upon the information by persons or entities other than the intended recipient is prohibited. If you receive this message in error, please contact the sender and delete the material from any and all computers. Mobistar does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. *END OF DISCLAIMER* ___ 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
Re: [j-nsp] JUNOS 10.4S6 for EX8200 - PR/676826
On Tue, Aug 30, 2011 at 08:28:31PM -0700, Jackson Jacobson wrote: I am curious about what version of junos people on the list run. If you're sticking way behind, why? I assume most people are running whatever SR JTAC gave them to fix their most painful support case. More generically, by platform: If you're on EX, you're probably pushed towards the bleeding edge. To some degree this is true with MX, but it doesn't seem to be progressing in the way that it is with EX. SRX, you might as well run whatever came on it, because it won't work anyway. The ALGs don't work, at times proxy arp doesn't work, your logs will be full of interesting (and scary) error messages, bugs that were supposed to have been fixed aren't, licensed features (like dynamic-vpn) don't work at ALL, etc. J series, 9.3 if you can get away with it, since Juniper has decided to make that thing into an enterprise firewall and is willing to kill any and all actual routing capability that stands between them and this goal of being able to sell 'something else' to those already burned by the SRX. M/T series probably have the most flexibility as they have been around long enough not to push people towards 10.4/11.[12] -- people can just select the appropriate SR. If it sounds like I'm bitter about Juniper's code quality of the last few years, it's early yet. Cheers, --msa ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS 10.4S6 for EX8200 - PR/676826
On Wednesday, August 31, 2011 08:43:26 PM Majdi S. Abbas wrote: If you're on EX, you're probably pushed towards the bleeding edge. To some degree this is true with MX, but it doesn't seem to be progressing in the way that it is with EX. In the early days of Junos 9.x, when the EX debuted, yes, running the latest code worked for us because the thing was simply too knew, and features we'd taken for granted in IOS were simply not mature when the boxes stared shipping. Fast-forward to today, and we're tracking them as we do the routers just for consistency. However, our use of these switches is pure Layer 2 Ethernet switching; so it's an alternative to whatever Cisco can do, i.e., nothing interesting that needs a specific software release. 10.4R4.5 today on our EX3200's/4200's. SRX, you might as well run whatever came on it, because it won't work anyway. The ALGs don't work, at times proxy arp doesn't work, your logs will be full of interesting (and scary) error messages, bugs that were supposed to have been fixed aren't, licensed features (like dynamic-vpn) don't work at ALL, etc. None here, but the constant pain about them on the list is glaring. Our office runs the Netscreens, and they seem solid! Don't know what's running there, Security team, e.t.c. J series, 9.3 if you can get away with it, since Juniper has decided to make that thing into an enterprise firewall and is willing to kill any and all actual routing capability that stands between them and this goal of being able to sell 'something else' to those already burned by the SRX. A really sad story what Juniper decided to do with these boxes. Would have made decent route reflectors if Juniper concentrated on that as an application. M/T series probably have the most flexibility as they have been around long enough not to push people towards 10.4/11.[12] -- people can just select the appropriate SR. Agree - we have far fewer issues with these as they're older and most of the new junk going into Junos today isn't to do with them save for a couple of features (which are sometimes hardware dependent) and general bug fixes. We've hit some silly bugs on the M-/T-series lately, but nothing near as bad as the MX. If it sounds like I'm bitter about Juniper's code quality of the last few years, it's early yet. Can't blame you. If you're new to Juniper, just coming from Cisco, feelings might be familiar. If you started with Juniper back in the days of Junos 5, 6, 7 and 8.4, as they say, Those were the days. 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
Re: [j-nsp] Juniper QinQ problem
Hi Steinar
I dont understand the differnce between Chassis wide VLAN and probably line
card based Vlan. Can you help me understand the same.
thanls
Regards
Abhijeet.C
From: sth...@nethelp.no sth...@nethelp.no
To: jstuxuhu0...@gmail.com
Cc: juniper-nsp@puck.nether.net
Sent: Tuesday, August 30, 2011 12:21 PM
Subject: Re: [j-nsp] Juniper QinQ problem
Recently, i had came cross a problem, the customer need me to configure
the QinQ in the MX960 products, i am wondering if there anyone had the
example of the QinQ configuration in the MX?
Do you mean QinQ (dual tagged) *termination*? Or something else? Here
is an example of a dual tagged customer (2 x 0x8100 tags) terminated on
an MX:
a...@xxx.yyy show configuration interfaces ge-0/0/9.976
vlan-tags outer 1012 inner 300;
family inet {
mtu 1500;
address 10.232.46.1/30;
}
Does the MX can end up the vlan in the line card, just like the ES line
card in the 7609-S?
Not sure what you're asking about here. If you're asking whether the
VLANs are global to the chassis, like normal LAN cards on a 7600, the
answer is *no*.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
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] Juniper QinQ problem
I dont understand the differnce between Chassis wide VLAN and probably line card based Vlan. Can you help me understand the same. There are lots of discussions about this on the cisco-nsp list, due to well known limitations of the 6500/7600 architecture. See for instance http://www.gossamer-threads.com/lists/cisco/nsp/99661 For a *switch* you normally expect VLANs to be global or chassis wide. For a *router* you normally expect VLANs to be per-port/per-interface. And then there are boxes like Cisco 7600 routers :-) (Yes, I realize this is a Juniper list.) Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper QinQ problem
On Wednesday, August 31, 2011 10:29:31 PM sth...@nethelp.no wrote: http://www.gossamer-threads.com/lists/cisco/nsp/99661 For a *switch* you normally expect VLANs to be global or chassis wide. For a *router* you normally expect VLANs to be per-port/per-interface. And then there are boxes like Cisco 7600 routers :-) (Yes, I realize this is a Juniper list.) I guess it's reasonable to discuss them as it's general design principle regardless of vendor. Truth be told, the ES/ES+ line cards on the 7600 (and now 6500) make VLAN ID's locally significant to a port on said line cards (scenarios may vary based on line card generation and number of tags used on sub-interfaces). However, those cards are pricey, and depending on your needs, an ASR9000 or MX240/480/960 may be more ideal. 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
Re: [j-nsp] Juniper QinQ problem
Hi Guys thanks i get that. Regards Abhijeet.C From: Mark Tinka mti...@globaltransit.net To: juniper-nsp@puck.nether.net Cc: sth...@nethelp.no; vyaaghrah-...@yahoo.com Sent: Wednesday, August 31, 2011 8:24 PM Subject: Re: [j-nsp] Juniper QinQ problem On Wednesday, August 31, 2011 10:29:31 PM sth...@nethelp.no wrote: http://www.gossamer-threads.com/lists/cisco/nsp/99661 For a *switch* you normally expect VLANs to be global or chassis wide. For a *router* you normally expect VLANs to be per-port/per-interface. And then there are boxes like Cisco 7600 routers :-) (Yes, I realize this is a Juniper list.) I guess it's reasonable to discuss them as it's general design principle regardless of vendor. Truth be told, the ES/ES+ line cards on the 7600 (and now 6500) make VLAN ID's locally significant to a port on said line cards (scenarios may vary based on line card generation and number of tags used on sub-interfaces). However, those cards are pricey, and depending on your needs, an ASR9000 or MX240/480/960 may be more ideal. Cheers, Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
