Hi,
With BGP BFD, the BGP session will tear down once the BFD keepalive is breached. In this configuration, the threshold is 9s. The hold-time does not really have any effect in this case as BFD timer is lower.
Note that BFD needs to enabled on both peers to be effective, else the default hold-time [90s] will prevail.
Can you provide a "show bgp neighbor x.x.x.x detail".
Also, if you provide a topology diagram may be helpful.
Cheers,
Ashvin
Hi,
Dst/src NAT rule was re-configured as "from zone/to zone" instead "from instance", but result same. ICMP works, but TCP session cannot be established by obvious reasons. Current configuration looks like:
set security nat source pool snat-pool address 1.1.1.1/32
set security nat source rule-set hairpin-nat from zone TRUST
set security nat source rule-set hairpin-nat to zone UNTRUST
set security nat source rule-set hairpin-nat rule hairpin-nat-rule match source-address 0.0.0.0/0
set security nat source rule-set hairpin-nat rule hairpin-nat-rule then source-nat pool snat-pool
set security nat destination pool hairpin-pool address 10.213.0.10/32
set security nat destination rule-set HAIRPIN from zxone TRUST
set security nat destination rule-set HAIRPIN rule rule-hairpin-destination match source-address 10.213.0.0/24
set security nat destination rule-set HAIRPIN rule rule-hairpin-destination match destination-address 2.2.2.2/32
set security nat destination rule-set HAIRPIN rule rule-hairpin-destination then destination-nat pool hairpin-pool
set security nat static rule-set STATIC-NAT from interface (uplink int. ip 3.3.3.3)
set security nat static rule-set STATIC-NAT rule STATIC-rule match destination-address 2.2.2.2/32
set security nat static rule-set STATIC-NAT rule STATIC-rule then static-nat prefix 10.213.0.10/32
set security policies from-zone TRUST to-zone TRUST policy default-permit match source-address any
set security policies from-zone TRUST to-zone TRUST policy default-permit match destination-address any
set security policies from-zone TRUST to-zone TRUST policy default-permit match application any
set security policies from-zone TRUST to-zone TRUST policy default-permit then permit
set security policies from-zone UNTRUST to-zone TRUST policy default-permit match source-address any
set security policies from-zone UNTRUST to-zone TRUST policy default-permit match destination-address 10.213.0.10
set security policies from-zone UNTRUST to-zone TRUST policy default-permit match application any
set security policies from-zone UNTRUST to-zone TRUST policy default-permit then permit
Also looks strange that from server 10.213.0.10 for internet access use source NAT ip 1.1.1.1, instead static NAT ip 2.2.2.2, how I know static NAT should be apply first.
BR,
Jurijs
Hi,
"traffic-engineering bgp-igp|-both-ribs" is not in this configuration.
Hi,
I'm not getting why we have "set protocols bgp group IBGP type internal" command for iBGP peering. In the following configuration, it's not been configured on either of side.
root@R1# show protocols bgp
group IBGP {
local-address 1.1.1.1;
neighbor 2.2.2.2 {
peer-as 65000;
bfd-liveness-detection {
minimum-interval 100;
root@R2# show protocols bgp
group IBGP {
local-address 2.2.2.2;
neighbor 1.1.1.1 {
peer-as 65000;
bfd-liveness-detection {
minimum-interval 100;
root@R1# run show bgp neighbor
Peer: 2.2.2.2+58599 AS 65000 Local: 1.1.1.1+179 AS 65000
Type: Internal State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress PeerAS Refresh>
Options: <BfdEnabled>
Peering shows that it's internal, which is expected, but what is the use of these keywords, internal/exeternal?
It might be a simple question but I see no importance of specifically "type internal/external" commands like we have built-in feature in Cisco IOS.
Thanks!
Hi,
I believe although the type is optional, its purpose is to sanitise the configuration.
For example, with config below:
routing-options {
autonomous-system 65000;
}
protocols {
bgp {
group BGP {
peer-as 65100;
neighbor 10.10.10.5;
}
}
}
root@MX# commit check
configuration check succeedsWhile this configuration is valid and commit check succeeds, however if we add a type, there is additional validation:
[edit protocols bgp group BGP]
root@MX# set type internal
root@MX# commit check
[edit protocols]
'bgp'
Error in neighbor 10.10.10.5 of group BGP:
internal peer's AS (65100) must be the same as the local AS (65000)
error: configuration check-out failed
At times the default AS specified in routing-options and the local-as in BGP configuration need not be same:
[edit protocols bgp group BGP] root@MX# set local-as 65100
[edit protocols bgp group BGP]
root@MX# show
type internal;
peer-as 65100;
local-as 65100;
neighbor 10.10.10.5;
[edit protocols bgp group BGP] root@MX# commit check configuration check succeeds
Another example, suppose we did a typo error on the peer-as but we know we want an eBGP peering [type external]:
[edit protocols bgp group BGP]
root@MX# show
type external;
peer-as 65000;
local-as 65000;
neighbor 10.10.10.5;
[edit protocols bgp group BGP]
root@MX# commit check
[edit protocols]
'bgp'
Error in neighbor 10.10.10.5 of group BGP:
external peer's AS (65000) must not be the same as the local AS (65000)
error: configuration check-out failedAs a best practice, I would always set the type in BGP configuration.
Cheers,
Ashvin
Can you explain how the BGP failover topology is setup? I'm not sure from the description exactly what the failure scenario is right now.
BFD is only forcing the removal of the peer at 9 seconds and allowing the session to return when BFD link is restored.
I'm guessing your issue is more likely a routing convergence or failover issue depending on how the alternate BGP session is setup and how the upstream in this case is handingly this as well.
I generally make the source nat portion of this rule specific to the local subnet involved as the source and use interface instead of a pool for the address. With destination of the server public nat address.
this keeps the scope of the rule very specific. And uses a nat addres that will definately bring the return traffic back to the firewall to hit the session instead of direct to the server.
Thanks Ashvin, this does make sense to me. 
Hi,
I am studying CoS at the minute and wondered if anyone could help clarify something for me.
I want to put my network control traffic into an LSP which I can then traffic engineer to a high level of protection and low latency path
I want to apply CoS to the network control traffic
So I have an output filter set on Lo0 to apply CoS to any traffic leaving Lo0 towards the range of addresses my other core node loopbacks are on:
eg.
term ldp {
from {
destination-address {
10.0.0.0/24;
}
protocol [ tcp udp ];
port ldp;
}
then {
forwarding-class network-control;
accept;
dscp 0x38;
}
----------
My question is: Given that I am putting this traffic through an LSP, in order to get the next node in the path to honour the CoS, should I be setting this to EXP instead of DSCP?
I would assume the next node will be looking at the MPLS header, expecting EXP to be defined and, upon not seeing a defined EXP, it will ignore the DSCP I have set.
Is this the case?
Thanks
I have a configuration that is setup as such. Main router in datacenter that has connectivity to AT&T MPLS network and another connection to an ISP. I have several other sites in the MPLS network that need to access the public internet via the ISP that is connected to the datacenter. All sites have this common setup, IBGP AS65001 between the SRX and the CPE Cisco router, EBGP AS7016 between the CPE and PE routers. My question is, how do I advertise the routes from the datacenter such that the default route 0/0 is brought to the datacenter and then routed accordingly.
I'm not sure I completely follow the routing topology.
Does the SRX iBGP peer to all the remote sites have the default route to the ISP in its route table?
If so, you could likely just add an route export term to send this default route down to the iBGP peers. Just insert this term into your existing route export policy.
set policy-options policy-statement YOUR-EXPORT-POLICY term default-export from route-filter 0.0.0.0/0 exact then accept
Neighbor relationship is only setup with the CPE at the site, although the srx's are in the same AS they are not setup as neighbors. The SRX in the datacenter has the default route to the ISP but the site SRX has a default route to the MPLS CPE router.
Hi every body,
I have a problem when config irb and bridge domain on logical system.
The diagram
irb.0 --- Router 1 (logical-system H1) ge1/1/1 --------------- Router 2 (logical-system H2) ge1/1/1 ---- irb.0
I config bridge domain on both router logical H1 and H2 through vlan-id 457 but i cant ping from irb.0 on logical H1 to irb.0 on logical H2. Please help me to check this issue.
Here is my config
On router 1
show
logical-systems {
H1 {
interfaces {
ge-1/1/0 {
unit 457 {
encapsulation vlan-bridge;
vlan-id 457;
}
unit 458 {
encapsulation vlan-bridge;
vlan-id 458;
}
}
ge-1/1/1 {
unit 457 {
encapsulation vlan-bridge;
vlan-id 457;
}
unit 458 {
encapsulation vlan-bridge;
vlan-id 458;
}
}
irb {
unit 457 {
family inet {
address 101.96.110.253/24 {
vrrp-group 1 {
virtual-address 101.96.110.1;
priority 250;
preempt {
hold-time 30;
}
accept-data;
}
}
}
}
unit 458 {
family inet {
address 101.96.111.253/24 {
vrrp-group 1 {
virtual-address 101.96.111.1;
priority 250;
preempt {
hold-time 30;
}
}
}
}
}
}
}
bridge-domains {
vlan-457 {
domain-type bridge;
vlan-id 457;
interface ge-1/1/0.457;
interface ge-1/1/1.457;
routing-interface irb.457;
}
vlan-458 {
domain-type bridge;
vlan-id 458;
interface ge-1/1/0.458;
interface ge-1/1/1.458;
routing-interface irb.458;
}
}
}
}
interfaces {
ge-1/1/0 {
vlan-tagging;
encapsulation flexible-ethernet-services;
}
ge-1/1/1 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
}
fxp0 {
unit 0 {
family inet {
address 10.20.2.1/24;
}
}
}
}
On router 2
show
logical-systems {
H2 {
interfaces {
ge-1/1/0 {
unit 457 {
encapsulation vlan-bridge;
vlan-id 457;
}
unit 458 {
encapsulation vlan-bridge;
vlan-id 458;
}
}
ge-1/1/1 {
unit 457 {
encapsulation vlan-bridge;
vlan-id 457;
}
unit 458 {
encapsulation vlan-bridge;
vlan-id 458;
}
}
irb {
unit 457 {
family inet {
address 101.96.110.254/24 {
vrrp-group 1 {
virtual-address 101.96.110.1;
priority 150;
preempt {
hold-time 30;
}
accept-data;
}
}
}
}
unit 458 {
family inet {
address 101.96.111.254/24 {
vrrp-group 1 {
virtual-address 101.96.111.1;
priority 150;
preempt {
hold-time 30;
}
}
}
}
}
}
}
bridge-domains {
vlan-457 {
domain-type bridge;
vlan-id 457;
interface ge-1/1/0.457;
interface ge-1/1/1.457;
routing-interface irb.457;
}
vlan-458 {
domain-type bridge;
vlan-id 458;
interface ge-1/1/0.458;
interface ge-1/1/1.458;
routing-interface irb.458;
}
}
}
}
interfaces {
ge-1/1/0 {
vlan-tagging;
encapsulation flexible-ethernet-services;
}
ge-1/1/1 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
}
fxp0 {
unit 0 {
family inet {
address 10.20.2.2/24;
}
}
}
}
[edit]
Hi,
Can you please check the state of the irb interfaces "show interfaces terse irb.*"
Are you able to ping the local irb interface IP address?
Cheers,
Ashvin
So if I understand correctly, the remote site SRX will already send all traffic via a default route to the datacenter MPLS router. Right? Or does this remote site default go somewhere else?
What routes does this device have for forwarding this traffic? Is there a default to send this somewhere and where?
I assume there is no neighbor relationship between the datacenter SRX with the ISP default and the datacenter MPLS router?
So here is a map of the basic layout.
Site SRX has the following static route 0.0.0.0/0 next-hop 172.16.0.110 which is to the AT&T MPLS router.
Site test config
system {
host-name TX03-FW-1;
auto-snapshot;
time-zone CST6CDT;
root-authentication {
}
name-server {
66.180.96.11;
64.238.96.11;
208.67.222.222;
208.67.220.220;
}
name-resolution {
no-resolve-on-input;
}
services {
ssh {
root-login allow;
protocol-version v2;
max-sessions-per-connection 32;
}
netconf {
ssh;
}
web-management {
management-url admin;
https {
system-generated-certificate;
interface [ vlan.0 fe-0/0/7.0 fe-0/0/6.0 ];
}
session {
idle-timeout 60;
}
}
dhcp {
pool 192.168.99.0/24 {
address-range low 192.168.99.60 high 192.168.99.200;
maximum-lease-time 86400;
default-lease-time 64800;
domain-name psscorp.local;
name-server {
10.10.100.40;
10.10.100.8;
}
router {
192.168.99.1;
}
boot-server 10.10.100.10;
option 160 ip-address 10.10.100.10;
propagate-settings vlan-trust;
}
}
}
syslog {
archive size 100k files 3;
inactive: user * {
any emergency;
}
file messages {
any critical;
authorization info;
}
file interactive-commands {
interactive-commands error;
}
inactive: file policy_session {
user info;
match RT_FLOW;
archive size 1000k world-readable;
structured-data;
}
inactive: file kmd-logs {
daemon info;
match KMD;
archive size 1000k world-readable;
structured-data;
}
file default-log-messages {
any info;
match "(requested 'commit' operation)|(copying configuration to juniper.save)|(commit complete)|ifAdminStatus|(FRU power)|(FRU removal)|(FRU insertion)|(link UP)|transitioned|Transferred|transfer-file|(license add)|(license delete)|(package -X update)|(package -X delete)|(FRU Online)|(FRU Offline)|(plugged in)|(unplugged)|GRES|(AIS_DATA_AVAILABLE)";
structured-data;
}
inactive: file web-filter-deny {
any any;
match WEBFILTER_URL_BLOCKED;
archive size 1m files 1 world-readable;
}
}
max-configurations-on-flash 5;
max-configuration-rollbacks 15;
license {
autoupdate {
url https://ae1.juniper.net/junos/key_retrieval;
}
}
ntp {
server 199.204.96.9;
}
}
interfaces {
interface-range interfaces-trust {
member fe-0/0/2;
member fe-0/0/3;
unit 0 {
family ethernet-switching {
vlan {
members vlan-trust;
}
}
}
}
fe-0/0/6 {
description "AT&T MPLS";
unit 0 {
family inet {
sampling {
input;
output;
}
address 172.16.0.109/29;
}
}
}
fe-0/0/7 {
description ISP2;
unit 0 {
family inet {
address 216.215.76.74/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.255.3/32;
}
}
}
vlan {
unit 0 {
family inet {
sampling {
input;
output;
}
address 192.168.99.1/24;
}
}
}
}
forwarding-options {
sampling {
input {
rate 100;
}
family inet {
output {
flow-server 192.168.99.107 {
port 2055;
version 5;
}
}
}
}
}
snmp {
community switch {
authorization read-only;
}
trap-group switch {
categories {
chassis;
link;
remote-operations;
routing;
rmon-alarm;
configuration;
}
targets {
10.10.100.29;
10.10.100.32;
}
}
trap-group space {
targets {
10.10.100.29;
}
}
}
routing-options {
graceful-restart;
static {
inactive: route 10.10.100.0/24 next-hop 172.17.0.1;
route 0.0.0.0/0 next-hop 172.16.0.110;
inactive: route 172.16.0.0/24 next-hop 172.16.0.110;
inactive: route 172.17.0.0/25 next-hop 172.16.0.110;
}
router-id 192.168.255.3;
autonomous-system 65001;
}
protocols {
bgp {
traceoptions {
file bgp-trace size 10k files 2 world-readable;
flag all detail;
flag keepalive;
}
group pss-att-bgp {
type internal;
export next-hop-self-policy;
neighbor 172.16.0.110;
}
}
lacp {
inactive: traceoptions {
file lacp-trace;
flag all;
}
}
stp {
disable;
}
}
policy-options {
policy-statement next-hop-self-policy {
term alter-next-hop {
from protocol direct;
then accept;
}
}
}
security {
inactive: log {
mode stream;
format sd-syslog;
stream JTAC-TEST {
host {
10.10.100.30;
}
}
}
address-book {
global {
address HOUDCTR 199.204.98.226/32;
address DATA_NET 192.168.99.0/24;
address-set REMOTE-SITES {
address HOUDCTR;
}
}
}
alg {
inactive: dns {
maximum-message-length 8192;
doctoring {
none;
}
}
mgcp disable;
msrpc disable;
sunrpc disable;
sql disable;
}
application-tracking;
flow {
inactive: traceoptions {
file JTAC size 1m;
flag basic-datapath;
packet-filter 1 {
source-prefix 10.11.11.9/30;
destination-prefix 8.8.8.8/32;
}
packet-filter 2 {
source-prefix 192.168.99.1/32;
destination-prefix 8.8.8.8/32;
}
packet-filter p1 {
source-prefix 192.168.99.100/32;
destination-prefix 23.2.199.148/32;
}
packet-filter p2 {
source-prefix 23.2.199.148/32;
destination-prefix 192.168.99.100/32;
}
}
allow-dns-reply;
sync-icmp-session;
tcp-mss {
all-tcp {
mss 1350;
}
ipsec-vpn {
mss 1350;
}
}
tcp-session {
no-syn-check;
no-sequence-check;
}
}
screen {
ids-option untrust-screen {
icmp {
ping-death;
}
ip {
source-route-option;
tear-drop;
}
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
timeout 20;
}
land;
}
}
}
nat {
source {
rule-set nsw_srcnat {
from zone Internal;
to zone Internet;
rule nsw-src-interface {
match {
source-address 0.0.0.0/0;
destination-address 0.0.0.0/0;
}
then {
source-nat {
interface;
}
}
}
}
}
}
policies {
from-zone Internal to-zone Internal {
policy Intra-Zone {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone Internet to-zone Internet {
policy Intra-Zone {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone Internal to-zone Internet {
policy All_Internal_Internet {
match {
source-address any;
destination-address any;
application any;
}
then {
permit {
inactive: application-services {
utm-policy pss-utm-policy;
}
}
log {
session-init;
session-close;
}
}
}
}
from-zone Internet to-zone Internal {
policy All_Internet_Internal {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
}
zones {
security-zone Internal {
host-inbound-traffic {
system-services {
all;
ike;
}
}
interfaces {
vlan.0 {
host-inbound-traffic {
system-services {
ping;
https;
ssh;
dhcp;
snmp;
}
}
}
}
}
security-zone Internet {
interfaces {
fe-0/0/6.0 {
host-inbound-traffic {
system-services {
ping;
http;
https;
ssh;
ike;
traceroute;
snmp;
}
protocols {
bgp;
}
}
}
lo0.0 {
host-inbound-traffic {
system-services {
ping;
}
protocols {
bgp;
}
}
}
}
}
}
}
firewall {
inactive: filter all {
term all {
then {
sample;
accept;
}
}
}
inactive: filter cflow {
term 1 {
then {
sample;
accept;
}
}
}
}
vlans {
vlan-trust {
vlan-id 3;
l3-interface vlan.0;
}
}
So in the ATT MPLS setup I assume this is a L3 VPN VRF for your traffic.
If that is the case you should be able to inject the default route from your data center SRX to the ATT peer at the data center. This will then become available at the remote site.
I further assume you added the static default route to the remote peer just to get the internet flowing into the MPLS connection. But since there was no default route learned from the data center this traffic basically blackholes at the remote MPLS router as a result.
Once you advertise the default route you should be able to remove the static one.
Hi,
An LSR would only look at the MPLS header to label-switch the packet, thus any CoS required needs MPLS EXP bits to be set.
As part of the CoS Configuration, you can configure and apply rewrite rules to mark/re-mark the packets accordingly on the egress interface such that Core facing MPLS interfaces gets MPLS EXP bits set based on the forwarding class the packet entered [either through BA or MF classifier].
Example:
class-of-service {
....
rewrite-rules {
exp CORE_EXP_REWRITE {
forwarding-class NC {
loss-priority low code-point 110;
}
}
}
interfaces x/x/x {
unit * {
classifiers {
exp BA_CORE_EXP_CLASSIFIER;
}
rewrite-rules {
exp CORE_EXP_REWRITE;
}
}
}
....
}When using MF classifier at the network edge [for example ingress PE], setting a DSCP marking would mark the IP header which may be left intact going through an MPLS core and be read and CoS treated on the egress PE which would look at the IP header.
Setting the forwarding-class would queue the packets and may be sufficient along with rewrite rules to EXP mark the MPLS header on MPLS core egress interfaces.
I also recommend as good practice to set the loss-priority in the MF classifier to avoid any mistreatment on the CoS path.
Worth noting also is that routing protocol traffic is marked with DSCP48 [ToS 0xc0] by default.
By wanting to put ldp traffic into an LSP, I guess you are referring to tLDP.
Cheers,
Ashvin
Thank you for your reply. I detected the problem is the link between two router. It works OK now.