Hi A.A,
Thanks a lot... Able to see BGP routes in the route table. However, still not able to see active/received/accepted route states in show bgp summary. Any idea what could be the issue here?
Thanks,
Vinay
Hi A.A,
Thanks a lot... Able to see BGP routes in the route table. However, still not able to see active/received/accepted route states in show bgp summary. Any idea what could be the issue here?
Thanks,
Vinay
Hi Vinay,
The syntax that you are looking for, will be seen only when other families are enabled on the BGP peer eg. "family inet-vpn unicast".
By default, only family inet unicast is enabled and the syntax you are seeing is expected if only this family is enabled.
If you want to see the change then try enabling other families along with "family inet unicast".
Hi Mateusz,
How are you generating default route for redistributing in NSSA area?
You should try advertising the default route by following below script, this will only advertise default route in NSSA area.
set protocols ospf area 0.0.0.1 nssa default-lsa type-7
Hi
I want to create two OSPF domains on My Juniper MX960. For this reason I created one Routing-Instance with Type virtual-router. The first thing I observed is I cannot enable protocol MPLS on Interfaces inside of Routing-Instance.. But I can enable LDP on those Interfaces. Another observed case is When I redistribute routes from Routing-Instance to Intet.0, Inet.3 will not received learned labels from the Routing-Instance.
I test this on Live Device and VMX and got the same result.
Is there any solution for this case? Or it just simply means I must not create separate OSPF Domains..
Thank you
Hello,
wrote: Hi
I want to create two OSPF domains on My Juniper MX960. For this reason I created one Routing-Instance with Type virtual-router.
The first thing I observed is I cannot enable protocol MPLS on Interfaces inside of Routing-Instance.. But I can enable LDP on those Interfaces. Another observed case is When I redistribute routes from Routing-Instance to Intet.0, Inet.3 will not received learned labels from the Routing-Instance.
I test this on Live Device and VMX and got the same result.
This is expected. Please use instance-type "no-forwarding" for separating OSPF domains in JUNOS if You so desire, but separate IGP domains is not a best practice to put it mildly.
wrote:
Is there any solution for this case? Or it just simply means I must not create separate OSPF Domains..
The latter. You could use OSPF multitopology https://kb.juniper.net/library/CUSTOMERSERVICE/technotes/2000308-en.pdf if You are brave but almost everything in networking can be achieved without separating IGP into isolated domains.
This is also true about OSPF NSSA and stub areas, BTW.
HTH
Thx
Alex
Hello,
Can you help understand why you want to create a separate OSPF domain?
One solution is to use logical system on your router. From routing perspective this would be as if it is a separate router and would help you to isolate your domain.
Logical-system supports OSPF and MPLS. Below is a link for configuring P2MP RSVP in logical system which you can use as a reference for configuring P2P RSVP LSP as well.
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/logical-systems-rsvp-p2mp.html
Regards,
Mayank Shah
not only in the area of nssa. Area 0 can't be nssa and if I run it for iBGP as IGP, the defaulte route is also advertised there. See the first two posts. I want to do something like the picture below with OSPF area 0 recommended as IGP for iBGP. OSPF Area 1 (nssa) as the default route broadcaster in the client devices zone.
Alex wrote that: "It is recommended to put R1-R2 link into area 0 and use separate OSPF area per spoke if possible." ....because it is recommended that BGP sessions should be set up between logical interfaces ....that's how I understand it so I tray to do that. Please help 🙂
Thanks for the answer and for your time.
What about this last question?
Now, in case of problem to bring the router back as it was before, is enough to simply insert the USB0 where the snapshot is saved and the router will recover the snapshot during the boot sequence without having me doing anything basically. Is this "assumption" correct?
Thanks
Hello,
wrote: not only in the area of nssa. Area 0 can't be nssa and if I run it for iBGP as IGP, the defaulte route is also advertised there.
"advertised there" means "0/0 route is announced via iBGP"?
Are You redistributing OSPF into iBGP?
If yes then You should apply import policy to Your iBGP which rejects/filters out 0/0 route.
HTH
Thx
Alex
Hi,
We're doing a POC with a partner wherein we are testing an auto-rerouting for a DDoS attack.
Attached is the diagram(POC Diagram.jpg).
Test IP: x.x.88.0/24
Corp Network ASN: 123456
Scrubbing Center ASN: 134190
DDoS Trigger Server( or INI): 45352
Community tag for auto-rerouting is: 123456:911
Target end-state:
1. Once a DDoS attack going to x.x.88.x has entered the Corporate network, the INI will advertise the x.x.88.0/24 prefix with a community tag of 123456:911 and a next-hop IP of the loopback of Core Router(x.x.x.246) to BorderRouter1.
2. Once BorderRouter1 receives the prefix from the INI, it should not export it to its other iBGP neighbors (CoreRouter(s)).
3. It should prefer the route from the INI but should not prefer the INI as the next-hop for x.x.88.0/24 but instead will rely on the next-hop set by the INI on the test prefix which is Core Router(x.x.x.246).
4. Once BorderRouter1 receives the prefix from the INI with community tag, it will automatically advertise the prefix to the Scrubbing Center.
5. Then BorderRouter1 will deny the x.x.88.0/24 prefix advertisement with community tag to its other ISP(Other peerings).
Current state(Manually triggering the INI, prior to live attack):
1. Once INI advertises the the x.x.88.0/24 prefix with a community tag of 123456:911 and a next-hop IP of the loopback of Core Router(x.x.x.246) to BorderRouter1, BorderRouter1 preferred next-hop to the x.x.88.0/24 prefix is the p2p peering with the INI instead of Core Router.
2. Because of this, points 2-5 of the target end-state are not accomplished.
***Even though INI advertises the x.x.88.0/24 prefix it should not be the path going to x.x.88.0/24 .
During the manual triggering of the INI, attached image(BorderRouter1 Output during manual triggering.jpg) shows the results we got on BorderRouter1.
We're receiving x.x.88.0/24 from the INI with community tag and next hop ip x.x.x.246 but the preferred next hop interface is gr-4/0/0 which is the tunnel interface facing INI. I'm also seeing 'hidden reason: protocol next hop is not on the interface' in the outputs.
Thus, points 2-5 of the target end-state are not accomplished.
Hoping somebody can help.
If you have questions, feel free to ask.
Thanks in advance.
Hello,
wrote: I'm also seeing 'hidden reason: protocol next hop is not on the interface' in the outputs.
Thanks in advance.
Please add following knob to Your INI peer group:
HTH
Thx
Alex
Greetings Folks,
We are seeing some application latency for a particular database server. There is no network latency seen but application latency is noticeable for some application that runs on this server.
Does implementing class of service help with this type of issues? We have class of service implemented for VOIP traffic on the intermediate network nodes, but wasn't sure if we could implement class of service for database traffic. Or is this something that has to be fixed by the database team?
We also have LDP enabled in the environment, so wasn't sure if COS can even be implemented for the MPLS routers in the path.
Hello Biraj,
CoS can be implemented when there is network congestion in your environment where packets are delayed or lost. However, in this case, you are saying that there is no latency in your network so you need to check on the applicable side or the server end.
CoS is available for MPLS and you can find the same here - https://www.juniper.net/documentation/en_US/junos/topics/concept/mpls-cos-qfx-series.html. But in this situation, I don't think CoS helps.
Hi all,
Any ideas why I am getting the following commit error?
bngMx480# commit check
re0:
[edit interfaces ae100 auto-configure stacked-vlan-ranges dynamic-profile AUTO-Stack-VLANs-Demux-LBN]
'ranges 832-832,any'
Only one profile is allowed if the number of ranges exceeds 32
error: configuration check-out failed
Hi Arix,
Could you provide config that you for the below :
interfaces ae100
&
AUTO-Stack-VLANs-Demux-LBN
Best Regards,
Mohamed
Hi Arix,
you maybe trying to add more than one dymanic profile so the limit will be 32 range only.
If this solves your problem, please mark this post as "Accepted Solution."
Hello Arix,
Greetings,
As per our documentation, you can configure multiple dynamic profile associations (up to 32) with different VLAN range groups on each physical interface.
Verify the config as mohamed said. Check the step 6 in the link : https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/subscriber-management-stacked-vlan-interface.html
Hope this helps. 😀
Please mark "Accept as solution" if this answers your query. Kudos are appreciated too!
Regards,
Sharat Ainapur
Hello,
Our goal is source all locally generated traffic from the Routing Engine (RE) of a device to use the IP address of the loopback interface. This will concern different traffic such as traffic going from the local RE of the device to the syslog server, NTP server, SNMP server, Radius server etc. To accomplish this we plan to use the "default-address-selection" command.
My only concern was for point to point links where the physical interface address is used for OSPF peering. For this particular connection instead of using the loopback address, we would want the interface address to be used, as we wouldn't be able to form OSPF peering if loopback address was used in this scenario.
There is also another way to source RE generated traffic for various specific protocols by using the source-address command, but this is not that efficient, as it requires us to specify the source address for each protocol.
Could somebody please advise on this setup?