Depending on configuration , but i think this is expected behaviior . Thy to read this
Re: MX-104 bgp neighbor go down -strange behavior-
Re: L3vpn
Hi,
Imangine this is the scenario
r1----bgp----r2-----bgp----CE(r3)-------PE1---------------------PE2------------CE(r4)----------r5-----------r6
Now r3 who is the cutomer edge router has already his internal network setup , how will PE1 vrf know about his internal network routes without running dynamic protocol, sure you can write static routes but that isnt managable, hence you need to have a dynamic routing protocol which gets all the customer routes from CE and then redistributes them to PE bgp process.
Re: MX-104 bgp neighbor go down -strange behavior-
Hi,
On a quick replication i did not see any flaps for default family
[edit] labroot:r1# set protocols bgp group ebgp neighbor 9.9.121.2 peer-as 200 [edit] labroot:r1# commit commit complete [edit] labroot:r1# run show bgp summary Groups: 2 Peers: 3 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 9.9.101.2 100 7 6 0 0 1:49 0/0/0/0 0/0/0/0 9.9.111.2 100 6 5 0 0 1:45 0/0/0/0 0/0/0/0 9.9.121.2 200 0 0 0 0 2 Active
I see from your output that a new vpn table is being advertised , were you trying to add a new address family support something similar like below, then you would definitely see a bump
labroot:r1# set protocols bgp family inet-vpn unicast [edit] labroot:r1# set protocols bgp group ebgp neighbor 9.9.121.2 peer-as 200 [edit] labroot:r1# commit commit complete [edit] labroot:r1# run show bgp summary Groups: 2 Peers: 3 Down peers: 3 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 0 0 0 0 0 0 bgp.l3vpn.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 9.9.101.2 100 0 0 0 0 2 Active 9.9.111.2 100 0 0 0 0 2 Active 9.9.121.2 200 0 0 0 0 2 Active
Re: Is it possible to set an mpls based layer3 vpn on my mx 960 router?
Hi,
It would definitely support, how about your configuration. Junos requires you to configure MPLS family on the interface with appropriate Label distribution protocol be it be Ldp / Rsvp.
Quick documenation link
http://www.juniper.net/techpubs/en_US/junos11.4/information-products/pathway-pages/product/11.4/
Quick reference for mpls configuration guide
Re: Not receiving netflow v9, v5 works.
This is what the configuration looks like at the moment:
When changing it from version9 to version5 netflow comes in perfectly fine.
Re: Not receiving netflow v9, v5 works.
Hi,
Am going throug the config snippet but in the mean while can you see if you are hitting any points from the restrictions section mentioned in the below document
Re: Not receiving netflow v9, v5 works.
"User-defined version 9 templates are not supported."
- + family inet {
- + output {
- + flow-server **.**.**.** {
- + port 2222;
- + version9 {
- + template {
- + ELK;
- + }
- + }
- + }
- services {
- + flow-monitoring {
- + version9 {
- + template ELK {
- + ipv4-template;
- + }
- + }
- + }
- + }
Could this be the problem? I defined "ELK" as a template.
Re: MX-104 bgp neighbor go down -strange behavior-
HI,
It is expected behaviour.
If you add any family on BGP group global level, it is applicable for all neighbor. during this change all bgp session will re-establish.
to avoid, apply family on neighbor level instead of BGP group global level.
e.g.
set protocols bgp group ebgp neighbor 9.9.121.2 family inet-vpn unicast
Re: Is it possible to set an mpls based layer3 vpn on my mx 960 router?
Hi,
have you added interface under protocol mpls, RSVP or LDP ?
have you apply family mpls on interface ?
If you are using LDP then lo0 should be part of protocol LDP.
Re: MX-104 bgp neighbor go down -strange behavior-
We didn't modify the internal BGP group. We just added another group. So I think this shouldn't be normal. Coming from Cisco, haven't seen this behaviour in any of their platforms.
Community add
Hi
Looking to blackhole traffic from anything annouced from community AS123:666 and pass this onto the upstream provider, but config isnt working during testing..
Have I configured the community "add" correctly?
set policy-options community AS123-666 members 123:666
set policy-options policy-statement ANNOUNCED-BY-AS123-IPV4 term 1 from route-filter x.x.x.x/32 address-mask 255.255.252.0
set policy-options policy-statement ANNOUNCED-BY-AS123-IPV4 term 1 from route-filter x.x.x.x/32 address-mask 255.255.254.0
set policy-options policy-statement ANNOUNCED-BY-AS123-IPV4 term 1 then community add AS123-666
set policy-options policy-statement ANNOUNCED-BY-AS123-IPV4 term 1 then accept
set policy-options policy-statement ANNOUNCE-TO-NTT-IPV4 term 3 from community RTBH
set policy-options policy-statement ANNOUNCE-TO-NTT-IPV4 term 3 then community add AS123-666
set policy-options policy-statement ANNOUNCE-TO-NTT-IPV4 term 3 then accept
Regards
Chris
Re: MX-104 bgp neighbor go down -strange behavior-
Reason for the flap is:
"code 6 (Cease) subcode 6 (Other Configuration Change), Reason: Configuration change - VPN table advertise"
It appears a BGP family change was also applied. This is standard BGP behavior and would be same accross vendors I suppose, Cisco included.
how can i check incoming interface
Hi,
Junos MX with a few bgp session to peers. There is a simple way to check the active incoming ineterface for some prefix/packet from console ?
thanks
Ted
Re: how can i check incoming interface
If it is transit traffic and you know which prefixes you are looking for, you could apply a firewall filter on the ingress interface to match the prefixes, count and log them for viewing the type of traffic. However, do not forget to add the "accept" action, else it would drop the traffic.
Unfortunately, "monitor traffic interface x/x/x" cannot be used to monitor transit traffic.
Re: Not receiving netflow v9, v5 works.
HI,
Probably so, I tried on a lab box with your configuration and it dint work for me either. At this point, i can assume we are hitting the limitation or there is a remote possibilty that we are missing on some config knob which seems unlikely as per documenation.
Protect an STM-1 interface.
Hello,
I have to protect an STM-1 interface that's connected to ADM device.
Currently we have only one router carrying these "unpacked" E1s and transported accross MPLS/IP network by using l2circuits.
I have made a search on Junos Documentation (http://www.juniper.net/documentation/en_US/junos15.1/topics/concept/sonet-aps-msp-overview.html) and found something about APS, however this documentation says that APS implementation doesn't work with l2circuits, I can't find anything on documentation regarding protect STM-1 using l2circuits. Can you please help find out this documentation?
Below the current scenario.
Thanks in Advance
Current scenario:
ADM ------ MX10 -------- MPLS/IP Network
Protected scenario desired:
ADM-------------MX10 ----------------------------- |
| |--------------MPLS/IP Network
|-------- MX10 ------------------------------|
Current configuration at unprotected router:
chassis{
fpc 1 {
pic 2 {
framing sdh;
vtmapping klm;
}
}
}
Interfaces {
cau4-1/2/0 {
partition 1-63 interface-type e1;
}
cstm1-1/2/0 {
no-partition interface-type cau4;
}
cau4-1/2/1 {
partition 1-63 interface-type e1;
}
cstm1-1/2/1 {
no-partition interface-type cau4;
}
e1-1/2/1:1 {
encapsulation satop;
unit 0;
}
e1-1/2/1:2 {
encapsulation satop;
unit 0;
}
e1-1/2/1:3 {
encapsulation satop;
unit 0;
}
e1-1/2/1:4 {
encapsulation satop;
unit 0;
}
e1-1/2/1:5 {
encapsulation satop;
unit 0;
}
e1-1/2/1:6 {
encapsulation satop;
unit 0;
}
e1-1/2/1:7 {
encapsulation satop;
unit 0;
}
e1-1/2/1:8 {
encapsulation satop;
unit 0;
}
e1-1/2/1:9 {
encapsulation satop;
unit 0;
}
e1-1/2/1:10 {
encapsulation satop;
unit 0;
}
cau4-1/2/2 {
partition 1-63 interface-type e1;
}
cstm1-1/2/2 {
no-partition interface-type cau4;
}
e1-1/2/2:25 {
encapsulation satop;
unit 0;
}
e1-1/2/2:26 {
encapsulation satop;
unit 0;
}
e1-1/2/2:29 {
encapsulation satop;
unit 0;
}
e1-1/2/2:30 {
encapsulation satop;
unit 0;
}
cau4-1/2/3 {
partition 1-63 interface-type e1;
}
cstm1-1/2/3 {
no-partition interface-type cau4;
}
}
Protocols{
l2circuit {
neighbor 10.14.3.3;
neighbor 10.14.3.11 {
interface e1-1/2/1:1.0 {
virtual-circuit-id 351012301;
description RtES5-AsdES2-GRI-E1-1;
ignore-encapsulation-mismatch;
ignore-mtu-mismatch;
}
interface e1-1/2/1:2.0 {
virtual-circuit-id 351022302;
description RtES5-AsdES2-GRI-E1-2;
ignore-encapsulation-mismatch;
ignore-mtu-mismatch;
}
interface e1-1/2/1:3.0 {
virtual-circuit-id 351032303;
description RtES5-AsdES2-GRI-E1-3;
ignore-encapsulation-mismatch;
ignore-mtu-mismatch;
}
interface e1-1/2/1:4.0 {
virtual-circuit-id 351042304;
description RtES5-AsdES2-GRI-E1-4;
ignore-encapsulation-mismatch;
ignore-mtu-mismatch;
}
interface e1-1/2/1:5.0 {
virtual-circuit-id 351052305;
description RtES5-AsdES2-GRI-E1-5;
ignore-encapsulation-mismatch;
ignore-mtu-mismatch;
}
}
--- not displayed all the l2circuits on the router.
}
Re: MX-104 bgp neighbor go down -strange behavior-
Hello,
I'm sorry but I do no see any BGP going down with these logs:
Jun 1 14:45:54 DEVICE-re0 rpd[1541]: %DAEMON-4: bgp_adv_main_update:8762: NOTIFICATION sent to NEIGHBOR-1 (Internal AS MY AS): code 6 (Cease) subcode 6 (Other Configuration Change), Reason: Configuration change - VPN table advertise
This log is a Notification sent to the neighbor.
Jun 1 14:45:54 DEVICE-re0 rpd[1541]: %DAEMON-4: bgp_adv_main_update:8762: NOTIFICATION sent to NEIGHBOR-2 (Internal AS MY AS): code 6 (Cease) subcode 6 (Other Configuration Change), Reason: Configuration change - VPN table advertise
This log says there's an BGP advertise, that's normal as the routing-table has changed, It has to update neighbors
Jun 1 14:45:54 DEVICE-re0 rpd[1541]: %DAEMON-4: bgp_set_peer_if: BGP peer NEIGHBOR-3 (External AS ISP AS) interface not found. Leaving peer idled
This message it's a litle more to worry about, it's seems when the new peer was added, there weren't interface for this neighbor, BGP status went to idle.
Base on this logs, I do not see any neighbor going down, I do not see BGP DOWN neighbor message.
Are you sure the new neigbor comes up?
Do you see the timers for old BGP neighbors reseted?
Regards,
LordofOceans
Re: MX-104 bgp neighbor go down -strange behavior-
Hi,
As per RFC4486, the Cease code is a notification message to signal BGP reset:
If a BGP speaker decides to administratively reset the peering with a neighbor due to a configuration change other than the ones described above, then the speaker SHOULD send a NOTIFICATION message with the Error Code Cease and the Error Subcode "Other Configuration Change".
https://tools.ietf.org/html/rfc4486
This indicates that the local router has initiated a BGP session reset and has notified its peers about the reset.
Also, Notification messages are sent to signal an error.
The BGP session Uptime can be verified with "show bgp summary".
For the new neighbor, is it Established or down?
Can you check in the respective routing-table if you see an active direct route towards the peer as the BGP config suggests an eBGP. Is this a direct or multihop eBGP peering?
Hope this helps.
Cheers
Ashvin
Re: Protect an STM-1 interface.
Re: Protect an STM-1 interface.
Hello,
Thanks for providing the link, but this won't help me.
Maybe it can helps for the second phase, but not to protect the STM-1.
Here we need to protect the STM-1 if the primary router fails, the backup router as to assume the STM-1 connection, meaning the ADM has to switch traffic for the backup router.
Please see the attached picture, it gives a beter idea.
I can't find anywhere documentation to make this possible.
Thanks