On Sun, May 30, 2010 at 10:16:14AM -0700, Kevin Oberman wrote:
I remember a posting to this list back in the late 90s from Tony Li,
who knows a bit about BGP. He urged that multi-hop BGP never be used
and pointed out that it had not been intended for use except as a test
tool, not a
On 28 May 2010, at 00:27, Ken Gilmour wrote:
ISP1 is the default gateway, ISP2 is a backup provider but which is always
active. Client comes in on ISP1's link, traffic goes back out on ISP1s link.
Client comes in on ISP2's link (non default gateway) but for some reason,
the packets seem to
You need to put a filter on your interfaces that references a filter later on
to not session track a flow. I think you need to be running Junos-jsr[0]
10.0 or 10.1 to use this :
The same goes for 9.x, just be sure to except traffic to the router
(like BGP session) from the packet-mode, they
* Rubens Kuhl:
You need to put a filter on your interfaces that references a
filter later on to not session track a flow. I think you need to
be running Junos-jsr[0] 10.0 or 10.1 to use this :
The same goes for 9.x, just be sure to except traffic to the router
(like BGP session) from the
your perfectly fine multihop BGP session could break when rerouting
occurs.
one of the many reasons that there are no perfectly fine multi-hop bgp
sessions.
randy
* Randy Bush:
your perfectly fine multihop BGP session could break when rerouting
occurs.
one of the many reasons that there are no perfectly fine multi-hop bgp
sessions.
Uhm, is there a way around them when building the iBGP mesh?
your perfectly fine multihop BGP session could break when rerouting
occurs.
one of the many reasons that there are no perfectly fine multi-hop bgp
sessions.
Uhm, is there a way around them when building the iBGP mesh?
nope
On Sun, May 30, 2010 at 1:46 PM, Florian Weimer f...@deneb.enyo.de wrote:
* Randy Bush:
your perfectly fine multihop BGP session could break when rerouting
occurs.
one of the many reasons that there are no perfectly fine multi-hop bgp
sessions.
Uhm, is there a way around them when
* Rubens Kuhl:
On Sun, May 30, 2010 at 1:46 PM, Florian Weimer f...@deneb.enyo.de wrote:
* Randy Bush:
your perfectly fine multihop BGP session could break when rerouting
occurs.
one of the many reasons that there are no perfectly fine multi-hop bgp
sessions.
Uhm, is there a way around
Date: Sun, 30 May 2010 18:39:39 +0200
From: Randy Bush ra...@psg.com
your perfectly fine multihop BGP session could break when rerouting
occurs.
one of the many reasons that there are no perfectly fine multi-hop bgp
sessions.
I remember a posting to this list back in the late 90s from
That would seem to be a good resolution (Firewall/NAT) . Aside from
that, perhaps a load
balancer for each segment might help?
One question that comes to mind is why (if ISP2 is a backup) would valid
traffic
be using that route?
Unless maybe your loadbalancing using a DNS round robin perhaps
On Thu, May 27, 2010 at 8:38 PM, Ken Gilmour ken.gilm...@gmail.com wrote:
Yes I believe that would be the default if the session was initiated on the
inside, but if it comes from outside on a particular interface which is not
the default route, why would the router then send the packet out
Ken Gilmour wrote:
ISP1 is the default gateway, ISP2 is a backup provider but which is always
active. Client comes in on ISP1's link, traffic goes back out on ISP1s link.
Client comes in on ISP2's link (non default gateway) but for some reason,
the packets seem to be going back out through the
Ken Gilmour wrote:
Yes I believe that would be the default if the session was initiated on the
inside, but if it comes from outside on a particular interface which is not
the default route, why would the router then send the packet out another
interface? Should the device not route session-based
Firewalls that can route and service properly multiple untrusts?
Good luck. Hit or miss. Constant flux.
Place a router in front of it and that will get you a ways there.
Ken Gilmour wrote:
Hi all,
I have a very peculiar situation here that i seem to have difficulty
explaining in such a way
:14 AM
To: Ken Gilmour
Cc: nanog@nanog.org
Subject: Re: Junos Asymmetric Routing
Firewalls that can route and service properly multiple untrusts?
Good luck. Hit or miss. Constant flux.
Place a router in front of it and that will get you a ways there.
Ken Gilmour wrote:
Hi all,
I have a very
Hi Jian,
Yes sir that's what I thought too. The packets are being NATted (and I also
used a bit of DNAT for port forwarding to test the theory) but the result is
the same.
Regards,
Ken
On 27 May 2010 23:46, Jian Gu guxiaoj...@gmail.com wrote:
Wouldn't simply configure source NAT on firewall
Hi Joe,
Interesting questions, Answers are below your questions:
On 28 May 2010 00:33, Joe Blanchard jbfixu...@gmail.com wrote:
That would seem to be a good resolution (Firewall/NAT) . Aside from that,
perhaps a load
balancer for each segment might help?
Possibly but this will cost money
not forwarding instance as in this
guide.
Jensen Tyler
Network Engineer
Fiberutilities Group, LLC
-Original Message-
From: Jensen Tyler [mailto:jty...@fiberutilities.com]
Sent: Friday, May 28, 2010 10:07 AM
To: Ken Gilmour
Cc: nanog@nanog.org
Subject: RE: Junos Asymmetric Routing
When
Hi Mark,
On 28 May 2010 06:37, Mark Hermsdorfer m...@hermsdorfer.net wrote:
Ken,
As others have pointed out typically interfaces are not kept track of in
state tables. Having said that, I've worked in the past with the ScreenOS
based SSG platforms that do this. So if you're coming from
Hi Jack
On 28 May 2010 07:08, Jack Bates jba...@brightok.net wrote:
Your BGP config with ISP2 is probably unideal. This has lead to packets
coming in via ISP2 despite the fact you prefer to use ISP1. Often, people
only do AS Prepend to alter traffic patterns. However, if a packet finds
it's
Hi Joe,
On 28 May 2010 08:13, Joe Maimon jmai...@ttec.com wrote:
Firewalls that can route and service properly multiple untrusts?
Good luck. Hit or miss. Constant flux.
Place a router in front of it and that will get you a ways there.
We replaced our OpenBSD routers with these SRXes
On Fri, May 28, 2010, Ken Gilmour wrote:
Yes sir I have used SSG for several years but mainly used BSD for the last
decade and most recently OpenBSD. There is an easy fix for this on PF for
OpenBSD and that is to tag the packets from each provider (as in not using
802.1q but a specific
We replaced our OpenBSD routers with these SRXes since they were supposed to
be multifunction devices (gateways and routers at the same time) which was
the selling point. So we expected them to do asymmetric routing and were
told they could, easily, but apparently they are not acting normally
Ken Gilmour wrote:
Strangely, BGP actually works without issues. The only issue is with
statically routed ranges.
Same rules apply, just without control on your end. If a packet hits
ISP2, ISP2 will send it to you by most ISP standards (prefer direct
customers over peers). Outbound, you
On 5/28/2010 07:37, Mark Hermsdorfer wrote:
Having said that, If the JunOS based SRX platform does not do session
tracking in the same was as the SSG platform it would seem that the most
reasonable solution would be to NAT the traffic as has already been pointed
out.
Gonna really highlight
Then you should look at your IGP, right?
On Fri, May 28, 2010 at 8:09 AM, Ken Gilmour ken.gilm...@gmail.com wrote:
Hi Jian,
Yes sir that's what I thought too. The packets are being NATted (and I also
used a bit of DNAT for port forwarding to test the theory) but the result is
the same.
* Ken Gilmour:
ISP1 is the default gateway, ISP2 is a backup provider but which is always
active. Client comes in on ISP1's link, traffic goes back out on ISP1s link.
Client comes in on ISP2's link (non default gateway) but for some reason,
the packets seem to be going back out through the
Hi all,
I have a very peculiar situation here that i seem to have difficulty
explaining in such a way for people to understand. I just got off the phone
to the Juniper Devs after about 4 hours with no result. They understand the
problem but can't seem to think of a working solution (last solution
Hi Ken,
Not sure if I correctly undestand you but default route its the route
that the packet must follow if it do not have a specific route for the
destination, so, if the next-hop for the source IP (3.3.3.3) is not in
the route table then the packet will follow the default route (ISP1).
So,
Hi Ken,
Not sure if I correctly undestand you but default route its the route
that the packet must follow if it do not have a specific route for the
destination, so, if the next-hop for the source IP (3.3.3.3) is not in
the route table then the packet will follow the default route (ISP1).
So,
Wow, very fast responses, Thanks Larry Sheldon and Ricardo Tavares!
On 27 May 2010 18:07, Ricardo Tavares curu...@gmail.com wrote:
Not sure if I correctly undestand you but default route its the route
that the packet must follow if it do not have a specific route for the
destination, so, if
On 2010-05-27 17:38, Ken Gilmour wrote:
Wow, very fast responses, Thanks Larry Sheldon and Ricardo Tavares!
On 27 May 2010 18:07, Ricardo Tavarescuru...@gmail.com wrote:
Not sure if I correctly undestand you but default route its the route
that the packet must follow if it do not have a
f the route announce is coming from the BGP neighbor you need to
verify if the next-hop indicated for this route is itself reached by
the router, if by recursion the router do not resolve how to go to the
next-hop then the announced route will be not available. THe bgp
sender must set the next-hop
On 5/27/2010 19:38, Ken Gilmour wrote:
Wow, very fast responses, Thanks Larry Sheldon and Ricardo Tavares!
On 27 May 2010 18:07, Ricardo Tavares curu...@gmail.com wrote:
Not sure if I correctly undestand you but default route its the route
that the packet must follow if it do not have a
Wouldn't simply configure source NAT on firewall 2.2.2.1 resolve the
problem gracefully? when connection requests coming in through ISP2,
source NAT the incoming traffic's source IP with IPs on firewall
inside interface, that way when server replies, firewall 2.2.2.1 will
guarantee to receive the
36 matches
Mail list logo
