Re: [j-nsp] Independent /32s for Interfaces - anybody doing that?

[Chris Kawchuk]

Just to add to this

On 31 May 2016, at 9:31 pm, Vincent Bernat  wrote:

> Unfortunately, the support vary widely accross vendors. I believe the
> support is pretty good with Cisco. With Juniper, it really depends on
> the equipment. The MX has pretty good support, but has some limitations
> (for example, static BFD + unnumbered doesn't work). 


Doing ip-unnumbered/OSPF on interfaces and also enabling LDP in the interface 
-- every now and then the LDP doesn't survive reboot, and have to "kick" (clear 
ldp neighbors) the LDP sessions for inet.3 to correctly populate on the box 
once OSPF is back up and established. It's once of the reasons I have never 
widely deployed using ip-unnumbered w/OSPF and MPLS in anything other than my 
lab environments. Happened on 13.x through 15.x on MX80 and MX480s with various 
RE's and SCBs/SCBEs. Never got around to opening a PR on this though...

Agreed is great for lab and quick prototyping so I don't have to fiddle around 
with assigning /30s and /31s when Im trying to do something higher-layer 
(L3VPN/VPLS/eVPN/iBGP/etc..)

Juniper produced a J-Learn called "MPLS Plug and Play for Metro Ethernet" 
(google for it) from many years ago (2007) which explicitly showed how to setup 
your devices to automatically create an IGP/MPLS/LDP mesh in a metro (for 
L2CKTs)...although it works for any topology of your choice.  Heavily uses the 
ip-unnubered and the lo0.0 inheritance schemes discussed in this thread; so 
should be widely supported if they were pushing this

- CK.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Independent /32s for Interfaces - anybody doing that?

[v]

Now I understand - thank you very much for your explanations!

Am 2016-05-31 um 13:31 schrieb Vincent Bernat:

  ❦ 31 mai 2016 13:12 CEST, v  :


I just read about using independent /32 addresses for interfaces and I
would like to know whether anybody uses that. Found the following
information about such a configuration:
-This means that there is no relation between the addresses on the two ends of 
an interface
-This relies on the IGP to provide this relationship
-This significantly reduces the burden of address management and synchronization
-Also, reconfiguration of topology is much easier

Are there more pros and cons than that?
Does anyone have experience with such a configuration?

Hi!

I believe that you are talking about unnumbered interfaces: you put a
/32 on a loopback and you tell other interfaces to use the loopback
address. For example:

interfaces {
 lo0 {
 unit 1 {
 family inet {
 address 203.0.113.3/32;
 }
 }
 }
 ge-0/0/1 {
 unit 0 {
 family inet {
 unnumbered-address lo0.1;
 }
 }
 }
 ge-0/0/2 {
 unit 0 {
 family inet {
 unnumbered-address lo0.1;
 }
 }
 }
}

I find this scheme very convienent:

  1. You can use only one public IP address for the whole equipment.

  2. You have less configuration to do and this is less error-prone. An
 IGP like OSPF would make each router discover the addresses of all
 other routers automatically.

Unfortunately, the support vary widely accross vendors. I believe the
support is pretty good with Cisco. With Juniper, it really depends on
the equipment. The MX has pretty good support, but has some limitations
(for example, static BFD + unnumbered doesn't work). The QFX doesn't
support unnumbered interfaces in various places (like for example, on an
IRB interface). From what I have been told, Juniper has no plan to fix
that. Cumulus supports them too (but I can't testify on the completeness
of the support). Other vendors may have no support at all for this, so
you get into some kind of vendor-lockin if you rely on this.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Independent /32s for Interfaces - anybody doing that?

[Vincent Bernat]

 ❦ 31 mai 2016 13:12 CEST, v  :

> I just read about using independent /32 addresses for interfaces and I
> would like to know whether anybody uses that. Found the following
> information about such a configuration:
> -This means that there is no relation between the addresses on the two ends 
> of an interface
> -This relies on the IGP to provide this relationship
> -This significantly reduces the burden of address management and 
> synchronization
> -Also, reconfiguration of topology is much easier
>
> Are there more pros and cons than that?
> Does anyone have experience with such a configuration?

Hi!

I believe that you are talking about unnumbered interfaces: you put a
/32 on a loopback and you tell other interfaces to use the loopback
address. For example:

interfaces {
lo0 {
unit 1 {
family inet {
address 203.0.113.3/32;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
unnumbered-address lo0.1;
}
}
}
ge-0/0/2 {
unit 0 {
family inet {
unnumbered-address lo0.1;
}
}
}
}

I find this scheme very convienent:

 1. You can use only one public IP address for the whole equipment.

 2. You have less configuration to do and this is less error-prone. An
IGP like OSPF would make each router discover the addresses of all
other routers automatically.

Unfortunately, the support vary widely accross vendors. I believe the
support is pretty good with Cisco. With Juniper, it really depends on
the equipment. The MX has pretty good support, but has some limitations
(for example, static BFD + unnumbered doesn't work). The QFX doesn't
support unnumbered interfaces in various places (like for example, on an
IRB interface). From what I have been told, Juniper has no plan to fix
that. Cumulus supports them too (but I can't testify on the completeness
of the support). Other vendors may have no support at all for this, so
you get into some kind of vendor-lockin if you rely on this.
-- 
Program defensively.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Independent /32s for Interfaces - anybody doing that?

[Mark Tinka]

On 31/May/16 13:12, v wrote:

> Hello,
>
> I just read about using independent /32 addresses for interfaces and I
> would like to know whether anybody uses that. Found the following
> information about such a configuration:
> -This means that there is no relation between the addresses on the two
> ends of an interface
> -This relies on the IGP to provide this relationship
> -This significantly reduces the burden of address management and
> synchronization
> -Also, reconfiguration of topology is much easier
>
> Are there more pros and cons than that?
> Does anyone have experience with such a configuration?

For your Loopback interface.

Think of it as a unique way to identify every device in your network,
regardless of the forwarding path taken to get to it.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Independent /32s for Interfaces - anybody doing that?

[v]

Hello,

I just read about using independent /32 addresses for interfaces and I would 
like to know whether anybody uses that. Found the following information about 
such a configuration:
-This means that there is no relation between the addresses on the two ends of 
an interface
-This relies on the IGP to provide this relationship
-This significantly reduces the burden of address management and synchronization
-Also, reconfiguration of topology is much easier

Are there more pros and cons than that?
Does anyone have experience with such a configuration?

Regards,
v
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX 3400 maximum number of concurrent NAT sessions

[Matt Bernstein via juniper-nsp]

On 31/05/2016 09:02, Adam Vitkovsky wrote:

I’d like to confirm whether I’m looking at the right number.
I’d like to understand the limitations of  a SRX3400 in terms of maximum number 
of concurrent NAT sessions.

Datasheet lists:
Maximum concurrent sessions 2.25 (3 million with Additional Extreme License).
I think the datasheets assume a full complement of SPCs--four in the 
case of the SRX3400, which scales up to 3.5m sessions in theory (it's 1m 
per SPC, but the first 0.5m are reserved for system overhead). Not sure 
what else in the system caps it to 2.25m/3m, and I can't comment 
specifically on NAT sessions, sorry.


Matt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] SRX 3400 maximum number of concurrent NAT sessions

[Adam Vitkovsky]

Hi folks,

I’d like to confirm whether I’m looking at the right number.
I’d like to understand the limitations of  a SRX3400 in terms of maximum number 
of concurrent NAT sessions.

Datasheet lists:
Maximum concurrent sessions 2.25 (3 million with Additional Extreme License).


show security flow cp-session summary
node0:
--
Maximum sessions: 2359296

However on this output I see only 500K on (SPU Cp-Flow) and 1M+ on (SPU Flow):
> show security flow session summary
node0:
--
Flow Sessions on FPC1 PIC0:
Maximum-sessions: 524288 <<<
Flow Sessions on FPC2 PIC0:
Maximum-sessions: 1048576


So is it actually good for 2M or just 1.5 concurrent NAT sessions please?
I'd appreciate any pointers
Thank you.


adam








Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp