SRX

Sanity check

I have interface ge-2/0/0 with vlan tagging and two sub interfaces assigned under this interface with vlan 101 and vlan 102.  Both of the subinterfaces are configured to connect to two different routers in the same AS with EBGP and both are sub interfaces are assigned to the untrust zone, I can communicate with machines behind router A and C from the SRX.  The only thing im having problems with is getting the routes of router C in router A and visa versa when it comes to Router C.    im thinking it has something to do with both of the subinterfaces being both in untrust zones.  I know the SRX is adveritising the routes it has learned from A and C to both routers but it seems that the two end routers only want to learn the direct/local subnets from the SRX.  For some reason im thinking maybe its because they are in both untrust zones, but I might be wrong.    Or do I need to make another export rule for the BGP routes?

Here is the general idea on what is configured 

(AS 7224) Router A --EBGP-- (ge2/0/0.1 untrust) SRX (ge2/0/0.2 untrust)  ---EBGP--Router C (AS 7224)

Hi Jasosullivan,

Issue is not related to both interface in the untrust zone.

Both A and C routers are in the same Autonomouse system (7224) , so in normal circumstance routes advertised by A will never be appearing on C and vice versa.  This is as per the BGP loop prevention mechanism. In fact in your current configuration firewall will never advertise the routes learned from A to C and vice versa.

But there are workaround to bypass these loop prevention mechanism, but gain at the cost of associated risk.

Flowing is one of the workaround.

Config on Firewall:

juniper@FIREWALL# show protocols BGP
group TEST {
neighbor x.x.x.x {
advertise-peer-as;
}
}

[edit]
juniper@FIREWALL#

Config on A and C:

juniper@A or C# show routing-options autonomous-system
100 loops 2;

[edit]
juniper@A or C#

Regards

Satinder Singh

What kind of relationship does router A have with router C? Are they IBGP peers? Share IGP domain? As Satin indicated, the default BGP route advertisement rules will prevent routes learned from an IGP peer to be readertised to an IBGP peer. In your case we do not know what relationship A have to C. If A and C are IBGP peers, they should be advertising the routes learned from the SRX which is external to both of them, and allow the route selection mechanism to do its thing. Moreover, Direct/Local routes have a preference of 0, which means they will always be the choice over other routng protocols. 

Thank you so much for the replies, they are in the same AS but they have no relashionship whats so ever so they have no connectivity to each other.

I will try out your suggestion monday when I get back to work and report back to you on my results!

Router A and C are not juniper routers

What protocol you are running between these 3 device?

(AS 7224) Router A --EBGP-- (ge2/0/0.1 untrust) SRX (ge2/0/0.2 untrust)  ---EBGP--Router C (AS 7224)

If I'm right you have problem with the BGP routes.

REgards

Satinder Singh

BGP between all three devices.  Router A and Router C have no idea about each other (they are virtual gateways with amazon AWS cloud enviroment)

Again here is the explaination of the problem:

Issue is not related to both interface in the untrust zone.

Both A and C routers are in the same Autonomouse system (7224) , so in normal circumstance routes advertised by A will never be appearing on C and vice versa.  This is as per the BGP loop prevention mechanism. In fact in your current configuration firewall will never advertise the routes learned from A to C and vice versa.

But there are workaround to bypass these loop prevention mechanism, but gain at the cost of associated risk.

Flowing is one of the workaround.

Config on Firewall:

juniper@FIREWALL# show protocols BGP 
group TEST {
neighbor x.x.x.x {
advertise-peer-as;
}
}

[edit]
juniper@FIREWALL#

Config on A and C:

juniper@A or C# show routing-options autonomous-system 
100 loops 2;

[edit]
juniper@A or C#

Regards

Satinder Singh

[quote]

Config on A and C:

juniper@A or C# show routing-options autonomous-system 
100 loops 2;

[edit]
juniper@A or C#

 [/quote]

I have enabled advertise-peer-as on both BGP sessions on the SRX, since the two end points are not a real router per say (Amazon AWS Virtual Private Gateway)

Hi,

Then here is the workaround, as-override feature will replace the peer AS with local AS

juniper@SRX-2# show protocols bgp
group TEST {
neighbor 1.1.1.1 {
as-override;
}
}

[edit]
juniper@SRX-2#

Regards

Satinder Singh

Thanks!  That seemed to push the routes out to both edge routers so im a little bit closer.  

I was doing a traceroute test from one interface to a machine on the other network 

root> traceroute source 169.254.255.74 10.2.3.5  
traceroute to 10.2.3.5 (10.2.3.5) from 169.254.255.74, 30 hops max, 40 byte ets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *

The traceroute above shows the source on the interface router c is plugged into trying to reach 10.2.3.5. located behind router a.  I know that 10.2.3.5 is up and running because I can ssh into it from the SRX console

Here is a show route from the srx

root> show route

inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.2.3.0/24 *[BGP/170] 00:42:08, localpref 100
AS path: 7224 I

So it does see the 10.2.3.0/24 network but for some reason it doesnt seem to want to route past the interface plugged into the C router

169.254.255.74????

Yes as I have said this is with Amazon AWS Direct Connect service, so APIA addresses. We have a drop directly into amazon AWS cloud enviroment in our cage

http://aws.amazon.com/directconnect/

full routing table

root# run show route

inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.2.3.0/24 *[BGP/170] 01:05:45, localpref 100
AS path: 7224 I
> to 169.254.255.77 via ge-2/0/0.1
10.2.4.0/23 *[BGP/170] 01:05:31, localpref 100
AS path: 7224 I
> to 169.254.255.73 via ge-2/0/0.0
10.2.6.0/30 *[Direct/0] 04:20:00
> via ge-0/0/0.0
10.2.6.1/32 *[Local/0] 1w0d 00:03:53
Local via ge-0/0/0.0
169.254.255.72/30 *[Direct/0] 1w0d 00:03:43
> via ge-2/0/0.0
169.254.255.74/32 *[Local/0] 1w0d 00:03:48
Local via ge-2/0/0.0
169.254.255.76/30 *[Direct/0] 5d 05:41:21
> via ge-2/0/0.1
169.254.255.78/32 *[Local/0] 5d 05:41:21
Local via ge-2/0/0.1
192.168.1.0/24 *[Direct/0] 6d 01:24:38
> via lo0.0
192.168.1.1/32 *[Local/0] 6d 01:24:38
Local via lo0.0

ok. Great information to know. Thanks. try this:

traceroute source interface ge-x/x/x.unit 10.2.3.5 

see if the trace is successful from the interface connecting to AWS. If that is Okay, then you could see if adding the 169/8 orlonger to martians specifically may help. This is not familiar teritory for me but I am always interested in anything SP related and anything new like this. It is not disallowed by default, but then it came in much later than when Juniper started the use of martians. BTW, do you know of others who use AIPA to connect to the AWS?

>show route 10.2.3.0/24

Which interface and next-hop to this destination? Is it correct?

root> show route 10.2.3.0/24

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.2.3.0/24 *[BGP/170] 15:58:38, localpref 100
AS path: 7224 I
> to 169.254.255.77 via ge-2/0/0.1

The interface is correct, it just seems the SRX doesnt want to route the traffic between router A and C

root# run show bgp summary
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
2 2 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
169.254.255.73 7224 2070 2209 0 2 16:28:15 1/1/1/0 0/0/0/0
169.254.255.77 7224 2062 2193 0 2 16:28:29 1/1/1/0 0/0/0/0

root# run show bgp neighbor
Peer: 169.254.255.73+179 AS 7224 Local: 169.254.255.74+64709 AS 65000
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: Hold Timer Expired Error
Export: [ ebgp-export bgp-export1 ]
Options: <Preference AuthKey AddressFamily PeerAS LocalAS Refresh As Override>
Options: <AdvertisePeerAs PeerSpecficLoopsAllowed>
Authentication key is configured
Address families configured: inet-unicast
Holdtime: 90 Preference: 170 Local AS: 65000 Local System AS: 100
Number of flaps: 2
Last flap event: HoldTime
Error: 'Hold Timer Expired Error' Sent: 2 Recv: 0
Peer ID: 169.254.255.73 Local ID: 192.168.1.1 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
Local Interface: ge-2/0/0.0
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 7224)
Peer does not support Addpath
Table inet.0 Bit: 10001
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 3
Last traffic (seconds): Received 8 Sent 17 Checked 33
Input messages: Total 2071 Updates 4 Refreshes 0 Octets 39475
Output messages: Total 2209 Updates 8 Refreshes 0 Octets 42362
Output Queue[0]: 0

Peer: 169.254.255.77+49645 AS 7224 Local: 169.254.255.78+179 AS 65001
Type: External State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: Hold Timer Expired Error
Export: [ ebgp-export bgp-export ]
Options: <Preference AuthKey AddressFamily PeerAS LocalAS Refresh As Override>
Options: <AdvertisePeerAs PeerSpecficLoopsAllowed>
Authentication key is configured
Address families configured: inet-unicast
Holdtime: 90 Preference: 170 Local AS: 65001 Local System AS: 100
Number of flaps: 2
Last flap event: HoldTime
Error: 'Hold Timer Expired Error' Sent: 2 Recv: 0
Peer ID: 169.254.255.77 Local ID: 192.168.1.1 Active Holdtime: 90
Keepalive Interval: 30 Peer index: 0
BFD: disabled, down
Local Interface: ge-2/0/0.1
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 7224)
Peer does not support Addpath
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 3
Last traffic (seconds): Received 26 Sent 15 Checked 22
Input messages: Total 2062 Updates 2 Refreshes 0 Octets 39261
Output messages: Total 2193 Updates 4 Refreshes 0 Octets 41862
Output Queue[0]: 0

[edit]
root#

policy-statement bgp-export {
from {
protocol bgp;
route-filter 10.2.4.0/23 exact accept;
}
then accept;
}
policy-statement bgp-export1 {
from {
protocol bgp;
route-filter 10.2.3.0/24 exact accept;
}
then accept;
}
policy-statement ebgp-export {
from {
protocol [ direct local static ];
route-filter 10.2.6.0/30 exact accept;
route-filter 192.168.1.0/24 exact accept;
}
then accept;
}

root# show protocols
router-advertisement {
interface em0.0;
}
bgp {
family inet {
unicast {
loops 2;
}
}
group external-peers {
type external;
advertise-peer-as;
authentication-key "nothing"; ## SECRET-DATA
export [ ebgp-export bgp-export1 ];
peer-as 7224;
local-as 65000;
neighbor 169.254.255.73 {
as-override;
}
}
group external-peer1 {
type external;
advertise-peer-as;
authentication-key "nothing"; ## SECRET-DATA
export [ ebgp-export bgp-export ];
peer-as 7224;
local-as 65001;
neighbor 169.254.255.77 {
as-override;
}
}
}
stp;