Quantcast
Channel: All Routing posts
Viewing all 8688 articles
Browse latest View live

Re: MX-104 bgp neighbor go down -strange behavior-

$
0
0

Depending on configuration , but i think this is expected behaviior . Thy to read this


Re: L3vpn

$
0
0

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-

$
0
0

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?

$
0
0

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

 

http://www.juniper.net/techpubs/en_US/junos11.4/information-products/pathway-pages/config-guide-mpls-applications/config-guide-mpls-applications-mpls.html#configuration

Re: Not receiving netflow v9, v5 works.

Re: Not receiving netflow v9, v5 works.

Re: Not receiving netflow v9, v5 works.

$
0
0

"User-defined version 9 templates are not supported."

 

  1. +          family inet {
  2. +              output {
  3. +                  flow-server **.**.**.** {
  4. +                      port 2222;
  5. +                      version9 {
  6. +                          template {
  7. +                              ELK;
  8. +                          }
  9. +                      }
  10. +                  }

 

 

  1. services {
  2. +      flow-monitoring {
  3. +          version9 {
  4. +              template ELK {
  5. +                  ipv4-template;
  6. +              }
  7. +          }
  8. +      }
  9. +  }

Could this be the problem? I defined "ELK" as a template.

 

Re: MX-104 bgp neighbor go down -strange behavior-

$
0
0

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?

$
0
0

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-

$
0
0

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

$
0
0

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-

$
0
0

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

$
0
0

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

$
0
0

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.

$
0
0

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.

$
0
0

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-

$
0
0

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

Re: MX-104 bgp neighbor go down -strange behavior-

$
0
0

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.

$
0
0

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

 

Viewing all 8688 articles
Browse latest View live