BGP and NAT... interesting problem

Discussion in 'Cisco' started by Gollum, Dec 12, 2003.

  1. Gollum

    Gollum Guest

    Hi, I have a small problem with an eBGP peering accross a NATing
    firewall.... the routing updates can not be NATed, so the routes to the
    internal network are as good as garbage. I can fix this up with a static
    route and redistribute into BGP for propogation, but I only want to
    distribute this route *if* the correct internal route is present. I suspect
    that I could 'Match' the internal route somehow in a route-map attached to
    the 'redistribute static' statement, and only redistribute if internal route
    is present....... anyone done this? BTW this design gets worse as I have 4
    statefull firewalls in a line so I have to set MED, Local Pref.. redist into
    RIP on the inside (so set different hops etc)... my head hurts.
    Gollum, Dec 12, 2003
    #1
    1. Advertising

  2. In article <brc9ob$hg8$>,
    Gollum <> wrote:
    >Hi, I have a small problem with an eBGP peering accross a NATing
    >firewall.... the routing updates can not be NATed, so the routes to the
    >internal network are as good as garbage. I can fix this up with a static
    >route and redistribute into BGP for propogation, but I only want to
    >distribute this route *if* the correct internal route is present. I suspect
    >that I could 'Match' the internal route somehow in a route-map attached to
    >the 'redistribute static' statement, and only redistribute if internal route
    >is present....... anyone done this? BTW this design gets worse as I have 4
    >statefull firewalls in a line so I have to set MED, Local Pref.. redist into
    >RIP on the inside (so set different hops etc)... my head hurts.


    Point your statics to the the IP addresses learned via eBGP rather than
    the next hop. See the "Redundant Firewall" whitepaper on my website for
    an extreme example.

    Performance warning: in the absence of an interface changing state,
    static routes are only checked during per minute processing, so it could
    take up to a full minute (and 30 sec on average) for a route to get from
    BGP to your IGP.

    Good luck and have fun!
    --
    Vincent C Jones, Consultant Expert advice and a helping hand
    Networking Unlimited, Inc. for those who want to manage and
    Tenafly, NJ Phone: 201 568-7810 control their networking destiny
    http://www.networkingunlimited.com
    Vincent C Jones, Dec 12, 2003
    #2
    1. Advertising

  3. Gollum

    Gollum Guest

    "Vincent C Jones" <> wrote in message
    news:brcu1v$lv4$...
    > In article <brc9ob$hg8$>,
    > Gollum <> wrote:
    > >Hi, I have a small problem with an eBGP peering accross a NATing
    > >firewall.... the routing updates can not be NATed, so the routes to the
    > >internal network are as good as garbage. I can fix this up with a static
    > >route and redistribute into BGP for propogation, but I only want to
    > >distribute this route *if* the correct internal route is present. I

    suspect
    > >that I could 'Match' the internal route somehow in a route-map attached

    to
    > >the 'redistribute static' statement, and only redistribute if internal

    route
    > >is present....... anyone done this? BTW this design gets worse as I have

    4
    > >statefull firewalls in a line so I have to set MED, Local Pref.. redist

    into
    > >RIP on the inside (so set different hops etc)... my head hurts.

    >
    > Point your statics to the the IP addresses learned via eBGP rather than
    > the next hop. See the "Redundant Firewall" whitepaper on my website for
    > an extreme example.
    >
    > Performance warning: in the absence of an interface changing state,
    > static routes are only checked during per minute processing, so it could
    > take up to a full minute (and 30 sec on average) for a route to get from
    > BGP to your IGP.
    >
    > Good luck and have fun!
    > --
    > Vincent C Jones, Consultant Expert advice and a helping hand
    > Networking Unlimited, Inc. for those who want to manage and
    > Tenafly, NJ Phone: 201 568-7810 control their networking destiny
    > http://www.networkingunlimited.com


    So, the real route disappears and the recursive lookup nature of the static
    would fail, the route becomes invalid and redistribution will stop eBGP
    users of the NATed route seeing the route. Neat. I was going down the path
    of looking for the dynamic 'real' route 'match' this in a route map (x) and
    then set a community in the next sequence to match the NAT static route (y)
    and set a community value (aligned with no-advertise attribute in the
    outside eBGP router neighbour statement).

    route map NAT permit 10
    match IP x
    route map NAT permit 20
    match IP y
    set community nn

    Because route maps (unless you use the 'continue' feature) will exit after a
    'match' has been made, the static route should not be binned by the
    'no-advertise' as long as a dynamic route for the real address is
    available.... I have not tried this for real yet, but I think the theory
    holds good. What do you think Vincent?

    Richard
    Gollum, Dec 14, 2003
    #3
  4. In article <brhiig$k6a$>,
    Gollum <> wrote:
    >
    >"Vincent C Jones" <> wrote in message
    >news:brcu1v$lv4$...
    >> In article <brc9ob$hg8$>,
    >> Gollum <> wrote:
    >> >Hi, I have a small problem with an eBGP peering accross a NATing
    >> >firewall.... the routing updates can not be NATed, so the routes to the
    >> >internal network are as good as garbage. I can fix this up with a static
    >> >route and redistribute into BGP for propogation, but I only want to
    >> >distribute this route *if* the correct internal route is present. I

    >suspect
    >> >that I could 'Match' the internal route somehow in a route-map attached

    >to
    >> >the 'redistribute static' statement, and only redistribute if internal

    >route
    >> >is present....... anyone done this? BTW this design gets worse as I have

    >4
    >> >statefull firewalls in a line so I have to set MED, Local Pref.. redist

    >into
    >> >RIP on the inside (so set different hops etc)... my head hurts.

    >>
    >> Point your statics to the the IP addresses learned via eBGP rather than
    >> the next hop. See the "Redundant Firewall" whitepaper on my website for
    >> an extreme example.
    >>
    >> Performance warning: in the absence of an interface changing state,
    >> static routes are only checked during per minute processing, so it could
    >> take up to a full minute (and 30 sec on average) for a route to get from
    >> BGP to your IGP.
    >>
    >> Good luck and have fun!
    >> --
    >> Vincent C Jones

    >
    >So, the real route disappears and the recursive lookup nature of the static
    >would fail, the route becomes invalid and redistribution will stop eBGP
    >users of the NATed route seeing the route. Neat. I was going down the path
    >of looking for the dynamic 'real' route 'match' this in a route map (x) and
    >then set a community in the next sequence to match the NAT static route (y)
    >and set a community value (aligned with no-advertise attribute in the
    >outside eBGP router neighbour statement).
    >
    >route map NAT permit 10
    >match IP x
    >route map NAT permit 20
    >match IP y
    >set community nn
    >
    >Because route maps (unless you use the 'continue' feature) will exit after a
    >'match' has been made, the static route should not be binned by the
    >'no-advertise' as long as a dynamic route for the real address is
    >available.... I have not tried this for real yet, but I think the theory
    >holds good. What do you think Vincent?
    >
    >Richard


    While this would appear to work to prevent eBGP peers from learning the
    route, it does nothing to prevent the local routing engine from using
    it. Is that really what you want? Or were you applying this to incoming
    advertisements? You need to think through all the uses of the routing
    information, both interior and exterior, and verify that your approach
    does not leave any of them working incorrectly.
    --
    Vincent C Jones, Consultant Expert advice and a helping hand
    Networking Unlimited, Inc. for those who want to manage and
    Tenafly, NJ Phone: 201 568-7810 control their networking destiny
    http://www.networkingunlimited.com
    Vincent C Jones, Dec 17, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. harald rüger
    Replies:
    0
    Views:
    511
    harald rüger
    Oct 25, 2004
  2. Ivan Ostreš

    Interesting BGP peering

    Ivan Ostreš, Feb 19, 2005, in forum: Cisco
    Replies:
    4
    Views:
    662
    Ivan Ostreš
    Feb 22, 2005
  3. papi
    Replies:
    4
    Views:
    2,197
    theapplebee
    Sep 8, 2009
  4. Jim Westwood
    Replies:
    6
    Views:
    908
    Jim Westwood
    Oct 15, 2005
  5. G.G.

    Interesting nat problem

    G.G., Nov 30, 2005, in forum: Cisco
    Replies:
    2
    Views:
    411
Loading...

Share This Page