Re: [j-nsp] VRF export/import of eBGP learned route
Use with caution in live environment as I'm going off of some testing I was recently doing in my lab and I'm pretty sure I saw this same issue. Sounds like something I saw with my internet boundary pe's, would add my AS on routes were learned from internet and send as vpnv4 routes into my internal ibgp environment and internal pe's were seeing their own AS and routes were being hidden as looped... Try this on PE1 If pe1 ebgp group is called "ebgp-to-ix"... If IX ip that you neighbor with is 1.2.3.4... If vrf on PE1 and PE2 is called "my-vrf"... ...do this on PE1... set routing-instances my-vrf protocols bgp group ebgp-to-ix neighbor 1.2.3.4 local-as private ...now see if PE2 is still seeing its own AS as looped - Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] VRF export/import of eBGP learned route
Grettings I'm setting up this VRF that hosts the full routing table. I have other peerings or remote PEs that import IX routes through eBGP as well. The problem resides on something TAC tells me is Juniper specific, which is to add my own internal ASN to the as-path when using vrf-import to get a route that was learned through eBGP from another router to avoid potential loops. So, let's say IX has AS 123 and I have AS 456 in the VRF, and my real inet.0 AS is 789, what is seen by another PE than the one learning the route directly from the IX is: IX -- eBGP - PE1 - iBGP inet-vpn - PE2 Route as-path seen by PE1: 123 XXX YYY I Route as-path seen by PE2: 456 123 XXX YYY I The behaviour is the same on all Junos routing devices in my core (MX + QFX5100) and I have to configure routing-options autonomous-system 456 loops 2 for the other peers to accept routes imported by eBGP on another node. Obviously, the "real" as-path is as follows, since the AS doing the underlay iBGP has ASN 789. 456 [789] 456 123 XXX YYY I I've tried independant domain but that makes me unable to filter any bgp attribute in vrf-imports and exports. I've also tried an "option A" peering between the routers and that revealed the underlay AS in the path. Using remove-private created a loop by re-sending the learned routes towards the edge. Would anybody have an idea on how to achieve the equivalent of having and inet.0 iBGP mesh and importing routes without the own as prepending that takes place as described? Thanks Phil. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks)
No, things changed there as well. Lookup merchant sillicon, and revise this post every 6 months. have you heard of Barefoot networks? The days of ASICs from Cisco are gone and we are glad, we tested the P4 DSL (cisco never got that right with mantel) on Nexus and its wonderful. The asics you speak of are no longer important or valuable because people realized that in many networking planets and galaxies, the asic is reflects the network design, they are related, and specifically for the data center, the clos fabric design won, and that does not require fancy asics. I guess your knowledge is out dated a bit. Cisco itself is using those merchant sillicon ASICs happily. (lookup Chuck's comments on nexus9000, best selling cisco switch ever)...guess it is a good switch, because bright box pushed cisco to do that, and if any one on this list can disagree with me here, i'm up to that challenge. What i have discovered recently is that things happen in following way. Your boss or his boss picks a work culture (no one gets fired for buying IBM/Cisco), that culture (buying the shiny suits) impacts how you do work, it makes you select vendors (the ones that sends me to vegas every year) and not the right network design, you select cisco and you are stuck there for life, because once they tell you how things should work (aka : certificates), things are worse, now every time you make a new network purchase (afraid of new CLI ), you will not be able to look the other way because you just dont know any thing else (and loosing your certificate value). I wish the culture would change to, no one got fired for buying closed but didnt get promoted either. change requires boldness. https://toolr.io/2018/06/18/stop-abusing-the-word-open/ On Wed, Jun 27, 2018 at 9:41 AM, wrote: > > Tails Pipes > > Sent: Friday, June 22, 2018 3:00 PM > > > > can you easily answer this question ? why packets are not pushed in > linux ? > > is it because of big switch, cumulus, pica8 ? > > > > can you push packets in linux without writing code to do that ? who is > writing > > that code ? > > > > this is supposedly a community effort, something that older generations > > dont understand. > > > If pure linux as NOS has some legs it'll fly regardless of cisco blessing, > don't worry no single company owns the whole industry. > Also we can argue that this is only about the OS but in reality it's also > the quality of apps running on top and the quality of the underlying HW > that plays a major role. > The quality of BGP app for instance, or the ability of the forwarding ASIC > to deliver the stated pps rate even if multiple features are enabled or > protect high priority traffic even if ASIC is overloaded. > > > Oh and with regards to: > < I am sick of having to learn all the cisco specific terms to all sorts > of different boxes and technologies > I'd recommend you read all the cisco books on networking to get yourself > educated on the topic and to get the difference between SW and HW > forwarding ( -on why packets are not routed in linux) > And while on that I suggest you read all Stanford university lectures on > how routers work too, it'll help you understand why Cisco and Juniper ASICs > are so much more expensive than white-box ASICs. > > adam > > netconsultings.com > ::carrier-class solutions for the telecommunications industry:: > > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Random question: JUNOS upgrades on dual-RE routers
I've been doing it for years with no ill effects. The only thing I do
is change the backup/master designations in chassis redundancy to
clear the alarm about running on the backup RE:
mx960> show configuration chassis redundancy |display set
set chassis redundancy routing-engine 0 backup
set chassis redundancy routing-engine 1 master
set chassis redundancy failover on-loss-of-keepalives
set chassis redundancy failover on-disk-failure
set chassis redundancy graceful-switchover
On Thu, Jun 28, 2018 at 09:28:25AM -0500, Aaron Gould wrote:
> In my testing I haven't seen an issue with leaving it like this, however,
> that is my lab testing I only turned up my dual re, (5) node 100 gig
> ring of mx960's about 2 months ago with live traffic, and haven't had to do
> any issu upgrades or anything ... so I can only speak from my lab test thus
> far... but, with re1 running as master and re0 running as backup, it's been
> fine in lab.
>
> ...lab 240...
> root@lab-mx-240> show chassis routing-engine | grep "slot|state|elec"
> Slot 0:
> Current state Backup
> Election priority Master (default)
> Slot 1:
> Current state Master
> Election priority Backup (default)
>
> ...lab 960...
> {master}
> agould@lab-960> show chassis routing-engine | grep "slot|state|elec"
> Slot 0:
> Current state Backup
> Election priority Master (default)
> Slot 1:
> Current state Master
> Election priority Backup (default)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Random question: JUNOS upgrades on dual-RE routers
Probably also good for us as engineers to gain confidence in our equipment knowing that it's purring along just fine on the re1 as master, makes us feel better that both re's work :) -Aaron -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Chuck Anderson I almost always leave it running as master on the former backup. It is good to exercise both REs periodically. I haven't bothered with ISSU in a long time since I have node/path redundancy. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Random question: JUNOS upgrades on dual-RE routers
In my testing I haven't seen an issue with leaving it like this, however,
that is my lab testing I only turned up my dual re, (5) node 100 gig
ring of mx960's about 2 months ago with live traffic, and haven't had to do
any issu upgrades or anything ... so I can only speak from my lab test thus
far... but, with re1 running as master and re0 running as backup, it's been
fine in lab.
...lab 240...
root@lab-mx-240> show chassis routing-engine | grep "slot|state|elec"
Slot 0:
Current state Backup
Election priority Master (default)
Slot 1:
Current state Master
Election priority Backup (default)
...lab 960...
{master}
agould@lab-960> show chassis routing-engine | grep "slot|state|elec"
Slot 0:
Current state Backup
Election priority Master (default)
Slot 1:
Current state Master
Election priority Backup (default)
- Aaron
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Random question: JUNOS upgrades on dual-RE routers
I almost always leave it running as master on the former backup. It is good to exercise both REs periodically. I haven't bothered with ISSU in a long time since I have node/path redundancy. On Thu, Jun 28, 2018 at 09:12:14AM -0500, Chris Adams wrote: > It's been a bit since I upgraded JUNOS on a dual-RE router, and I was > refreshing my memory from the documentation. I noticed at the end they > list switching RE mastership back to the first RE (which of course would > cause a second network outage)... is that really needed? Do you do > that, or do you leave it running on the previously-stand-by RE? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Random question: JUNOS upgrades on dual-RE routers
It's been a bit since I upgraded JUNOS on a dual-RE router, and I was refreshing my memory from the documentation. I noticed at the end they list switching RE mastership back to the first RE (which of course would cause a second network outage)... is that really needed? Do you do that, or do you leave it running on the previously-stand-by RE? -- Chris Adams ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Ipsec tunnel flapping
remote site logs are also shared below: Jun 28 17:23:20 rpd[1398]: EVENT st0.0 index 79 Jun 28 17:23:20 kmd[1403]: KMD_VPN_DOWN_ALARM_USER: VPN VPN-SOORTY from 123.123.123.123 is down. Local-ip: 50.50.50.50, gateway name: gw-soortybd, vpn name: VPN-SOORTY, tunnel-id: 131073, local tunnel-if: st0.0, remote tunnel-ip: 10.115.10.2, Local IKE-ID: 50.50.50.50, Remote IKE-ID: 123.123.123.123, XAUTH username: Not-Applicable, VR id: 0 Jun 28 17:23:20 rpd[1398]: EVENT UpDown st0.0 index 79 Jun 28 17:23:20 rpd[1398]: EVENT UpDown st0.0 index 79 10.115.10.1 -> 10.115.10.1 Jun 28 17:23:20IFP trace> ifp_ifl_anydown_change_event: IFL anydown change event: "st0.0" Jun 28 17:23:20IFP trace> ifp_ifl_chg: IFL chg: "st0.0 ifl_id 79" Jun 28 17:23:20IFP trace> ifp_create_tunnel_session: duplicate tunnel session add(st0). skip tunnel session creation Jun 28 17:23:20 mib2d[1426]: SNMP_TRAP_LINK_DOWN: ifIndex 584, ifAdminStatus up(1), ifOperStatus down(2), ifName st0.0 Jun 28 17:23:35 rpd[1398]: EVENT st0.0 index 79 Jun 28 17:23:35 kmd[1403]: KMD_PM_SA_ESTABLISHED: Local gateway: 50.50.50.50, Remote gateway: 123.123.123.123, Local ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Remote ID: ipv4_subnet(any:0,[0..7]= 0.0.0.0/0), Direction: inbound, SPI: 0x9e4d39d0, AUX-SPI: 0, Mode: Tunnel, Type: dynamic Jun 28 17:23:35 rpd[1398]: EVENT UpDown st0.0 index 79 Jun 28 17:23:35 kmd[1403]: KMD_PM_SA_ESTABLISHED: Local gateway: 50.50.50.50, Remote gateway: 123.123.123.123, Local ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), Remote ID: ipv4_subnet(any:0,[0..7]= 0.0.0.0/0), Direction: outbound, SPI: 0xabfd4940, AUX-SPI: 0, Mode: Tunnel, Type: dynamic Jun 28 17:23:35 rpd[1398]: EVENT UpDown st0.0 index 79 10.115.10.1 -> 10.115.10.1 Jun 28 17:23:35 kmd[1403]: KMD_VPN_UP_ALARM_USER: VPN VPN-SOORTY from 123.123.123.123 is up. Local-ip: 50.50.50.50, gateway name: gw-soortybd, vpn name: VPN-SOORTY, tunnel-id: 131073, local tunnel-if: st0.0, remote tunnel-ip: 10.115.10.2, Local IKE-ID: 50.50.50.50, Remote IKE-ID: 123.123.123.123, XAUTH username: Not-Applicable, VR id: 0 Jun 28 17:23:35IFP trace> ifp_ifl_anydown_change_event: IFL anydown change event: "st0.0" Jun 28 17:23:35IFP trace> ifp_ifl_chg: IFL chg: "st0.0 ifl_id 79" Jun 28 17:23:35IFP trace> ifp_create_tunnel_session: duplicate tunnel session add(st0). skip tunnel session creation Jun 28 17:23:35 mib2d[1426]: SNMP_TRAP_LINK_UP: ifIndex 584, ifAdminStatus up(1), ifOperStatus up(1), ifName st0.0 On Thu, Jun 28, 2018 at 3:24 PM, sameer mughal wrote: > Gentlemans, > > anyone help me on this issue? > > On Mon, Jun 25, 2018 at 10:37 PM, sameer mughal > wrote: > >> Dear Alexandre, >> Please guide how can I fix this issue? It raise suddenly before this on >> same configuration ipsec tunnel was working fine for more than 5 to 6 >> months. >> >> On Mon, Jun 25, 2018, 8:22 PM Alexandre Guimaraes < >> alexandre.guimar...@ascenty.com> wrote: >> >>> Sameer >>> >>> >>> Reason: IPSec SA delete payload received from peer, corresponding IPSec >>> SAs cleared >>> >>> >>> This is a phase 2 problem, maybe deadpeerdetection failure, VPN >>> monitoring failure, a failure during rekey when old SA is deleted >>> notification sent to delete old SA. Most of the cases. >>> >>> >>> >>> att >>> Alexandre >>> >>> Em 25 de jun de 2018, à(s) 03:42, sameer mughal >>> escreveu: >>> >>> both sites on srx. >>> following are the logs. >>> >>> show log junilog|match st0.15 >>> Jun 25 01:47:51 rpd[1867]: EVENT st0.15 index 86 >> PointToPoint Multicast> >>> Jun 25 01:47:51 rpd[1867]: EVENT UpDown st0.15 index 86 >> PointToPoint Multicast Localup> >>> Jun 25 01:47:51 rpd[1867]: EVENT UpDown st0.15 index 86 10.115.10.2 -> >>> 10.115.10.2 >>> Jun 25 01:47:51 kmd[1902]: KMD_VPN_DOWN_ALARM_USER: VPN IPSEC-15-VPN >>> from 103.229.87.66 is down. Local-ip: 124.29.233.138, gateway name: >>> IKE-U15-GW, vpn name: IPSEC-15-VPN, tunnel-id: 131075, local tunnel-if: >>> st0.15, remote tunnel-ip: 10.115.10.1, Local IKE-ID: 124.29.233.138, Remote >>> IKE-ID: 103.229.87.66, XAUTH username: Not-Applicable, VR id: 0, >>> Traffic-selector: , Traffic-selector local ID: ipv4_subnet(any:0,[0..7]= >>> 0.0.0.0/0), Traffic-selector remote ID: ipv4_subnet(any:0,[0..7]=0.0.0 >>> .0/0), SA Type: Static, Reason: IPSec SA delete payload received from >>> peer, corresponding IPSec SAs cleared >>> Jun 25 01:47:51 mib2d[1865]: SNMP_TRAP_LINK_DOWN: ifIndex 588, >>> ifAdminStatus up(1), ifOperStatus down(2), ifName st0.15 >>> Jun 25 01:48:06 kmd[1902]: KMD_VPN_UP_ALARM_USER: VPN IPSEC-15-VPN >>> from 103.229.87.66 is up. Local-ip: 124.29.233.138, gateway name: >>> IKE-U15-GW, vpn name: IPSEC-15-VPN, tunnel-id: 131075, local tunnel-if: >>> st0.15, remote tunnel-ip: 10.115.10.1, Local IKE-ID: 124.29.233.138, Remote >>> IKE-ID: 103.229.87.66, XAUTH username: Not-Applicable, VR id: 0, >>> Traffic-selector: , Traffic-selector local ID: ipv4_subnet(any:0,[0..7]= >>> 0.0.0.0/0), Traffic-selector remote ID:
Re: [j-nsp] Ipsec tunnel flapping
Gentlemans,
anyone help me on this issue?
On Mon, Jun 25, 2018 at 10:37 PM, sameer mughal
wrote:
> Dear Alexandre,
> Please guide how can I fix this issue? It raise suddenly before this on
> same configuration ipsec tunnel was working fine for more than 5 to 6
> months.
>
> On Mon, Jun 25, 2018, 8:22 PM Alexandre Guimaraes <
> alexandre.guimar...@ascenty.com> wrote:
>
>> Sameer
>>
>>
>> Reason: IPSec SA delete payload received from peer, corresponding IPSec
>> SAs cleared
>>
>>
>> This is a phase 2 problem, maybe deadpeerdetection failure, VPN
>> monitoring failure, a failure during rekey when old SA is deleted
>> notification sent to delete old SA. Most of the cases.
>>
>>
>>
>> att
>> Alexandre
>>
>> Em 25 de jun de 2018, à(s) 03:42, sameer mughal
>> escreveu:
>>
>> both sites on srx.
>> following are the logs.
>>
>> show log junilog|match st0.15
>> Jun 25 01:47:51 rpd[1867]: EVENT st0.15 index 86 > PointToPoint Multicast>
>> Jun 25 01:47:51 rpd[1867]: EVENT UpDown st0.15 index 86 > PointToPoint Multicast Localup>
>> Jun 25 01:47:51 rpd[1867]: EVENT UpDown st0.15 index 86 10.115.10.2 ->
>> 10.115.10.2
>> Jun 25 01:47:51 kmd[1902]: KMD_VPN_DOWN_ALARM_USER: VPN IPSEC-15-VPN
>> from 103.229.87.66 is down. Local-ip: 124.29.233.138, gateway name:
>> IKE-U15-GW, vpn name: IPSEC-15-VPN, tunnel-id: 131075, local tunnel-if:
>> st0.15, remote tunnel-ip: 10.115.10.1, Local IKE-ID: 124.29.233.138, Remote
>> IKE-ID: 103.229.87.66, XAUTH username: Not-Applicable, VR id: 0,
>> Traffic-selector: , Traffic-selector local ID: ipv4_subnet(any:0,[0..7]=
>> 0.0.0.0/0), Traffic-selector remote ID: ipv4_subnet(any:0,[0..7]=0.0.
>> 0.0/0), SA Type: Static, Reason: IPSec SA delete payload received from
>> peer, corresponding IPSec SAs cleared
>> Jun 25 01:47:51 mib2d[1865]: SNMP_TRAP_LINK_DOWN: ifIndex 588,
>> ifAdminStatus up(1), ifOperStatus down(2), ifName st0.15
>> Jun 25 01:48:06 kmd[1902]: KMD_VPN_UP_ALARM_USER: VPN IPSEC-15-VPN from
>> 103.229.87.66 is up. Local-ip: 124.29.233.138, gateway name: IKE-U15-GW,
>> vpn name: IPSEC-15-VPN, tunnel-id: 131075, local tunnel-if: st0.15, remote
>> tunnel-ip: 10.115.10.1, Local IKE-ID: 124.29.233.138, Remote IKE-ID:
>> 103.229.87.66, XAUTH username: Not-Applicable, VR id: 0, Traffic-selector:
>> , Traffic-selector local ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0),
>> Traffic-selector remote ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), SA
>> Type: Static
>> Jun 25 01:48:06 rpd[1867]: EVENT st0.15 index 86 > PointToPoint Multicast>
>> Jun 25 01:48:06 rpd[1867]: EVENT UpDown st0.15 index 86 > PointToPoint Multicast>
>> Jun 25 01:48:06 rpd[1867]: EVENT UpDown st0.15 index 86 10.115.10.2 ->
>> 10.115.10.2
>> Jun 25 01:48:06 mib2d[1865]: SNMP_TRAP_LINK_UP: ifIndex 588,
>> ifAdminStatus up(1), ifOperStatus up(1), ifName st0.15
>> Jun 25 01:51:52 kmd[1902]: KMD_VPN_DOWN_ALARM_USER: VPN IPSEC-15-VPN
>> from 103.229.87.66 is down. Local-ip: 124.29.233.138, gateway name:
>> IKE-U15-GW, vpn name: IPSEC-15-VPN, tunnel-id: 131075, local tunnel-if:
>> st0.15, remote tunnel-ip: 10.115.10.1, Local IKE-ID: 124.29.233.138, Remote
>> IKE-ID: 103.229.87.66, XAUTH username: Not-Applicable, VR id: 0,
>> Traffic-selector: , Traffic-selector local ID: ipv4_subnet(any:0,[0..7]=
>> 0.0.0.0/0), Traffic-selector remote ID: ipv4_subnet(any:0,[0..7]=0.0.
>> 0.0/0), SA Type: Static, Reason: IPSec SA delete payload received from
>> peer, corresponding IPSec SAs cleared
>> Jun 25 01:51:52 rpd[1867]: EVENT st0.15 index 86 > PointToPoint Multicast>
>> Jun 25 01:51:52 rpd[1867]: EVENT UpDown st0.15 index 86 > PointToPoint Multicast Localup>
>> Jun 25 01:51:52 rpd[1867]: EVENT UpDown st0.15 index 86 10.115.10.2 ->
>> 10.115.10.2
>> Jun 25 01:51:52 mib2d[1865]: SNMP_TRAP_LINK_DOWN: ifIndex 588,
>> ifAdminStatus up(1), ifOperStatus down(2), ifName st0.15
>> Jun 25 01:52:07 rpd[1867]: EVENT st0.15 index 86 > PointToPoint Multicast>
>> Jun 25 01:52:07 rpd[1867]: EVENT UpDown st0.15 index 86 > PointToPoint Multicast>
>> Jun 25 01:52:07 kmd[1902]: KMD_VPN_UP_ALARM_USER: VPN IPSEC-15-VPN from
>> 103.229.87.66 is up. Local-ip: 124.29.233.138, gateway name: IKE-U15-GW,
>> vpn name: IPSEC-15-VPN, tunnel-id: 131075, local tunnel-if: st0.15, remote
>> tunnel-ip: 10.115.10.1, Local IKE-ID: 124.29.233.138, Remote IKE-ID:
>> 103.229.87.66, XAUTH username: Not-Applicable, VR id: 0, Traffic-selector:
>> , Traffic-selector local ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0),
>> Traffic-selector remote ID: ipv4_subnet(any:0,[0..7]=0.0.0.0/0), SA
>> Type: Static
>> Jun 25 01:52:07 rpd[1867]: EVENT UpDown st0.15 index 86 10.115.10.2 ->
>> 10.115.10.2
>> Jun 25 01:52:07 mib2d[1865]: SNMP_TRAP_LINK_UP: ifIndex 588,
>> ifAdminStatus up(1), ifOperStatus up(1), ifName st0.15
>>
>> {primary:node0}
>>
>> On Mon, Jun 25, 2018 at 3:03 AM, Alexandre Guimaraes <
>> alexandre.guimar...@ascenty.com> wrote:
>>
>>> Have you checked the errors? Do a deep Inspection and check the packets
>>> to see what’s the behavior
