Re: [j-nsp] OSPF default-lsa
the default-lsa is not generated because of Junos 'active backbone detection' http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/configuring-the-backbone-area-and-other-areas.html Active backbone detection is implemented to verify that area border routers are connected to the backbone. If the connection to the backbone area is lost, then the router’s default metric is not advertised, effectively rerouting traffic through another area border router with a valid connection to the backbone. I don't know if and how it can be disabled. On Tue, 2010-07-27 at 12:31 +1000, Julien Goodwin wrote: I've been having some weirdness with OSPF default-lsa's, in that when a hosts only other area 0 OSPF peer goes away the default drops, despite the fact that the host has full routes via BGP. Is there any way to say that I *always* want a default-lsa sent, no matter what my OSPF adjacencies may be? ___ 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] OSPF default-lsa
On 27/07/10 18:42, Luca Tosolini wrote: the default-lsa is not generated because of Junos 'active backbone detection' http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/configuring-the-backbone-area-and-other-areas.html Active backbone detection is implemented to verify that area border routers are connected to the backbone. If the connection to the backbone area is lost, then the router’s default metric is not advertised, effectively rerouting traffic through another area border router with a valid connection to the backbone. I don't know if and how it can be disabled. And a quick google later the magic appears to be (from Network Mergers Migrations, my copy of which is at home, and I wouldn't have looked to it for OSPF insight). set protocols ospf no-active-backbone Which is now on all my area 0 routers. Thanks a lot. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX80 IRB
On Jul 26, 2010, at 11:25 PM, Chuck Anderson wrote:
On Mon, Jul 26, 2010 at 06:52:14PM +0200, Tim Vollebregt wrote:
We have just received a Juniper MX80 and are building the configuration.
The machine is running Junos 10.2 R1.8
The issue we are experiencing is that the IRB interface seems to be
not working, although it seems to be configured correctly.
Configuration:
Try configuring it the old 9.2 way and let us know if it works:
ge-1/0/0 {
unit 200 {
encapsulation vlan-bridge;
vlan-id 200;
irb {
unit 200 {
family inet {
address x.x.x.x/27;
address x.x.x.x/29;
bridge-domains {
VLAN200 {
domain-type bridge;
vlan-id 200;
interface ge-1/0/0.200;
routing-interface irb.200;
Thanks.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Hi Chuck,
I'm getting errors when changing to this configuration. It is only possible to
use encapsulation vlan-bridge on unit 0. And when I change it to unit 0:
messageVLAN Encapsulation: Not allowed on untagged interfaces/message
/xnm:error
source-daemondcd/source-daemon
edit-path[edit interfaces ge-1/0/0]/edit-path
statementunit 0/statement
message invalid encapsulation/message
/xnm:error
error: configuration check-out failed
This issue seems to be really strange as we have it working the 10.x way on
another router. When I configure Ge-1/0/0 as a routed interface it works fine.
Regards,
Tim
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX80 IRB
On Tuesday, July 27, 2010, Tim Vollebregt t...@interworx.nl wrote:
On Jul 26, 2010, at 11:25 PM, Chuck Anderson wrote:
On Mon, Jul 26, 2010 at 06:52:14PM +0200, Tim Vollebregt wrote:
We have just received a Juniper MX80 and are building the configuration.
The machine is running Junos 10.2 R1.8
The issue we are experiencing is that the IRB interface seems to be
not working, although it seems to be configured correctly.
Configuration:
Try configuring it the old 9.2 way and let us know if it works:
ge-1/0/0 {
unit 200 {
encapsulation vlan-bridge;
vlan-id 200;
irb {
unit 200 {
family inet {
address x.x.x.x/27;
address x.x.x.x/29;
bridge-domains {
VLAN200 {
domain-type bridge;
vlan-id 200;
interface ge-1/0/0.200;
routing-interface irb.200;
Thanks.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Hi Chuck,
I'm getting errors when changing to this configuration. It is only possible
to use encapsulation vlan-bridge on unit 0. And when I change it to unit 0:
messageVLAN Encapsulation: Not allowed on untagged interfaces/message
/xnm:error
source-daemondcd/source-daemon
edit-path[edit interfaces ge-1/0/0]/edit-path
statementunit 0/statement
message invalid encapsulation/message
/xnm:error
error: configuration check-out failed
This issue seems to be really strange as we have it working the 10.x way on
another router. When I configure Ge-1/0/0 as a routed interface it works fine.
Regards,
Tim
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Tim:
Could you please paste in your entire ge-1/0/0 interface and
bridge-domain VLAN200 configuration at the time you do get the commit
error?
Thanks,
Addy.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX80 IRB
Hello,
Tim Vollebregt a écrit (Tue, Jul 27, 2010 at 10:40:54AM +0200) :
I'm getting errors when changing to this configuration. It is only
possible to use encapsulation vlan-bridge on unit 0. And when I
change it to unit 0:
messageVLAN Encapsulation: Not allowed on untagged interfaces/message
/xnm:error
source-daemondcd/source-daemon
edit-path[edit interfaces ge-1/0/0]/edit-path
statementunit 0/statement
message invalid encapsulation/message
/xnm:error
error: configuration check-out failed
This issue seems to be really strange as we have it working the 10.x
way on another router. When I configure Ge-1/0/0 as a routed
interface it works fine.
This configuration is working for us (MX240, 10.1R1.8):
interfaces {
ge-1/0/7 {
flexible-vlan-tagging;
native-vlan-id 1;
encapsulation extended-vlan-bridge;
unit 1 {
vlan-id 1;
family bridge;
}
unit 210 {
vlan-id 210;
family bridge;
}
unit 240 {
vlan-id 240;
family bridge;
}
}
irb {
unit 210 {
family inet {
address x.x.x.x/24;
}
}
unit 240 {
family inet {
address x.x.x.x/23;
address x.x.x.x/24;
}
}
bridge-domains {
VLAN-1 {
domain-type bridge;
vlan-id 1;
interface ge-1/0/7.1;
}
VLAN-210 {
domain-type bridge;
vlan-id 210;
interface ge-1/0/7.210;
routing-interface irb.210;
}
VLAN-240 {
domain-type bridge;
vlan-id 240;
interface ge-1/0/7.240;
routing-interface irb.240;
}
}
HTH,
--
Emmanuel Halbwachs Observatoire de Paris-Meudon
Resp. Réseau/Sécurité 5 Place Jules Janssen
tel : +33 1 45 07 75 54F 92195 MEUDON CEDEX
fax : +33 1 45 07 01 89 véhicules : 11 av. Marcelin Berthelot
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPLS in the Access
On Sat, Jul 24, 2010 at 3:27 AM, Pavel Lunin plu...@senetsy.ru wrote: Another approach can be a large VC ring of EX4200s built with VCE (ethernet) links: http://www.juniper.net/us/en/local/pdf/implementation-guides/8010045-en.pdf Seems to be a reasonable solution when scale of up to 9 nodes in a single ring is OK. First EX4200 is known to be more or less stable (in my experience), second VCCP is actualy ISIS which is way more interesting than most ethernet scaling technologies rooted in LAN. As of my experience, Juniper's VC implementation is rather not bad. Moreover they even announced EX4500 to support virtual chassis some day, but this is too dreamy by now, and no one knows how good EX4500 will be. I think the biggest problem with this approach, is the limit of 24K MAC addresses across the entire VC. This is a problem we'll be running into in the not so distant future - I don't know if CCCs are the right (only?) solution to this. Cheers, Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX80 IRB
On Tue, Jul 27, 2010 at 10:40:54AM +0200, Tim Vollebregt wrote:
I'm getting errors when changing to this configuration. It is only
possible to use encapsulation vlan-bridge on unit 0. And when I
change it to unit 0:
messageVLAN Encapsulation: Not allowed on untagged interfaces/message
/xnm:error
This following commits for me. The point of the exercise is to see if
MPC Trio cards *require* 9.2-style configurations: using separate
logical units for each VLAN, encapsulation vlan-bridge, refer to all
the logical unit interfaces in bridge-domain in order to actually
function. I.e. do they not work with 9.5+ style VLAN Bundles: family
bridge, interface-mode access/trunk, vlan-id-list? In my experience
with testing some new MPC Trio cards, this conclusion is true. A
perfectly working VLAN Bundle bridging configuration on DPC cards
failed miserably when copied over to MPC cards until it was
reconfigured the 9.2 non-VLAN Bundled way.
ge-2/0/1 {
flexible-vlan-tagging;
native-vlan-id 200;
encapsulation flexible-ethernet-services;
unit 200 {
encapsulation vlan-bridge;
vlan-id 200;
}
}
irb {
unit 200 {
family inet {
address 10.11.12.13/24;
}
}
}
VLAN200 {
domain-type bridge;
vlan-id 200;
interface ge-2/0/1.200;
routing-interface irb.200;
}
This issue seems to be really strange as we have it working the 10.x
way on another router. When I configure Ge-1/0/0 as a routed
interface it works fine.
Does the other router where this works have the new MPC Trio cards?
Or is it using the older DPC cards?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX80 IRB
On Tue, Jul 27, 2010 at 03:46:41PM +0200, magno wrote: Today Trio only supports the old style config. in the near future, the new style config will be supported as well. I have several problems with the way Juniper handled this: 1. The configuration commits without any warnings or errors. There is no indication that what you have configured is unsupported. No logs, no alarms, no nothing. 2. I've seen MPCs crash/go into a reboot loop when configuring them the new VLAN Bundle way. (For the OP: do your MPC's go into a reboot loop, alternately showing offline/online under show chassis fpc pic-status?) They should gracefully fail to work when doing something unsupported and make loud noises when you do. 3. Documentation is severely lacking. In the 10.2 Release Notes, no where does it say today Trio only supports JUNOS 9.2 features (except when talking about the MX80 specifically, and some other specific features--nothing about the other Trio cards or about bridging/VLAN Bundles specifically). I've only heard that from statements made by my Juniper reps. Even then, you have to really dig deep in the Network Interfaces guide and Layer 2 Configuration Guide to find references to 9.5+ required on VLAN Bundles and other configuration statements and features. The 10.x Release Notes really ought to say In this release, Trio only supports JUNOS 9.2 features and configurations on the following cards and platforms and then list out *exactly* which hardware and configuration statements this applies to. The rest of the configuration guides ought to have warnings sprinkled throughout saying Not supported on Trio! with pointers to the old way that works on Trio. These warnings should stay in the documentation and Release Notes until the limitations no longer apply. The current situation is a horrible landmine for customers wishing to migrate/upgrade from DPC to Trio, as well as brand new customers like myself who haven't read the 9.2 documentation and earlier Release Notes. Why should I have to go back 7 releases worth of documentation to configure my brand new hardware that is only supported at all under 10.0/10.1 and only supported under 10.2 when mixed with DPC cards? Finally, JTAC/ATAC can't even figure out the above!!! I have a case open and they *still* haven't come to the solution because they haven't realized that Today Trio only supports the old style config and what that really means. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPLS in the Access
I think the biggest problem with this approach, is the limit of 24K MAC addresses across the entire VC. This is a problem we'll be running into in the not so distant future - I don't know if CCCs are the right (only?) solution to this. Right. This scheme has quite appreciable scaling limits. If the next tier is DSLAM/MSAN for residential broadband, the avg of 100 MACs per port (even a bit higher since you most probably not use all 24 ports on the two 'centeral' boxes) seems normal. If you connect business customers right to the VC ring, this is not that bad as well, though not an infinity. But if you want the next tier of access switches where you aggregate the customers' links (say another x24), well, this can be a problem: 24k/240/24 = just 4 MACs per port or 8 if you use LAG to connect those switches to different VC-members. So if you want to provide multipoint L2 services for business customers, most probably this is not enough in such a 2-tier case. CCC is a solution but VC losses half of its benefits, if you add the second tier here. Anyway adding another tier of cheap switches here seems to be a way to get the old good switching garbage. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
