Re: [j-nsp] cgnat on service module - interesting bgp advertisements

[Aaron]

Sure Tim, …where in the world are those statics coming from ??

 

agould@eng-lab-mx104-cgn> show route table one.inet.0 | grep 1.2.3.

1.2.3.129/32*[Static/1] 02:57:02

1.2.3.130/31*[Static/1] 02:57:02

1.2.3.132/30*[Static/1] 02:57:02

1.2.3.136/29*[Static/1] 02:57:02

1.2.3.144/28*[Static/1] 02:57:02

1.2.3.160/27*[Static/1] 02:57:02

1.2.3.192/27*[Static/1] 02:57:02

1.2.3.224/28*[Static/1] 02:57:02

1.2.3.240/29*[Static/1] 02:57:02

1.2.3.248/30*[Static/1] 02:57:02

1.2.3.252/31*[Static/1] 02:57:02

1.2.3.254/32*[Static/1] 02:57:02

 

agould@eng-lab-mx104-cgn>

 

agould@eng-lab-mx104-cgn> show route table one.inet.0 protocol bgp | grep 1.2.3.

 

agould@eng-lab-mx104-cgn>

 

agould@eng-lab-mx104-cgn>

 

agould@eng-lab-mx104-cgn> show configuration routing-instances one | display set

set routing-instances one instance-type vrf

set routing-instances one interface ms-1/0/0.2

set routing-instances one route-distinguisher 10.101.12.243:1

set routing-instances one vrf-target import target:1:1

set routing-instances one vrf-target export target:1:1

set routing-instances one vrf-table-label

 

agould@eng-lab-mx104-cgn>

 

agould@eng-lab-mx104-cgn> show configuration protocols bgp | display set

set protocols bgp group my-ibgp type internal

set protocols bgp group my-ibgp local-address 10.101.12.243

set protocols bgp group my-ibgp neighbor 10.101.0.2 family inet-vpn unicast

 

agould@eng-lab-mx104-cgn>

 

agould@eng-lab-mx104-cgn> show configuration policy-options

 

agould@eng-lab-mx104-cgn>

 

 

From: Tim Jackson [mailto:jackson@gmail.com] 
Sent: Tuesday, April 19, 2016 7:01 PM
To: Aaron 
Cc: jnsp 
Subject: Re: [j-nsp] cgnat on service module - interesting bgp advertisements

 

Mind pasting your show route for those routes and your export policy?

On Apr 19, 2016 6:48 PM, "Aaron"  > 
wrote:

Very interesting. anyone know why this is happening ?  Is this documented ?
I put a /25 as the public nat pool, but look what this mx104 is advertising
via bgp.. It appears to chop up that /25 into a bunch of smaller subnets and
advertise those out





agould@eng-lab-mx104-cgn> show configuration | grep 1.2.3. | display set

set services nat pool nat1 address 1.2.3.128/25  





agould@eng-lab-mx104-cgn> show route advertising-protocol bgp 10.101.0.2
table one.inet.0



one.inet.0: 782 destinations, 970 routes (782 active, 0 holddown, 0 hidden)

  Prefix  Nexthop  MED LclprefAS path

* 10.144.2.4/30 Self 
100I

* 1.2.3.129/32   Self 100  
  I

* 1.2.3.130/31   Self 100  
  I

* 1.2.3.132/30   Self 100  
  I

* 1.2.3.136/29   Self 100  
  I

* 1.2.3.144/28   Self 100  
  I

* 1.2.3.160/27   Self 100  
  I

* 1.2.3.192/27   Self 100  
  I

* 1.2.3.224/28   Self 100  
  I

* 1.2.3.240/29   Self 100  
  I

* 1.2.3.248/30   Self 100  
  I

* 1.2.3.252/31   Self 100  
  I

* 1.2.3.254/32   Self 100  
  I





Aaron



___
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] cgnat on service module - interesting bgp advertisements

[Tim Jackson]

Mind pasting your show route for those routes and your export policy?
On Apr 19, 2016 6:48 PM, "Aaron"  wrote:

> Very interesting. anyone know why this is happening ?  Is this documented ?
> I put a /25 as the public nat pool, but look what this mx104 is advertising
> via bgp.. It appears to chop up that /25 into a bunch of smaller subnets
> and
> advertise those out
>
>
>
>
>
> agould@eng-lab-mx104-cgn> show configuration | grep 1.2.3. | display set
>
> set services nat pool nat1 address 1.2.3.128/25
>
>
>
>
>
> agould@eng-lab-mx104-cgn> show route advertising-protocol bgp 10.101.0.2
> table one.inet.0
>
>
>
> one.inet.0: 782 destinations, 970 routes (782 active, 0 holddown, 0 hidden)
>
>   Prefix  Nexthop  MED LclprefAS path
>
> * 10.144.2.4/30   Self 100I
>
> * 1.2.3.129/32 Self 100I
>
> * 1.2.3.130/31 Self 100I
>
> * 1.2.3.132/30 Self 100I
>
> * 1.2.3.136/29 Self 100I
>
> * 1.2.3.144/28 Self 100I
>
> * 1.2.3.160/27 Self 100I
>
> * 1.2.3.192/27 Self 100I
>
> * 1.2.3.224/28 Self 100I
>
> * 1.2.3.240/29 Self 100I
>
> * 1.2.3.248/30 Self 100I
>
> * 1.2.3.252/31 Self 100I
>
> * 1.2.3.254/32 Self 100I
>
>
>
>
>
> Aaron
>
>
>
> ___
> 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

[j-nsp] cgnat on service module - interesting bgp advertisements

[Aaron]

Very interesting. anyone know why this is happening ?  Is this documented ?
I put a /25 as the public nat pool, but look what this mx104 is advertising
via bgp.. It appears to chop up that /25 into a bunch of smaller subnets and
advertise those out

 

 

agould@eng-lab-mx104-cgn> show configuration | grep 1.2.3. | display set

set services nat pool nat1 address 1.2.3.128/25

 

 

agould@eng-lab-mx104-cgn> show route advertising-protocol bgp 10.101.0.2
table one.inet.0

 

one.inet.0: 782 destinations, 970 routes (782 active, 0 holddown, 0 hidden)

  Prefix  Nexthop  MED LclprefAS path

* 10.144.2.4/30   Self 100I

* 1.2.3.129/32 Self 100I

* 1.2.3.130/31 Self 100I

* 1.2.3.132/30 Self 100I

* 1.2.3.136/29 Self 100I

* 1.2.3.144/28 Self 100I

* 1.2.3.160/27 Self 100I

* 1.2.3.192/27 Self 100I

* 1.2.3.224/28 Self 100I

* 1.2.3.240/29 Self 100I

* 1.2.3.248/30 Self 100I

* 1.2.3.252/31 Self 100I

* 1.2.3.254/32 Self 100I

 

 

Aaron

 

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

Re: [j-nsp] VPLS and IRB

[Chuck Anderson]

On Wed, Apr 20, 2016 at 01:14:17AM +0200, j...@czmok.de wrote:
> Hi,
> 
> i am looking for the following solution:
> 
> - SITE A - VPLS SITE 1
> - SITE B - VPLS SITE 2
> 
> On Site A i receive on ae0. Traffic which is tagged with VLAN 
> On Site B i want to provide a Layer3 Interface which provides 
> Layer3-Termination of VLAN
> Between Site A and Site B i want to use vpls

> on SITE b:
> 
> TEST {
> instance-type virtual-switch;
> route-distinguisher 1.2.3.5:;
> vrf-target target::;
> protocols {
> vpls {
> site-range 3;
> no-tunnel-services;
> site B {
> site-identifier 1;
> }
> }
> }
> bridge-domains {
> vlan {
> vlan-id ;
> routing-interface irb.;
> }
> }
> }

Don't use a virtual-switch, just use a regular vpls instance, and add
a routing-interface irb..  Addionally use connectivity-type irb so
the VPLS instance stays up even with no physical ports in it:

TEST {
instance-type vpls;
route-distinguisher 1.2.3.5:;
vrf-target target::;
routing-interface irb.;
protocols {
vpls {
site-range 3;
no-tunnel-services;
site B {
site-identifier 1;
}
connectivity-type irb;
}
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VPLS and IRB

[Chris Kawchuk]

Add connectivity-type irb; to the vpls {} stanza.

i.e. at [edit routing-instances TEST protocols vpls]


"Specifies when a VPLS connection is taken down depending on whether or not the 
interface for the VPLS routing instance is customer-facing or integrated 
routing and bridging (IRB)..."

ce (default)—   Require that for the VPLS connection to be up, the 
customer-facing interface for the VPLS routing instance must also be up. If the 
customer-facing interface fails, the VPLS connection is taken down.

irb —   Allow a VPLS connection to remain up so long as an IRB 
interface is configured for the VPLS routing instance.

permanent   —   Allow a VPLS connection to remain up until specifically 
taken down.


http://www.juniper.net/documentation/en_US/junos15.1/topics/reference/configuration-statement/connectivity-type-edit-protocols-vpls.html



On 20 Apr 2016, at 9:14 am, j...@czmok.de wrote:

> TEST {
>instance-type virtual-switch;
>route-distinguisher 1.2.3.5:;
>vrf-target target::;
>protocols {
>vpls {
>site-range 3;
>no-tunnel-services;
>site B {
>site-identifier 1;
>}
>}
>}
>bridge-domains {
>vlan {
>vlan-id ;
>routing-interface irb.;
>}
>}
> }

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

[j-nsp] VPLS and IRB

[j...@czmok.de]

Hi,

i am looking for the following solution:

- SITE A - VPLS SITE 1
- SITE B - VPLS SITE 2

On Site A i receive on ae0. Traffic which is tagged with VLAN 
On Site B i want to provide a Layer3 Interface which provides 
Layer3-Termination of VLAN
Between Site A and Site B i want to use vpls

I’m struggling with the irb setup on site B, site A seems easy:

TEST {
instance-type vpls;
interface ae0.1;
route-distinguisher 1.2.3.4:;
vrf-target target::;
protocols {
vpls {
site-range 3;
no-tunnel-services;
site A {
site-identifier 2;
interface ae0.;
}
}
}
}

on SITE b:

TEST {
instance-type virtual-switch;
route-distinguisher 1.2.3.5:;
vrf-target target::;
protocols {
vpls {
site-range 3;
no-tunnel-services;
site B {
site-identifier 1;
}
}
}
bridge-domains {
vlan {
vlan-id ;
routing-interface irb.;
}
}
}

and irb. has
family inet address 2.3.2.1/24;


thoughts ? irb. seems “hardware-down”

jc@siteB# run show interfaces irb. 
  Logical interface irb.4001 (Index 364) (SNMP ifIndex 662)
Flags: Hardware-Down Up SNMP-Traps 0x0 Encapsulation: ENET2
Bandwidth: 1000mbps
Routing Instance: TEST Bridging Domain: vlan+
 
Thanks for any help



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

Re: [j-nsp] ACX5048 - vlan-map conflict with routing-instance with vlan-id tags

[Daniel Verlouw]

Hi Aaron,

On Tue, Apr 19, 2016 at 10:43 PM, Aaron  wrote:
> Goal, to do tagging on ge-0/0/38 for 802.1q vlan tags of 10 and 17 and also,
> put those tagged frames into the SAME vlan/bridge-domain so that they can
> use the same ip subnet on the irb.10 interface that sits atop that vlan.

if memory serves me well, you can simply leave out the
input-/output-vlan-map from the interface config. It will
automatically be normalized to the vlan-id specified under your [edit
vlans vlan10] config. Check with 'show int extensive' and you should
see an implicit vlan swap operation. Or; remove the vlan-id and
explicitly define an input-/output-vlan-map on all interfaces part of
this bridge domain.

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

Re: [j-nsp] ACX5048 - vlan-map conflict with routing-instance with vlan-id tags

[Aaron]

Please forgive the mess in the previous copy/paste, hopefully this is
clearer...



agould@eng-lab-5048-1# show | compare
[edit interfaces]
+   ge-0/0/38 {
+   flexible-vlan-tagging;
+   encapsulation flexible-ethernet-services;
+   unit 17 {
+   encapsulation vlan-bridge;
+   vlan-id 17;
+   input-vlan-map {
+   swap;
+   vlan-id 10;
+   }
+   output-vlan-map swap;
+   }
+   }
[edit vlans vlan10]
 interface ae6.10 { ... }
+interface ge-0/0/38.17;
{master:0}[edit]

agould@eng-lab-5048-1#
{master:0}[edit]

agould@eng-lab-5048-1# commit
[edit vlans vlan10 interface]
  'ge-0/0/38.17'
interface with input/output vlan-maps cannot be added to a
routing-instance with a vlan-id/vlan-tags configured
error: commit failed: (statements constraint check failed)
{master:0}[edit]

agould@eng-lab-5048-1# show vlans vlan10
vlan-id 10;
interface ae5.10;
interface ae6.10;
##
## Warning: interface with input/output vlan-maps cannot be added to a
routing-instance with a vlan-id/vlan-tags configured
##
interface ge-0/0/38.17;
l3-interface irb.10;
{master:0}[edit]

agould@eng-lab-5048-1# rollback
load complete
{master:0}[edit]

agould@eng-lab-5048-1#
 



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

Re: [j-nsp] QFX10002 as P Router

[Nitzan Tzelniker]

First Juniper MX doesn't use VoQ

For the QFX10K  it use eight ingress queue per output port as described here

http://www.juniper.net/documentation/en_US/junos15.1/topics/concept/cos-qfx-series-voq-understanding.html

Nitzan

On Tue, Apr 19, 2016 at 3:31 PM, Adam Vitkovsky 
wrote:

> > Nitzan Tzelniker
> > Sent: Saturday, April 16, 2016 8:22 PM
> >
> > 1. Same performance 500G
> > 2. Same memory technology (3d memory architecture ) 3. Both use Virtual
> > output Queue 4. Both announce on the same day
> >
> Well MXes also have VOQs and... :)
> What is important is how granular the VOQs are. (not mentioning other QOS
> system design choices that are crucial for a core box in a converged
> network).
> PTXes have VOQ for of each of the 8 egress port queues -which is to my
> knowledge the best granularity out there.
> Does QFX have the same?
>
> *by a converged network I mean one that carries traffic of different
> priorities.
>
> 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

[j-nsp] ACX5048 - vlan-map conflict with routing-instance with vlan-id tags

[Aaron]

Goal, to do tagging on ge-0/0/38 for 802.1q vlan tags of 10 and 17 and also,
put those tagged frames into the SAME vlan/bridge-domain so that they can
use the same ip subnet on the irb.10 interface that sits atop that vlan.

 

Getting errors, anyone know how to resolve please ?  ACX5048

 

Aaron

 

 

 
 agould@eng-lab-5048-1# show | compare
[edit interfaces]
+   ge-0/0/38 {
+   flexible-vlan-tagging;
+   encapsulation flexible-ethernet-services;
+   unit 17 {
+   encapsulation vlan-bridge;
+   vlan-id 17;
+   input-vlan-map {
+   swap;
+   vlan-id 10;
+   }
+   output-vlan-map swap;
+   }
+   }
[edit vlans vlan10]
 interface ae6.10 { ... }
+interface ge-0/0/38.17;

{master:0}[edit]



 
 agould@eng-lab-5048-1#

{master:0}[edit]

 

 
 agould@eng-lab-5048-1# commit
[edit vlans vlan10 interface]
  'ge-0/0/38.17'
interface with input/output vlan-maps cannot be added to a
routing-instance with a vlan-id/vlan-tags configured
error: commit failed: (statements constraint check failed)

{master:0}[edit]

 

 

 
 agould@eng-lab-5048-1# show vlans
vlan10
vlan-id 10;
interface ae5.10;
interface ae6.10;
##
## Warning: interface with input/output vlan-maps cannot be added to a
routing-instance with a vlan-id/vlan-tags configured
##
interface ge-0/0/38.17;
l3-interface irb.10;

{master:0}[edit]



 
 agould@eng-lab-5048-1# rollback
load complete

{master:0}[edit]
 
 agould@eng-lab-5048-1#

 

 

 

 

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

Re: [j-nsp] Cisco vs Juniper confused

[Roland Dobbins]

On 19 Apr 2016, at 18:52, Dave Bell wrote:


Sacrifice the connectivity to one customer to save the rest.


If that's the only viable option in a given situation, sure.

But it's nice to have choices; S/RTBH and flowspec provide additional 
capabilities which don't necessarily include completing the attack on 
behalf of the miscreants.


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

Re: [j-nsp] Cisco vs Juniper confused

[Roland Dobbins]

On 16 Apr 2016, at 23:25, Satish Patel wrote:


We are seeing attack all over the world, how you will stop them using
source blackholing?


It is a tool in the toolbox.  It is very effective in certain scenarios 
as a) it runs at wire-speed on the routers, b) can handle tens of 
thousands (if not more) of sources, and c) a great deal of large-scale 
attacks such as UDP reflection/amplification attacks aren't spoofed from 
the perspective of the attack target.


These day most of people use opendns and chargen style spoofing 
attack.


#1, this is incorrect.  It isn't wise to generalize based solely upon 
your own *perceived* experiences (which may be incomplete for various 
reasons).


#2, as noted above, UDP reflection/amplification attacks aren't spoofed 
on the reflector/amplifier-target leg of the attack.  While you 
obviously wouldn't S/RTBH OpenDNS, you can S/RTBH lots of other attack 
sources.


I've been using S/RTBH operationally for many years, and helping others 
do the same.  It's another tool in the toolbox, and can be a very useful 
one, when utilized appropriately.


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

Re: [j-nsp] Cisco vs Juniper confused

[Payam Chychi]

A lot can be done using dscp/qos + PBR + BGP and a decent mitigation 
segment (PCRE/suricata/bro ids)




On 2016-04-19, 4:52 AM, Dave Bell wrote:

You use destination black holing. Sacrifice the connectivity to one
customer to save the rest.

On 16 April 2016 at 17:25, Satish Patel  wrote:


We are seeing attack all over the world, how you will stop them using
source blackholing? These day most of people use opendns and chargen
style spoofing attack.

On Sat, Apr 16, 2016 at 10:53 AM, Roland Dobbins 
wrote:

On 16 Apr 2016, at 19:22, Satish Patel wrote:


also in DDoS S/RTBH not handy.

Incorrect.

---
Roland Dobbins 
___
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


___
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] QFX10002 as P Router

[Adam Vitkovsky]

> Nitzan Tzelniker
> Sent: Saturday, April 16, 2016 8:22 PM
>
> 1. Same performance 500G
> 2. Same memory technology (3d memory architecture ) 3. Both use Virtual
> output Queue 4. Both announce on the same day
>
Well MXes also have VOQs and... :)
What is important is how granular the VOQs are. (not mentioning other QOS 
system design choices that are crucial for a core box in a converged network).
PTXes have VOQ for of each of the 8 egress port queues -which is to my 
knowledge the best granularity out there.
Does QFX have the same?

*by a converged network I mean one that carries traffic of different priorities.

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

Re: [j-nsp] Cisco vs Juniper confused

[Dave Bell]

You use destination black holing. Sacrifice the connectivity to one
customer to save the rest.

On 16 April 2016 at 17:25, Satish Patel  wrote:

> We are seeing attack all over the world, how you will stop them using
> source blackholing? These day most of people use opendns and chargen
> style spoofing attack.
>
> On Sat, Apr 16, 2016 at 10:53 AM, Roland Dobbins 
> wrote:
> > On 16 Apr 2016, at 19:22, Satish Patel wrote:
> >
> >> also in DDoS S/RTBH not handy.
> >
> > Incorrect.
> >
> > ---
> > Roland Dobbins 
> > ___
> > 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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco vs Juniper confused

[Adam Vitkovsky]

> Rolf Hanßen
> Sent: Saturday, April 16, 2016 2:05 PM
>
> Hi,
>
> just an idea for networks with small budget that do not want to blackhole the
> destination but also do not want attack traffic to enter their
> network:
>
> Rent 1 additional ports from each upstream provider and convince the
> upstream provider to accept /32 routes without exporting them (I know not
> all will do this, this may be the hardest part of the whole szenario).
> Connect all those ports to a single Layer3 switch like a EX4550 or even 
> smaller.
>
> Connect some cheap mitigation solution like Wanguard to it (don't know if
> similar software exists from other vendors).
But for this to scrub and not black hole legit traffic destined for the 
customer the pipes all the way to Wanguard solution public ports would have to 
be the size of the primary upstream links.
So I guess it boils down to what is cheaper whether buying extra links from 
each of your transit providers or buying scrubbing services from one of them.


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

Re: [j-nsp] MPLS L2VPN Cisco and Juniper

[Mohammad Khalil]

Thanks Mark
I just want to check if the configuration I pasted do work (actually am
testing this in GNS3 and am not sure if it will work due to limitations)

On Tue, Apr 19, 2016 at 10:11 AM, Mark Tinka  wrote:

>
>
> On 19/Apr/16 08:59, Mohammad Khalil wrote:
>
> > Hi Mark
> > Yes am aware dear , but what made me confused that I read some
> > inter-operability issues in one of the forums
> > What my customer needs is to build generally l2 VPN circuit and he is
> > wondering which to follow
> > The main setup is ASR9K and MX which are running in different ASs , so
> > what inter-as option will be the more scalable and is there any
> > limitation from the ASR9K line card ?
>
> If you're doing straight LDP-based EoMPLS pw's, then this is vanilla.
>
> If you're doing BGP-based EoMPLS pw's that are not VPLS/EVPN, I know
> this is what Juniper call(ed) L2VPN. Cisco did not support this back in
> the day, but since they now support BGP AD for VPLS/EVPN, there might be
> support for this; I'm not sure.
>
> The only time we consider signaling pw's via BGP is if we're doing VPLS
> or EVPN, not point-to-point circuits.
>
> Mark.
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MPLS L2VPN Cisco and Juniper

[Mark Tinka]

On 19/Apr/16 08:59, Mohammad Khalil wrote:

> Hi Mark
> Yes am aware dear , but what made me confused that I read some
> inter-operability issues in one of the forums
> What my customer needs is to build generally l2 VPN circuit and he is
> wondering which to follow
> The main setup is ASR9K and MX which are running in different ASs , so
> what inter-as option will be the more scalable and is there any
> limitation from the ASR9K line card ?

If you're doing straight LDP-based EoMPLS pw's, then this is vanilla.

If you're doing BGP-based EoMPLS pw's that are not VPLS/EVPN, I know
this is what Juniper call(ed) L2VPN. Cisco did not support this back in
the day, but since they now support BGP AD for VPLS/EVPN, there might be
support for this; I'm not sure.

The only time we consider signaling pw's via BGP is if we're doing VPLS
or EVPN, not point-to-point circuits.

Mark.

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

Re: [j-nsp] MPLS L2VPN Cisco and Juniper

[Mohammad Khalil]

Hi Mark
Yes am aware dear , but what made me confused that I read some
inter-operability issues in one of the forums
What my customer needs is to build generally l2 VPN circuit and he is
wondering which to follow
The main setup is ASR9K and MX which are running in different ASs , so what
inter-as option will be the more scalable and is there any limitation from
the ASR9K line card ?

BR,

On Tue, Apr 19, 2016 at 9:47 AM, Mark Tinka  wrote:

>
>
> On 19/Apr/16 08:42, Mohammad Khalil wrote:
> > Thanks a lot Aaron , much appreciated
> > So , VPLS (Cisco term) is operable with Juniper
> > Now , the l2circuit configuration I posted is functional ?
> > Because I want to propose my customers all options :)
>
> VPLS is not a Cisco-specific term.
>
> Cisco's AToM EoMPLS (x-connect) is equivalent to Juniper's l2circuit.
>
> Mark.
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MPLS L2VPN Cisco and Juniper

[Mark Tinka]

On 19/Apr/16 08:42, Mohammad Khalil wrote:
> Thanks a lot Aaron , much appreciated
> So , VPLS (Cisco term) is operable with Juniper
> Now , the l2circuit configuration I posted is functional ?
> Because I want to propose my customers all options :)

VPLS is not a Cisco-specific term.

Cisco's AToM EoMPLS (x-connect) is equivalent to Juniper's l2circuit.

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

Re: [j-nsp] MPLS L2VPN Cisco and Juniper

[Mohammad Khalil]

Thanks a lot Aaron , much appreciated
So , VPLS (Cisco term) is operable with Juniper
Now , the l2circuit configuration I posted is functional ?
Because I want to propose my customers all options :)

BR,
Mohammad

On Mon, Apr 18, 2016 at 10:27 PM, Aaron  wrote:

> you didn't tell me whether you wanted rfc4761 or rfc4762, so i'm giving
> you both of my scenario notes...make sure you prove this out before going
> live with it.  These were my notes from when I tested this in my lab last
> year…  hopefully I didn’t leave to much out and you can make sense of this…
>
>
>
> - Aaron
>
>
>
> 
>
> RFC4761 VPLS - BGP AD w/BGP Sig
>
>
>
> * MX104---
>
>
>
> set interfaces ge-1/3/2 encapsulation ethernet-vpls
>
>
>
> set interfaces ge-1/3/2 unit 0 family vpls
>
>
>
> set protocols mpls interface ge-1/3/0.0
>
>
>
> set protocols ldp interface ge-1/3/0.0
>
>
>
> set protocols ldp interface lo0.0
>
>
>
> set protocols bgp group ibgp type internal
>
>
>
> set protocols bgp group ibgp local-address 10.101.12.248
>
>
>
> set protocols bgp group ibgp family inet-vpn unicast
>
>
>
> set protocols bgp group ibgp family l2vpn signaling
>
>
>
> set protocols bgp group ibgp neighbor 10.101.0.254 local-as 64512
>
>
>
> set routing-instance vlan100 instance-type vpls
>
>
>
> set routing-instance vlan100 interface ge-1/3/2.0
>
>
>
> set routing-instance vlan100 route-distinguisher 10.101.12.248:32768
>
>
>
> set routing-instance vlan100 vrf-target target:65535:10100
>
>
>
> set routing-instance vlan100 protocols vpls
>
>
>
> set routing-instance vlan100 protocols vpls site-range 8
>
>
>
> set routing-instance vlan100 protocols vpls no-tunnel-service
>
>
>
> set routing-instance vlan100 protocols vpls site my_site site-identifier 2
>
>
>
> set routing-instance vlan100 protocols vpls site my_site interface
> ge-1/3/2.0
>
>
>
>
>
> ** ASR9k---
>
>
>
> (i don't show port config with efp and into bridge domain)
>
>
>
> (also shown are inet and inet6 af's (what cisco calls vpnv4 and vpnv6, i
> don't think those were really needed for this vpls lab...)
>
>
>
> router bgp 64512
>
>
>
> neighbor-group rr-clients-l2vpn_4761-vpnv4-and-6
>
>
>
>   remote-as 64512
>
>
>
>   update-source Loopback0
>
>
>
>   address-family vpnv4 unicast
>
>
>
>   address-family vpnv6 unicast
>
>
>
>   address-family l2vpn vpls-vpws
>
>
>
>Signalling ldp disable
>
>
>
> neighbor 10.101.12.248
>
>
>
>   use neighbor-group rr-clients-l2vpn_4761-vpnv4-and-6
>
> l2vpn
>
>
>
> autodiscovery bgp
>
>
>
>   signaling-protocol bgp
>
>
>
>mtu mismatch ignore
>
>
>
> bridge group v100
>
>
>
>   bridge-domain v100
>
>
>
>vfi v100
>
>
>
> vpn-id 10100
>
>
>
> autodiscovery bgp
>
>
>
>  rd auto
>
>
>
>  route-target import 65535:10100
>
>
>
>  route-target export 65535:10100
>
>
>
>  signaling-protocol bgp
>
>
>
>   ve-id 5
>
>
>
>   ve-range 11
>
>
>
>
>
> 
>
> RFC4762 VPLS - BGP AD w/LDP Sig
>
>
>
> * MX104---
>
>
>
> set interfaces ge-1/3/2 encapsulation ethernet-vpls
>
>
>
> set interfaces ge-1/3/2 unit 0 family vpls
>
>
>
> set protocols mpls interface ge-1/3/0.0
>
>
>
> set protocols ldp interface ge-1/3/0.0
>
>
>
> set protocols ldp interface lo0.0
>
>
>
> set protocols bgp group ibgp type internal
>
>
>
> set protocols bgp group ibgp local-address 10.101.12.248
>
>
>
> set protocols bgp group ibgp family inet-vpn unicast
>
>
>
> set protocols bgp group ibgp family l2vpn auto-discovery-only
>
>
>
> set protocols bgp group ibgp neighbor 10.101.0.254 local-as 64512
>
>
>
> set routing-instances vlan100 instance-type vpls
>
>
>
> set routing-instances vlan100 interface ge-1/3/2.0
>
>
>
> set routing-instances vlan100 route-distinguisher 10.101.12.248:32768
>
>
>
> set routing-instances vlan100 l2vpn-id l2vpn-id:65535:10100
>
>
>
> set routing-instances vlan100 vrf-target target:65535:10100
>
>
>
> set routing-instances vlan100 protocols vpls no-tunnel-services
>
>
>
> ** ASR9k---
>
>
>
> (i don't show port config with efp and into bridge domain)
>
>
>
> (also shown are inet and inet6 af's (what cisco calls vpnv4 and vpnv6, i
> don't think those were really needed for this vpls lab...)
>
>
>
> router bgp 64512
>
>
>
> neighbor-group rr-clients-l2vpn_4762-vpnv4-and-6
>
>
>
>   remote-as 64512
>
>
>
>   update-source Loopback0
>
>
>
>   address-family vpnv4 unicast
>
>
>
>   address-family vpnv6 unicast
>
>
>
>   address-family l2vpn vpls-vpws
>
>
>
> neighbor 10.101.12.248
>
>
>
>   use neighbor-group rr-clients-l2vpn_4762-vpnv4-and-6
>
>
>
> l2vpn
>
>
>
> bridge group v100
>
>
>
>   bridge-domain v100
>
>
>
>vfi v100
>
>
>
> vpn-id 10100
>
>
>
> autodiscovery bgp
>
>
>
>  rd auto
>
>
>
>  route-target import 65535:10100
>
>
>
>  route-target export 65535:10100
>
>
>
>  signaling-protocol ldp
>
>
>
>   vpls-id 65535:10100
>
>
>
>
>
>
>
>