Re: [j-nsp] Juniper BNG - Termination of N:1 subscribers into different RI (DEMUX)

[Krasimir Avramski]

Hi,

It is possible  - basically, you should have an almost identical
configuration for aaa and dhcp server in both routing contexts.

krasi@test>show subscribers
Interface IP Address/VLAN ID  User Name
 LS:RI
demux0.3221225528  1444
default:default
demux0.3221225529 100.16.0.42 retail
 *default:retail*

Underlying (vlan based demux) interface for the dhcp subscriber is bound to
"default:default" routing context:
krasi@test> show subscribers client-type dhcp address 100.16.0.42 detail
|match under
Underlying Interface: demux0.3221225528

while the subscriber is terminated in "default:retail" routing context (as
specified by radius).

Debug confirms the move of route context:
 Apr 29 15:38:53.798056
[MSTR][DEBUG][default:default][SVR][INET][demux0.3221225528][SID=131]
cedb_entry_rc_update_required: Client 65618 needs to be moved from INET
routing instance default:default to INET routing instance default:retail
Apr 29 15:38:53.798063
[MSTR][DEBUG][default:retail][SVR][INET][demux0.3221225528][SID=131]
cedb_entry_rc_update: Moved client 65618 from routing instance
default:default to routing instance default:retail
Apr 29 15:38:53.798068
[MSTR][DEBUG][default:retail][SVR][INET][demux0.3221225528][SID=131]
cedb_entry_rc_update: wholesale routing instance default:default number of
wholesale clients moved out : 1, retail routing instance default:retail
number of wholesale clients moved in :1

Best Regards,
Krasi

On Wed, 28 Apr 2021 at 05:54, Fraser McGlinn  wrote:

> Hey Guys,
>
> I’ve got a requirement from a customer where they are needing to terminate
> multiple different subscribers on the same layer 2 domain (delivered via a
> last mile provider that doesn't support unique vlan per subscriber,
> retarded I know!) into different routing instances via IP based demux.
> I’ve got the IP Based demux stuff working fine with triggers via DHCP,
> however this seems to only work for a single RI and just errors out with:
>
> Apr 27 22:36:26.755944 [MSTR][WARN]
> [default:default][SVR][INET][xe-0/0/1.3558][SID=201546]
> cedb_entry_rc_update_required: Required move of client 142407 from routing
> instance default:default to routing instance default:cgnat is invalid.
> Client's incoming interface config in wholesale(0x9fff98d8) or retail(0)
> INET routing context could not be retrieved.
> Apr 27 22:36:26.755996 [MSTR][INFO]
> [default:default][SVR][INET][xe-0/0/1.3558][SID=201546]
> jdhcpd_local_server_auth_request_ack_common: Invalid
> logical-system/routing-instance supplied during authentication, dropping
>
> This seems expected based on my experience with VLAN based demux where you
> have to drop the first dip of the double dip auth into the new RI in order
> for DHCP to be running in the same RI as the subscriber is terminated in.
> So the problem I’m trying to solve is how to build the same style
> configuration as the double dip with dynamic VLANs but for a single shared
> switching domain with multiple subs.
>
> The topology is as follows:
> Subscribers, shared layer 2 domain in last mile provider -> MX on vlan
> 3558 -> demux per household -> IP interface
>
> I’ve tried playing around with line-identity auto-configure but I can’t
> seem to get it working at all. Possible I’m trying to use it in the wrong
> way, the documentation seems to be missing bits of glue to tie all the
> concepts together.
>
> Has anyone else solved this problem? Is this even possible? I do
> understand that even if it is possible there are many pitfalls with this
> approach, its just the old have to fudge a solution based on requirements
> outside of your control. Naturally PPPoE works great in this instance, but
> anyhow requirements are pushing to at least try for IPOE.
>
> Cheers,
> Fraser
> ___
> 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] arp bug workaround (mx204)

[Krasimir Avramski]

Hi,

I have tested with 18.2.
With 19.4R3 I have the same commit error.
18.4 is also affected with static configuration, but once a demux is
managed by subscriber-management, the underlying ps is allowed:

show interfaces demux0.3221225477 extensive
  Logical interface demux0.3221225477 (Index 536870952) (SNMP ifIndex
20040)
   (Generation 10)
Flags: Up Encapsulation: ENET2
Interface set: test
Demux:
  *Underlying interface: ps0.3221225476* (Index 536870950)

I suggest downgrading to a working version with your setup and then open a
case with jtac. Seems the limit is introduced in 18.3 or 18.4

Best Regards,
Krasi



On Wed, 14 Apr 2021 at 12:57, Baldur Norddahl  wrote:

> Hello
>
> I finally had time to implement this, but unfortunately I get this error
> at commit:
>
> admin@interxion-edge1# commit
> error: Underlying interface for vlan/ip demux can't be ps
> error: configuration check-out failed
>
> This is on mx204 version 21.1R1.11.
>
> Was something changed to disallow ip demux on top of VPLS ps interfaces?
> Is there an alternative to the ps interface? Krasimir appears to have a
> successful test, what is the difference?
>
> If you need the full config that I am trying to commit, please send a
> direct mail. It contains user IP addresses so I am not happy about having
> that on the mailing list.
>
> Thanks,
>
> Baldur
>
>
>
> Den tor. 5. nov. 2020 kl. 12.48 skrev Krasimir Avramski  >:
>
>> Hi Baldur,
>>
>> Indeed, you are persistent in asking for that issue ;-). The idea is to
>> use the RFC1925 6a) - "It is always possible to add another level of
>> indirection."
>>
>> krasi@test# show interfaces ps201 unit 60
>> demux-source inet;
>> vlan-tags outer 2301 inner 1711;
>> family inet {
>> unnumbered-address lo0.1;
>> }
>>
>> krasi@test# show interfaces demux0
>> unit 60 {
>> demux-options {
>> underlying-interface ps201.60;
>> }
>> family inet {
>> demux-source {
>> 185.24.168.2/32;
>> }
>> unnumbered-address lo0.1 preferred-source-address 185.24.168.1;
>> }
>> }
>> unit 61 {
>> demux-options {
>> underlying-interface ps201.60;
>> }
>> family inet {
>> demux-source {
>> 212.237.105.194/32;
>> }
>> unnumbered-address lo0.1 preferred-source-address 212.237.105.1;
>> }
>> }
>>
>> krasi@test# show routing-instances internet routing-options
>> static {
>> route 185.24.168.2/32 {
>> qualified-next-hop demux0.60;
>> }
>> route 212.237.105.194/32 {
>> qualified-next-hop demux0.61;
>> }
>> }
>>
>> krasi@test# run show interfaces demux0.60 |match "Pref|Under"
>>   Underlying interface: ps201.60 (Index 528)
>>   Family Inet Source prefixes, total 1
>>   Prefix: 185.24.168.2/32
>>   Preferred source address: 185.24.168.1
>>
>>
>> krasi@test# run show interfaces demux0.61 |match "Pref|Under"
>>   Underlying interface: ps201.60 (Index 528)
>>   Family Inet Source prefixes, total 1
>>   Prefix: 212.237.105.194/32
>>   Preferred source address: 212.237.105.1
>>
>> krasi@test# run monitor traffic interface demux0.60 no-resolve
>> 
>> 13:29:05.274236 Out arp who-has 185.24.168.2 tell 185.24.168.1
>> 13:29:18.976788 Out arp who-has 185.24.168.2 tell 185.24.168.1
>>
>> krasi@test# run monitor traffic interface demux0.61 no-resolve
>> .
>> 13:30:01.788921 Out arp who-has 212.237.105.194 tell 212.237.105.1
>> 13:30:15.788642 Out arp who-has 212.237.105.194 tell 212.237.105.1
>>
>> Btw, you can use only one demux ifl for the extra ip address and set
>> appropriate preferred-source-address on ps201.60 and demux0.60
>>
>> HTH,
>> Krasi
>>
>> On Wed, 4 Nov 2020 at 22:02, Baldur Norddahl  wrote:
>>
>>> Hello
>>>
>>> I am trying to work around an arp bug in Junos. The issue is as follows:
>>>
>>> set interfaces ps201 unit 60 vlan-tags outer 2301
>>> set interfaces ps201 unit 60 vlan-tags inner 1711
>>> set interfaces ps201 unit 60 family inet unnumbered-address lo0.1
>>> set routing-instances internet routing-options static route
>>> 185.24.168.2/32
>>> qualified-next-hop <http://185.24.168.2/32qualified-next-hop> ps201.60
>>> mac-address b4:75:0e:15:38:9e
>>> set routing-instances internet routing-options stat

Re: [j-nsp] arp bug workaround (mx204)

[Krasimir Avramski]

Hi Baldur,

Indeed, you are persistent in asking for that issue ;-). The idea is to use
the RFC1925 6a) - "It is always possible to add another level of
indirection."

krasi@test# show interfaces ps201 unit 60
demux-source inet;
vlan-tags outer 2301 inner 1711;
family inet {
unnumbered-address lo0.1;
}

krasi@test# show interfaces demux0
unit 60 {
demux-options {
underlying-interface ps201.60;
}
family inet {
demux-source {
185.24.168.2/32;
}
unnumbered-address lo0.1 preferred-source-address 185.24.168.1;
}
}
unit 61 {
demux-options {
underlying-interface ps201.60;
}
family inet {
demux-source {
212.237.105.194/32;
}
unnumbered-address lo0.1 preferred-source-address 212.237.105.1;
}
}

krasi@test# show routing-instances internet routing-options
static {
route 185.24.168.2/32 {
qualified-next-hop demux0.60;
}
route 212.237.105.194/32 {
qualified-next-hop demux0.61;
}
}

krasi@test# run show interfaces demux0.60 |match "Pref|Under"
  Underlying interface: ps201.60 (Index 528)
  Family Inet Source prefixes, total 1
  Prefix: 185.24.168.2/32
  Preferred source address: 185.24.168.1


krasi@test# run show interfaces demux0.61 |match "Pref|Under"
  Underlying interface: ps201.60 (Index 528)
  Family Inet Source prefixes, total 1
  Prefix: 212.237.105.194/32
  Preferred source address: 212.237.105.1

krasi@test# run monitor traffic interface demux0.60 no-resolve

13:29:05.274236 Out arp who-has 185.24.168.2 tell 185.24.168.1
13:29:18.976788 Out arp who-has 185.24.168.2 tell 185.24.168.1

krasi@test# run monitor traffic interface demux0.61 no-resolve
.
13:30:01.788921 Out arp who-has 212.237.105.194 tell 212.237.105.1
13:30:15.788642 Out arp who-has 212.237.105.194 tell 212.237.105.1

Btw, you can use only one demux ifl for the extra ip address and set
appropriate preferred-source-address on ps201.60 and demux0.60

HTH,
Krasi

On Wed, 4 Nov 2020 at 22:02, Baldur Norddahl  wrote:

> Hello
>
> I am trying to work around an arp bug in Junos. The issue is as follows:
>
> set interfaces ps201 unit 60 vlan-tags outer 2301
> set interfaces ps201 unit 60 vlan-tags inner 1711
> set interfaces ps201 unit 60 family inet unnumbered-address lo0.1
> set routing-instances internet routing-options static route
> 185.24.168.2/32
> qualified-next-hop  ps201.60
> mac-address b4:75:0e:15:38:9e
> set routing-instances internet routing-options static route
> 212.237.105.194/32 qualified-next-hop ps201.60 mac-address
> d8:07:b6:46:7a:31
> set routing-instances internet interface ps201.60
> set protocols router-advertisement interface ps201.60
>
> The above works but hardcodes the MAC address of the customer. This is
> necessary because there is no way to make Junos choose the correct source
> address for ARP requests for both 185.24.168.2/32 and 212.237.105.194/32
> at
> the same time. You could do either of the following but not both:
>
> set interfaces ps201 unit 60 family inet unnumbered-address lo0.1
> preferred-source-address 185.24.168.1
> set interfaces ps201 unit 60 family inet unnumbered-address lo0.1
> preferred-source-address 212.237.105.1
>
> With 185.24.168.1/24 and 212.237.105.1/24 both being configured on lo0.1.
>
> There exists an algorithm, unfortunately only mandatory for IPv6, that
> automatically chooses the closest available address from the list of
> possible candidate addresses. But Junos does not implement this for IPv4
> (unknown if it does for IPv6). Instead it will always use the primary
> address from lo0.1 if specified, otherwise a random address.
>
> The CPE will ignore ARP requests from the juniper router that have the
> wrong source address. Our only solution has been to use the mac-address
> parameter to hardcode the address, which sidesteps the issue by not using
> ARP.
>
> This is also a problem with subscriber management.
>
> We use the above configuration for customers that paid for an extra IP
> address. Often the extra address is from a different series than his
> original address, because all addresses have been assigned. We can not
> retroactively fix that as we have an existing customer base and customers
> do not like to be told to change their static configuration, DNS names etc.
>
> So I am searching for work arounds. For example if I could make an ACL that
> rewrites the vlans matching an IP address, such that the two IPs were on
> two different VLANs, I could solve this by having two interfaces for the
> customer. Alas that does not seem to be possible.
>
> Anyone have an idea how to create some sort of work around that does not
> force the MAC address to be hardcoded?
>
> Thanks,
>
> Baldur
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> 

Re: [j-nsp] static arp with unnumbered-address

[Krasimir Avramski]

Hello,

The static arp assignments are possible by borrowing the idea from
subscriber management access or access-internal routes (subs management
will do that automatically upon subscriber dhcp binding):

krasi@test# show interfaces ge-0/0/0
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 10 {
vlan-tags outer 402 inner 1016;
family inet {
unnumbered-address lo0.1;
}
}
krasi@test# show routing-instances internet routing-options
access-internal {
route 1.1.1.1/32 {
qualified-next-hop ge-0/0/0.10 {
mac-address 00:11:11:11:11:11;
}
}
}

krasi@test# run show route table internet protocol access-internal
internet.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
1.1.1.1/32 *[Access-internal/12] 00:03:51
> to #0 0.11.11.11.11.11 via ge-0/0/0.10

krasi@test# run show arp no-resolve vpn internet
MAC Address   Address Interface Flags
00:11:11:11:11:11 1.1.1.1 ge-0/0/0.10  permanent

HTH,
Krasi


On Thu, 13 Feb 2020 at 15:09, Baldur Norddahl  wrote:

> Den tor. 13. feb. 2020 kl. 13.12 skrev Alexander Arseniev <
> arsen...@btinternet.com>:
>
> > Hello,
> > So. this whole setup is built for saving 2 IP from each /26, correct?
> >
>
> No the purpose is to avoid needing to use a /30 minimum per customer. Lets
> say we have subnet 192.0.2.0/26:
>
> 192.0.2.0 network - unusable
> 192.0.2.1 default gateway for customers
> 192.0.2.2 customer1 unit 10 vlan 10
> 192.0.2.3 customer2 unit 11 vlan 11
> 192.0.2.4 customer3 unit 12 vlan 12
> etc
> 192.0.2.63 broadcast - unusable
>
> So each customer is on a different vlan also called the customer vlan
> (CVLAN) model (actual deployment uses q-in-q). We use /32 routes to each
> customer, however the customer believes he is part of a /26. This is so
> multiple customers can share the same gateway IP address.
>
> The IP waste is related to the size of the subnet. In this case we choose a
> /26 which means we lose 3 IPs out of 64. The alternative without using
> unnumbered address would look like this:
>
> 192.0.2.0 network IP unit 10 vlan 10
> 192.0.2.1 gateway unit 10 vlan 10
> 192.0.2.2 customer1 unit 10 vlan 10
> 192.0.2.3 broadcast unit 10 vlan 10
> 192.0.2.4 network unit 11 vlan 11
> 192.0.2.5 gateway unit 11 vlan 11
> 192.0.2.6 customer2 unit 11 vlan 11
> 192.0.2.7 broadcast unit 11 vlan 11
> etc
>
> Each customer would then live inside his very own /30 and done like that it
> would probably just work. Nobody wants to do it like that anymore. The
> waste is 75%.
>
> Regards,
>
> Baldur
>
>
>
> > If You reconsider and decide You can afford to waste 2/64 = 3% of Your
> > IPv4 address estate, then on the face of it, looks like perfect use case
> > for EVPN with its /32 routes auto-created from ARP.
> > You can assign multiple 1st IPs from multitude of /26 to each EVPN IRB
> > interface with proper /26 netmask instead of tinkering with
> > unnumbered-address.
> > And if You export these /32 into Your iBGP, the /32 will be routed to
> > according to usual iBGP rules (local pref|metric etc).
> > Thanks
> > Alex
> >
> > -- Original Message --
> > From: "Baldur Norddahl" 
> > To: "Juniper List" 
> > Sent: 13/02/2020 09:50:34
> > Subject: Re: [j-nsp] static arp with unnumbered-address
> >
> > >Hi Alex
> > >
> > >Thanks for the reply. Ok I managed to make a bad example. This is
> actually
> > >from our running configuration and all the routes are /32 routes. The
> > issue
> > >is that the customers have all been assigned IPv4 addresses from random
> > >subnets. The subnets are usually sized /26 and the first address is
> > >configured on the router loopback interface, such that customers can use
> > it
> > >as the default gateway using proxy arp.
> > >
> > >The problem is that arp is not working correctly. When selecting the
> > source
> > >address for ARP requests, the router is picking a random IP address from
> > >the loopback interface instead of the IP address from the subnet that
> > >matches what the customer expects. This can be fixed by using:
> > >
> > >family inet {
> > > unnumbered-address lo0.1 preferred-source-address a.b.c.1;
> > > }
> > >
> > >However this does not fix the issue for customers having multiple IP
> > >addresses assigned from different subnets. And they are usually using a
> > >switch to connect multiple devices, so just routing IP address #2 to IP
> #1
> > >is no good.
> > >
> > >We come from another platform where this was not a problem. The other
> > >platform (ZTE) would do the right thing and do ARP using the correct
> > source
> > >address without us needing to do anything. The IP addresses have been
> > >assigned and used by the customers for years, so we can not just simply
> > >change the allocation scheme. It seems Juniper is not truly into a world
> > >where wasting addresses with old school /30 to a customer that only
> needs
> > a
> > >/32 is not working for us poor 

Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?

[Krasimir Avramski]

Hi,

If you use the MX as subscriber access dhcp server/relay it will populate
the host routes(access-internal) and arp entries automatically upon dhcp
negotiation. In that setup usually the ethernet interface(segment) is
unnumbered and only /32 host routes to subscribers are installed - no
network route with rsvl next-hop in PFE. Traffic to unused IP address space
would be silently dropped.

Best Regards,
Krasi

On Fri, 1 Feb 2019 at 01:32, Clarke Morledge  wrote:

> Thank you for the input thus far, folks.
>
> Let me explain just a bit more about what I am dealing with. Because we
> get so much garbage scanning, if the scanner tries to hit an IP address,
> that does not have an ARP resolution, it really clutters up traffic
> unnecessarily. A simple case from my lab illustrates some of the
> difficulty.
>
> Here I am sending a single transit packet, passing through my MX, destined
> to an IP that will not resolve. Since the MX has nowhere immediately to
> send the packet, the RE spits out a bunch of ARP requests:
>
> 17:30:35.095861 ARP, Request who-has 192.168.10.21 tell 192.168.10.8,
> length 46
> 17:30:35.713821 ARP, Request who-has 192.168.10.21 tell 192.168.10.8,
> length 46
> 17:30:36.613849 ARP, Request who-has 192.168.10.21 tell 192.168.10.8,
> length 46
> 17:30:37.513831 ARP, Request who-has 192.168.10.21 tell 192.168.10.8,
> length 46
> 17:30:38.313831 ARP, Request who-has 192.168.10.21 tell 192.168.10.8,
> length 46
>
> Correspondingly, rtsockmon -tn logs this:
>
> [17:30:35:099.939] kernel Proute  add inet 192.168.10.21
> tid=36 plen=32 type=dest flags=0x180 nh=hold nhflags=0x1 nhidx=1290
> rt_nhiflist = 0 altfwdnhidx=0 filtidx=0 lr_id = 0 featureid=0
> rt_mcast_nhiflist=-1610628420
> [17:30:35:101.376] kernel Pnexthopadd inet  nh=hold
> flags=0x1 uflags=0x0 idx=1290 ifidx=421 filteridx=0 lr_id =0
> [17:30:39:013.595] kernel Proute  delete  inet 192.168.10.21
> tid=36 plen=32 type=dest flags=0x180 nh=hold nhflags=0x1 nhidx=1290
> rt_nhiflist = 0 altfwdnhidx=0 filtidx=0 lr_id = 0 featureid=0
> rt_mcast_nhiflist=-1610628420
> [17:30:39:013.710] kernel Pnexthopdelete  inet  nh=hold
> flags=0x5 uflags=0x0 idx=1290 ifidx=421 filteridx=0 lr_id =0
>
> In a real world case, we have generally observed a fairly even
> distribution of scanning attempts on non-resolving IPs, across an entire
> subnet, over time. So, let's say you have an unused class C, being scanned
> at the rate of 4 IPs per second, such that every address gets scanned once
> a minute.  Assuming that each incoming transit packet kicks off 5 ARP
> requests (1 initial, plus 4 retries), as I saw above, that would trigger
> somewhere over 1200 ARP requests a minute, or about 20 ARP packets a
> second.
>
> That is a fairly moderate amplification type of attack.
>
> In a DHCP-serviced subnet, like a /20 with some 4000 available host IPs,
> we might have only 3000 being used at any one time, but we want to give
> enough headroom to accommodate fluctuations in DHCP usage. But that leaves
> those 1000 remaining, unused IPs unintentionally triggering lots of
> unnecessary ARP traffic.
>
> Specifically, what would be nice, is if there was a way to manipulate that
> ARP retry mechanism, from 4 retries, down to 2, to cut down on the noise.
> So far, I have not found a knob in Junos on the MX to do this.
>
> Am I missing something?
>
> Clarke Morledge
> College of William and Mary
> Information Technology - Network Engineering
> Jones Hall (Room 18)
> 200 Ukrop Way
> Williamsburg VA 23187
>
> ___
> 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] ARP resolution algorithm? Storage of MX transit packets?

[Krasimir Avramski]

At least It will not flood ARPs under segment network probes.

In the past these punts were throttled in the PFE . This was done with
default values of 66 pps per segment with an upper merit of 500 per PFE.
You would had seen the following entry in the syslog: "NH: resolutions from
iif 90 throttled".

I haven't seen these messages recently? -  I do not know how NH rsvl punt
policers are integrated with DDoS arp/resolve system.

Best Regards,
Krasi

On Thu, 31 Jan 2019 at 18:12, Saku Ytti  wrote:

> On Thu, 31 Jan 2019 at 16:22, Krasimir Avramski  wrote:
>
> > Yes, you can for ipv4/ipv6:
> >
> https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/arp-learning-neighor-discovery-disabling.html
> >
> > With the ability to set static ARP/ND you definitely could offload host
> route programming to external system.
>
> Cool. Have you tried it? In my trivial test it does not disable punting:
>
> y...@r24.labxtx01.us.bb-re1# run show route forwarding-table table
> default destination 192.0.2.0/24
> Routing table: default.inet
> Internet:
> DestinationType RtRef Next hop   Type IndexNhRef Netif
> 192.0.2.0/24   intf 0rslv  825 1 ae0.0
> 192.0.2.0/32   dest 0 192.0.2.0  recv  797 1 ae0.0
>
> {master}[edit interfaces ae0 unit 0 family inet]
> y...@r24.labxtx01.us.bb-re1# set no-neighbor-learn
>
> {master}[edit interfaces ae0 unit 0 family inet]
> y...@r24.labxtx01.us.bb-re1# commit
> re1:
> configuration check succeeds
> re0:
> commit complete
> re1:
> commit complete
>
> {master}[edit interfaces ae0 unit 0 family inet]
> y...@r24.labxtx01.us.bb-re1# run show route forwarding-table table
> default destination 192.0.2.0/24
> Routing table: default.inet
> Internet:
> DestinationType RtRef Next hop   Type IndexNhRef Netif
> 192.0.2.0/24   intf 0rslv  825 1 ae0.0
> 192.0.2.0/32   dest 0 192.0.2.0  recv  797 1 ae0.0
>
>
> It did disable resolution though, but it's not really attractive to me
> without disabling punting.
>
> --
>   ++ytti
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?

[Krasimir Avramski]

Hi,


I don't think you can turn it off in JunOS. So they'd have to change
> code anyhow, at which point, I'd rather take translation than static
> config.
>

Yes, you can for ipv4/ipv6:
https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/arp-learning-neighor-discovery-disabling.html

With the ability to set static ARP/ND you definitely could offload host
route programming to external system.

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

Re: [j-nsp] MX80 Input Scheduling/Shaping

[Krasimir Avramski]

Hi,


> but it's just not allowed through software on the 10GE ports.
>
 It is allowed since 16.1

> I'm not certain but I faintly recall that the fixed chassis MX80 didn't
> have QX.
>
 Correct.

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

Re: [j-nsp] PE-CE issue with OSPF routes not getting into routing table

[Krasimir Avramski]

Hi,

The route from your output has DN bit set (Opt 0xa2) and it is loop
prevention mechanism as described in rfc4577.

More info from Juniper docs:
http://www.juniper.net/techpubs/en_US/junos12.2/topics/usage-guidelines/vpns-configuring-routing-between-pe-and-ce-routers-in-layer-3-vpns.html

Best Regards,
Krasi

On Sun, Aug 26, 2018, 05:19 Raymond, Adam via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> Hi,
>
> Complex one, so I will try to describe this carefully.
>
> I have a IPv4 layer 3 MP-BGP VPN. There are two PEs that have an
> OSPF adjacency to CEs inside the VPN. The VPN only has a single OSPF area:
> 0.0.0.0. An external route, 172.16.64.0/20, is inserted into the VPN
> (called IP_ASC_VPN_1) via redistribution from iBGP and into OPSF.
> The slightly odd thing about this setup compared to a traditional
> VPN is that the PEs have devices connected to them that don't support
> dynamic routing - they are just node with a IP address and default gateway
> configured on them:
>
>   PE3 -- CE5
>   |
>   P --P
>   |   |
>   P -- PE1 --OSPF-- CE1 --OSPF-- CE2 --OPSF-- CE3 --OSPF-- PE2 -- P
> |   |
>NodeNode
>
> All of this works when all of the network is up and operational, but when
> the link from the P routers to the PEs breaks:
>   PE3 -- CE5
>   |
>   P --P
>   |   |
>   P -X- PE1 --OSPF-- CE1 --OSPF-- CE2 --OPSF-- CE3 --OSPF-- PE2 -- P
>  |   |
> NodeNode
>
> Then the Node closest to the break becomes unreachable from CE5. CE5 is
> also the router that inserts 172.16.64.0/20 into the VPN. I can log into
> PE1 by jumping from CE1 and see what is happening on that router. PE1 is
> still learning the 172.16.64.0/20 route via OSPF as you can see it in the
> OSFP database:
> araymond@PE1> show ospf database external extensive lsa-id 172.16.64.0
> instance IP_ASC_VPN_1
> OSPF AS SCOPE link state database
>  Type   ID   Adv Rtr   Seq  Age  Opt  Cksum
> Len
> Extern   172.16.64.0  172.16.49.68 0x8001   192  0xa2 0xf2f1
> 36
>   mask 255.255.240.0
>   Topology default (ID 0)
> Type: 2, Metric: 3000, Fwd addr: 0.0.0.0, Tag: 208.0.255.152
>   Aging timer 00:56:47
>   Installed 00:03:06 ago, expires in 00:56:48
>   Last changed 00:03:06 ago, Change count: 1
>
> where 172.16.49.68 is the router-id of PE2.
>
> The problem is that this route doesn't get added to the
> IP_ASC_VPN_1.inet.0 routing table. There seems to be something that makes
> this route ineligible, but I cannot figure out what it is. Can anyone help
> me with that?
>
> Regards,
>
> Adam Raymond | IP Platform Engineering Team Lead
>
> M: 0410 347 012   D: 03 8623 3638 | ext   E: adam.raym...@vocus.com.au
> 
> P: +61 3 8613   W: vocus.com.au
> A: 333 Collins Street, Melbourne, VIC 3000, Australia  |  Follow us:
>
>
>
> ___
> 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] Longest Match for LDP (RFC5283)

[Krasimir Avramski]

Hi

It is used in Access Nodes(default route to AGN) with
LDP-DOD(Downstream-on-Demand) Seamless MPLS architectures - RFC7032

A sample with LDP->BGP-LU redistribution on AGN is here

.

Best Regards,
Krasi

On 24 July 2018 at 16:35,  wrote:

> Hi James
>
> > Of James Bensley
> > Sent: Tuesday, July 24, 2018 11:17 AM
> >
> > Hi All,
> >
> > Like my other post about Egress Protection on Juniper, is anyone using
> what
> > Juniper call "Longest Match for LDP" - their implementation of
> > RFC5283 LDP Extension for Inter-Area Label Switched Paths (LSPs) ?
> >
> > The Juniper documentation is available here:
> >
> > https://www.juniper.net/documentation/en_US/junos/topics/concept/long
> > est-match-support-for-ldp-overview.html
> >
> > https://www.juniper.net/documentation/en_US/junos/topics/task/configur
> > ation/configuring-longest-match-ldp.html
> >
> > As before, as far as I can tell only Juniper have implemented this:
> > - Is anyone use this?
> > - Are you using it in a mixed vendor network?
> > - What is your use case for using it?
> >
> > I'm looking at IGP/MPLS scaling issues where some smaller access layer
> > boxes that run MPLS (e.g. Cisco ME3600X, ASR920 etc.) and have limited
> > TCAM. We do see TCAM exhaustion issues with these boxes however the
> > biggest culprit of this is Inter-AS MPLS Option B connections. This is
> because
> > Inter-AS OptB double allocates labels, which means label TCAM can run out
> > before we run out of IP v4/v6 TCAM due to n*2 growth of labels vs
> prefixes.
> >
> > I'm struggling to see the use case for the feature linked above that has
> been
> > implemented by Juniper. When running LDP the label space TCAM usage
> > increments pretty much linearly with IP prefix TCAM space usage.
> > If you're running the BGP VPNv4/VPNv6 address family and per-prefix
> > labeling (the default on Cisco IOS/IOS-XE) then again label TCAM usage
> > increases pretty much linearly with IP prefix TCAM usage. If you're using
> per-
> > vrf/per-table labels or per-ce labels then label TCAM usage increases in
> a
> > logarithmic fashion in relation to IP Prefix usage, and in this scenario
> we run
> > out of IP prefix TCAM long before we run out of label TCAM.
> >
> > My point here is that label TCAM runs out because of BGP/RSVP/SR usage,
> > not because of LDP usage.
> >
> > So who is using this feature/RFC on low end MPLS access boxes (QFX5100 or
> > ACX5048 etc.)?
> > How is it helping you?
> > Who's running out of MPLS TCAM space (on a Juniper device) before they
> > run out of IP prefix space when using LDP (and not RSVP/SR/BGP)?
> >
> I certainly was not aware of this one,
> Interesting concept I'm guessing for OptB in Inter-Area deployments? (or a
> neat alternative to current options?),
>
> Suppose I have ABR advertising default-route + label down to a stub area,
> And suppose PE-3 in this stub area wants to send packets to PE1 and PE2 in
> area 0 or some other area.
> Now I guess the whole purpose of "Longest Match for LDP"  is to save
> resources on PE-3 so that all it has in its RIB/FIB is this default-route +
> LDP label pointing at the ABR.
> So it encapsulates packets destined to PE1 and PE2 with the only transport
> label it has and put the VPN label it learned via BGP from PE1 and PE2 on
> top and send the packets to ABR,
> When ABR receives these two packets -how is it going to know that these are
> not destined to it and that it needs to stitch this LSP further to LSPs
> toward PE1 and PE2 and also how would it know which of the two packets it
> just received is supposed to be forwarded to PE1 and which to PE2?
> This seem to defeat the purpose of an end-to-end LSPs principle where the
> labels stack has to uniquely identify the label-switch-path's end-point (or
> group of end-points)
> The only way out is if ABR indeed thinks these packets are destined for it
> and it also happens to host both VRFs and actually is advertised VPN
> prefixes for these VRFs to our PE-3 so that PE-3 sends packets to PE1 and
> PE2 these will land on ABR ain their respective VRFs and will be send
> further by ABR to PE1 and PE2.
>
> In the old world the PE-3 would need to have a route + transport label for
> PE1 and PE2.
> Options:
> a) In single area for the whole core approach, PE3 would have to hold these
> routes + transport labels for all other PEs in the backbone -same LSDB on
> each host requirement.
> b) In multi-area with BGP-LU (hierarchical MPLS) we could have ABR to
> advertise only subset of routes + labels to PE-3 (or have PE-3 to only
> accept routes it actually needs) -this reduction might suffice or not,
> note:
> no VPN routes at the ABR.
> c) I guess this new approach then further reduces the FIB size requirements
> on PE-3 by allowing it to have just one prefix and transport label  (or two
> in case of redundant ABRs), but it increase 

Re: [j-nsp] mx960 to mx960 via ciena 6500 - mtu smaller in the middle

[Krasimir Avramski]

>
> If you are carrying the full table for example, then you could end up with
> BGP UPDATE messages 16000
> bytes long they won't cross the link. Y


Just to mention that rfc4271 states maximum bgp message size of 4096,
although there is a draft
https://tools.ietf.org/html/draft-ietf-idr-bgp-extended-messages-24 that
could change this in the future.

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

Re: [j-nsp] Experience with MX10003

[Krasimir Avramski]

Hi  Niall,

The turbo fib is set of route convergence optimisations in rpd(kernel
update thread), kernel and pfe(trio). Released in 15.1F6

with
~25k r/s, performance really depends on hw(re, mpc) used as well as sw
features enabled(e.g. nsr).

Best Regards,
Krasi

On 26 January 2018 at 05:56, Niall Donaghy  wrote:

> Hi Guilano,
>
> I was thrilled to read your post, as we are investigating putting a large
> number of MX204s [same RE; half the RAM] and some MX10k3s in our network
> later this year.
> The financials are quite compelling vs. MX480/960, and so we're about to
> do similar testing to what you're currently doing.
> In fact, RIB -> FIB programming speed and 17.4 bugs are our chief concerns.
>
> If you are willing to share your testing data or summaries, we and others
> on the list would greatly appreciate that knowledge sharing I am sure.
>
> Can you clarify what you're referring to by 'turbo FIB'?
>
> Best regards,
> Niall
>
> Niall Donaghy
> Senior Network Engineer
> GÉANT
> T: +44 (0)1223 371393
> M: +44 (0) 7557770303
> Skype: niall.donaghy-dante
> PGP Key ID: 0x77680027
> nic-hdl: NGD-RIPE
>
> Networks • Services • People
> Learn more at www.geant.org​
> ​GÉANT is the collective trading name of the GÉANT Association and GEANT
> Limited.
>
> GÉANT Vereniging (Association) is registered in the Netherlands with the
> Chamber of Commerce in Amsterdam. Registration number: 40535155. Registered
> office: Hoekenrode 3, 1102BR Amsterdam, The Netherlands.
> GEANT Limited  is registered in England & Wales. Registration number:
> 2806796. Registered office: City House, 126-130 Hills Road, Cambridge CB2
> 1PQ, UK.
>
>
>
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Giuliano C. Medalha
> Sent: 25 January 2018 18:43
> To: juniper-nsp 
> Subject: Re: [j-nsp] Experience with MX10003
>
> We are testing the MX10003 right now.
>
> It is a pretty amazing box.
>
> The routing engine is so power for control plane ... bgp, ospf etc
>
> The timers for BGP to put routes on FIB is something special ( after turbo
> fib ).  With BGP PIC reconvergence is very fast too.
>
> We will test the mpc for traffic with spirent testcenter.
>
> Junos 17.4 already supoorts mx204 and mx10003 and is available for download
>
> Att
>
> Giuliano
>
> Giuliano C. Medalha
> WZTECH NETWORKS
> +55 (17) 98112-5394
> giuli...@wztech.com.br
> 
> From: juniper-nsp  on behalf of
> Pavel Lunin 
> Sent: Thursday, January 25, 2018 4:09:35 PM
> To: alexander.marh...@gmx.at
> Cc: juniper-nsp
> Subject: Re: [j-nsp] Experience with MX10003
>
> Not that brand new. MPC7-like, which has been around for quite some time.
>
> What should be completely new in this box is the fabric.
>
> The main gotcha is that they are still not shipping it. Same for mx204.
> Respectively no software is available publicly for these platforms yet.
>
> It means that you'll get something close to production-ready by the end of
> Q3 2018.
>
> It's quite normal though. Add a year to the announcement date, you'll get
> the date when you can (try to) put it in production. Well, maybe.
>
> Regards,
> Pavel
>
> 25 янв. 2018 г. 6:16 ПП пользователь "Alexander Marhold" <
> alexander.marh...@gmx.at> написал:
>
> > Hi
> > Regarding same chipset as mx960:
> >
> > RE yes x86
> > PFE a clear no NO  it uses a "BRAND NEW" 3rd generation TRIO chipset
> > with 400G throughput  also built into the MX204
> >
> > Grabbed info from a BDM document in PPT describing both new platforms
> > Regards
> >
> > alexander
> >
> > -Ursprüngliche Nachricht-
> > Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im
> > Auftrag von Alain Hebert
> > Gesendet: Donnerstag, 25. Januar 2018 17:47
> > An: Juniper List
> > Betreff: [j-nsp] Experience with MX10003
> >
> >  Hi,
> >
> >  After the bad experience with the QFX5100, now our rep is pushing
> > for
> > MX10003 instead of MX960.
> >
> >  While its half the routing (10T versus 4T), at 1/2 the price, and
> > a barely 3U in space, for the same chipset (coming from the sales guy).
> >
> >  Anything ring thru?  Or we're going to be just another bunch of
> > crash test dummies for Juniper to test this new platform?
> >
> >  Thanks for your time.
> >
> > --
> > -
> > Alain Hebertaheb...@pubnix.net
> > PubNIX Inc.
> > 50 boul. St-Charles
> > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> > Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
> >
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> > 

Re: [j-nsp] RE-S-1300 - memory upgrade possible?

[Krasimir Avramski]

Hi,

We did it with no problems ~10 years ago. We used 2x 2GB registered ECC.
For more details contact me offlist.

Best Regards,
Krasi



On 2 January 2018 at 14:34, Tore Anderson  wrote:

> I've got a few MX-es with the RE-S-1300 in my network. While out of
> support, they work just fine, except for the fact that the 2 GB of
> memory is getting rather tight.
>
> Hoping to squeeze some a little bit of extra life out of those boxes, I
> was wondering if anyone on the list tried to replace whatever DIMMs are
> found on the RE-S-1300 in order to double up the total memory to 4 GB?
> If so, any success?
>
> Tore
> ___
> 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] error: the ethernet-link-fault-management subsystem is not running on a QFX5100

[Krasimir Avramski]

CFM is not supported on QFX family.
ACX5K supports this feature.

Best Regards,
Krasi

On 23 October 2017 at 12:39, Vasil Kanev  wrote:

> Hi there,
>
> On an QFX5100 VC  i`m trying to configure OAM CFM but when i try to check
> status i got this:
>
> error: the ethernet-connectivity-fault-management subsystem is not running
>
> Here is my config:
>
> {master:0}[edit protocols oam ethernet connectivity-fault-management]
> action-profile LINK_DOWN {
> default-actions {
> interface-down;
> }
> }
> maintenance-domain lab {
> level 7;
> name-format character-string;
> maintenance-association labMA {
> continuity-check {
> hold-interval 1;
> }
> mep 999 {
> interface xe-0/0/0.0 vlan 66;
> direction down;
> auto-discovery;
> }
> }
> }
> ___
> 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] ACX control plane filter

[Krasimir Avramski]

Had already been answered in the thread:

"The script is building only /32 "local" prefixes.
Your suggestion is building "direct" prefixes and when matching at the
FTF, you can achieve "undesired" results."

Best Regards,
Krasi


On 22 March 2017 at 20:00, Eduardo Schoedler  wrote:

> have you tried to do a prefix-list like this?
>
>
> {master}[edit]
> regress@R1-RE0# *show policy-options | no-more*
> prefix-list router-ipv4 {
> apply-path "interfaces <*> unit <*> family inet address <*>";
> }
>
>
> --
> Eduardo Schoedler
>
>
> Em seg, 20 de mar de 2017 às 06:24, Johan Borch 
> escreveu:
>
> > Hi
> >
> > Do anyone have a control plane filter for ACX they can share? :) they
> don't
> > seem to support using standard loopback filters.
> >
> > Johan
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> --
> Eduardo Schoedler
> ___
> 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] ISIS route leaking from Level2 to Level1

[Krasimir Avramski]

Hi Cydon,

Lower the aggregatde route preference below 18.


Best Regards,
Krasi

On 18 November 2016 at 13:11, Cydon Satyr  wrote:

> Hello experts,
>
> If I create an aggregate route on L1/2 router and export it to Level1 ("to
> level 1"), this route does not have up/down bit set, making it eligible for
> leaking back to Level 2.
> What happens is that now router which originated aggregated route prefers
> same route over ISIS making a constant oscillation.
>
> Is there a way to prevent this?
>
>
> Thanks
> ___
> 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] Communities on l2vpn instances

[Krasimir Avramski]

Hi,

You can follow the vpls example (l2vpn/l3vpn/l2circuit traffic mapping is
the same):
http://www.juniper.net/documentation/en_US/junos15.1/topics/usage-guidelines/vpns-mapping-vpls-traffic-to-specific-lsps.html

install-nexthop  lsp lsp-name: Use the "strict" option to enable
strict mode, which checks to see if any of the LSP next hops specified in
the policy are up. If none of the specified LSP next hops are up, the
policy installs the discard next hop.

Best Regards,
Krasi


On 26 September 2016 at 16:43, Luis Balbinot  wrote:

> Hi.
>
> It's possible to set communities at the "protocol l2vpn" level in a
> l2vpn routing-instance at three different places:
>
> set interface xxx community yyy
> set site xxx community yyy
> set site xxx interface yyy community zzz
>
> But these don't seem to change anything. Documentation on these
> commands is pretty much inexistent. Does anyone know how/if they work?
>
> My idea is to set communities to aggregate l2vpn instances and control
> which groups take different LSPs. All communities set from a VRF
> export policy are only sent on the BGP sessions and are not installed
> at the local l2vpn tables. Is there a way to set multiple communities
> locally on a l2vpn routing-instance?
>
> Luis
> ___
> 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 router reccomendations

[Krasimir Avramski]

Built-in ports H-QoS(MX80/104) is supported on 16.1:
https://www.juniper.net/techpubs/en_US/junos16.1/information-products/topic-collections/release-notes/16.1/topic-105380.html#jd0e4451

Best Regards,
Krasi

On 29 July 2016 at 15:00, Adam Vitkovsky  wrote:

> > Saku Ytti [mailto:s...@ytti.fi]
> > Sent: Friday, July 29, 2016 10:33 AM
> >
> > On 29 July 2016 at 06:08, Anhost  wrote:
> > > Those boxes have no fabric to connect to which makes it appear to
> double
> > the bw. The onboard 10G ports are the connections that would otherwise go
> > to the scb's.
> >
> > The MICs are the ones which are on 'fabric side'. The rationale is easy.
> WAN
> > side has 4*XFP PHY, fabric side does not have. To connect anything in
> fabric
> > side you'll need IX chips. Hence 4x10GE MIC could never work in
> > MX80/MX104, because it relies on MQ's WAN side PHYs.
> >
> Ok that makes sense, but I have read somewhere that on MX80 (not sure
> about MX104), only MICs have H-QOS (but I'd expect the H-QOS to be
> available in the WAN out rather than Fabric out direction).
> So I probably remember it the other way around it's the integrated ports
> that only support H-QOS then?
>
>
> 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.
>
> ---
>  This email has been scanned for email related threats and delivered
> safely by Mimecast.
>  For more information please visit http://www.mimecast.com
>
> ---
> ___
> 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] Problem with BGP

[Krasimir Avramski]

Hi,
What is the reason of using "local-as
"
feature? You can try to set "loops 2" option as described in the link.

Best Regards,
Krasi


On 28 April 2016 at 09:58, Johan Borch  wrote:

> Hi
>
> Both cisco and Juniper have as-override configured on their external
> session. But the problem is when I shut down the juniper peer. Routes
> receieved from cisco is still hidden and looped.
>
> Johan
>
> On Wed, Apr 27, 2016 at 11:02 PM, Mark Tinka  wrote:
>
> >
> >
> > On 27/Apr/16 19:59, Johan Borch wrote:
> >
> > > Hi
> > >
> > > I have a problem that perhaps the experts on this list can help me shed
> > > some light on :)
> > >
> > > The problem involves two PE routers one Cisco IOS and one Juniper MX.
> > MPLS
> > > & co between them. Each PE have a VRF, same route-target. Each of these
> > > PE-routers have a BGP session inside the VRF that connects to a
> customer
> > > site via supplier and a leased line. These leased lines should be
> > redundant
> > > for each other.
> > >
> > > Both BGP sessions use local as AS65534 and supplier on other side is
> > > AS65535. Sessions are up and I'm receiving routes from supplier in each
> > PE.
> > >
> > > Now to my problem.
> > >
> > > If I cut the leased line on the Cisco PE it will populate the vrf
> routing
> > > table on the Cisco PE with routes from the Juniper PE learned over
> MPLS,
> > no
> > > problem.
> > > If I cut the leased line on the Juniper PE then Juniper PE should learn
> > the
> > > routes from the Cisco PE, but all routes are hidden and Juniper thinks
> > that
> > > AS65534 is looped.
> > >
> > > If I check a route on Juniper PE it says:
> > >
> > > AS path: $MY_MPLS_NET_AS 65534 65535 $SUPPLIER_AS $SUPPLIER_AS I
> (Looped:
> > > 65534) (sorry for the obfuscation)
> > >
> > > State: 
> > >
> > > Hidden reason: reason not available
> > >
> > > VRF on Juniper side is configured with:
> > > autonomous-system 64560 independent-domain
> > >
> > > What am I missing? Can I tell JunOS do not think it is a loop somehow?
> > > Would it be easier to peer with different ASN from each PE?
> >
> > Do you have "as-override" configured on the Juniper VRF?
> >
> > Mark.
> >
> ___
> 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] protect ssh and telnet

[Krasimir Avramski]

Hey Aaron,


file show /var/db/scripts/commit/ifl-addr.slax


version 1.0;

ns junos = "http://xml.juniper.net/junos/*/junos;;
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm;;
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0;;

import "../import/junos.xsl";

match configuration {
var $toplevel = .;
var $vrf = "one"; /* name of routing instance */
var $direct = 0; /* set this to 1 for building  "direct" prefixes, default
is "local"" */

 {
 {
 {
 "ifl-addr-v4";
for-each ($toplevel/routing-instances/instance[name =
$vrf]/interface) {
var $ifd = substring-before(name, ".");
var $unit = substring-after(name, ".");
for-each ($toplevel/interfaces/interface[name =
$ifd]/unit[name = $unit]/family/inet/address) {
  var $addr = jcs:parse-ip(name);
if ($direct) {
{
 $addr[4]_"/"_$addr[3];
   }
}
else {
 {
 $addr[1];
}
}
}
}
 }
 }
 }
}

Best Regards,
Krasi


On 15 April 2016 at 23:12, Aaron  wrote:

> Right, that’s what I saw recently when working through a case with JTAC…
>
>
>
> I need a solution that will…
>
> 1 – apply to ONLY my direct/local actual ip addresses on my ACX5048
>
> 2 – apply to ONLY routing-instance vrf “one”
>
>
>
>
>
> agould@eng-lab-acx5048-1
> #
> show policy-options prefix-list all-internet | display inheritance
> ##
> ## apply-path was expanded to:
> ## 10.101.14.124/30;
> ## 10.101.14.108/30;
> ## 1.2.3.64/28;
> ## 10.95.255.0/26;
> ## 10.101.12.245/32;
> ##
> apply-path "interfaces <*> unit <*> family inet address <*>";
>
>
>
>
>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] protect ssh and telnet

[Krasimir Avramski]

Hi Aaron,

Currently script is building list of all configured ifls (except
logical-systems defined). You can tag the the vrf "one" addresses through
"apply-macro" and modify script to add address based on that condition.

Sample ifl tag:
set interfaces xe-0/0/0 unit 0 family inet address 3.3.3.3/24 apply-macro
vrf-one

Best Regards,
Krasi




On 15 April 2016 at 19:10, Aaron <aar...@gvtc.com> wrote:

> Thanks Krasi, Hmmm, this looks very interesting, I want to try it in my
> lab… also, please let me know if this will ONLY work for my
> routing-instance vrf “one” interfaces…
>
>
>
> My vrf “one” is where my public/vulnerable ip’s live…
>
>
>
> I don’t need to protect my default core vrf which is all 10.x.x.x and that
> domain is behing a mgmt. net firewall boundary
>
>
>
> Aaron
>
>
>
> *From:* Krasimir Avramski [mailto:kr...@smartcom.bg]
> *Sent:* Friday, April 15, 2016 6:51 AM
> *To:* Aaron <aar...@gvtc.com>
> *Cc:* Chris Jones <ipv6fre...@gmail.com>; Juniper-Nsp <
> juniper-nsp@puck.nether.net>
>
> *Subject:* Re: [j-nsp] protect ssh and telnet
>
>
>
> Hi Aaron,
>
>
>
> Below is commit script which is building dynamic prefix list (containing
> local IPv4 addresses) you could reference in FTF:
>
>
>
> krasi# show system scripts commit
>
> allow-transients;
>
> file ifl-addr-v4.slax;
>
>
>
>
>
>
>
>
>
> krasi# run file show /var/db/scripts/commit/ifl-addr-v4.slax
>
> version 1.0;
>
>
>
> ns junos = "http://xml.juniper.net/junos/*/junos;;
>
> ns xnm = "http://xml.juniper.net/xnm/1.1/xnm;;
>
> ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0;;
>
>
>
> import "../import/junos.xsl";
>
>
>
> match configuration {
>
>  {
>
>  {
>
>  {
>
>  "ifl-addr-v4";
>
>   for-each (interfaces/interface/unit/family/inet/address)
> {
>
> var $address = substring-before(name, "/");
>
>  {
>
>$address;
>
>}
>
>   }
>
>  }
>
>  }
>
>  }
>
> }
>
>
>
>
>
>
>
> krasi# show policy-options |display inheritance |display commit-scripts
>
> prefix-list ifl-addr-v4 {
>
> 1.1.1.1/32;
>
> 10.10.111.1/32;
>
> }
>
>
>
>
>
> krasi# set interfaces xe-0/0/0 unit 0 family inet address 2.2.2.2/30
>
>
>
> [edit]
>
> root# commit
>
> commit complete
>
>
>
> [edit]
>
> root# show policy-options |display inheritance |display commit-scripts
>
> prefix-list ifl-addr-v4 {
>
> 1.1.1.1/32;
>
> 2.2.2.2/32;
>
> 10.10.111.1/32;
>
>  }
>
>
>
>
>
> Best Regards,
>
> Krasi
>
>
>
> On 13 April 2016 at 23:43, Aaron <aar...@gvtc.com> wrote:
>
> Thanks Chris, but apparently the Juniper ACX5048 is an exception to the
> lo0 rule…  see link
>
>
>
> http://kb.juniper.net/InfoCenter/index?page=content <
> http://kb.juniper.net/InfoCenter/index?page=content=KB28893=search=en_US=1305252358192>
> =KB28893=search=en_US=1305252358192
>
>
>
> I’ve been able to accomplish protecting telnet/ssh on my ACX5048 like this…
>
>
>
> set routing-instances one forwarding-options family inet filter input
> protect-5048
>
> set firewall family inet filter protect-5048 term 1 from
> destination-address 1.1.1.1/32
>
> set firewall family inet filter protect-5048 term 1 from protocol tcp
>
> set firewall family inet filter protect-5048 term 1 from destination-port
> telnet
>
> set firewall family inet filter protect-5048 term 1 from destination-port
> ssh
>
> set firewall family inet filter protect-5048 term 1 then count
> protect-5048-counter
>
> set firewall family inet filter protect-5048 term 1 then discard
>
> set firewall family inet filter protect-5048 term 2 then accept
>
>
>
> 1.1.1.0/24 is a subnet on an interface in vrf “one” on my acx5048…
>
>
>
> The only thing is that I will need to make it a policy with my colleagues
> that if/when we churn public address space or add new interfaces on our
> acx5048’s, part of the process will be to add a line to our firewall acl…
>
>
>
> set firewall family inet filter protect-5048 term 1 from
> destination-address 1.1.2.1/32
>
> set firewall family inet filter protect-5048 term 1 from
> destination-address 1.1.3.1/32
>
> etc
>
>
>
> QUESTION – does anyone know 

Re: [j-nsp] protect ssh and telnet

[Krasimir Avramski]

Hi Roberto,

The script is building only /32 "local" prefixes.
Your suggestion is building "direct" prefixes (cisco "connected" networks)
and when matching at the FTF level (note that is NOT lo0 filter)  depending
on the filter action you can achieve "undesired" results.

Best Regards,
Krasi

On 15 April 2016 at 19:39, Roberto Bertó <roberto.be...@gmail.com> wrote:

> What's difference between your junos script and this apply-path?
>
> set policy-options prefix-list router-ipv4 apply-path "interfaces <*> unit
> <*> family inet address <*>"
>
>
> 2016-04-15 13:10 GMT-03:00 Aaron <aar...@gvtc.com>:
>
>> Thanks Krasi, Hmmm, this looks very interesting, I want to try it in my
>> lab… also, please let me know if this will ONLY work for my
>> routing-instance vrf “one” interfaces…
>>
>>
>>
>> My vrf “one” is where my public/vulnerable ip’s live…
>>
>>
>>
>> I don’t need to protect my default core vrf which is all 10.x.x.x and
>> that domain is behing a mgmt. net firewall boundary
>>
>>
>>
>> Aaron
>>
>>
>>
>> From: Krasimir Avramski [mailto:kr...@smartcom.bg]
>> Sent: Friday, April 15, 2016 6:51 AM
>> To: Aaron <aar...@gvtc.com>
>> Cc: Chris Jones <ipv6fre...@gmail.com>; Juniper-Nsp <
>> juniper-nsp@puck.nether.net>
>> Subject: Re: [j-nsp] protect ssh and telnet
>>
>>
>>
>> Hi Aaron,
>>
>>
>>
>> Below is commit script which is building dynamic prefix list (containing
>> local IPv4 addresses) you could reference in FTF:
>>
>>
>>
>> krasi# show system scripts commit
>>
>> allow-transients;
>>
>> file ifl-addr-v4.slax;
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> krasi# run file show /var/db/scripts/commit/ifl-addr-v4.slax
>>
>> version 1.0;
>>
>>
>>
>> ns junos = "http://xml.juniper.net/junos/*/junos;;
>>
>> ns xnm = "http://xml.juniper.net/xnm/1.1/xnm;;
>>
>> ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0;;
>>
>>
>>
>> import "../import/junos.xsl";
>>
>>
>>
>> match configuration {
>>
>>  {
>>
>>  {
>>
>>  {
>>
>>  "ifl-addr-v4";
>>
>>   for-each
>> (interfaces/interface/unit/family/inet/address) {
>>
>> var $address = substring-before(name, "/");
>>
>>  {
>>
>>$address;
>>
>>}
>>
>>   }
>>
>>  }
>>
>>  }
>>
>>  }
>>
>> }
>>
>>
>>
>>
>>
>>
>>
>> krasi# show policy-options |display inheritance |display commit-scripts
>>
>> prefix-list ifl-addr-v4 {
>>
>> 1.1.1.1/32 <http://1.1.1.1/32> ;
>>
>> 10.10.111.1/32 <http://10.10.111.1/32> ;
>>
>> }
>>
>>
>>
>>
>>
>> krasi# set interfaces xe-0/0/0 unit 0 family inet address 2.2.2.2/30 <
>> http://2.2.2.2/30>
>>
>>
>>
>> [edit]
>>
>> root# commit
>>
>> commit complete
>>
>>
>>
>> [edit]
>>
>> root# show policy-options |display inheritance |display commit-scripts
>>
>> prefix-list ifl-addr-v4 {
>>
>> 1.1.1.1/32 <http://1.1.1.1/32> ;
>>
>> 2.2.2.2/32 <http://2.2.2.2/32> ;
>>
>> 10.10.111.1/32 <http://10.10.111.1/32> ;
>>
>>  }
>>
>>
>>
>>
>>
>> Best Regards,
>>
>> Krasi
>>
>>
>>
>> On 13 April 2016 at 23:43, Aaron <aar...@gvtc.com <mailto:aar...@gvtc.com>
>> > wrote:
>>
>> Thanks Chris, but apparently the Juniper ACX5048 is an exception to the
>> lo0 rule…  see link
>>
>>
>>
>> http://kb.juniper.net/InfoCenter/index?page=content <
>> http://kb.juniper.net/InfoCenter/index?page=content <
>> http://kb.juniper.net/InfoCenter/index?page=content=KB28893=search=en_US=1305252358192>
>> =KB28893=search=en_US=1305252358192>
>> =KB28893=search=en_US=1305252358192
>>
>>
>>
>> I’ve been able to accomplish protecting telnet/ssh on my ACX5048 like
>> this…
>>
>>
>>
>> set routing-instanc

Re: [j-nsp] protect ssh and telnet

[Krasimir Avramski]

Hi Aaron,

Below is commit script which is building dynamic prefix list (containing
local IPv4 addresses) you could reference in FTF:

krasi# show system scripts commit
allow-transients;
file ifl-addr-v4.slax;




krasi# run file show /var/db/scripts/commit/ifl-addr-v4.slax
version 1.0;

ns junos = "http://xml.juniper.net/junos/*/junos;;
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm;;
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0;;

import "../import/junos.xsl";

match configuration {
 {
 {
 {
 "ifl-addr-v4";
  for-each (interfaces/interface/unit/family/inet/address) {
var $address = substring-before(name, "/");
 {
   $address;
   }
  }
 }
 }
 }
}



krasi# show policy-options |display inheritance |display commit-scripts
prefix-list ifl-addr-v4 {
1.1.1.1/32;
10.10.111.1/32;
}


krasi# set interfaces xe-0/0/0 unit 0 family inet address 2.2.2.2/30

[edit]
root# commit
commit complete

[edit]
root# show policy-options |display inheritance |display commit-scripts
prefix-list ifl-addr-v4 {
1.1.1.1/32;
2.2.2.2/32;
10.10.111.1/32;
 }


Best Regards,
Krasi

On 13 April 2016 at 23:43, Aaron  wrote:

> Thanks Chris, but apparently the Juniper ACX5048 is an exception to the
> lo0 rule…  see link
>
>
>
> http://kb.juniper.net/InfoCenter/index?page=content <
> http://kb.juniper.net/InfoCenter/index?page=content=KB28893=search=en_US=1305252358192>
> =KB28893=search=en_US=1305252358192
>
>
>
> I’ve been able to accomplish protecting telnet/ssh on my ACX5048 like this…
>
>
>
> set routing-instances one forwarding-options family inet filter input
> protect-5048
>
> set firewall family inet filter protect-5048 term 1 from
> destination-address 1.1.1.1/32
>
> set firewall family inet filter protect-5048 term 1 from protocol tcp
>
> set firewall family inet filter protect-5048 term 1 from destination-port
> telnet
>
> set firewall family inet filter protect-5048 term 1 from destination-port
> ssh
>
> set firewall family inet filter protect-5048 term 1 then count
> protect-5048-counter
>
> set firewall family inet filter protect-5048 term 1 then discard
>
> set firewall family inet filter protect-5048 term 2 then accept
>
>
>
> 1.1.1.0/24 is a subnet on an interface in vrf “one” on my acx5048…
>
>
>
> The only thing is that I will need to make it a policy with my colleagues
> that if/when we churn public address space or add new interfaces on our
> acx5048’s, part of the process will be to add a line to our firewall acl…
>
>
>
> set firewall family inet filter protect-5048 term 1 from
> destination-address 1.1.2.1/32
>
> set firewall family inet filter protect-5048 term 1 from
> destination-address 1.1.3.1/32
>
> etc
>
>
>
> QUESTION – does anyone know how to make this firewall acl or include a
> confition or policy somehow to apply the firewall policy to ONLY LOCAL
> ROUTES (/32’s) ?  that would be nice , so that I would never have to
> add/subtract specific ip addresses in this firewall policy.
>
>
>
> Aaron
>
>
>
>
>
>
>
> From: Chris Jones [mailto:ipv6fre...@gmail.com]
> Sent: Wednesday, April 13, 2016 10:05 AM
> To: Aaron 
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] protect ssh and telnet
>
>
>
> To answer OPs actual question:
>
>
>
> What you're looking for is an RE filter, applied to lo0. A great resource
> explaining them and some best practices, etc. check out Doug Hank's Day One
> book:
> http://www.juniper.net/us/en/training/jnbooks/day-one/fundamentals-series/securing-routing-engine/
>
>
>
> On Tue, Mar 29, 2016 at 10:26 PM, Aaron  > wrote:
>
> I'm new to Juniper. and I'm looking to protect ssh/telnet on all interfaces
> on my juniper ACX5048's.
>
>
>
> In Cisco you can protect the virtual interface (vty) with a acl
> (access-class) so that any remote login attempts (ssh or telnet) or
> protected.
>
>
>
> How do I protect ssh and telnet globally in Junos ?  I only want to allow
> ssh and telnet from certain trusted management subnets.
>
>
>
> Aaron
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net  juniper-nsp@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
>
>
>
>
> --
>
> Chris Jones
> JNCIE-ENT #272
> CCIE# 25655 (R)
>
> ___
> 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] Why doesn't memory utilization in "show chassis routing-engine" count in "Inactive" and "Buffers" memory?

[Krasimir Avramski]

Hi,

It used to be calculated like (Total - Free - Inactive - Cached)/Total, but
changed somewhere in 7.x.

>From the book: "Dirty pages need to be paged out, but flushing a page is
extremely expensive compared to freeing a clean page. Thus, dirty pages are
given extra time on the inactive queue by cycling them through the queue
twice before being flushed. They cycle through the list once more while being
cleaned. This extra time on the inactive queue will reduce unnecessary I/O
caused by prematurely paging out an active page."

So, dirty pages are slowly "cleaned" and moved from inactive to cache(for
the next cycle of pageout process which runs when the system is under
memory pressure or when the queues are out of balance) and cache pages are
freed to maintain a minimum number of free pages - consequently Inact
memory is not so easily accessible by the kernel.

Regards,
Krasi

On 9 October 2015 at 15:57, Martin T  wrote:

> Hi,
>
> according to "The Design and Implementation of the FreeBSD Operating
> System"(https://books.google.ee/books?id=KfCuBAAAQBAJ=PA290=PA290)
> kernel divides used memory into five lists: Active, Inactive, Wired,
> Cache and Free. In addition, some memory is used for disk caching.
> Utilization of those lists can be seen with "top" or "show system
> processes extensive" commands. For example:
>
> Mem: 130M Active, 42M Inact, 51M Wired, 14M Cache, 34M Buf, 764K Free
> Swap: 512M Total, 512M Free
>
>
> So actually *used* memory is Wired and Active and if those two pools
> need additional amount of memory then this is taken from Inactive,
> Cached, Buffers or Free pools. This makes me wonder why "show chassis
> routing-engine" command calculates memory according to following
> formula(at least on M and MX series):
>
> Memory utilization % = (Total - Free - Cached)/Total
>
> In other words, it doesn't count in Inactive and Buffers lists as free
> memory while actually those should be available for Active and Wired
> immediately if needed. This makes one believe that memory utilization
> on his RE is always very high.
>
>
> Why doesn't memory utilization in "show chassis routing-engine" count
> in Inactive and Buffers memory?
>
>
>
> thanks,
> Martin
> ___
> 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] RFC3107 to LDP stitching

[Krasimir Avramski]

Hi Adam,


And cmd: “set protocols bgp group nni-opt-c family inet labeled-unicast
 per-prefix-label”
 -only creates label mapping for BGP-LU label that remote AS ASBR
 advertised for remote AS PE loopback with LDP label that local AS ASBR
 allocated for this prefix.


I don't think per-prefix-label has anything to do with stitching. IMHO
stitching in that direction is done through bgp -- ldp redistribution
policy ( usually ldp egress-policy ) or bgp-lu is extended from ASBRs
to the local PEs as typical inter-as option C
http://www.juniper.net/techpubs/en_US/junose12.3/topics/concept/mbgp-inter-as-option-c-overview.html#id-35896
scenario.

So now the only mystery is the need for explicit null label advertised by
 local AS ASBR (acting as PE) for its own loopback to remote AS ASBR
 Without this the VPN ping doesn’t work
 But it might something to do with the vrf table-label


This works for me without explicit-null and in disregard of vrf-table-label.

I recommend to reconsider mp-bgp with AFI=1, SAFI=1,4 as more flexible way
than bgp-igp-both-ribs/resolve-vpn. Note that you still need to
redistribute ldp from inet.3 and isis from inet.0 through bgp policy on
both ASBRs. The tricky part here is to leak ASBRs loopback routes also in
inet.3 - (i.e.  interface-routes rib-group controlled through
import-policy)

In summary if you don't want to extend bgp-lu to all PEs then you need
mutual redistribution between ldp/isis and bgp-lu in order to stitch lsp
transport.

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

Re: [j-nsp] RFC3107 to LDP stitching

[Krasimir Avramski]

 was there already.
 ASBR also allocates label 3 for its own loopback and advertises it to
 remote AS ASBR.

 Regarding the  labeled-unicast rib inet.3:
 set routing-options rib-groups export-inet0 import-rib inet.3 --primary
 table where routes are to be installed
 set routing-options rib-groups export-inet0 import-rib inet.0 --secondary
 tabel where routes are to be installed
 set protocols bgp group nni-opt-c family inet labeled-unicast rib-group
 export-inet0 -- to get routes from inet.3 into inet.0 so that ISIS and LDP
 can disseminate them in local AS
 set protocols bgp group nni-opt-c family inet labeled-unicast rib inet.3
 -- to install the labeled prefixes received from remote ASBR in remote AS
 into inet.3 and to stitch them to LDP labels
 - so manually copying routes from inet.3 to inet.0
 - it also does the LSP stitching so remote AS NHs or received routes have
 their rfc3107 assigned label stitched to LDP label - where the LDP label
 was assigned to the prefixes once leaked into inet.0
 - problem is that only routes in inet.3 are advertised from local AS ASBR
 to ASBR in remote AS because inet.3 is the primary table for the SAFI 3 -so
 RR loopbacks are missing i.e. those are not part of inet.3 thus not
 advertised to remote AS.
 - don't know how to fix this



 adam
 From: Krasimir Avramski [mailto:kr...@smartcom.bg]
 Sent: 01 April 2015 10:42
 To: Adam Vitkovsky
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] RFC3107 to LDP stitching


 Hi Adam,

 Yes, bgp-igp-both-ribs is needed for transport LSP stitching on ASBRs.
 BGP-LU works as follow:
 If the route has label then select new label and perform swap.
 If there is no label then select new label and perform pop - note for the
 direct routes(such as loopback) implicit label 3 is used.

 So, ISIS local AS PE routes are advertised and label operation POP is
 programmed  - this exposes traffic with vpn labels (requested by local AS
 PEs different from asbr ) to the ASBR itself and since such ip-vpn routes
 are not advertised, upon label lookup they are dropped.
 When  bgp-igp-both-ribs is configured the LDP, RSVP routes are already in
 inet.0 so when redistributed, label operation SWAP is programmed (actual
 LSP transport stitch).

 Personally I prefer rib inet.3 way - this should work in case you
 establish both inet and labeled-unicast bgp families (actually rib
 inet.3 is only way to do that). This will relax the need
 of bgp-igp-both-ribs(when it is not desired since the change is global for
 the router) and resolve-vpn and through the policies you
 can granularly control what is advertised for data path stitching and what
 for control plane purposes.(plane IP).

 As per local PE functionality on ASBR are you sure you properly
 redistributed local loopbacks through the bgp-lu - while I'm not 100% sure
 it should work without explicit-null  Do you have vrf-table-label in
 VRF?

 Regards,
 Krasi

 On 1 April 2015 at 01:48, Adam Vitkovsky adam.vitkov...@gamma.co.uk
 wrote:
 Hi Folks,

 So for the RFC3107 to LDP stitching if ASBR is also a PE the working
 config for ASBR is as follows but I'm not sure why/how it actually works.

 set protocols mpls traffic-engineering bgp-igp-both-ribs
 set protocols bgp group nni-opt-c family inet labeled-unicast
 per-prefix-label (probably optional)
 set protocols bgp group nni-opt-c family inet labeled-unicast
 explicit-null connected-only
 set protocols bgp group nni-opt-c family inet labeled-unicast resolve-vpn

 Why do I need to use bgp-igp-both-ribs or possibly mpls-forwarding
 option (haven't tested that yet) to copy routes from inet.3 to inet.0 if
 I'm already using resolve-vpn and with resolve-vpn the primary table
 for RFC3107 routes is inet.0 and inet.0 already has the local AS PEs and
 RRs loopbacks in it, so those are advertised to the remote AS.
 It seems like the bgp-igp-both-ribs is necessary for the inet.0 or I
 should say mpls.0 - RFC3107 LSP stitching but I have no idea how/why.

 And also why the ASBR acting as PE won't accept packet with just the VPN
 label and there's this explicit-null label stack required.

 The resolve-vpn vs rib inet.3.
 Ok so resolve-vpn option uses inet.0 as primary routing table and will
 just copy the RFC3107 labeled routes to inet.3 table.
 The RFC3107 labeled routes have be placed in the inet.3 routing table so
 that VRF routes from remote AS have NH in inet.3 for proper NH resolution
 (In case the ASBR is also a PE for a vrf spanning across the ASNs).
 Since inet.0 is still the primary table the remote-AS PE loopbacks can be
 advertised via ISIS to local AS RRs -i.e pure IP connectivity is in place
 so MP-eBGP can be formed.
 However with rib inet.3 the inet.3 will become the primary routing table
 for RFC3107 routes.
 So then you need to manually leak routes from inet.3 to inet.0 using
 rib-groups the remote-AS prefixes (PE loopbacks) can be advertised via ISIS
 to RRs.
 However since inet.3 is the primary table only for RFC3107 session only
 routes

Re: [j-nsp] RFC3107 to LDP stitching

[Krasimir Avramski]

Hi Adam,

Yes, bgp-igp-both-ribs is needed for transport LSP stitching on ASBRs.
BGP-LU works as follow:
If the route has label then select new label and perform swap.
If there is no label then select new label and perform pop - note for the
direct routes(such as loopback) implicit label 3 is used.

So, ISIS local AS PE routes are advertised and label operation POP is
programmed  - this exposes traffic with vpn labels (requested by local AS
PEs different from asbr ) to the ASBR itself and since such ip-vpn routes
are not advertised, upon label lookup they are dropped.
When  bgp-igp-both-ribs is configured the LDP, RSVP routes are already in
inet.0 so when redistributed, label operation SWAP is programmed (actual
LSP transport stitch).

Personally I prefer rib inet.3 way - this should work in case you
establish both inet and labeled-unicast bgp families (actually rib
inet.3 is only way to do that). This will relax the need
of bgp-igp-both-ribs(when it is not desired since the change is global for
the router) and resolve-vpn and through the policies you
can granularly control what is advertised for data path stitching and what
for control plane purposes.(plane IP).

As per local PE functionality on ASBR are you sure you properly
redistributed local loopbacks through the bgp-lu - while I'm not 100% sure
it should work without explicit-null  Do you have vrf-table-label in
VRF?

Regards,
Krasi

On 1 April 2015 at 01:48, Adam Vitkovsky adam.vitkov...@gamma.co.uk wrote:

 Hi Folks,

 So for the RFC3107 to LDP stitching if ASBR is also a PE the working
 config for ASBR is as follows but I'm not sure why/how it actually works.

 set protocols mpls traffic-engineering bgp-igp-both-ribs
 set protocols bgp group nni-opt-c family inet labeled-unicast
 per-prefix-label (probably optional)
 set protocols bgp group nni-opt-c family inet labeled-unicast
 explicit-null connected-only
 set protocols bgp group nni-opt-c family inet labeled-unicast resolve-vpn

 Why do I need to use bgp-igp-both-ribs or possibly mpls-forwarding
 option (haven't tested that yet) to copy routes from inet.3 to inet.0 if
 I'm already using resolve-vpn and with resolve-vpn the primary table
 for RFC3107 routes is inet.0 and inet.0 already has the local AS PEs and
 RRs loopbacks in it, so those are advertised to the remote AS.
 It seems like the bgp-igp-both-ribs is necessary for the inet.0 or I
 should say mpls.0 - RFC3107 LSP stitching but I have no idea how/why.

 And also why the ASBR acting as PE won't accept packet with just the VPN
 label and there's this explicit-null label stack required.

 The resolve-vpn vs rib inet.3.
 Ok so resolve-vpn option uses inet.0 as primary routing table and will
 just copy the RFC3107 labeled routes to inet.3 table.
 The RFC3107 labeled routes have be placed in the inet.3 routing table so
 that VRF routes from remote AS have NH in inet.3 for proper NH resolution
 (In case the ASBR is also a PE for a vrf spanning across the ASNs).
 Since inet.0 is still the primary table the remote-AS PE loopbacks can be
 advertised via ISIS to local AS RRs -i.e pure IP connectivity is in place
 so MP-eBGP can be formed.
 However with rib inet.3 the inet.3 will become the primary routing table
 for RFC3107 routes.
 So then you need to manually leak routes from inet.3 to inet.0 using
 rib-groups the remote-AS prefixes (PE loopbacks) can be advertised via ISIS
 to RRs.
 However since inet.3 is the primary table only for RFC3107 session only
 routes in inet.3 are advertised from local AS to the remote AS and RR
 loopbacks are not in inet.3 which is a show stopper unless it's somehow
 possible to leak routes from inet.0 to inet.3.

 I'd appreciate any thoughts, ideas on how this actually works.

 adam

 ---
  This email has been scanned for email related threats and delivered
 safely by Mimecast.
  For more information please visit http://www.mimecast.com

 ---


 ___
 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] NG-MVPN RPT-SPT mode no receiver CE limitation?

[Krasimir Avramski]

 We used SPT-only mode and didn't see any difference in
 channel changes, because in SPT-only mode, the (S,G) state
 is already present on the Receiver PE router, so an IGMP
 Join request does not have to travel the RPT tree like if
 you RPT-SPT mode.


Well with the caveat that in RPT-SPT after the first Receiver PE travels
the RPT, the (S,G) state is already known to remaining Receiver PEs due to
bgp inherent protocol optimization -  type-5 SA generated by source PE, so
we are effectively in the SPT-only operation  after the first subscriber
behind the first Receiver PE.

With the static igmpv3 on every Receiver mvpn PE we actually wanted to
emulate VPLS with p2mp optimization (that was initial deployment) avoiding
L2 churn.

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

Re: [j-nsp] NG-MVPN RPT-SPT mode no receiver CE limitation?

[Krasimir Avramski]

Hello Vladi,

I didn't mention you are interested in RPT-SPT mode - I just thought you
have local PE receivers issue that was typical in early days of mvpn and of
course we used  SPT-only with SSM mode.There were inherent pfe
infrastructure problems with composite nh needed to dealt with direct ifls
and p2mp (especially on source PE).

Best Regards,
Krasi


On 27 May 2014 17:42, Vladislav A. VASILEV vladislavavasi...@gmail.comwrote:

 This is a snippet from Deploying MBGP Multicast VPNs:


 *At the time of this writing, Junos OS does not support RPT-SPT mode if
 the CSources*

 *or C-Receivers are locally connected to the PEs. It is mandatory to have
 a*

 *CE between a PE and a host. This limitation is specific of RPT-SPT, it
 does not affect*

 *the default SPT-only mode.*


 The book is from May 2011, so I assume things must have changed. Otherwise
 what I have should not work at all. I guess I'll wait for JTAC to get back
 to me.


 Thanks,

 Vladi


 On Tue, May 27, 2014 at 3:27 PM, Krasimir Avramski kr...@smartcom.bgwrote:

 I have had customer using exactly the same setup (in production) without
 any problems on receiver PE (static igmp local receivers for faster channel
 zapping). Now I can't remember if igmp was effectively filtered on
 downstream access equipment. The problem with local receivers was only on
 Source PE ( if you have type-7 C-M route then Source PE local receivers
 would stop receive mcast traffic - 9.6 release, DPC hardware). The work
 around was to deploy another vrf on source PE to terminate local receivers
 and source mcast interface and mvpn vrf serving only remote PEs). On 11.2
 it was dependent on type of hardware used(MPC, DPC) for interfaces
 connecting multicast source, mpls core and local receivers - for example if
 DPC hardware was used for ifls connecting mcast source, mpls core and local
 receivers then it was OK - every other combination (including only MPC
 hardware) affected local source PE receivers or remote PEs not receiving
 multicast traffic at all.
 I really don't know current state with latest software/hardware, but
 rather you are hitting some bug.

 Best Regards,
 Krasi


  On 27 May 2014 14:13, Vladislav A. VASILEV 
 vladislavavasi...@gmail.comwrote:

  Does anybody know if this limitation still exist:

 Source CE --- Source PE --- MPLS Network --- Receiver PE --- Static IGMP
 under VRF interface (no Receiver CE)

 It works but the problem is that for no reason multicast traffic would
 stop
 flowing (within a few days) due to BGP withdrawing all route types
 (except
 neighbour discovery). Deactivating/activating the routing instance under
 the receiver PE solves the problem for a few days and it would then
 happen
 again. I've had a JTAC case opened for a few weeks now, but I still have
 not been given a clear answer as to whether or not this is supported.

 Thanks,
 Vladi
 ___
 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] NG-MVPN RPT-SPT mode no receiver CE limitation?

[Krasimir Avramski]

I have had customer using exactly the same setup (in production) without
any problems on receiver PE (static igmp local receivers for faster channel
zapping). Now I can't remember if igmp was effectively filtered on
downstream access equipment. The problem with local receivers was only on
Source PE ( if you have type-7 C-M route then Source PE local receivers
would stop receive mcast traffic - 9.6 release, DPC hardware). The work
around was to deploy another vrf on source PE to terminate local receivers
and source mcast interface and mvpn vrf serving only remote PEs). On 11.2
it was dependent on type of hardware used(MPC, DPC) for interfaces
connecting multicast source, mpls core and local receivers - for example if
DPC hardware was used for ifls connecting mcast source, mpls core and local
receivers then it was OK - every other combination (including only MPC
hardware) affected local source PE receivers or remote PEs not receiving
multicast traffic at all.
I really don't know current state with latest software/hardware, but rather
you are hitting some bug.

Best Regards,
Krasi


On 27 May 2014 14:13, Vladislav A. VASILEV vladislavavasi...@gmail.comwrote:

 Does anybody know if this limitation still exist:

 Source CE --- Source PE --- MPLS Network --- Receiver PE --- Static IGMP
 under VRF interface (no Receiver CE)

 It works but the problem is that for no reason multicast traffic would stop
 flowing (within a few days) due to BGP withdrawing all route types (except
 neighbour discovery). Deactivating/activating the routing instance under
 the receiver PE solves the problem for a few days and it would then happen
 again. I've had a JTAC case opened for a few weeks now, but I still have
 not been given a clear answer as to whether or not this is supported.

 Thanks,
 Vladi
 ___
 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] VRRP aware IGMP/PIM

[Krasimir Avramski]

Hello,

Why you use the hello-interval of 0 on PE1 PIM configuration?
While I'm not 100% sure this probably prevents sending hello messages on
segment so potentially  PIM DR election is broken - there is possibility
both PE routers to believe they are DRs for the segment.(PE1 seeing P2'S
hellos elects himself because of highest IP address and PE2 not seeing
neighbor hellos elect himself as one and only pim router on segment)

HTH,
Krasi


On 13 May 2014 15:09, Misak Khachatryan m.khachatr...@gnc.am wrote:

 Hello,

 i have following scheme:


 PE1  CE  PE2
   |
Multicast Receiver

 PE1 - MX480
 PE2 - MX80
 CE  - EX4200

 VLAN with IGMP snooping configured on CE. VRRP and VRF with NG-MVPN
 configured on PE1 and PE2. IGMP enabled on both CE facing interfaces.

 Now both PEs sending multicast streams to receiver, despite on that one
 VRRP peer is active, second - passive, which causes unpredicted results on
 receiver side. Disabling IGMP or interface from any side makes everything
 to work perfect.

 I think there should be a way to tell IGMP that it should accept register
 messages until router is not VRRP master, but I can't find it.

 Any thoughts?

 Config parts:


 misak@PE1# show interfaces ge-0/0/1 unit 3093
 description IPTV_Ashtarak_OLT1;
 vlan-id 3093;
 family inet {
 address 10.12.0.1/20 {
 vrrp-group 112 {
 virtual-address 10.12.0.1;
 priority 255;
 fast-interval 100;
 preempt;
 }
 }
 }

 misak@PE1# show protocols igmp interface ge-0/0/1.3093
 version 3;

 misak@PE1# show routing-instances IPTV
 instance-type vrf;
 interface ge-0/0/1.3093;
 interface vt-1/3/0.0 {
 multicast;
 }
 interface lo0.1;
 route-distinguisher 65500:3093;
 provider-tunnel {
 selective {
 group 239.255.0.0/24 {
 source 10.0.242.0/23 {
 ldp-p2mp;
 }
 }
 }
 }
 vrf-target target:65500:3093;
 vrf-table-label;
 forwarding-options {
 dhcp-relay {
 forward-snooped-clients all-interfaces;
 server-group {
 IPTV_DHCP {
 10.0.237.2;
 }
 }
 group Abovyan {
 active-server-group IPTV_DHCP;
 relay-option-82 {
 circuit-id {
 use-interface-description logical;
 }
 }
 interface ge-0/0/1.3093 {
 overrides {
 allow-snooped-clients;
 always-write-giaddr;
 always-write-option-82;
 }
 }
 }
 }
 }
 protocols {
 pim {
 rp {
 local {
 family inet {
 address 10.0.238.6;
 }
 }
 }
 interface all {
 mode sparse;
 version 2;
 hello-interval 0;
 }
 }
 mvpn;
 }

 misak@PE2# show interfaces ge-1/0/9 unit 3093
 description IPTV_Ashtarak_OLT1;
 vlan-id 3093;
 family inet {
 address 10.12.0.9/20 {
 vrrp-group 112 {
 virtual-address 10.12.0.1;
 priority 100;
 fast-interval 100;
 }
 }
 }

 misak@PE2# show protocols igmp interface ge-1/0/9.3093
 version 3;

 misak@PE2# show routing-instances IPTV
 instance-type vrf;
 interface ge-1/0/9.3093;
 interface lo0.1;
 route-distinguisher 10.255.255.8:3093;
 vrf-target target:65500:3093;
 vrf-table-label;
 forwarding-options {
 dhcp-relay {
 forward-snooped-clients all-interfaces;
 server-group {
 IPTV_DHCP {
 10.0.237.2;
 }
 }
 group Abovyan {
 relay-option-82 {
 circuit-id {
 use-interface-description logical;
 }
 }
 interface ge-1/0/9.3093 {
 overrides {
 allow-snooped-clients;
 always-write-giaddr;
 always-write-option-82;
 }
 }
 }
 }
 }
 protocols {
 pim {
 rp {
 static {
 address 10.0.238.6;
 }
 }
 interface all {
 mode sparse;
 version 2;
 }
 }
 mvpn {
 receiver-site;
 }
 }

 Junos version 12.3

 --
 Best regards,
 Misak Khachatryan,
 Network Administration and
 Monitoring Department Manager,
 GNC-Alfa CJSC.
 ___
 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 external routes in database but not in routing table

[Krasimir Avramski]

domain vpn tag(external route tag) is already set to 0 - the problem is
that D/N bit is set as per RFC4576 (0x82 from your output lsa options).

Krasi


On 29 April 2014 11:05, Mohammad Salbad masal...@gmail.com wrote:

 Thank you all experts for your support and help



 Based on what I understood from you:

 In order to be able to add the ospf external routes into the routing table
 I
 shall ask the service provider to set the domain-vpn-tag value to 0 on his
 PE.

 And there nothing to be done on my MX router (CE) to ignore the DN bit set
 by the service provider PE.



 Thank you again

 M. Salbad



 From: Ivan Ivanov [mailto:ivanov.i...@gmail.com]
 Sent: Tuesday, April 29, 2014 11:01 AM
 To: Amos Rosenboim
 Cc: Mohammad Salbad; juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] OSPF external routes in database but not in routing
 table



 Hi,



 Try to configure under the OSPF stanza for removing DN bit in Type 5 LSA -
 'domain-vpn-tag 0'

 If you want to disable DN bit checks for Type 3 LSA add - 'domain-id
 disable'

 HTH,

 Ivan,





 On Tue, Apr 29, 2014 at 8:49 AM, Amos Rosenboim a...@oasis-tech.net
 mailto:a...@oasis-tech.net  wrote:

 Hi,

 I know Cisco have a configuration knob for this, I believe it's called
 vrf-capability.
 I am not sure If Juniper have something similar.

 Amos

 Sent from my iPhone


 On 29 Apr 2014, at 02:21, Mohammad Salbad masal...@gmail.com
 mailto:masal...@gmail.com mailto:masal...@gmail.com
 mailto:masal...@gmail.com  wrote:

 1.1.1.1 is PE router id

 so far we believe the issue is due to DN bit is set by the provider and
 hence the external routes are not injected in the routing table...as per
 Alberto Santos below reply to me:

  as expected in rfc4577, Type 5 LSA must set DN bit, if the router does
 not
 set it, domain tag should be used instead. I believe the PE router is
 setting the DN bit and because of the routing instance was config as VRF it
 is not installing the route, I think you should change to VR type instead.

 So I'm wondering if there is any way to ignore the DN bit for the external
 routes received from the provider ospf link? That I don't want to keep the
 instance type to be vrf NOT VR...

 Regards
 M. Salbad

 -Original Message-
 From: Payam Chychi [mailto:pchy...@gmail.com mailto:pchy...@gmail.com ]
 Sent: Tuesday, April 29, 2014 2:17 AM

 To: Mohammad Salbad; juniper-nsp@puck.nether.net
 mailto:juniper-nsp@puck.nether.net mailto:juniper-nsp@puck.nether.net
 mailto:juniper-nsp@puck.nether.net 
 Subject: Re: [j-nsp] OSPF external routes in database but not in routing
 table

 Hi Mohammad,

 - Any route-maps preventing the prefix from being installed?
 - How are you learning 1.1.1.1?


 Payam

 On 2014-04-28, 2:13 PM, Mohammad Salbad wrote:
 Dear Experts



 we have an MX router connected to a service provider network which
 provides us with OSPF L3VPN connectivity with remote branches.



 at the beginning we used to have our connection with the provider into
 a routing instance with type virtual router and we were able to
 receive external routes from remote branches from our provider ospf
 link.

 for special purposes we decided to change the instance type to be vrf
 in our MX  router.

 once we have changed the instance type to be vrf external routes
 received through our provider connection are no longer in the routing
 table although they are in the ospf data base



 Below is a sample of ospf database for one of the external routes
 which were not injected in routing table



 Extern   10.10.10.10   1.1.1.1   0x80003a74   893  0x82 0x347d  36

   mask 255.255.255.252

   Topology default (ID 0)

 Type: 2, Metric: 1, Fwd addr: 0.0.0.0, Tag: 0.0.0.0

   Aging timer 00:45:07

   Installed 00:14:52 ago, expires in 00:45:07

   Last changed 01:03:59 ago, Change count: 1



 Any Ideas???



 Regards

 M. Salbad





 ___

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


 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 mailto:juniper-nsp@puck.nether.net mailto:juniper-nsp@puck.nether.net
 mailto:juniper-nsp@puck.nether.net 

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




 --
 Best Regards!

 Ivan Ivanov

 ___
 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] maximum BGP multipath ECMP supported on M7i or M10i routers?

[Krasimir Avramski]

Hi,

Two types of balancing supported: per prefix (bgp multipath) and per flow
(ECMP next-hop including bgp multipath)
Up to 64 ECMP next-hops on MX(DPC, MPC), M120, M10i(Enhanced CFEB), M320(
FPC dependent), T(FPC dependent) for RSVP, LDP, ISIS(ipv4/6), OSPF(ipv4/6),
IBGP(ipv4/6), EBGP(ipv4/6).
Symmetric load 
balancinghttp://www.juniper.net/techpubs/en_US/junos12.2/topics/usage-guidelines/interfaces-configuring-symmetrical-load-balancing-lag-on-mx-routers.htmlover
802.3ad link aggregation groups (LAGs) on MX routers with MPCs.

Best Regards,
Krasi



On 31 March 2014 22:14, Yucong Sun sunyuc...@gmail.com wrote:

 Do anyone have in-sight on this?

 More over, I guess my quest is to find a device that support

 1) per flow hashing with as many as ECMP route as possible.  (not sure how
 many ECMP route is supported)
 2) consistent hashing (existing flow don't break if route is added or
 removed)   (juniper doc didn't mention this)

 Your opinion/experience on this is greatly appreciated.

 Thanks.


 On Fri, Mar 28, 2014 at 12:44 PM, Yucong Sun sunyuc...@gmail.com wrote:

  Hi,
 
  Does anyone know how many BGP multipath ECMP routes does a M7i/M10i
  router support? 16? 32 ? 64?
 
  I found this document :
 
 
 
 http://www.juniper.net/techpubs/en_US/junos13.3/topics/reference/configuration-statement/maximum-ecmp-edit-chassis.html
 
  which says 16/32/64  but it was only mentioning MPLS routes, not BGP
  multipath routes . I think they might be the samething, but just want
  to be sure.
 
  Thanks!
 
 ___
 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] Community matching policy

[Krasimir Avramski]

A match 100:100
B match 101:101
Your TEST1 term match on !A OR !B = !(A AND B), so it effectively rejects
every route that has NO communities 100:100 AND 101:101 (at the same time)
Your target is to accept A OR B, so you can first match and accept on these
communities (TEST1 OR TEST2 defined without invert-match) and then reject
everything else.

Best Regards,
Krasi


On 31 March 2014 12:10, Andrew Khan good1...@outlook.com wrote:

 Hi -

 Let's say I want to reject everything except the following communities:

 Either 100:100
 OR 101:101
 OR both 100:100 101:100

 Tried to setup something:

 [edit policy-options]
 policy-statement TEST {
   term TEST1 {
   from community [ TEST1 TEST2 ]; ///Is not it logical OR, and
 matching everything except what I want because of invert-match//
then reject;
}
   term TEST2 {
  then accept;    And then this should accept what I wanted /
}
 }

 [edit policy-options]
community TEST1 {
   invert-match;
members 100:100;
}
community TEST2 {
invert-match;
members 101:101;
}

 However it is rejecting everything. Any thoughts what I'm missing here or
 perhaps the approach is not correct.

 Thanks in advance.


 ___
 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] Community matching policy

[Krasimir Avramski]

With the requirement to use only invert-match community definitions let
say:
TEST1 =  everything except 100:100
TEST2 = everything except 101:101
we have !TEST1 OR !TEST2 ( these are target routes you want to accept)  =
!(!!TEST1  !!TEST2) = !(TEST1  TEST2)

So define policies:

policy-statement TEST1 {
term 1 {
from community TEST1;
then accept;
}
term 2 {
then reject;
}
}
policy-statement TEST2 {
term 1 {
from community TEST2;
then accept;
}
term 2 {
then reject;
}
}

then apply the following policy expression to BGP neighbor: (!(TEST1 
TEST2)):

group test {
neighbor a.b.c.d {
import ( ! ( TEST1  TEST2 ));
}
}


Best regards,
Krasi



On 31 March 2014 14:00, Andrew Khan good1...@outlook.com wrote:

  Hello Krasi,
 Thanks for the reply, appreciated. Sorry I did not mention in my first
 email that I'm trying to find a workaround while using invert-match. Any
 idea on achieving the same results when using invert-match.

 Kind regards,


 --
 Date: Mon, 31 Mar 2014 13:41:40 +0300
 Subject: Re: [j-nsp] Community matching policy
 From: kr...@smartcom.bg
 To: good1...@outlook.com
 CC: juniper-nsp@puck.nether.net


 A match 100:100
 B match 101:101
 Your TEST1 term match on !A OR !B = !(A AND B), so it effectively
 rejects every route that has NO communities 100:100 AND 101:101 (at the
 same time)
 Your target is to accept A OR B, so you can first match and accept on
 these communities (TEST1 OR TEST2 defined without invert-match) and then
 reject everything else.

 Best Regards,
 Krasi


 On 31 March 2014 12:10, Andrew Khan good1...@outlook.com wrote:

 Hi -

 Let's say I want to reject everything except the following communities:

 Either 100:100
 OR 101:101
 OR both 100:100 101:100

 Tried to setup something:

 [edit policy-options]
 policy-statement TEST {
   term TEST1 {
   from community [ TEST1 TEST2 ]; ///Is not it logical OR, and
 matching everything except what I want because of invert-match//
then reject;
}
   term TEST2 {
  then accept;    And then this should accept what I wanted /
}
 }

 [edit policy-options]
community TEST1 {
   invert-match;
members 100:100;
}
community TEST2 {
invert-match;
members 101:101;
}

 However it is rejecting everything. Any thoughts what I'm missing here or
 perhaps the approach is not correct.

 Thanks in advance.


 ___
 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] MX80 Route table Size

[Krasimir Avramski]

Agree.. other elements like counters, filters, descriptors etc .. but it is
dynamic allocation which isn't  the case with ichip - 16M bank for
firewalls , 16M for jtree with fixed regions. Although  there is a
workaround(
http://www.juniper.net/techpubs/en_US/junos10.4/topics/task/configuration/junos-software-jtree-memory-repartitioning.html)
for
ichip I am calculating the worst case scenario with unique inner vpn label
usage with composite nexthops.


Best Regards,
Krasi


On 24 September 2013 09:40, Saku Ytti s...@ytti.fi wrote:

 On (2013-09-24 08:49 +0300), Krasimir Avramski wrote:

  Ichip(DPC) has 16-32M RLDRAM and holds 1M routes in FIB, so 256M on trio
 is
  huge increment - it is in realm of ~5M routes(since they use dynamic
 memory
  allocation to fill up with routes only) and more than 1M labeled prefix

 I don't think this is apples to apples. The 16MB RLDRAM is just for jtree,
 while 256MB in trio has lot more than just ktree, and some elements are
 sprayed across the 4*64MB devices which make up the 256MB RDLRAM.

 I'd be quite comfortable with 2M FIB throughout the lifecycle of current
 generation, but I've never heard JNPR quote anything near this for trio
 scale.

 I'm not sure I either understand why it matters if route is labeled or
 not, if
 each route has unique label, then it means you're wasting NH space, but if
 you
 are doing next-hop-self and advertising only loopback labels, then I don't
 think labeled route should be more expensive.
 (NH lives in RLDRAM in Trio as well, and I believe it specifically is
 sprayed
 across all four RLDRAM devices).

 --
   ++ytti
 ___
 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] MX80 Route table Size

[Krasimir Avramski]

We are aware ppc on mx80 is slower than intel REs... but the original
question was for scalability not for performance/convergence.
Take a look at newer MX104 for more RE performance.

Krasi


On 24 September 2013 17:18, Nitzan Tzelniker nitzan.tzelni...@gmail.comwrote:

 Hi,

 The problem with the MX80 is not the FIB size but the slow RE
 The time it take to receive full routing table is long and to put it into
 the FIB is even worst

 Nitzan


 On Tue, Sep 24, 2013 at 10:21 AM, Krasimir Avramski kr...@smartcom.bgwrote:

 Agree.. other elements like counters, filters, descriptors etc .. but it
 is
 dynamic allocation which isn't  the case with ichip - 16M bank for
 firewalls , 16M for jtree with fixed regions. Although  there is a
 workaround(

 http://www.juniper.net/techpubs/en_US/junos10.4/topics/task/configuration/junos-software-jtree-memory-repartitioning.html
 )
 for
 ichip I am calculating the worst case scenario with unique inner vpn label
 usage with composite nexthops.


 Best Regards,
 Krasi


 On 24 September 2013 09:40, Saku Ytti s...@ytti.fi wrote:

  On (2013-09-24 08:49 +0300), Krasimir Avramski wrote:
 
   Ichip(DPC) has 16-32M RLDRAM and holds 1M routes in FIB, so 256M on
 trio
  is
   huge increment - it is in realm of ~5M routes(since they use dynamic
  memory
   allocation to fill up with routes only) and more than 1M labeled
 prefix
 
  I don't think this is apples to apples. The 16MB RLDRAM is just for
 jtree,
  while 256MB in trio has lot more than just ktree, and some elements are
  sprayed across the 4*64MB devices which make up the 256MB RDLRAM.
 
  I'd be quite comfortable with 2M FIB throughout the lifecycle of current
  generation, but I've never heard JNPR quote anything near this for trio
  scale.
 
  I'm not sure I either understand why it matters if route is labeled or
  not, if
  each route has unique label, then it means you're wasting NH space, but
 if
  you
  are doing next-hop-self and advertising only loopback labels, then I
 don't
  think labeled route should be more expensive.
  (NH lives in RLDRAM in Trio as well, and I believe it specifically is
  sprayed
  across all four RLDRAM devices).
 
  --
++ytti
  ___
  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] MX80 Route table Size

[Krasimir Avramski]

Ichip(DPC) has 16-32M RLDRAM and holds 1M routes in FIB, so 256M on trio is
huge increment - it is in realm of ~5M routes(since they use dynamic memory
allocation to fill up with routes only) and more than 1M labeled prefix
routes.


Best Regards,
Krasi


On 23 September 2013 23:51, Saku Ytti s...@ytti.fi wrote:

 On (2013-09-23 16:42 -0400), David Miller wrote:

  If your setup and/or your projections of DFZ growth will have your FIB
  hitting 1Mill routes within the estimated lifetime of the box, then a
  bigger MX with RE-S-1800x4(s) is decidedly bigger (in performance,
  route capacity, and price).

 Alas, bigger MX won't do much/anything to help with FIB scaling. You're
 inherently limited by the LU chip memory, which does not grow when you
 upgrade
 to bigger box.
 Juniper is somewhat behind the curve in FIB scale compared to competition.

 --
   ++ytti
 ___
 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] IGMP problem

[Krasimir Avramski]

Hello,
Actually this config generates PIM (*,G) joins upstream to RP.
I'm not aware of static igmp joins(generated) or igmp proxies support in
junos (excluding junosE) - though there is a  feature that translates PIM
to 
IGMP/MLDhttp://www.juniper.net/techpubs/en_US/junos11.4/topics/topic-map/mcast-message-translation.html


Krasi


On 10 September 2013 12:55, Vladislav Vasilev
vladislavavasi...@gmail.comwrote:

 Hi Robert,

 What you have below only adds the interface to the OIL for that group. No
 IGMP joins are generated!

 Regards,
 Vladislav A. VASILEV


 On 10 Sep 2013, at 07:51, Robert Hass wrote:

  Hi
  I would like to setup static IGMP joins between Cisco and Juniper.
  But it's not working. Juniper is not sending IGMP Joins.
  Same configuration Cisco + Cisco working without issues. Any clues ?
 
  Interface configuration for Juniper at Cisco side:
 
  interface GigabitEthernet1/1/1
  description Juniper
  no switchport
  ip address 10.10.10.21 255.255.255.252
  ip pim passive
  !
 
  Here is output of IGMP membership - none :(
 
  cisco#sh ip igmp membership | include GigabitEthernet1/1/1
  cisco#
 
  Here is JunOS configuration:
 
  interfaces {
 ge-0/0/0 {
 unit 0 {
 family inet {
 address 10.10.10.22/30;
 }
 }
 }
  routing-options {
 static {
 route 0.0.0.0/0 next-hop 10.10.10.21;
 }
  }
  protocols {
 igmp {
 interface ge-0/0/0.0 {
 version 2;
 static {
 group 231.0.0.3;
 group 231.0.0.4;
 }
 }
 }
 pim {
 rp {
 static {
 address 10.10.10.255 {
 version 2;
 }
 }
 }
 interface ge-0/0/0.0 {
 mode sparse;
 version 2;
 }
 join-load-balance;
 }
  }
 
  Rob
  ___
  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] VPLS Multihoming on Junos - FEC confusion

[Krasimir Avramski]

Hi,

Note the junos 7.5 release introduction of
multi-hominghttp://www.juniper.net/techpubs/en_US/junos/topics/reference/configuration-statement/multi-homing-edit-protocols-vpls.htmlstanza
(under routing-instances
instance-name protocols vpls site site-name) specified in FEC 128 doc.
Believe me that with 7.5 release only BGP signaling/autodiscovery was
supported -  I remember that at this time there was VPLS standard
battlehttp://www.lightreading.com/document.asp?doc_id=589392


Krasi


On 10 September 2013 17:18, Darren O'Connor darre...@outlook.com wrote:

 I understand that part, but it doesn't answer the original question.

 Thanks
 Darren
 http://www.mellowd.co.uk/ccie



  From: per.gran...@gcc.com.cy
  To: darre...@outlook.com; kr...@smartcom.bg
  CC: juniper-nsp@puck.nether.net
  Subject: RE: [j-nsp] VPLS Multihoming on Junos - FEC confusion
  Date: Tue, 10 Sep 2013 13:20:17 +
 
  Perhaps this is useful:
 
 
 https://www.juniper.net/techpubs/en_US/junos/topics/topic-map/vpls-bgp-multihoming.html
 
  There are two places in the configuration where you can configure VPLS
 multihoming. One is for FEC 128, and the other is for FEC 129:
 
  For FEC 128-routing-instances instance-name protocols vpls site
 site-name multi-homing
  For FEC 129-routing-instances instance-name protocols vpls multi-homing
 
 
  -Original Message-
  From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On
 Behalf Of Darren O'Connor
  Sent: Tuesday, September 10, 2013 3:53 PM
  To: Krasimir Avramski
  Cc: juniper-nsp@puck.nether.net
  Subject: Re: [j-nsp] VPLS Multihoming on Junos - FEC confusion
 
  That's my thought too. However even the 12.3 VPLS configuration guide
 states FEC128 multihoming. But again showing with BGP
 
  Thanks
  Darren
  http://www.mellowd.co.uk/ccie
 
 
 
  Date: Mon, 9 Sep 2013 23:30:08 +0300
  Subject: Re: [j-nsp] VPLS Multihoming on Junos - FEC confusion
  From: kr...@smartcom.bg
  To: darre...@outlook.com
  CC: juniper-nsp@puck.nether.net
 
  Hello,
  IMHO there is mess with docs/terms. FEC 128 multihoming as described has
 nothing to do with ldp. It's bgp signaling and autodiscovery.
  Krasi
 
 
  On 8 September 2013 22:37, Darren O'Connor darre...@outlook.com wrote:
 
 
 
 
 
 
 
  Hi list.
 
 
 
  I'm going over the VPLS multihoming options on Juniper's web site. I'm
 not concerned with LAG and MC-LAG for the moment.
 
 
 
  As far as I'm aware, FEC128 is when you are using manual discovery of
 pseudowires (LDP) - FEC129 is when you are using BGP auto-discovery.
 
 
 
  Juniper techpub for FEC129 multihoming I don't have a problem with as it
 shows how to multihome with BGP:
 https://www.juniper.net/techpubs/en_US/junos/topics/topic-map/vpls-bgp-multihoming.html
 
 
 
 
  The FEC128 multihome techpub says that you cannot enable LDP signalling,
 you have to use BGP signalling:
 http://www.juniper.net/techpubs/en_US/junos/topics/usage-guidelines/vpns-configuring-vpls-multihoming.html
 
 
 
 
 
 
  I know that you can use LDP for manual discovery and LDP will then
 signal VC labels. You can also use BGP for auto-discovery and LDP for VC
 label signalling. You can also use BGP for both.
 
 
 
  What I don't get is how you could use FEC128 with BGP signalling. Junos
 doesn't give you the option to only signal through BGP but manual discovery
 through LDP.
 
 
 
  So my question is, when exactly would the FEC128 config be used over the
 FEC129 config? If you are using BGP for signalling are you not using BGP
 for discovery at the same time?
 
 
 
  Or maybe I'm just misunderstanding something.
 
 
 
 
 
  Thanks
 
  Darren
 
  http://www.mellowd.co.uk/ccie
 
 
 
 
 
 
 
  ___
 
  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] VPLS Multihoming on Junos - FEC confusion

[Krasimir Avramski]

Hello,

IMHO there is mess with docs/terms. FEC 128 multihoming as described has
nothing to do with ldp. It's bgp signaling and autodiscovery.

Krasi


On 8 September 2013 22:37, Darren O'Connor darre...@outlook.com wrote:




 Hi list.

 I'm going over the VPLS multihoming options on Juniper's web site. I'm not
 concerned with LAG and MC-LAG for the moment.

 As far as I'm aware, FEC128 is when you are using manual discovery of
 pseudowires (LDP) - FEC129 is when you are using BGP auto-discovery.

 Juniper techpub for FEC129 multihoming I don't have a problem with as it
 shows how to multihome with BGP:
 https://www.juniper.net/techpubs/en_US/junos/topics/topic-map/vpls-bgp-multihoming.html

 The FEC128 multihome techpub says that you cannot enable LDP signalling,
 you have to use BGP signalling:
 http://www.juniper.net/techpubs/en_US/junos/topics/usage-guidelines/vpns-configuring-vpls-multihoming.html


 I know that you can use LDP for manual discovery and LDP will then signal
 VC labels. You can also use BGP for auto-discovery and LDP for VC label
 signalling. You can also use BGP for both.

 What I don't get is how you could use FEC128 with BGP signalling. Junos
 doesn't give you the option to only signal through BGP but manual discovery
 through LDP.

 So my question is, when exactly would the FEC128 config be used over the
 FEC129 config? If you are using BGP for signalling are you not using BGP
 for discovery at the same time?

 Or maybe I'm just misunderstanding something.


 Thanks
 Darren
 http://www.mellowd.co.uk/ccie



 ___
 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] L2VPN Termination

[Krasimir Avramski]

Hi,

On the core instance: set routing-instances xyz_IP_Transit protocols vpls
connectivity-type irb

Krasi


On Mon, Jul 29, 2013 at 11:35 PM, Paul Stewart p...@paulstewart.org wrote:

 Thanks folksŠ

 I have an issue with implementing this and was hoping for a sanity
 check. ;)

 On the core side of this implementation I am not taking the VPLS
 instance to any form of a physical interface - I only have an IRB
 interface and the VPLS path will not come up.  I'm assuming the VPLS path
 won't establish because of lack of a physical interface or is it just
 something else that I've misconfigured?

 Core Router (MX480):

 paul@xxx show configuration routing-instances
 xyz_IP_Transit {
 instance-type vpls;
 vlan-id 100;
 routing-interface irb.100;
 route-distinguisher xx.xx.xx.xx:100;
 vrf-target target:11666:9100;
 protocols {
 vpls {
 site-range 20;
 no-tunnel-services;
 site Core {
 site-identifier 2;
 }
 }
 }
 }

 CPE Facing Router (MX80):


 paul@dis1.peterborough4 show configuration routing-instances
 xyz_IP_Transit {
 instance-type vpls;
 vlan-id 100;
 interface ge-1/1/0.100;
 route-distinguisher xx.xx.xx.xx:100;
 vrf-target target:11666:9100;
 protocols {
 vpls {
 site-range 20;
 no-tunnel-services;
 site customer {
 site-identifier 1;
 }
 }
 }
 }


 Thanks,

 Paul


 On 2013-07-26 2:08 PM, Tarko Tikan ta...@lanparty.ee wrote:

 hey,
 
  Alternatively use routed VPLS on the core box if it is also an MX and a
  standard VPLS instance on the edge:
 
 http://www.juniper.net/techpubs/en_US/junos10.2/topics/task/configuratio
  n/vpls-irb-solutions.html
 
 +1 for this. Not a hack, we have been using this for a while now and got
 all major bugs fixed over time. In production for hundreds of thousands
 of customers.
 
 Don't use lt- interfaces if you don't have to.
 
  Or if you are game then in the next release you should get psX
  interfaces on the MX for direct PWHT although it will still be bound to
  an lt- interface underneath.  Documentation already exists for this for
  13.1.
 
 +1 for this as well. This will supposedly support all the features
 physical ports do so you can do HQoS etc.
 
 --
 tarko
 ___
 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] Internet access from VRF issue

[Krasimir Avramski]

Hi,

Make R4 RR for R1 (family inet unicast) and it should work. You will have
further intricacy on R3 accepting this route because R4 vpn-inet family
will not reset next-hop self automatically. In order to fix this you should
apply nhs for this route through explicit vrf-export policy.

The reason your OSFP routes are not advertised is that you already had
enabled RR under VPN4 family, so your vpn4 export table moved to
bgp.l3vpn.0 (from your output shared here):

R4@M7i-2# run show route advertising-protocol bgp 172.27.255.3
*bgp.l3vpn.0*: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
.
Since there are no ospf routes in this table they are not advertised.

Auto-export feature is not an option here since secondary routes are not
honoured and I'm not aware rt-export process module to hide protocols
origin ;-).
https://www.juniper.net/techpubs/en_US/junos10.1/topics/example/route-sharing-simple-overlapping-vpns-solutions.html


Best Regards,
Krasi


On Tue, Jun 4, 2013 at 11:33 PM, Alexey alexey.saz...@yandex.ru wrote:

 Mihai, Olivier,
 thanks for your response, I also suggests that it could be related with
 IBGP rules, but unfortunately making R4 route-reflector for R3 doesn't
 resolve the issue:

 R4@M7i-2# show protocols bgp
 ...
 group vpnv4-r3 {
 type internal;
 local-address 172.27.255.4;
 family inet-vpn {
 unicast;
 }
 cluster 0.0.0.1;
 neighbor 172.27.255.3;
 }

 [edit]
 R4@M7i-2#

 R4@M7i-2# run show route advertising-protocol bgp 172.27.255.3

 bgp.l3vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
 Restart Complete
   Prefix  Nexthop  MED LclprefAS path
   172.27.255.4:100:2.2.2.2/32
 * Self 1001 I
   172.27.255.4:100:172.27.0.4/30
 * Self 100I

 [edit]
 R4@M7i-2#

 Earlier I also try to use rib-group inet0-vrf which imports routes to
 inet.0 and Customer.inet.0 tables, ospf routes get into Customer.inet.0 but
 still don't get advertised to R3:

 R4@M7i-2# show protocols ospf
 rib-group inet0-vrf;

 R4@M7i-2# show routing-options rib-groups
 inet0-vrf {
 import-rib [ inet.0 Customer.inet.0 ];
 }


 The same ospf route in both tables of R4:
 R4@M7i-2# run show route protocol ospf 172.27.0.0/30

 inet.0: 32 destinations, 37 routes (30 active, 0 holddown, 2 hidden)
 Restart Complete
 + = Active Route, - = Last Active, * = Both

 172.27.0.0/30  *[OSPF/10] 00:07:35, metric 100

   to 172.27.0.10 via ge-1/3/0.41

 inet.3: 7 destinations, 11 routes (2 active, 0 holddown, 7 hidden)
 Restart Complete

 Customer.inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0
 hidden)
 + = Active Route, - = Last Active, * = Both

 172.27.0.0/30  *[OSPF/10] 00:07:35, metric 100

   to 172.27.0.10 via ge-1/3/0.41

 [edit]
 R4@M7i-2#

 But still no ospf routes advertised to R3:




 [edit]
 R4@M7i-2#


 --
 Alexey S.
 Leading engineer
 Network solutions team
 CCIE RS

 alexey.saz...@yandex.ru

 04.06.2013, 21:09, Mihai mihaigabr...@gmail.com:

 for R3, sorry :)
 
   On 06/04/2013 07:56 PM, Mihai wrote:
Hello,
 
Maybe I am wrong, but as long as R1,R3,R4 are internal bgp neighbors,
 R4
should be route reflector for R4.
 
Regards,
Mihai
 
On 06/04/2013 06:44 PM, Alexey wrote:
Hi guys,
 
Now I'm preparing for JNCIE-SP certification, and faced with problem
providing internet-access for VPN users.
 
I attach my test topology to email.
R4 and R3 are PE routers which holds vrf table Customer, R1 router
holds ipv4 static route 8.8.8.8/32 to represent Internet routes.
Between R4 and R3 there is vpnv4 IBGP session and Between R4 and R1 -
ipv4 IBGP.
 
I use rib-group to import IPv4 routes received from R1 also in table
Customer.inet.0. Routes are imported as expected and I see
 8.8.8.8/32
in vrf Customer:
R4# run show route table Customer 8.8.8.8
 
Customer.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0
hidden)
+ = Active Route, - = Last Active, * = Both
 
8.8.8.8/32 *[BGP/170] 00:50:35, localpref 100, from 172.27.255.1
AS path: I
to 172.27.0.10 via ge-1/3/0.41, label-switched-path r4-to-r1
[edit]
R4@M7i-2#
 
But the problem is that R4 doesn't pass this route from VRF to R3 via
MP-BGP.
R4@M7i-2# run show route advertising-protocol bgp 172.27.255.3
 
Customer.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0
hidden)
Prefix Nexthop MED Lclpref AS path
* 2.2.2.2/32 Self 100 1 I
* 172.27.0.4/30 Self 100 I
 
[edit]
R4@M7i-2#
 
The same task was in bootcamp lab guide book, and according to it,
other members of VRF do receive internet routes. I also tried to use
VRF export policy;vrf-table-label - nothing helps.
Please help, may be there is some knob to make it work?
 
PS:All routers are real equipment 

Re: [j-nsp] Reg: 6VPE - Inter-AS

[Krasimir Avramski]

Set ipv4-compatible ipv6 address

show interfaces ge-1/0/1
flexible-vlan-tagging;
speed 1g;
encapsulation flexible-ethernet-services;
unit 10 {
vlan-id 10;
family inet {
address 10.10.115.1/30;

family inet6 {
address :::10.10.115.1/126;
}
}
family mpls;
}



Best Regards,
Krasi



On Wed, Mar 27, 2013 at 9:35 AM, viks ... vikram4ual...@gmail.com wrote:

 Hi All,

 Am testing Inter-AS vpnv4/6 in LAB. Inter-AS vpnv4 is working, but i VPNV6
 is not working.

 The connectivity is as below...

 7206VXR[PE]7604[core]MX80[ASBR 9583] X [ASBR 101 and PE] 7206VXR.

 I can see vpnv6 routes in AS101 advertised from AS9583 . But am not seeing
 the vpnv6 routers advertised by AS101.

 ASBR101 is advertising the routes to ASBR9583, but i dont see it in
 ASBR9583.

 Attached the configurations, pls correct if the configuration is wrong.

 rgds...
 VikramS

 ___
 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] Reg: 6VPE - Inter-AS

[Krasimir Avramski]

Hi,

set protocols bgp group MPEBGP keep all

By the way you don't need ldp on asbr peer interface.

On Wed, Mar 27, 2013 at 1:19 PM, viks ... vikram4ual...@gmail.com wrote:

 Thanks Krasi, I tired that but it was not working...



 On Wed, Mar 27, 2013 at 1:49 PM, Krasimir Avramski kr...@smartcom.bgwrote:


 Set ipv4-compatible ipv6 address

 show interfaces ge-1/0/1
 flexible-vlan-tagging;
 speed 1g;
 encapsulation flexible-ethernet-services;
 unit 10 {
 vlan-id 10;
 family inet {
 address 10.10.115.1/30;

 family inet6 {
 address :::10.10.115.1/126;
 }
 }
 family mpls;
 }



 Best Regards,
 Krasi



 On Wed, Mar 27, 2013 at 9:35 AM, viks ... vikram4ual...@gmail.comwrote:

 Hi All,

 Am testing Inter-AS vpnv4/6 in LAB. Inter-AS vpnv4 is working, but i
 VPNV6
 is not working.

 The connectivity is as below...

 7206VXR[PE]7604[core]MX80[ASBR 9583] X [ASBR 101 and PE]
 7206VXR.

 I can see vpnv6 routes in AS101 advertised from AS9583 . But am not
 seeing
 the vpnv6 routers advertised by AS101.

 ASBR101 is advertising the routes to ASBR9583, but i dont see it in
 ASBR9583.

 Attached the configurations, pls correct if the configuration is wrong.

 rgds...
 VikramS

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





 --

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

Re: [j-nsp] Routing loop with OSPFv3 NSSA and external routes

[Krasimir Avramski]

Hi,

Section 4.8.5 http://tools.ietf.org/html/rfc5340#section-4.8.5.
 (Calculating AS External and NSSA Routes from OSPFv3) reference section
2.5 from NSSA http://tools.ietf.org/html/rfc3101#section-2.5 with the
assumption RFC1583Compatibility is disabled.
Seems like bug for me.

Best Regards,
Krasi


On Thu, Feb 21, 2013 at 1:55 PM, Tore Anderson t...@fud.no wrote:

 Hi list,

 I'm scratching my head over an OSPFv3 routing loop to an external NSSA
 destination that happens when extending the area to another router in
 the backbone.

 This is (hopefully) all the relevant parts of the currently (working)
 setup. The two routers R1 and R2 are MX-es running JUNOS 12.2R3,
 SW1 is an EX4200 VC running 10.4R6.

 2001:db8::1/128 gets advertised to SW1 by a host using RIPng, and SW1
 exports this route into OSPFv3.

   2001:db8::1/128
 | (RIPng-advertised)
 ~
 |
   [SW1 - ID 192.0.2.40]
 |
 | (NSSA area 10.0.0.0)
 |
 | xe-1/2/0.5
   [R2 - ID 192.0.2.4]
 | ae0.0 | xe-1/2/0.6
 |   |
 | (area 0)  | (area 0)
 |   |
 | ae0.0 | xe-1/2/0.6
   [R1 - ID 192.0.2.5]


 On R2 I can see the external NSSA route appear fine:

 R2 show ospf3 route 2001:db8::1 extensive
 Prefix   Path  Route  NH   Metric
  Type  Type   Type
 2001:db8::1/128  Ext2  NetworkIP   2
   NH-interface xe-1/2/0.5, NH-addr fe80::3
   Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium

 ...and on R1 I can see that the ABR R2 translated it into a normal
 external route and advertised it into area 0:

 R1 show ospf3 route 2001:db8::1 extensive
 Prefix   Path  Route  NH   Metric
  Type  Type   Type
 2001:db8::1/128  Ext2  NetworkIP   2
   NH-interface ae0.0, NH-addr fe80::2
   NH-interface xe-1/2/0.6, NH-addr fe80::62:2
   Area 0.0.0.0, Origin 192.0.2.4, Fwd NZ, Priority medium

 The problem occurs when I attempt to include R1 into area 10.0.0.0.
 This I do by adding ae0.0 on R1 and R2 into the area in secondary
 mode. My problem is that as soon as I do so, traffic to
 2001:db8::1/128 starts to loop between R1 and R2.

 As expected, R1 now sees the type-7 LSA generated by SW1 (and
 readvertises it into area 0 since it's now an ABR):

 R1 run show ospf3 route 2001:db8::1 extensive
 Prefix   Path  Route  NH   Metric
  Type  Type   Type
 2001:db8::1/128  Ext2  NetworkIP   2
   NH-interface ae0.0, NH-addr fe80::2
   Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium

 R2, on the other hand, for seam prefers the area 0 external route that
 was generated by R1 over the NSSA route generated by SW1:

 R2 run show ospf3 route 2001:db8::1 extensive
 Prefix   Path  Route  NH   Metric
  Type  Type   Type
 2001:db8::1/128  Ext2  NetworkIP   2
   NH-interface ae0.0, NH-addr fe80::1
   NH-interface xe-1/2/0.6, NH-addr fe80::62:1
   Area 0.0.0.0, Origin 192.0.2.5, Fwd NZ, Priority medium

 I have the exact same topology set up for IPv4/OSPFv3/RIPv2, and then
 R2 prefers the route it learned from SW1's Type-7 LSA within area
 10.0.0.0, instead of the normal external route received from R1. I would
 have expected the same to happen with OSPFv3, but for some reason the
 priorities are the other way around.

 Anyone have an idea as to whether this is a bug or if I'm doing
 something wrong here?

 BR,
 --
 Tore Anderson
 ___
 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] Junos labeled-unicast announces unusable routes, certainly this is a bug

[Krasimir Avramski]

You CAN configure both AFI=1 SAFI=1 and AFI=1 SAFI=4 on the same BGP
session by specifying inet.3 for labeled-unicast routes:
family inet {
unicast;
labeled-unicast {
rib {
inet.3;
}
}
}


And redistributing LDP/RSVP routes from inet.3 makes perfect LSP stitching
through BGP-LU by label swapping.

Best Regards,
Krasi

On Mon, Jan 21, 2013 at 12:59 PM, Jeff Wheeler j...@inconcepts.biz wrote:

 On Mon, Jan 21, 2013 at 4:27 AM, Alex Arseniev alex.arsen...@gmail.com
 wrote:
  Probably not what you want to hear at the moment but it is working as
  designed.

 No, it isn't.

 Junos BGP is announcing routes it knows, for sure, are invalid.  It
 knows that because BGP is making up a wrong label (2^20-1) because it
 hasn't allocated one, and it can't announce the route without a label.
  This is an inexcusable bug that is very far from working as
 designed.

 The documentation is wrong, you cannot configure both AFI=1 SAFI=1 and
 AFI=1 SAFI=4 on the same BGP session.  If it worked as documented, the
 above behavior would not happen, and AFI=1 SAFI=1 would be available
 to use for these routes.  That is not the case.

 --
 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

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

Re: [j-nsp] Multicast senders/receivers on the same PE (different VRF) with NG MVPN

[Krasimir Avramski]

Hi,
vt when used with multicast keyword(in configuration upon binding VT ifl
to VRF) is only used for multicast traffic replication(loopback) to
receivers living in different MVPN instances. The unicast traffic can still
use vrf-table-label, the same vt ifl as multicast, a different vt ifl than
multicast, or neither.
Also the tunnel hardware is only needed when remote PE is receiving through
P2MP LSP and has more than one MVPN instance that could have receivers for
a given source (is importing the routes for a particular source).
The VT's to PFE anchoring is defined with tunnel services
definition(slot/pic or mic) - so if needed traffic goes through fabric to
the anchor PFE for processing.


Best Regards,
Krasi

On Mon, Dec 17, 2012 at 3:02 PM, Vladislav A. VASILEV 
vladislavavasi...@gmail.com wrote:

 Hi Krasimir,

 I had only considered vt interfaces for doing filtering/additional look
 ups for traffic egressing L3VPNs (prior to the vrf-table-lable being
 available). I now have a working NG MVPN (extranet). However, what if I
 wanted to have senders/receivers physically terminated on the same router,
 but on different MPCs? Effectively, traffic wouldn't be processed by the
 same Trio chip = different vt interface!

 Thanks,
 Vladi




 On Thu, Nov 22, 2012 at 1:54 PM, Krasimir Avramski kr...@smartcom.bgwrote:

 Hi,

 NG-MVPN extranets are supported since junos 9.5:


 http://www.juniper.net/techpubs/en_US/junos11.4/topics/topic-map/mcast-mbgp-extranets.html#jd0e120

 As I remember in some corner cases(only two extranet VRFs on the same
 router - if my memory serves me right) there is NO need for tunnel hw (VT-
 ifls)  -  only  vrf-table-label (lsi ifls) should do the trick.

 Best Regards,
 Krasi

 On Thu, Nov 22, 2012 at 2:54 PM, Vladislav A. VASILEV 
 vladislavavasi...@gmail.com wrote:

 Hi all,

 I need to deliver multicast data to a receiver in a VRF, which resides on
 the same PE as the sender VRF.

 The only way I see this could be done is by putting one of the VRFs into
 a
 logical system and presenting the traffic over an lt interface. The
 problem
 is that this type of design does not scale. What if down the road I had
 another customer which wanted to receive multicast data from both the
 current sender/receiver? I'd then need to put it into another logical
 system (basically introducing another PE, being a logical one)?

 What options do I have?

 Thanks,
 Vladi
 ___
 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] Multicast senders/receivers on the same PE (different VRF) with NG MVPN

[Krasimir Avramski]

Well, juniper does NOT support fabric multicast replication, so inter PFE
multicast robustness depends on:
number of fabrics installed and fabric capacity(legacy/enhanced).
binary + unary multicast replication support - trio only mode (DPC are
not allowed) using network-services enhanced-ip.

Best Regards,
Krasi

On Mon, Dec 17, 2012 at 4:37 PM, Vladislav A. VASILEV 
vladislavavasi...@gmail.com wrote:

 Hi,

 The only thing I wasn't sure about was, whether or not the traffic goes
 through the fabric in cases where you have different VTs (I'm almost
 certain this used to be a problem).

 Thanks,
 Vladi


 On Mon, Dec 17, 2012 at 2:16 PM, Krasimir Avramski kr...@smartcom.bgwrote:

 Hi,
 vt when used with multicast keyword(in configuration upon binding VT
 ifl to VRF) is only used for multicast traffic replication(loopback) to
 receivers living in different MVPN instances. The unicast traffic can still
 use vrf-table-label, the same vt ifl as multicast, a different vt ifl than
 multicast, or neither.
 Also the tunnel hardware is only needed when remote PE is receiving
 through P2MP LSP and has more than one MVPN instance that could have
 receivers for a given source (is importing the routes for a particular
 source).
 The VT's to PFE anchoring is defined with tunnel services
 definition(slot/pic or mic) - so if needed traffic goes through fabric to
 the anchor PFE for processing.


 Best Regards,
 Krasi

 On Mon, Dec 17, 2012 at 3:02 PM, Vladislav A. VASILEV 
 vladislavavasi...@gmail.com wrote:

 Hi Krasimir,

 I had only considered vt interfaces for doing filtering/additional look
 ups for traffic egressing L3VPNs (prior to the vrf-table-lable being
 available). I now have a working NG MVPN (extranet). However, what if I
 wanted to have senders/receivers physically terminated on the same router,
 but on different MPCs? Effectively, traffic wouldn't be processed by the
 same Trio chip = different vt interface!

 Thanks,
 Vladi




 On Thu, Nov 22, 2012 at 1:54 PM, Krasimir Avramski kr...@smartcom.bgwrote:

 Hi,

 NG-MVPN extranets are supported since junos 9.5:


 http://www.juniper.net/techpubs/en_US/junos11.4/topics/topic-map/mcast-mbgp-extranets.html#jd0e120

 As I remember in some corner cases(only two extranet VRFs on the same
 router - if my memory serves me right) there is NO need for tunnel hw (VT-
 ifls)  -  only  vrf-table-label (lsi ifls) should do the trick.

 Best Regards,
 Krasi

 On Thu, Nov 22, 2012 at 2:54 PM, Vladislav A. VASILEV 
 vladislavavasi...@gmail.com wrote:

 Hi all,

 I need to deliver multicast data to a receiver in a VRF, which resides
 on
 the same PE as the sender VRF.

 The only way I see this could be done is by putting one of the VRFs
 into a
 logical system and presenting the traffic over an lt interface. The
 problem
 is that this type of design does not scale. What if down the road I had
 another customer which wanted to receive multicast data from both the
 current sender/receiver? I'd then need to put it into another logical
 system (basically introducing another PE, being a logical one)?

 What options do I have?

 Thanks,
 Vladi
 ___
 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] VPLS issues

[Krasimir Avramski]

Hi
strict is only useful in case you want to cease vpls service when all lsps
matching .*-SILVER.* are down. Default behavior (without strict keyword)
with empty(or down) install-nexthop match is to ignore term.

Since the aim is to route over single lsp why regex-lsp is used?  Why not
install-nexthop lsp *lsp-name.*
*
*
Best Regards,
Krasi




On Fri, Nov 30, 2012 at 8:59 PM, Christian cdebalo...@neotelecoms.comwrote:

 Hello,
 Any luck with the strict option at the install-nexthop ?
 Rgds,

 Christian

 Le 30/11/2012 17:41, Richard A Steenbergen a écrit :

  Does anybody have any experience with forced LSP path selection for VPLS
 circuits? Long story short, when we fire up traffic on one particular
 VPLS instance, we're seeing SOME of the traffic it's carrying being
 blackholed. The pattern is one of certain IP or even TCP port pairs
 being blocked, and it seems to rotate over time, which screams hashing
 across multiple LSPs where one of them is doing something bad, and it
 changes as the LSPs resignal over time to me. To try and lock this
 down, I'm trying to force the VPLS traffic to route over a single LSP,
 in the usual manner with a forwarding-table export policy, and a very
 simple extended community regexp against the vrf-target community.

 term VPLS {
  from community MATCH_VPLS;
  then {
  install-nexthop lsp-regex .*-SILVER.*;
  load-balance per-packet;
  accept;
  }
 }

 But it sure as hell doesn't look like it's narrowing the LSP selection:

 ras@re0.router show route forwarding-table family vpls table blah
 Routing table: blah.vpls
 VPLS:
 DestinationType RtRef Next hop   Type Index NhRef Netif
 ...
 00:xx:xx:xx:xx:xx/48 user 0  indr 1050634 5
   idxd  3223 2
 idx:1  xx.xx.142.132 Push 262153, Push
 655412(top)  4543 1 xe-7/3/0.0
 idx:1  xx.xx.142.62  Push 262153, Push
 752660, Push 691439(top)  1315 1 xe-4/1/0.0
 idx:2  xx.xx.142.132 Push 262153, Push
 758372(top)  1923 1 xe-7/3/0.0
 idx:2  xx.xx.142.62  Push 262153, Push
 382341, Push 691439(top)  2541 1 xe-4/1/0.0
 idx:3  xx.xx.142.132 Push 262153, Push
 758372(top)  1923 1 xe-7/3/0.0
 idx:3  xx.xx.142.62  Push 262153, Push
 382341, Push 691439(top)  2541 1 xe-4/1/0.0
 idx:4  xx.xx.142.30  Push 262153, Push
 714676(top)  1500 1 xe-4/1/1.0
 idx:4  xx.xx.142.62  Push 262153, Push
 619458, Push 378636(top)  3864 1 xe-4/1/0.0
 idx:xx xx.xx.142.82  Push 262153, Push
 601828(top)   989 1 xe-5/0/0.0
 idx:xx xx.xx.142.132 Push 262153, Push
 684644(top)  3516 1 xe-7/3/0.0
 idx:xx xx.xx.142.62  Push 262153, Push
 528898, Push 760875(top)  4766 1 xe-4/1/0.0
 idx:xx xx.xx.142.62  Push 262153, Push
 792036, Push 691439(top)  3473 1 xe-4/1/0.0

 Any ideas, about this or about troubleshooting the forwarding plane for
 VPLS in general? Other than that VPLS just sucks... :)


 __**_
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://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] Multicast senders/receivers on the same PE (different VRF) with NG MVPN

[Krasimir Avramski]

Hi,

NG-MVPN extranets are supported since junos 9.5:

http://www.juniper.net/techpubs/en_US/junos11.4/topics/topic-map/mcast-mbgp-extranets.html#jd0e120

As I remember in some corner cases(only two extranet VRFs on the same
router - if my memory serves me right) there is NO need for tunnel hw (VT-
ifls)  -  only  vrf-table-label (lsi ifls) should do the trick.

Best Regards,
Krasi

On Thu, Nov 22, 2012 at 2:54 PM, Vladislav A. VASILEV 
vladislavavasi...@gmail.com wrote:

 Hi all,

 I need to deliver multicast data to a receiver in a VRF, which resides on
 the same PE as the sender VRF.

 The only way I see this could be done is by putting one of the VRFs into a
 logical system and presenting the traffic over an lt interface. The problem
 is that this type of design does not scale. What if down the road I had
 another customer which wanted to receive multicast data from both the
 current sender/receiver? I'd then need to put it into another logical
 system (basically introducing another PE, being a logical one)?

 What options do I have?

 Thanks,
 Vladi
 ___
 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] Fw: L2 Circuits accross domains

[Krasimir Avramski]

Hi,

Can you share the output of:

show route table inet.3  5.1.1.2(ASN1234)
show route table inet.3 5.1.1.1  (ASN 4321)
show ldp database l2circuit   --   on both PEs

Alex, imho redistributing ldp through egress-policy wouldn't stitch mpls
transport (assume LDP) b/w remote PEs(domains).
Using ldp peering b/w ASBRs (since IGP is redistributed) should be enough
since LDP downstream unsolicited with ordered control is default for J/C.

Best Regards,
Krasi

On Tue, Nov 20, 2012 at 1:07 PM, Peter Nyamukusa
peternyamuk...@yahoo.comwrote:

 Thanks Alex,

 I had already redistibuted all my loopback into my IGP and all were
 reachable


 
 | Kind Regards,  |
 | Peter Nyamukusa|
 | MCSE-2000/2003, CCNP, CCIP, CCDP, CCVP,  |
 | JNICIS-ent, JNCIS-er, JNCIS-Sec, JNCIA-Ex, Linux+, A+   |

 -


 
  From: Alex Arseniev alex.arsen...@gmail.com
 To: Peter Nyamukusa peternyamuk...@yahoo.com;
 juniper-nsp@puck.nether.net
 Sent: Tuesday, November 20, 2012 12:28 PM
 Subject: Re: [j-nsp] Fw: L2 Circuits accross domains

 You should have remote loopbacks also redistributed into LDP (if your
 transport label is from LDP).
 In JUNOS, this does not happen by default, you must have LDP egress-policy
 for this to occur. By default, LDP announces only primary lo0.0 IP@.
 Absent this, your L2circuits would show OL error (no outgoing label).
 Before you ask, this is totally different to CSCO IOS which announces all
 routes (bar BGP ones) as LDP FECs.
 HTH
 Rgds
 Alex

 - Original Message - From: Peter Nyamukusa 
 peternyamuk...@yahoo.com
 To: juniper-nsp@puck.nether.net
 Cc: pe...@nyamukusa.com
 Sent: Tuesday, November 20, 2012 7:46 AM
 Subject: [j-nsp] Fw: L2 Circuits accross domains


 - Forwarded Message -

 From: Peter Nyamukusa peternyamuk...@yahoo.com
 To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
 Sent: Tuesday, November 20, 2012 9:33 AM
 Subject: L2 Circuits accross domains


 Hi Folks,

 I have an exsisting L3 / L2 MPLS network with Cisco ASR on the Core as PE
 router and Junper routers as PE router, i have been running l2circuits
 sucessfully for some time now with out any problems using the below configs
 on my PEs, I am running IS-IS as my IGP and BGP



 [edit protocols l2circuit]
 peter@xxx-PE1# show

 }
 neighbor 41.x.x.1 {
 interface ge-0/0/2.2001 {
 virtual-circuit-id 2001;
 description XYZ L2;
 no-control-word;

 ignore-mtu-mismatch;

 [edit interfaces ge-0/0/2]
 peter@xxx-PE1# show
 description Customers L2 Circuits;
 vlan-tagging;
 encapsulation vlan-ccc;
 unit 2001 {
 description XYZ L2;
 encapsulation vlan-ccc;
 vlan-id 2001;
 }

 Neighbor: 41.x.x.2
 Interface Type St Time last up # Up trans
 ge-0/0/2.2001(vc 2001) rmt Up Nov 13 15:29:31 2012 1
 Remote PE: 41.x.x.2, Negotiated control-word: No
 Incoming label: 299776, Outgoing label: 299776
 Local interface: ge-0/0/2.2001, Status: Up, Encapsulation:
 VLAN
 Description: XYZ L2
 Neighbor: 41.x.x.x.1
 Interface Type St Time last up # Up trans
 ge-0/0/2.2101(vc 2101) rmt Up Nov 13 15:29:28 2012 1
 Remote PE: 41.x.x.1, Negotiated control-word: Yes (Null)
 Incoming label: 299792, Outgoing label: 333568
 Local interface: ge-0/0/2.2101, Status: Up, Encapsulation: VLAN
 Description: ABC L2 - ANY POP



 Now I am trying to extend these L2 circuits to anther MPLS Domain where we
 have direct Gigabit fibre connection I am using the same concept and
 establish ospf peering on the ASBR router with the remote ASN and
 redistributed my IGP so my loopbacks are seen by the PEs on both sides of
 the domains and establish ldp peering how ever the l2circuit is not coming
 up any help is appriciated as I have been working on this more than 24hrs
 and think that i am now a bit clouded


 peter@yyy-BR1# run show l2circuit connections (ASN 1234)
 Layer-2 Circuit Connections:

 Legend for connection status (St)
 EI -- encapsulation invalid NP -- interface h/w not present
 MM -- mtu mismatch Dn -- down
 EM -- encapsulation mismatch VC-Dn -- Virtual
 circuit Down
 CM -- control-word mismatch Up -- operational
 VM -- vlan id mismatch CF -- Call admission control failure
 OL -- no outgoing label IB -- TDM incompatible bitrate
 NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration
 BK -- Backup Connection ST -- Standby Connection
 CB -- rcvd cell-bundle size bad XX -- unknown

 Legend for interface status
 Up -- operational
 Dn -- down
 Neighbor: 5.1.1.2
 Interface Type St Time last up # Up trans
 ge-0/0/0.2900(vc 2900) rmt OL

 peter@xxx-PE1# run show l2circuit connections (ASN4321)
 Layer-2 Circuit Connections:

 Legend for connection status (St)
 EI -- encapsulation invalid NP -- interface h/w not present
 MM -- mtu mismatch Dn -- down
 EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down
 CM 

Re: [j-nsp] WAN input prioritization on MX

[Krasimir Avramski]

On Mon, Oct 15, 2012 at 4:40 PM, Gustavo Santos gustkil...@gmail.comwrote:


 For instance: If the current wan ingress traffic total is 450mbits and high
 priority traffic is 100mbits, and low priority is 350mbits = no packet
 discard, but if traffic towards high priority subnet is 300mbits and low
 priority is 300mbits, then the queuing / scheduler will drop the low
 priority traffic until the sources traffic gets shaped to 200mbits for the
 low priority and the high priority gets 300mbits.

 On Linux it's quite simple to achieve.


AFAIK this is only possible with ingress queuing (EQ2, DPC-EQ hardware,
ingress CoS not enabled by default)  and simple filters:
http://www.juniper.net/techpubs/en_US/junos10.4/topics/usage-guidelines/cos-configuring-ingress-hierarchical-cos-on-enhanced-queuing-dpcs.html
http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/mf-classifiers-simple-filters-overview-cos-config-guide.html
http://www.juniper.net/techpubs/en_US/junos10.4/topics/example/mf-classifiers-example-simple-filters-cos-config-guide.html

Unfortunately MPCs are still not supported

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

Re: [j-nsp] JUNIPER POLICER and CoS Shaping Rate

[Krasimir Avramski]

Hi,

MPC/MIC interfaces take all Layer 1 and Layer 2 overhead bytes into account
when shaping.
egress-shaping-overhead configuartion is an option  - you can
add/subtract from [-63, +128] bytes.

http://www.juniper.net/techpubs/en_US/junos10.2/information-products/topic-collections/config-guide-cos/topic-43439.html

Best Regards,
Krasi


On Thu, Oct 4, 2012 at 5:54 AM, GIULIANO (WZTECH) giuli...@wztech.com.brwrote:

 People,

 Some topics where questioned today about how to limit traffic for vlan
 subscribers using MX5 routers.

 The main question is related to system architecture related to the main
 gear (internal machine) to control and limiting packets.

 Using policers (input or output) or shaping-rate we have quite the same
 result: miscalculating or error.

 If we create a rule like the following:


 set class-of-service interfaces ge-0/0/1 unit 530 shaping-rate 20m


 The output traffic rates 19.2~ Mbps only (using MRTG and SNMP statistics
 and graphics).

 We ever needs to allocate more bandwidth for the subscriber like.

 set class-of-service interfaces ge-0/0/1 unit 530 shaping-rate 22m

 To get the correct result ...

 Using policers generate almost the same result for output traffic.

 Is this because of system architecture or this is a graphic's mistake ?

 The burst size limit influence this result ? It must be calculated using
 what kind of parameter ?

 For example (same physical interface, same MTU, etc):

 Interface ge-0/0/0 unit 10 - VLAN 10 - 30 Mbps What is the correct burst ?

 Interface ge-0/0/0 unit 20 - VLAN 20 - 50 Mbps What is the correct burst ?

 Interface ge-0/0/0 unit 30 - VLAN 30 - 150 Mbps What is the correct burst ?

 Interface ge-0/0/0 unit 30 - VLAN 30 - 4 Mbps What is the correct burst ?

 Does anyone has solved this problems ?

 Is it possible to get a correct parameter and points to a correct limit
 for the contracted bandwidth ?

 Thanks a lot,

 Giuliano


 __**_
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://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] Multicast IPv6 and M-VPNv6

[Krasimir Avramski]

Hi,

ng-mvpn for v6 multicast is supported from 10.0

The same concept as v4 mvpn with the following technicalities:
http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/release-notes/10/topic-39000.html#jd0e3530

Regards,
Krasi, JNCIE-M #1051

On Wed, Mar 14, 2012 at 1:01 PM, Muhd Safwan muhammadsaf...@gmail.comwrote:

 Hi,

 Has anyone implemented the Multicast IPv6 before? How about M-VPNv6.
 If yes, is there any configuration reference that i can refer to?

 Is it the same concept with IPv4 Multicast and VPNv4 Multicast?

 Thanks

 Safwan
 ___
 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] QOS (Network Control traffic Queue)

[Krasimir Avramski]

And most flexible way since 10.0 - applying output filter to loopback
interface:
http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-cos/cos-assigning-fc-dscp-to-re-pkts.html#id-fine-grain-RE-9740


Note that filter is applied after traffic was treated by
host-outbound-traffic

Krasi
JNCIE-M #1051
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Dual Stack Aggregate Policing via Firewall Filter

[Krasimir Avramski]

Hi,
For sure it is working on MXs and suppose all M - have not enough
expirience regarding srx/j.

Krasi
On 2 Mar 2012 18:17, Devin Kennedy devinkennedy...@hotmail.com wrote:

 Thanks for your response Krasi.  Unfortunately it appears it’s not
 supported on the SRX/J series in that way.  It won’t commit stating that
 it’s the wrong platform for using the logical-interface-policer statement
 in that manner.

 ** **

 ** **

 ** **

 *From:* Krasimir Avramski [mailto:kr...@smartcom.bg]
 *Sent:* Thursday, March 01, 2012 11:16 AM
 *To:* Devin Kennedy
 *Cc:* juniper-nsp@puck.nether.net
 *Subject:* Re: [j-nsp] Dual Stack Aggregate Policing via Firewall Filter**
 **

 ** **

 Hi,
 It is possible to reference logical-interface-policer in
 interface-specific filters for inet and inet6 families.

 Krasi

 On 1 Mar 2012 16:11, Devin Kennedy devinkennedy...@hotmail.com wrote:*
 ***

 Hello:



 We are currently testing dual stack CoS on the Juniper platform and we're
 not seeing any way to aggregate the policing applied to IPv4 and IPv6.  We
 want to allocate a customer a specific amount of bandwidth, say 10m
 (including both IPv4 and IPv6 traffic in any proportional amount), and have
 the traffic policed to 10m regardless of the amount of IPv4 or IPv6
 traffic.




 I see there is an option to use a logical-interface-policer at the unit
 level:



 firewall policer 10M-policing

 {

 logical-interface-policer;

 if-exceeding {

bandwidth-limit 10m;

burst-size-limit 100k;

 }

 then discard;

 }





 interfaces {

  fe-2/0/3 {

  vlan-tagging;

   unit 200 {

   vlan-id 200;

policer {

input 10M-policing;

output 10M-policing;

 }



 However, we are policing differently for each CoS queue so we need to call
 policers via MF and BA filters.  The problem is that there has to be a
 different filter for each family (inet and inet6), so the two are not able
 to use an aggregate amount.  So if we apply the same 10m policer to each
 family it won't aggregate and instead applies an instance of the policer
 for
 each family (so a total of 20m).



 Does anyone know if it's possible to configure an aggregate policer across
 two different firewall filters?  Below is an example of what we are
 currently doing:



 ge-0/0/1 {

per-unit-scheduler;

vlan-tagging;

speed 100m;

link-mode full-duplex;

gigether-options {

no-auto-negotiation;

}

unit 2001 {

vlan-id 2001;

family inet {

filter {

output cos_filter;

}

address x.x.x.x/30;

}

family inet6 {

filter {

output cos_filter-v6;

}

address x::x/64;

}

}

 }



 The cos_filter then calls BA and MF filters such as:



 [edit]

 juniper@SRX210-2-IPV6# show firewall family inet filter cos1_MF

 term 1 {

from {

protocol [ udp tcp ];

port 2081;

}

then {

policer cos1_drop_8000K_out_medium;

count COS1_MF_counter;

forwarding-class cos1;

accept;

}

 }



 [edit]

 juniper@SRX210-2-IPV6# show firewall family inet filter cos1_ba

 term 1 {

from {

dscp [ 46 40 ];

}

then {

policer cos1_drop_8000K_out_medium;

count cos1_BA_PLP_Low_counter;

forwarding-class cos1;

accept;

}

 }



 And here is the common policer called by both the inet and inet6 filters
 (MF
 and BA for each family):



 [edit]

 juniper@SRX210-2-IPV6# show firewall policer cos1_drop_8000K_out_medium

 filter-specific;

 if-exceeding {

bandwidth-limit 8m;

burst-size-limit 1m;

 }

 then discard;





 We need that 8m to apply to both families together.  Any pointers?







 Thanks,



 Devin

 ___
 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] Dual Stack Aggregate Policing via Firewall Filter

[Krasimir Avramski]

Hi,
It is possible to reference logical-interface-policer in interface-specific
filters for inet and inet6 families.

Krasi
On 1 Mar 2012 16:11, Devin Kennedy devinkennedy...@hotmail.com wrote:

 Hello:



 We are currently testing dual stack CoS on the Juniper platform and we're
 not seeing any way to aggregate the policing applied to IPv4 and IPv6.  We
 want to allocate a customer a specific amount of bandwidth, say 10m
 (including both IPv4 and IPv6 traffic in any proportional amount), and have
 the traffic policed to 10m regardless of the amount of IPv4 or IPv6
 traffic.




 I see there is an option to use a logical-interface-policer at the unit
 level:



 firewall policer 10M-policing

 {

 logical-interface-policer;

 if-exceeding {

bandwidth-limit 10m;

burst-size-limit 100k;

 }

 then discard;

 }





 interfaces {

  fe-2/0/3 {

  vlan-tagging;

   unit 200 {

   vlan-id 200;

policer {

input 10M-policing;

output 10M-policing;

 }



 However, we are policing differently for each CoS queue so we need to call
 policers via MF and BA filters.  The problem is that there has to be a
 different filter for each family (inet and inet6), so the two are not able
 to use an aggregate amount.  So if we apply the same 10m policer to each
 family it won't aggregate and instead applies an instance of the policer
 for
 each family (so a total of 20m).



 Does anyone know if it's possible to configure an aggregate policer across
 two different firewall filters?  Below is an example of what we are
 currently doing:



 ge-0/0/1 {

per-unit-scheduler;

vlan-tagging;

speed 100m;

link-mode full-duplex;

gigether-options {

no-auto-negotiation;

}

unit 2001 {

vlan-id 2001;

family inet {

filter {

output cos_filter;

}

address x.x.x.x/30;

}

family inet6 {

filter {

output cos_filter-v6;

}

address x::x/64;

}

}

 }



 The cos_filter then calls BA and MF filters such as:



 [edit]

 juniper@SRX210-2-IPV6# show firewall family inet filter cos1_MF

 term 1 {

from {

protocol [ udp tcp ];

port 2081;

}

then {

policer cos1_drop_8000K_out_medium;

count COS1_MF_counter;

forwarding-class cos1;

accept;

}

 }



 [edit]

 juniper@SRX210-2-IPV6# show firewall family inet filter cos1_ba

 term 1 {

from {

dscp [ 46 40 ];

}

then {

policer cos1_drop_8000K_out_medium;

count cos1_BA_PLP_Low_counter;

forwarding-class cos1;

accept;

}

 }



 And here is the common policer called by both the inet and inet6 filters
 (MF
 and BA for each family):



 [edit]

 juniper@SRX210-2-IPV6# show firewall policer cos1_drop_8000K_out_medium

 filter-specific;

 if-exceeding {

bandwidth-limit 8m;

burst-size-limit 1m;

 }

 then discard;





 We need that 8m to apply to both families together.  Any pointers?







 Thanks,



 Devin

 ___
 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] l2vpn problem

[Krasimir Avramski]

encapsulation flexible-ethernet services under IFD and encapsulation
vlan-ccc under IFL(logical unit)?

Krasimir Avramski
JNCIE #1051
On 18 Oct 2011 22:32, Paul Stewart p...@paulstewart.org wrote:

 We are starting to work on migrating many layer2 LAN connections over to
 our
 MPLS environment.   I did a lab on l2vpn and it worked fine - trying it now
 as a test on a production network and it's not working ;)



 A pair of MX80's directly connected to one another - each MX80 has a
 trunked
 Ethernet port connected to a notebook computer for testing (each notebook
 supports dot1q VLAN and the proper VLAN is assigned).



 Trying to figure out why this won't work and pretty sure it's config
 related
 or my lack of understanding on something I thought I understood ;)



 Between the MX80's is iBGP and LSP's established (remote end example):



 xx.xx.100.72  11666  15798  15787   0   1  5d
 0:11:59 Establ

  inet.0: 0/0/0/0

  bgp.l3vpn.0: 0/0/0/0

  bgp.l2vpn.0: 1/1/1/0

  inet6.0: 0/0/0/0

  bgp.l3vpn-inet6.0: 0/0/0/0

  customer-1.l2vpn.0: 1/1/1/0



 paul@dis1.millbrook1# run show route receive-protocol bgp xx.xx.100.72



 inet.0: 381163 destinations, 511426 routes (381163 active, 0 holddown, 0
 hidden)



 inet.3: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)



 mpls.0: 44 destinations, 44 routes (44 active, 0 holddown, 0 hidden)



 inet6.0: 55308 destinations, 56716 routes (55308 active, 0 holddown, 0
 hidden)



 bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

  Prefix  Nexthop  MED LclprefAS path

  xx.xx.100.72:1:2:1/96

 * xx.xx.100.72 0  I



 customer-1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0
 hidden)

  Prefix  Nexthop  MED LclprefAS path

  xx.xx.100.72:1:2:1/96

 * xx.xx.100.72 0  I





 Router #1 is xx.xx.100.71 for loopback

 Router #2 is xx.xx.100.72 for loopback



 RSVP/LSP is fully established and appears operational.



 I keep getting local site signaled down status on the l2vpn:



 paul@dis1.millbrook1 show l2vpn connections

 Instance: customer-1

  Local site: dis1.millbrook1 (1)

connection-site   Type  St Time last up  # Up trans

2 rmt   LD



 Configuration on router #1 looks like this:



 interfaces {

ge-1/3/5 {

description TEST_l2vpn;

vlan-tagging;

unit 512 {

vlan-id 512;

}

   }

 }



 policy-options {

community vpn-A members target:11666:9000;

 }



 routing-instances {

customer-1 {

instance-type l2vpn;

interface ge-1/3/5.512;

route-distinguisher xx.xx.100.71:1;

vrf-target target:11666:9000;

protocols {

l2vpn {

encapsulation-type ethernet-vlan;

interface ge-1/3/5.512;

site dis1.millbrook1 {

site-identifier 1;

interface ge-1/3/5.512;

}

}

}

}

 }







 Router #2 configuration looks like this:



 interfaces {

ge-1/3/5 {

description TEST_l2vpn;

vlan-tagging;

unit 512 {

vlan-id 512;

}

}

 }



 policy-options {

community vpn-A members target:11666:9000;

 }



 routing-instances {

customer-1 {

instance-type l2vpn;

interface ge-1/3/5.512;

route-distinguisher xx.xx.100.72:1;

vrf-target target:11666:9000;

protocols {

l2vpn {

encapsulation-type ethernet-vlan;

interface ge-1/3/5.512;

site dis2.millbrook1 {

site-identifier 2;

interface ge-1/3/5.512;

}

}

}

}

 }



 Thanks for any input,



 Paul



 ___
 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] Policy-options: Logical AND for community values

[Krasimir Avramski]

import !(condition1  condition2)
where condition1 policy ACCEPT first comunity and condition2 policy ACCEPT
invert-match comunity.

Krasi
On 20 Sep 2011 17:35, Rafael Rodriguez packetjoc...@gmail.com wrote:
 Hello list,

 I've run into a snag and need some advice.

 *Goal:*
 Within a policy, reject prefixes that meet two conditions. All other
 prefixes are accepted.

 *Conditions (logical AND):*
 1) Prefix must contain a community tag of 65000:999
 2) Prefix must NOT contain a community tag of 65000:.11.. (regex)

 In condition 2) it is much easier for me to describe what I don't want
than
 it is to describe what I do want (invert-match community).

 I currently have this working but I am uncomfortable with the solution as
I
 don't quite understand why its working :)

 Here is the working policy I am uncomfortable with (rejects prefix
 10.10.10.10/32):

 *The Setup:*
 R1 sends R2 various prefixes with community tags.

 *R1 Config:*
 [edit routing-options static]
 route 10.10.10.10/32 {
 discard;
 tag 10;
 community [ 65000:999 65000:52255 ];
 }
 route 10.10.10.20/32 {
 discard;
 tag 10;
 community [ 65000:999 65000:51155 ];
 }
 route 10.10.10.30/32 {
 discard;
 tag 10;
 community 65000:51155;
 }
 route 10.10.10.40/32 {
 discard;
 tag 10;
 community 65000:12345;
 }
 route 10.10.10.50/32 {
 discard;
 tag 10;
 }

 root@R1-LAB# show policy-options policy-statement test
 from {
 protocol static;
 tag 10;
 }
 then accept

 root@R1-LAB# show protocols bgp group test
 neighbor 1.1.1.2 {
 export test;
 peer-as 65000;
 }


 *R2 Config:*
 root@R2-LAB# ...icy-statement deny
 term deny {
 from {
 protocol bgp;
 community condition1;
 }
 to {
 protocol bgp;
 community condition2;
 }
 then default-action reject;
 }

 root@R2-LAB# show policy-options community condition1
 members ^65000:999$;

 [edit]
 root@R2-LABa# show policy-options community condition2
 invert-match;
 members ^65000:.11..$;

 root@R2-Lab# show protocols bgp group test
 neighbor 1.1.1.1 {
 import deny;
 peer-as 65000;
 }

 *R2 show commands:*
 root@R2-LAB# run show route receive-protocol bgp 1.1.1.1

 inet.0: 15 destinations, 15 routes (14 active, 0 holddown, 1 hidden)
 Prefix Nexthop MED Lclpref AS path
 * 10.10.10.20/32 1.1.1.1 100 I
 * 10.10.10.30/32 1.1.1.1 100 I
 * 10.10.10.40/32 1.1.1.1 100 I
 * 10.10.10.50/32 1.1.1.1 100 I


 *Results and Questions:*
 :) it works (10.10.10.10 is filtered out b/c it has 65000:999 AND does not
 have 65000:.11..) but I don’t quite understand the relationship between
 ‘from’, ‘to’, and ‘then’ in the policy-statement. From my understand the
 ‘from’ and the ‘to’ are treated as logical ANDs. Both need to evaluate to
 TRUE. See highlighted section below, this is where I got the idea of using
 ‘from’ and ‘to’. I've never used the 'to' statement, remember being told
 that its usually used to verify which level IS-IS prefixes are destined
for.
 Anyways, I’d appreciate any feedback and clarification on the ‘from’,
‘to’,
 and ‘then’ statements.

 root@CR1-TCK1-LAB-Boca# set policy-options policy-statement test ?
 Possible completions:
 + apply-groups Groups from which to inherit configuration data
 + apply-groups-except Don't inherit configuration data from these groups
 dynamic-db Object may exist in dynamic database
 from Conditions to match the source of a route
 term Policy term
 then Actions to take if 'from' and 'to' conditions match
 to Conditions to match the destination of a route

 So I am looking for ways/options on accomplishing the listed goals from
 above. Currently I know of two ways, 1) utilizing 'from' and 'to' and 2)
 policy subroutines. Are there other ways, one better than another, etc?
 Thanks for reading.

 Cheers,
 RR
 ___
 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] Next Gen MVPN flooding assistance

[Krasimir Avramski]

Hi,

It is normal behavior with inclusive P-tunnels (in your case P2MP lsps).It
is default without explicit selective configuration.

Regards,
Krasi

On Fri, Sep 16, 2011 at 4:10 PM, Chris Evans chrisccnpsp...@gmail.comwrote:

 I took a few minutes to setup NG-MVPN using RSVP-TE P2MP LSP in my lab. I
 have 3 boxes setup in a triangle format. I have multicast flowing properly,
 however I'm seeing a weird anomaly that i'd like to get some clarification
 on.
 All of the P2MP RSVP sessions are up properly, things appear to be signaled
 properly, traffic flows properly on the devices that should be getting it.
 What I am seeing is on the sender PE, whenever there is a receiver on a
 far-end PE's requesting traffic the sender PE floods its to both downstream
 PEs. It looks to be flooding it across two LSP paths as I see traffic rates
 double what they should be. If I stop the receiver both PEs stop getting
 traffic, as expected.

 On the PE that doesn't have the receiver if I do 'show multicast route
 instance name extension' it shows that route in the table, shows that is
 received via PIM  (forwarding devices show MVPN) and it also shows it as
 pruned.

 Anyone seen this?
 ___
 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] Next Gen MVPN flooding assistance

[Krasimir Avramski]

It is RI context. Actually group and source are (C-S, C-G).
Please refer the wildcard usage in docs:
http://www.juniper.net/techpubs/en_US/junos10.1/information-products/topic-collections/config-guide-vpns/topic-40020.html

Regards,
Krasi

On Fri, Sep 16, 2011 at 5:05 PM, Chris Evans chrisccnpsp...@gmail.comwrote:

 Okay that is what I was thinking.. I had the initial configuration without
 the selective and saw the results I asked about. I then put in selective
 configuration, but am unsure if I really have it right.

 What should the source be? routing-instance IP or global IP? I assume the
 group should be SSM?


 My original configuration which I saw the flooding:
 provider-tunnel {
 rsvp-te {
 label-switched-path-template {
 default-template;

 My configuration that I made to be selective:
 provider-tunnel {
 rsvp-te {
 label-switched-path-template {
 default-template;
 }
 }
 selective {
 group 232.1.1.3/32 {
 wildcard-source {
 threshold-rate 500;
 rsvp-te {
 label-switched-path-template {
 default-template;
 }
 }
 }
 source 172.16.1.3/32 {
 rsvp-te {
 label-switched-path-template {
 default-template;


 On Fri, Sep 16, 2011 at 9:46 AM, Krasimir Avramski kr...@smartcom.bgwrote:

 Hi,

 It is normal behavior with inclusive P-tunnels (in your case P2MP lsps).It
 is default without explicit selective configuration.

 Regards,
 Krasi

 On Fri, Sep 16, 2011 at 4:10 PM, Chris Evans chrisccnpsp...@gmail.comwrote:

  I took a few minutes to setup NG-MVPN using RSVP-TE P2MP LSP in my lab.
 I
 have 3 boxes setup in a triangle format. I have multicast flowing
 properly,
 however I'm seeing a weird anomaly that i'd like to get some
 clarification
 on.
 All of the P2MP RSVP sessions are up properly, things appear to be
 signaled
 properly, traffic flows properly on the devices that should be getting
 it.
 What I am seeing is on the sender PE, whenever there is a receiver on a
 far-end PE's requesting traffic the sender PE floods its to both
 downstream
 PEs. It looks to be flooding it across two LSP paths as I see traffic
 rates
 double what they should be. If I stop the receiver both PEs stop getting
 traffic, as expected.

 On the PE that doesn't have the receiver if I do 'show multicast route
 instance name extension' it shows that route in the table, shows that
 is
 received via PIM  (forwarding devices show MVPN) and it also shows it as
 pruned.

 Anyone seen this?
 ___
 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] Difference between (AS-Path, as-override, Loops) juniper Cisco !!!

[Krasimir Avramski]

You can disable this sanity check by reverting to an really old behavior
with:
advertise-peer-as in bgp. Without as-override enabled this will delegate
as-loop responsibility to CPE.

Regards,
Krasi

On Wed, Sep 14, 2011 at 9:10 PM, medrees medr...@isu.net.sa wrote:

 Hi Experts

   Firstly, I want to explain the difference between Cisco  Juniper
 regarding the as-path attribute in BGP routes and how they overcome the
 routing loops for BGP routing between PE-CE.

 Cisco : send the BGP routes to the EBGP neighbor and the checking of the
 as-path attribute is responsibility of received neighbor and  if the
 received as-path include the local AS number the route is rejected so that
 the (allow-as in) feature can override this action in the local router or
 (as-override) feature in the sender EBGP neighbor's router.

 Juniper: Before sending the BGP route the sender check the as-path
 attribute
 and if it include AS number of the received neighbor it won't send the
 route, so that the (As-override) feature is an option to allow this routes
 to be sent but there isn't meaning for (loops ) feature which equivalent to
 (Cisco allow-as in) feature where the route won't be received unless sender
 check no routing loops may occur.

 So that, in juniper no need for (loops) command, or SOO where even if there
 is backdoor link in CE multi-homed site for the same reason (the PE or the
 sender always check the BGP routes as-path before sending it).

 Thanks in advance for your support

 Best Regards,
 Mohamed Edrees

 ___
 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] several vlans under one vpls routing instance

[Krasimir Avramski]

Missing no-tunnel-services or vt interface .

Krasi
On 3 May 2011 19:24, meryem Z merye...@hotmail.com wrote:
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] vpls and virtual switches (vlan-id none) not supported

[Krasimir Avramski]

If vlan tags are to be removed in VPLS PW how to demultiplex b/w bridge
domains in a virtual switch ?

Krasi

On Tue, Mar 22, 2011 at 1:28 PM, jbues...@jb-internetworking.com wrote:

 Hi there,

 I have the following issue:

 switch1--(ciscoPE)-(MX80)switch2
  switch3

 Switch1 is connected to a Cisco PE
 Switch2 and switch 2 are connected to a MX80 in the same bridge domain.

 The bridge-domain is configured in the virtual-switch and VPLS is
 activated.

 Now the problem is, previously when I did not needed bridging for VPLS
 (and this virtual-switches) I had enabled the command vlan-id none under
 the VPLS routing-instance.

 This command ensures that packets send over the VPLS cloud have their
 vlan-tag removed.This ensures interop with Cisco.

 Now with virtual switches this command is not supported. This means that
 the switches behind the MX have connectiviy but not towards the switch
 behind the Cisco PE.

 How can I resolve this issue?

 My config looks like:

 ge-1/0/0 {
native-vlan-id 500;
speed 100m;
mtu 1504;
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list 500;
}
}
 }
 ge-1/0/1 {
native-vlan-id 500;
speed 100m;
mtu 1504;
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list 500;
}
}
 }

 vpls1 {
instance-type virtual-switch;
interface ge-1/0/0.0;
interface ge-1/0/1.0;
protocols {
vpls {
no-tunnel-services;
vpls-id 500;
mtu 1600;
neighbor 10.110.0.2;
  }
}
bridge-domains {
vpls1 {
domain-type bridge;
vlan-id 500;
}
}
 }


 Thanks

 ___
 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] Use of lt-Interfaces on Juniper MX for binding multiple VPLS Instances to several CCC (unidirectional Ethernet P2P) Servcies RxTx-loop to same interface

[Krasimir Avramski]

Hi,

Can you share more details of application requiring such transitions?
Why not just use p2mp lsps inside vlps for flooded traffic:
http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-vpns/vpns-flooding-unknown-traffic-using-point-to-multipoint-lsps.html#id-11510467

HTH,
Krasi

On Fri, Oct 8, 2010 at 3:17 PM, Prochaska Gerhard 
gerhard.procha...@a1telekom.at wrote:


 Hi Roger !

 I am able to glue a VPLS Instance together with a CCC Service using a
 physical Hairpin. But alas to spend two 10G Interfaces just to stich a
 service 

 Next thing i tried was to use the LT-Interface. I was surprised to see that
 i can only replicate unidirectional Traffic (eg Audio or Video) on a VPLS
 Instanz and then send it over the Netzwork with
 P2MP LSPs by stitching the services on an lt-Interface and that it does NOT
 work in the other direction.

 I wanted to replicate the streams on in the Target Node (as i do on the
 source node) using a VPLS Instance and binding the lt- port to the VPLS.
 Its strange but this did NOT work.

 So i like to find out if this is a bug or if there is a reason for this
 behaviour.

 Next i tried to use just a single port for the physical loop. Two ports are
 too expensive. Maybe i do something wrong in my config here for i m not
 familiary what can be done with
 VLAN Tag swapping and what restrictions exist here.

 What i mean with single port physical loop is that i connect the Rx and Tx
 Fiber of the same port and loop back the traffic exiting from one interface
 back to the same physical interface.
 I guess i can do this as VLAN-CCC wont do any MAC learning.

 The only thing is when i define the whole port with:

 encapsulation flexible-ethernet-service
 flexible-vlan-tagging

 and then define a unit which i like to connect to the VPLS Instance and one
 to bind to the CCC Service i can not find the correct syntax to swap
 VLAN-IDs to make traffic arriving on one the CCC unit
 go to the VPLS unit when reinserted to the port by the RxTx-Loop.

 Do you know if this can be done ?

 greetings
 Gerhard


 
 Von: roger ratcliff [mailto:ratcliff.ro...@googlemail.com]
 Gesendet: Freitag, 08. Oktober 2010 13:42
 An: Prochaska Gerhard
 Betreff: Re: [j-nsp] Use of lt-Interfaces on Juniper MX for binding
 multiple VPLS Instances to several CCC (unidirectional Ethernet P2P)
 Servcies

 Hi Gerhard !

 As ccc is an uniderectional service it might be possible that the behaviour
 on an LT Interface differs for vpls to ccc stitching an ccc to vpls
 stitching.
 Is an interesting question as ccc is much easier to implement than standard
 Layer 2 point to point services. Please let me know the results if you get
 out of forum response for that problem.

 roger

 On Thu, Oct 7, 2010 at 7:05 PM, Prochaska Gerhard 
 gerhard.procha...@a1telekom.atmailto:gerhard.procha...@a1telekom.at
 wrote:

 When i tie a VPLS Instance to a CCC Service using an lt-Interface:

 Interface lt-x/x/x
  unit 100
  encapsulation vlan-vpls
   vlan-id 100
   peer-unit 200

  unit 200
  encapsulation vlan-ccc
  vlan-id 100
  peer-unit 100

 protocol connections

 p2mp-receive switch name
  transmitt-p2mp-lsp p2mp-lsp-name
  input-interface lt-x/x/x.200

 Everything works as expected. So the lt-Interface transports traffic from
 the VPLS Instance to the p2mp Tree.
 When i change my config to pass traffic from the CCC Side to a VPLS
 Instance via an lt-Interface my troubles start.

 Interface lt-x/x/x
  unit 100
  encapsulation vlan-vpls
   vlan-id 100
   peer-unit 200

  unit 200
  encapsulation vlan-ccc
  vlan-id 100
  peer-unit 100

 protocol connections

 p2mp-receive switch name
  receive-p2mp-lsp p2mp-lsp-name
  output-interface lt-x/x/x.200

  monitor interface lt-x/x/x shows traffic arriving at the lt-Interface from
 the CCC Side but it is not passed on to the VPLS.

 Is this expected behaviour or a bug ? In other words:

 As CCC is a unidirectional service did Juniper only implement the VPLS -
 CCC direction and skip the CCC - VPLS Part or should an LT-Interface
 alsways be usable to tie VPLS and CCC together in both directions.

 VPLS - CCC as well as CCC - VPLS.

 Quick response would be very welcome !!

 Thx
 Gerhard


 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.netmailto:
 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] Filtering the export of VRF routes with iBGP export filters....

[Krasimir Avramski]

Well, a typical scenario is interpovider vpn(option B,C) where ASBR
should advertise vpn nlri only from selected customer sites(vrfs) to
external peers.Route Target Filtering(rfc4684) is another option but
although great automation/reduction achieved regarding route
information flows, care should be taken when external peering is
involved.

Cheers,
Krasi

On Tue, Aug 31, 2010 at 8:56 PM, Keegan Holley
keegan.hol...@sungard.com wrote:
 Have you tried any of the other suggestions?  I don't think I've ever had to
 export a group of routes and then filter then anyway.  Just out of curiosity
 where did this requirement come from?  Route reflection usually provides
 enough reduction in the routing table size.


 On Tue, Aug 31, 2010 at 10:44 AM, David Ball davidtb...@gmail.com wrote:

 Thanks Krasimir.  I'd run across that knob previously, but my
 understanding
 is that the functionality provided by vpn-apply-export is enabled when a
 router is configured as a route-reflector, which mine are already.  Will
 give it a whirl anyways, though.

 David


 On 31 August 2010 04:25, Krasimir Avramski kr...@smartcom.bg wrote:

  You probably missing  vpn-apply-export stanza in your bgp cluster
  group.
 
  HTH
  Krasi
 
  On Mon, Aug 30, 2010 at 11:25 PM, David Ball davidtb...@gmail.com
  wrote:
    Ts/MXs running 10.0.R3.10
  
   I don't have access to my actual configs, but think I can verbalize
   anyways.
  
    Does anyone know if it's possible to filter a given VRF route prior
   to
   export to an iBGP peer?  Naturally, the route itself includes an RD
   and
  RT,
   and I can't get my 'match' clauses to work.
  
    I've been trying matching on things like community (ie. community
  SOMENAME
   members target:###:###), on RIB (ie. rib bgp.l3vpn.0), and also using
   a
   route-filter (which I don't believe supports VRF routes), but with no
   success.  For interest's sake, I'm running in 'route-reflector-ready'
  mode,
   in that routes are being exported from bgp.l[2|3]vpn.0 rather than
   from
  the
   individual routing tables themselves, hence my trying to match on the
   bgp.l3vpn.0 RIB instead of an individual VRF's RIB.
  
    I was sure I saw a workaround listed here, but can't find it in the
   archives for the life of me.
  
   David
   ___
   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] Stealing from MX firewall jtree space

[Krasimir Avramski]

Yep, and the reason is that they are hidden in primary rib, so as secondary
routes (which primary routing table is inet.0) in secondary rib they are
inherently hidden.

The policy itself is working correctly - secondary routes are in the rib but
marked as hidden.

Unfortunately we should give up...

Regards,
Krasi

 -Original Message-
 From: Richard A Steenbergen [mailto:r...@e-gerbil.net]
 Sent: 18.12.2009 9:21 AM
 To: Krasimir Avramski
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Stealing from MX firewall jtree space
 
 On Wed, Dec 16, 2009 at 11:37:06PM +0200, Krasimir Avramski wrote:
  What about terminating bgp neighbor in inet.0 with bgp operating over
  a rib-group under family inet:
 
  protocols bgp
  group xy {
  neighbor x.x.x.x {
  import xy;
  family inet {
  unicast {
  rib-group xy;
  }
  }
  }
  }
 
  Then import routing-policy xy states:
 
  policy-statement xy
  term 1 {
  from community to_inet_0;
  to rib inet.0;
  then accept;
  }
  term 2 {
  to rib inet.0;
  then reject;
  }
  term 3 {
  from community to_vrf;
  to rib vrf.inet.0;
  then accept;
  }
  term 4 {
  to rib vrf.inet.0;
  then reject;
  }
 
 Hrm so I was testing this, and noticed an odd behavior... When you
 reject the route from inet.0 (for example, like you're doing in term 2)
 it also rejects the route in all other ribs, even if you explicitly
 accept them (like in your term 3). Term order doesn't seem to matter
 (putting term 3 before term 2 doesn't help), and it only happens to
 routes that you reject to inet.0 (rejecting the routes to another rib
 doesn't reject it from inet.0). Other attribute modifications appear to
 work as expected, I only see this problem when you reject the route, but
 setting localpref to 0 doesn't help if this is a more specific route so
 it isn't a true replacement for a working reject into inet.0.
 
 The multi-topology routing features are much closer to what I'm actually
 trying to accomplish, but unfortunately it is missing pretty much every
 feature that would be needed to do anything useful with it (ability to
 import from another topology, ability to use policy-statements to
 control your protocol import, etc). Sigh, no way to win. :)
 
 --
 Richard A Steenbergen r...@e-gerbil.net   http://www.e-gerbil.net/ras
 GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

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

Re: [j-nsp] Stealing from MX firewall jtree space

[Krasimir Avramski]

Hello,

route-memory-enhanced introduced in 9.6

What about terminating bgp neighbor in inet.0 with bgp operating over a
rib-group under family inet:

protocols bgp
group xy {
neighbor x.x.x.x {
import xy;
family inet {
unicast {
rib-group xy;
}
}
}
}

Then import routing-policy xy states:

policy-statement xy
term 1 {
from community to_inet_0;
to rib inet.0;
then accept;
}
term 2 {
to rib inet.0;
then reject;
}
term 3 {
from community to_vrf;
to rib vrf.inet.0;
then accept;
}
term 4 {
to rib vrf.inet.0;
then reject;
}


Best Regards,
Krasi

On Wed, Dec 16, 2009 at 10:25 PM, Richard A Steenbergen 
r...@e-gerbil.netwrote:

 On Wed, Dec 16, 2009 at 11:54:33AM -0800, Derick Winkworth wrote:
  ##
  To allocate more memory for routing tables, include the
 route-memory-enhanced
  statement at the [edit chassis] hierarchy level:
  [edit chassis]
  route-memory-enhanced;
  ##
 
  You have to restart the FPC once you do this...

 What code is that in? No love in 9.5.

 --
 Richard A Steenbergen r...@e-gerbil.net   http://www.e-gerbil.net/ras
 GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
 ___
 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] flow-route questions.

[Krasimir Avramski]

Hi, 


 While thinking about using RFC5575 (flow routes), i found at
 least some questions that i'm not able to answer.
 
 a) RFC clearly states that 'flow routes must be validated'
 and describes validation procedure using destination-prefix
 attribute. But at the same time RFC does not enforce
 destination-prefix attribute to be present in flow specifications,
 and does not provide any detail on how to validate flow specifications
 missing destination-prefix - i.e., should validation procedure
 drop them all or should it accept all such flowspecs ?
 I suppose that as the latter case opens a too large security hole
 (imagine customer that blackholes all google.com by setting only
 source-address), JunOS implements former case at least on eBGP links,
 but that behaviour is not confirmed in documentation...
 

If destination-prefix is missing implementation tend to default(0.0.0.0/0),
so you MUST have active default route pointing to originator in order to
validate.

 b) As far as flow specs are the part of the same BGP session
 as the usual inet-unicast routes - are they subject of the
 same import policy configured for peer/peer-group or the
 validation procedure is the only import policy for these NLRI ?
 If the former case is correct - are there any way to distinguish
 inet-unicast and inet-flow NLRI ? (Why it's important for us:
 we're using prefix-filters to filter our client announces,
 and, as far as we should not require explicit route-object
 configured for any destination client may wish to filter - inet-unicast
 routes should proceed filtered as usually, but for flowspec's
 there is prefix-limit and validation procedure, and that seems
 to be enough).

Flowspecs are subject of import policy

 c) Is there any way to filter some flow specifications from
 client announces ? F.e., i do not like idea that my customer
 may request mapping some traffic to network-control priority
 by the means of flowspecs...


AFAIK current junos implementation doesn't support traffic marking actions.
Since the actions are defined though extended communities it is possible to
filter by matching on them:

policy-statement flow {
term 1 {
from {
rib inetflow.0;
community rate;
}
then reject;
}
term 2 {
then accept;
}
}
community rate members traffic-rate:*:*;
community redir members redirect:*:*;
community traf-action members traffic-action:*:*;



 d) And, finally: unfortunately, not all our customers runs Juniper :(
 Is there any way to 'translate' some customer updates (classic
 blackhole by /32 route with specific community) into flow routes ?

Might be this requires PSDP RE SDK ;-) or external route server to
translate.

Keep in mind there is no compatibility of flowspecs, extended dhcp
subscriber and input FTF in the same route table.

HTH,
Krasimir
Avramski

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

Re: [j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables Issue

[Krasimir Avramski]

Hi, 

It seems the router is RR or ebgp for family inet-vpn. In this case routes
in vrf tables are exported to global bgp.l3vpn.0 with respective vrf-export
policies.

I'm pretty sure the problematic routes are being advertised to remote PEs
but with missing communities. This can be checked:

show route advertising-protocol bgp remote PE ip 61.217.192.0/18 detail

In order to solve just add rt-premium community for desired routes in
vrf-export policy applied to CT vrf. 

HTH,
Krasi

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Jimmy Halim
 Sent: 08.10.2009 4:35 AM
 To: ntari...@juniper.net; juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables Issue
 
 Hi Tarique,
 
 For your info, I have escalated this to JTAC as well. Waiting for their
 update.
 
 Hi guys,
 
 Anyone has encountered the same issue before?
 Bgp.l3vpn table is receiving routes from direct peering that is
 provisioned
 on the same PE. This shouldn't be the case.
 And that PE only advertising routes to other PEs under bgp.l3vpn table,
 and
 they are not advertising any routes on any of VRF tables defined on that
 PE.
 
 Thanks  Regards,
 Jimmy
 
 -Original Message-
 From: Jimmy Halim [mailto:ji...@pacnet.net]
 Sent: Tuesday, October 06, 2009 11:13 AM
 To: 'ntari...@juniper.net'; 'juniper-nsp@puck.nether.net'
 Subject: RE: [j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables Issue
 
 Hi Tarique,
 
 I have tried it. But it is still not being advertised :(
 
 Regarding my query, for strange reason bgp.l3vpn table in router A is
 storing the routes that learned via direct BGP peering that being
 provisioned in router A. I believe this shouldn't be the case. bgp.l3vpn
 table only should store routes that are learned via other PEs.
 
 
 show route table bgp.l3vpn.0 20.139.160.0/20
 
 bgp.l3vpn.0: 316660 destinations, 316660 routes (316660 active, 0
 holddown,
 0 hidden)
 + = Active Route, - = Last Active, * = Both
 
 1.1.1.1:9001:20.20.0.0/16 - 1.1.1.1:9001 is RT of CT vrf
*[BGP/170] 5d 23:44:00, MED 100, localpref 250
   AS path: 123 321 I
  to 20.20.20.1 via ge-0/2/0.0 
 
 So, router A is advertising those routes learned via direct BGP peering
 under bgp.l3vpn table. There are no routes being advertised out to other
 PEs
 under CT vrf table or premium vrf table.
 
 Thanks  Regards,
 Jimmy
 
 -Original Message-
 From: Nalkhande Tarique Abbas [mailto:ntari...@juniper.net]
 Sent: Monday, October 05, 2009 6:11 PM
 To: Jimmy Halim; juniper-nsp@puck.nether.net
 Subject: RE: [j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables Issue
 
 
 Hi Jimmy,
 
 How about adding another term in your premium-export policy ..
 
 term export-CT {
 from community csr-CT-vrf;
 then accept;
 }
 
 ... before reject on both the sides.
 
 
 Coming to your query on direct route in bgp.l3vpn table, do you mean this
 is
 a direct route from inet.0? Is this BGP peer not under any VRF  at a
 global
 level?
 
 
 
 Thanks  Regards,
 Tarique A. Nalkhande
 
 -Original Message-
 From: Jimmy Halim [mailto:ji...@pacnet.net]
 Sent: Monday, October 05, 2009 2:52 PM
 To: Nalkhande Tarique Abbas; juniper-nsp@puck.nether.net
 Subject: RE: [j-nsp] Layer 3 VPN Routing and Forwarding (VRF) Tables Issue
 
 Hi Tarique,
 
 Yes, I am leaking CT crf routes into premium vrf on router A using the
 community.
 
 policy-options policy-statement csr-rib-policy-from-CT-vrf-peer term aloha
 {
 from {
 community csr-CT-vrf;
 }
 to rib vrf_premium.inet.0;
 then {
 accept;
 }
 }
 
 ==
 Export policy on router A:
 
 routing-instances vrf_premium:
 instance-type vrf;
 route-distinguisher 1.1.1.1:9005;
 vrf-export premium-export;
 vrf-table-label;
 
 
 policy-options policy-statement premium-export:
 term add-premium {
 from protocol [ direct static bgp ];
 then {
 community add rt-premium;
 accept;
 }
 }
 then reject;
 
 
 community rt-premium:
 members target:10026:9005;
 
 ===
 Import policy on router B:
 
 routing-instances vrf_premium:
 instance-type vrf;
 route-distinguisher 2:2:2:2:9005;
 vrf-import premium-import;
 vrf-table-label;
 
 
 policy-options policy-statement premium-import term add-premium {
 from community rt-premium;
 then accept;
 }
 then reject;
 
 
 community rt-premium:
 members target:10026:9005
 
 
 By the way, what do you think of the route table bgp.l3vpn.0?
 Is it correct to say that it shouldn't show the direct peering routes that
 is provisioned on the same PE?
 
 route table bgp.l3vpn.0 61.217.192.0/18
 
 bgp.l3vpn.0: 316803 destinations, 316803 routes (316803 active, 0
 holddown,
 0 hidden)
 + = Active Route, - = Last Active, * = Both
 
 

Re: [j-nsp] firewall policer

[Krasimir Avramski]

Hi,

Apply the same filter to both IFLs.

Filter-specific policer shares bandwidth if you use it multiple times in
the same filter (for example a policer referenced under multiple filter
terms)


If you use a filter applied to multiple IFLs and filter is NOT explicitly
defined as interface-specific (which is default) then policer is shared on
all filter instances where applied.

And hey, this will work only if IFLs where the filter applied are under the
same I-chip(PFE) group. There is no way to share policer instance between
different PFEs.

HTH,
Krasi

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Bit Gossip
 Sent: 03.07.2009 5:30 PM
 To: Sean Clarke
 Cc: juniper-nsp
 Subject: Re: [j-nsp] firewall policer
 
 Unfortunately I have tested it but the result is that the policer
 operates independently on the 2 interfaces with the result that the
 total out of the 2 GE is 2000k and not 1000k.
 
 Any idea way and how I can get it to work in aggregate fashion.
 
 Thanks,
 bit.
 
 On Wed, 2009-04-15 at 13:53 +0200, Sean Clarke wrote:
  The way you have done it, the bandwidth will be shared
 
 
  Adding filter-specific knob to the policer will make them unique ...
 i.e.
 
  policer P {
   filter-specific;
   if-exceeding {
   bandwidth-limit 1000k;
   burst-size-limit 15k;
   }
   then discard;
  }
 
 
 
  On 4/15/09 1:33 PM, Bit Gossip wrote:
   platform MX480 junos 9.3
  
   in the following config the same policer is appllied to 2 different
   interfaces via 2 different firewall filters.
  
   Will the policer police at 1 mbps the aggregate traffic of the 2
   interfaces; or it will police independent at 1 mbps the 2 differrent
   interfaces?
  
 ge-5/2/1 {
unit 0 {
filter {
output F1;
}
}
}
   ge-5/2/2 {
unit 0 {
filter {
output F2;
}
}
}
  
   policer P {
if-exceeding {
bandwidth-limit 1000k;
burst-size-limit 15k;
}
then discard;
   }
  
   filter F1 {
term NATIONAL {
from {
source-class C1;
}
then {
policer P;
count C1;
accept;
}
}
term REMAINING {
then {
count REMAINING;
accept;
}
}
   }
   filter F2 {
term NATIONAL {
from {
source-class C2;
}
then {
policer P;
count C2;
accept;
}
}
term REMAINING {
then {
count REMAINING;
accept;
}
}
   }
  
  
   ___
   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] flow-routes then routing-instance action

[Krasimir Avramski]

Hi Felix,

I loaded your setup and it works for me.
First if you expect icmp (destination unreachable) replies you should change 
the the 10.10.5.7/32 host route to reject  - otherwise although redirected to 
RI testFlow they are silently discarded.

How you decided the traffic is not passing VRF?
Which junos version?

Regards,
Krasi


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:juniper-nsp-
 [EMAIL PROTECTED] On Behalf Of Felix Schueren
 Sent: Wednesday, October 15, 2008 2:44 PM
 To: j-nsp
 Subject: [j-nsp] flow-routes then routing-instance action
 
 I can't wrap my head around how the routing-instance config on Junos
 should look like for me to be able to use a flow route to put traffic
 into the routing instance, maybe one of you can help.
 
 I have a flow route like this:
 
 show configuration routing-options flow
 route flow-test {
 match {
 destination 10.5.6.7/32;
 source 192.168.9.8/32;
 }
 then routing-instance target:20773:5656;
 }
 
 which is propagated through the core. The whole flow distribution stuff
 works, I can discard or rate-limit by flow-routes just fine.
 
 anyhow, from inetflow.0:
 
 10.5.6.7,192.168.9.8/96 (1 entry, 1 announced)
 *BGPPreference: 170/-101
 Next hop type: Fictitious
 Next-hop reference count: 11
 State: Active Int Ext
 Local AS: 20773 Peer AS: 20773
 Age: 19:28:54
 Task: BGP_20773.10.30.255.225+58095
 Announcement bits (1): 0-Flow
 AS path: I ()
 Communities: 20773:667 no-advertise redirect:20773:5656
 Localpref: 100
 
 
 I have a routing instance like this:
 
 [edit routing-instances testFlow]
 [EMAIL PROTECTED] show
 instance-type vrf;
 route-distinguisher 20773:5656;
 vrf-target target:20773:5656;
 routing-options {
 static {
 defaults {
 resolve;
 }
 route 10.5.6.7/32 discard;
 route 0.0.0.0/0 next-table inet.0;
 }
 }
 
 (yeah, it's moot that way, I could just as well filter etc, it's just a
 test setup, get the basics right before I start the interesting stuff).
 
 My problem is: traffic does not seem to get directed into the instance.
 Do I need to use a different instance-type? Any other ideas?
 
 Kind regards,
 
 Felix
 
 --
 Felix Schueren, Head of NOC
 
 Host Europe GmbH - http://www.hosteurope.de
 Welserstraße 14 - D-51149 Köln - Germany
 Telefon: (0800) 4 67 83 87 - Telefax: (01805) 66 32 33
 HRB 28495 Amtsgericht Köln - UST ID DE187370678
 Geschäftsführer: Uwe Braun - Patrick Pulvermüller - Stewart Porter
 ___
 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] VPLS LM Status?

[Krasimir Avramski]

A typical usage of multiple local sites is multihoming. One site can be
multihomed another not.

I noticed you complain for this but it should work - just specify site
preferences in multihomed sites ( although I think bgp selection should fall
down skipping some steps like lowest IGP metric ..)

 

The mesh-groups is notion in regards to split-horizon rules in VPLS.

They are used (9.1) for interoperability between LDP and BGP signaling.

Also will be used is future releases for H-VPLS ( ldp sig) and inter-AS
VPLS.

 

In your setup the local mesh-groups (interfaces under site-IDs) should
forward flooded and learned traffic  - working as designed.

 

Regards,

Krasi 

 

  _  

From: Marlon Duksa [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 05, 2008 8:14 AM
To: Krasimir Avramski
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] VPLS LM Status?

 

It works. Thanks.
Can you please elaborate a bit more  what do you mean by local mesh-groups?
I tried to forward learned traffic as well as flooded from interfaces
between local sites and interfaces within local sites...traffic was flowing
in any case.
Are those mesh groups supposed to supress some traffic? Not quite sure what
is the purpose of multiple local sites? If I have many interfaces in a
single site, wouldn't that work as well?
Thanks,
marlon



On Mon, Aug 4, 2008 at 1:30 AM, Krasimir Avramski [EMAIL PROTECTED] wrote:

Hello,

Only one pseudowire is setup between PEs of a VPLS domain.

There are already pseudowires 1-2 and 1-3, so site ID 1 is minimum
designated in PE for this VPLS domain. At the forwarding plain you should
not have any problems in communication between interfaces in site 4 to local
interfaces in site 1 and remote site IDs 2 and 3.
LM, RM states are not considered errors, that is more information for the
pseudowire selection.

Think of a site (VE) as a selection of PE-CE interfaces (local mesh-group)
for a vpls domain.

Also when configuring multihoming specify the site preferences in order PEs
to solve collisions and choose single forwarder.


Regards,
Krasi


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:juniper-nsp-
 [EMAIL PROTECTED] On Behalf Of Marlon Duksa
 Sent: Monday, August 04, 2008 1:16 AM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] VPLS LM Status?

 Does anyone know why would I get the LM status (local site ID not minimum
 designated) on my VPLS connection.
 I have two sites configured on a single PE in the same VPLS.
 One site is coming up just fine, but the other is not.

 The remote side for the 'not up' connection is complaining with the RM
 status (remote site ID not minimum designated).

 What does this 'ID not minimun designated' mean?
 My sites ID are unique withing the VPLS and within the range that is
 defined
 for the site-range.

 This is the config on my local router:

 [EMAIL PROTECTED] show routing-instances
 vpls {
 instance-type vpls;
 interface ge-0/1/1.0;
 interface ge-8/2/0.0;
 interface ge-5/3/4.0;
 route-distinguisher 100:100;
 vrf-target target:200:200;
 protocols {
 vpls {
 site-range 10;
 no-tunnel-services;
 site green {
 site-identifier 1;
 interface ge-0/1/1.0;
 interface ge-8/2/0.0;
 }
 site multi {
 site-identifier 4;
 interface ge-5/3/4.0;
 }
 }
 }
 }




 And this is the status:

 [EMAIL PROTECTED] run show vpls connections
 Layer-2 VPN connections:

 Legend for connection status (St)
 EI -- encapsulation invalid  NC -- interface encapsulation not
 CCC/TCC/VPLS
 EM -- encapsulation mismatch WE -- interface and instance encaps not
 same
 VC-Dn -- Virtual circuit downNP -- interface hardware not present
 CM -- control-word mismatch  - -- only outbound connection is up
 CN -- circuit not provisioned- -- only inbound connection is up
 OR -- out of range   Up -- operational
 OL -- no outgoing label  Dn -- down
 LD -- local site signaled down   CF -- call admission control failure
 RD -- remote site signaled down  SC -- local and remote site ID collision
 LN -- local site not designated  LM -- local site ID not minimum
 designated
 RN -- remote site not designated RM -- remote site ID not minimum
 designated
 XX -- unknown connection status  IL -- no incoming label
 MM -- MTU mismatch   MI -- Mesh-Group ID not availble

 Legend for interface status
 Up -- operational
 Dn -- down

 Instance: vpls
   Local site: green (1)
 connection-site   Type  St Time last up  # Up
 trans
 2 rmt   Up Aug  3 22:02:16 2008
 1
   Local interface: lsi.1048578, Status: Up, Encapsulation: VPLS
 Description: Intf - vpls vpls local site 1 remote site 2
   Remote PE: 2.2.2.2, Negotiated control-word: No
   Incoming label: 262154, Outgoing label: 800032
 3

Re: [j-nsp] Next Gen MVPN and signalling protocol

[Krasimir Avramski]

Hello,

You can change preference of rsvp signaled lsps globally or per LSP :

set protocols mpls preference 10


or only for particular lsp:
 
set protocols mpls label-switched-path xxx preference 10

Krasi

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:juniper-nsp-
 [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
 Sent: Thursday, June 26, 2008 4:35 PM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] Next Gen MVPN and signalling protocol
 
 Hi group,
 
 This is my problem:
 
 We have an MPLS backbone using LDP. We are configuring Next Gen MVPN.
 For that we have to configure RSVP on all the core router. The problem
 is that we would like to keep LDP for the data and RSVP for the
 multicast, but like RSVP has a preference of 7 and LDP has a preference
 of 9, all the traffic use now the LSPs created with RSVP.
 The easiest way will be to increase RSVP preference to 10, but I can't
 do it.
 
 I am studying some advanced options like install-nexthop lsp lsp-name,
 traffic-engineering bgp-igp, traffic-engineering mpls-forwarding,
 but it seems not to be the good way. May be an other idea will be to use
 an other routing-table just for multicast for each L3-VPN.
 
 Do you have some advices?
 
 Thanks !
 Samuel
 ___
 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] VPN ID for BGP VPLS

[Krasimir Avramski]

Yes, 
The VE ID is site-identifier,

protocols {

vpls {
vpls-id id-name; # LDP signaling only.
neighbor neighbor-id; # LDP signaling only.
site-range 10; #BGP signaling only.
mac-table-size 1024; 

site greenPE1 { #BGP signaling only.
site-identifier 1;
interface fe-0/1/0.0;

Regards,
Krasi

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Monika M
Sent: Friday, October 26, 2007 11:51 AM
To: juniper-nsp
Subject: [j-nsp] VPN ID for BGP VPLS

Does Juniper have a way to configure VPN ID for VPLS instances?


Regards,
Monika M.
___
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