BGP sessions towards internal route reflectors were up and established for almost one month. After adding the new BGP group, ALL sessions went down/reset and are now up and established.

The strange thing is, we don't see this behaviour in MX-960. We have several MX-104 and the issue happened in two of them, were we implemented new BGP groups.

It seems to me that this issue is MX-104 specific. Can anybody try this on a real device? (in lab, please!) The idea is to validate this behaviour.

Thanks.

Hi,

AFAIK STM protection accross 2 nodes can be achieved with APS:

http://www.juniper.net/documentation/en_US/junos15.1/topics/example/sonet-basic-aps-support-configuring.html

However I am not sure about the l2circuit protection.

Apparently, ALU has a solution for this scenario, although the below scenario is ATM:

https://infoproducts.alcatel-lucent.com/html/0_add-h-f/93-0267-HTML/7X50_Advanced_Configuration_Guide/MC-APS_PW-RED.pdf

I believe in JUNOS, this could be done using l2circuit backup neighbors in a full-mesh of primary & backup:-

#show protocols l2circuit 
neighbor 192.168.0.3 {
    interface ge-0/0/1.0 {
        virtual-circuit-id 10;
        backup-neighbor 192.168.0.4 {
            virtual-circuit-id 11;
        }
    }
}

Worth testing in a lab.

Typically I see this requirement from large institutions that connect VPN with many customers.  They are asking that the traffic you send them have a source address that is in a public space controled and assigned to you.  This prevents routing issues on the many tunnels they have needing to coordinate the use of RFC1918 addresses across many companies without overlap.

This is NOT the same as NAT-T (NAT traversal) of your VPN gateway.

For this application you could use one of the public addresses assigned to you by your ISP and place this on the st0 interface then create source NAT on interface rules for traffic you send into the tunnel.

Thanks a lot Steve, I was thinking same and configured mtu 9000 on core facing interfaces and interfaces connected to CE and even on CE I configured 9000 MTU. After that I am able to achieve ping with payload size of 1450 even under vpls site MTU is configured 2000

Is it possible to create a VC whose 2 members are each a VR, and each of these VR run in a logical system on separate, standalone MX480?

I know this may be a crazy idea, but I have severe power, space and budget constraints.  I am exploring all possible ideas as to how to support WAN and ISP connectivity in 2 separate buildings.

Hi guys,

Hope you could help me on this. Some days ago found that a vrf label of a VPLS was mapped to 2 different LSI interfaces each corresponding to a different VRF and actually a different logical system:

1 label mapped to 2 different LSIs:

> show route forwarding-table label 262147
Routing table: default.mpls
MPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
262147 user 0 Pop 2195 2 lsi.1049345

Logical system: MIAV
Routing table: default.mpls
MPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
262147 user 0 Pop 2759 2 lsi.17826311

VPLS 1:

> show vpls connections instance vpls-CUSTOMER-A

Instance: vpls-CUSTOMER-A
Edge protection: Not-Primary
Local site: MIA
connection-site Type St Time last up # Up trans
3 rmt Up Jun 1 18:27:05 2016 1
Remote PE: 10.10.10.31, Negotiated control-word: No
Incoming label: 262147, Outgoing label: 262210
Local interface: lsi.1049345, Status: Up, Encapsulation: VPLS
Description: Intf - vpls vpls-CUSTOMER-A local site 2 remote site 3

VPLS 2 (in logical system):

> show vpls connections instance vpls-CUSTOMER-B logical-system MIAV

Instance: vpls-CUSTOMER-B
VPLS-id: 3793
Neighbor Type St Time last up # Up trans
10.0.120.204(vpls-id 3793) rmt Up Jun 1 18:27:13 2016 1
Remote PE: 10.0.120.204, Negotiated control-word: No
Incoming label: 262147, Outgoing label: 262194
Negotiated PW status TLV: No
Local interface: lsi.17826311, Status: Up, Encapsulation: VLAN
Description: Intf - vpls vpls-CUSTOMER-B neighbor 10.0.120.204 vpls-id 3793
Flow Label Transmit: No, Flow Label Receive: No

I have 2 particular questions here...

1) How is equipment determining to which LSI will traffic be mapped to?

2) Is this normal behavior? Shouldn't be a unique label allocated to a VRF despite it being on default or user logical system? Don't they all share a common forwarding plane?

Thanks in advance.

This feels like something is wrong.  The MTU overhead for VPLS VLANs is only 4, so the 1450 limit has to be imposed somewhere in the path.  

Where are you sending the ping from and to? 

Hello Folks,

Kind of new to Juniper but slowly working my way through the transition from Cisco to Juniper. Have a problem I just can't seem to wrap my head around with a GRE in a routing-instance.

I have two sites that I'm trying to connected together via a GRE residing inside a routing instance. At the R1 site the GRE is sourced from the loopback lo0.0 and at R3 it's destination is an actual interface. I want to pass OSPF over this tunnel between the two routing instances. The tunnel doesn't appear to be coming up and the OSPF peers don't either since the tunnel never comes up.  There is another site that sits between the two sites that functions as part of the transport between the two sites and routing in the global inet.0 is functioning as expected.

R1

root# run show configuration | display set

set version 15.1F3.11

set system syslog user * any emergency

set system syslog file messages any notice

set system syslog file messages authorization info

set system syslog file interactive-commands interactive-commands any

set interfaces em0 unit 0 family inet address 10.10.10.1/30

set interfaces em1 unit 0 family inet address 172.16.1.1/29

set interfaces em2 unit 0 family inet address 172.16.1.2/29

set interfaces em3 unit 0 family inet address 134.123.1.1/24

set interfaces gre unit 100 tunnel source 10.10.10.1

set interfaces gre unit 100 tunnel destination 10.10.10.2

set interfaces gre unit 100 family inet address 192.168.1.1/30

set interfaces gre unit 200 tunnel source 20.20.20.1

set interfaces gre unit 200 tunnel destination 10.10.10.6

set interfaces gre unit 200 family inet mtu 1400

set interfaces gre unit 200 family inet address 192.168.100.1/30

set interfaces lo0 unit 0 family inet address 20.20.20.1/32

set protocols ospf area 0.0.0.0 interface gre.100

set protocols ospf area 0.0.0.0 interface lo0.0

set routing-instances DELTA-CIC instance-type virtual-router

set routing-instances DELTA-CIC interface em1.0

set routing-instances DELTA-CIC interface em3.0

set routing-instances DELTA-CIC protocols ospf area 0.0.0.49 interface em1.0

set routing-instances DELTA-CIC protocols ospf area 0.0.0.49 interface em3.0 passive

set routing-instances NDCS instance-type virtual-router

set routing-instances NDCS interface em2.0

set routing-instances NDCS interface gre.200

set routing-instances NDCS routing-options static route 10.10.10.6/32 next-table inet.0

set routing-instances NDCS routing-options static route 20.20.20.1/32 next-table inet.0

set routing-instances NDCS protocols ospf area 0.0.0.49 interface em2.0

set routing-instances NDCS protocols ospf area 0.0.0.49 interface gre.200

R2

root> show configuration | display set

set version 15.1F3.11

set system syslog user * any emergency

set system syslog file messages any notice

set system syslog file messages authorization info

set system syslog file interactive-commands interactive-commands any

set interfaces em0 unit 0 family inet address 10.10.10.2/30

set interfaces em1 unit 0 family inet address 10.10.10.5/30

set interfaces gre unit 100 tunnel source 10.10.10.2

set interfaces gre unit 100 tunnel destination 10.10.10.1

set interfaces gre unit 100 family inet address 192.168.1.2/30

set interfaces lo0 unit 1 family inet address 20.20.20.2/32

set protocols ospf area 0.0.0.0 interface gre.100

set protocols ospf area 0.0.0.0 interface lo0.1 passive

set protocols ospf area 0.0.0.0 interface em1.0

R3

root# run show configuration | display set
set version 15.1F3.11
set system syslog user * any emergency
set system syslog file messages any notice
set system syslog file messages authorization info
set system syslog file interactive-commands interactive-commands any
set chassis network-services ethernet
set interfaces em0 unit 0 family inet address 10.10.10.6/30
set interfaces em1 unit 0 family inet address 172.16.2.1/29
set interfaces em2 unit 0 family inet address 172.16.2.2/29
set interfaces em3 unit 0 family inet address 134.123.2.1/24
set interfaces gre unit 200 tunnel source 10.10.10.6
set interfaces gre unit 200 tunnel destination 20.20.20.1
set interfaces gre unit 200 family inet mtu 1400
set interfaces gre unit 200 family inet address 192.168.100.2/30
set protocols ospf area 0.0.0.0 interface em0.0
set routing-instances DELTA-CIC instance-type virtual-router
set routing-instances DELTA-CIC interface em2.0
set routing-instances DELTA-CIC interface em3.0
set routing-instances DELTA-CIC protocols ospf area 0.0.0.0 interface em2.0
set routing-instances DELTA-CIC protocols ospf area 0.0.0.0 interface em3.0 passive
set routing-instances NDCS instance-type virtual-router
set routing-instances NDCS interface em1.0
set routing-instances NDCS interface gre.200
set routing-instances NDCS routing-options static route 20.20.20.1/32 next-table inet.0
set routing-instances NDCS routing-options static route 10.10.10.6/32 next-table inet.0
set routing-instances NDCS protocols ospf area 0.0.0.0 interface em1.0
set routing-instances NDCS protocols ospf area 0.0.0.49 interface gre.200

Any help in figuring this out would be very much appreciated.

Thanks

Mike

Thank you rakesh for your explaination

Hello,

I see that you have GRE not in the routing instance, how do you propose to carry the updates from Instance of let us R1 to instance of other Router R2 ? I dont see any mpls nor vrf-lite sort of configuration. Basically you got to have either of these two or a way to leak routes from Routing-instance to global to make this happen

Regards

Rakesh

Hi,

Which  Junos version and Platform is this code running on ? Have you captured any packets to see what is the MTU that you are receiving on the PE interface end ?

Regards

Rakesh

I appreciate your efforts Sylar, thanks.

I spoke with my colleague who explained that we're not using an user-defined template as we clearly specify the ipv4-template under services flow-monitoring.

Am I missing something? What could be causing version9 netflow not coming in while version5 netflow works fine. We really want to work with version9 as it offers a lot more.

I've gone through the restrictions section and haven't really noticed anything that could be a solution. It might be just me. If anyone needs more specific information to help troubleshoot I'd gladly provide it.

Hi,

AFAIK, the BGP reset behavior is same accross all JUNOS platforms when changes are applied to BGP family, MX480 and MX960 inclusive.

Can you paste the diff of the changes ['show configuration | compare rollback x'] that caused the BGP reset.

Cheers,

Ashvin

Hello Rakesh,

I should have explained it a little better..  The GRE(100) from R1 to R2  is part of the global and it rides a direct service provider connection.  It's really just part of the transport between site R1 and R3 and won't reside in and routing-instances.

GRE(200) on the other hand goes from R1 to R3 to join the NDCS routing-insances at both site R1 and R3. 

Thanks

MIke

Hi, 

Each logical system has independent label space, so when a packet arrives at given LS( depending on how you interconnect LSs) it is processed on LS's own context(RIB and FIB) and takes different LSI IFL (which has common parent IFD and should be unique per LS)

HTH,

Krasi

Question about mx80 ram usage.

The mx80 RE has only 2G ram. Which kind of features/scaling would you expect? I'm asking because we are facing some issues and i would like to know if those are expected or if there's a config error or bug etc.

The box1 (mx80) is a RR. It has approx 45 bgp sessions (mostly v4 and vpnv4, also some v6). 2 times full v4 table and one full v6 table. Mpls PE functions, a approx 15 vrfs etc. Ram usage reported by "show chas routing-eng" is 95%. I think this is quite high. Is this expected?

Calculating the ram usage so that "inact" ram is free yields over 10% lower figure.

Box2 is same hw, same junos, almost same features and number of routes. But 10% lower ram usage. There's no single process explaining the difference. E.g. rpd res/size figure is almost the same. I have not found the explanation looking at process lists.

Both boxes are running Junos 13.3R6.5.

Would MX104 be much better form this perspective? It has 4G ram.

Do you have any other tips on how to proceed the troubleshooting?

Thanks

Hello,

This is a ages-old well-known problem with Logical Routers/Systems.

Because each LR/LS has independent Routing Process Daemon a.k.a. RPD, these RPDs run in uncoordinated fashion/are free to pick any label and guess what - with label algorithm being the same, the LR/LS RPDs pick overlapping labels!

Your choices are:

1/ do not use LS for MPLS at all

2/ use "vrf-table-label" only in 1 LS, others can use VT interfaces

3/ host LS uplinks/"core-facing" interfaces on separate FPCs.

HTH

Thx

Alex

Hi 

AFAIK "gre"  interface is not intended for transit traffic. Try to replace "gre" interfaces with gr-0/0/10

I see you are using vMX , so enable tunnel services:

# show chassis
fpc 0 {
pic 0 {
tunnel-services {
bandwidth 1g;
}
}
}

HTH,

Krasi

Hi,

I did a quick setup in my lab and looks like you have few things to setup w.r.t to configuration

1. The static routes which you have defined in NCDS.inet.0 for respective loopbacks would not work as you might have to use a rib-group definition.

here is the sample config which works for me, let me know if you have anything to ask

routing-options {
    interface-routes {
        rib-group inet NDCS;
    }
    rib-groups {
        NDCS {
            import-rib [ inet.0 NDCS.inet.0 ];
        }
    }
}

on R3

lab# show protocols ospf 
rib-group NCDS; -------> specific case here as you want your gre to destine to loopback of r1 and in my topology its been learnt by ospf, you can swap protocol of your choice, logic remains the same.
area 0.0.0.0 {
    interface all;
}

lab# show routing-instances NDCS                            
instance-type virtual-router;
interface gre.200;
routing-options {
    static { --> this definition has no effect
        route 10.10.10.6/32 next-table inet.0;
        route 20.20.20.1/32 next-table inet.0;
    }
}
protocols {
    ospf {
        area 0.0.0.0 {
            interface all;
        }
    }
}

once you apply rib-groups this is how routing tables appear, you can always control the routes you want via a policy

lab# run show route 

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

10.10.10.0/30      *[Direct/0] 00:48:46
                    > via lt-1/0/10.12
10.10.10.1/32      *[Local/0] 00:48:46
                      Local via lt-1/0/10.12
10.10.10.4/30      *[OSPF/10] 00:40:07, metric 2> to 10.10.10.2 via lt-1/0/10.12
20.20.20.1/32      *[Direct/0] 00:48:46> via lo0.0
224.0.0.5/32       *[OSPF/10] 00:41:01, metric 1
                      MultiRecv

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

10.10.10.0/30      *[Direct/0] 00:29:14
                    > via lt-1/0/10.12
10.10.10.1/32      *[Local/0] 00:29:14
                      Local via lt-1/0/10.12
10.10.10.6/32      *[Static/5] 00:36:53
                      to table inet.0
20.20.20.1/32      *[Direct/0] 00:29:14> via lo0.0
                    [Static/5] 00:35:57
                      to table inet.0
192.168.1.0/30     *[Direct/0] 00:39:51> via gre.200
                    [OSPF/10] 00:05:25, metric 1> via gre.200
192.168.1.1/32     *[Local/0] 00:39:51
                      Local via gre.200
224.0.0.5/32       *[OSPF/10] 00:05:30, metric 1
                      MultiRecv

[edit]
lab@MX480-re0# run show ospf neighbor instance NDCS    
Address          Interface              State     ID               Pri  Dead
192.168.1.2      gre.200                Full      192.168.1.2      128    33


[edit]
lab@MX480-re0# run ping 192.168.1.1 routing-instance NCDS    
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.775 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.788 ms
^C
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.775/0.782/0.788/0.006 ms

Hello Krasi,

Your indeed correct that it's vMX that I have running virtually as a Qemu host in GNS3 to simulate a real world task that I'm working on. 

Tried to enable tunneling services but I have a feeling since it's a Qemu host running in GNS3 that poses problems.  That said I can get GRE 100 that connects R1 and R2 to come up no problem and peer up OSPF between R1 and R2.  I would assume which can be certainly wrong that tunnel 200 should be able to come up if the configuration was correct since tunnel 100 does come up.

Another interesting twist to this is if at R1 I use a physical interface instead of the loopback it works.  Had to change to loopback though because the 10.10.10.0/30 subnet between R1 and R2 isn't distributed to the rest of the network due to who the provider is.  Different IP's/subnets for the real network.

Thanks Again

Mike